Four Days on a Borrowed Key: The BigCommerce Ribon Breach and the App You Forgot You Installed

17:21 BST on Sunday, 13 September. That's when, according to the notice Master of Malt sent its customers, someone started using a BigCommerce application key that belonged to a marketing app called Ribon. Access stopped at 21:12 BST on Thursday, 17 September, when BigCommerce pulled the app from affected stores. Call it just under 100 hours.

Nobody broke into BigCommerce. Nobody phished a Master of Malt employee. Nobody guessed a password. The attackers held a key that the store had already agreed to trust, and they used it the way it was designed to be used.

I spend most of my week looking at OAuth grants and service accounts in SaaS tenants, and this is the incident I'll be pointing customers at for the rest of the year. Not because it's large. Because every reassuring sentence in the disclosures is technically true and still misses the point.

What we actually know

Here's what holds up across BleepingComputer, The Register and GBHackers, all working from BigCommerce's statement and Master of Malt's customer email:

• Ribon and Ribon 1.5 are BigCommerce marketplace apps owned and operated by Be A Part Of, a Fastr brand. They sell "shopping experience optimization," which typically means scripts running on the storefront.
• BigCommerce said credentials belonging to those two apps "had been compromised and used to inject malicious scripts into a small number of merchant storefronts."
• The exposed shopper data was full names, email addresses, phone numbers and shipping addresses. Master of Malt says passwords and payment details sit in a separate system and weren't touched.
• BigCommerce confirmed the compromise on 17 September and uninstalled the apps the same day. Master of Malt says the platform told it on 18 September, and founder Justin Petszaft emailed customers that evening.
• Master of Malt reported to the UK Information Commissioner's Office. GBHackers cites an ICO case reference issued on 19 September.
• BleepingComputer notes that BigCommerce supports more than 1,200 third-party apps. Master of Malt told customers Ribon was installed on hundreds of stores.

What we don't know matters just as much. Be A Part Of and Fastr hadn't commented at the time of writing. Nobody has said how the key left the developer's hands, whether it was a per-store token or something broader, or how many merchants actually had scripts injected. Law firm Emery Reddy says "several retailers" are notifying customers. Master of Malt is the only one named so far.

So I won't speculate about the theft. I'll look at the four phrases every merchant on any SaaS commerce platform is going to hear the next time this happens, and what each one leaves out.

"The BigCommerce platform was not breached"

True, and it's the sentence I'd most like to retire.

When you install a marketplace app, you hand its developer a credential that can act on your store. On BigCommerce, that's an OAuth flow at install time that issues the app an access token scoped to whatever permissions you clicked through. The token lives on the developer's infrastructure, not yours. You can't see where it's stored, who at the vendor can read it, or whether it ended up in a CI variable, a support engineer's laptop or a config file in a repo.

That's the model across Shopify, Salesforce, Microsoft 365 and Google Workspace too. The platform's perimeter can be perfect while your effective perimeter includes every vendor you've ever granted a scope to. The platform wasn't breached. Your trust graph was. It's the same pattern behind the Storm-3168 service principal secret that sat in a GitHub edit history: a non-human identity with real permissions, stored somewhere the owner of the data never looks.

The uncomfortable part is what "removing the app" actually meant here. BigCommerce had to uninstall Ribon from stores to cut off access. That tells you the credential was valid until the install relationship ended. There was no merchant-side setting that would have expired it on Monday morning.

"Payment card data was not exposed"

Also true, and also narrower than it sounds.

Names, emails, phone numbers and delivery addresses are the raw material for the next stage, not the end of the attack. Emery Reddy's warning to affected retailers was about phishing, and they're right to lead with it. Think about what an attacker can send now: a message to a named customer, at their real address, referencing a real order from a real whisky retailer, maybe with a "your delivery failed, confirm your card" link. That email won't trip anyone's suspicion. The shopper bought from that store last month.

We saw the same reasoning in the Gyazo breach, where a password reset couldn't undo session tokens already in the wild. The data that leaves isn't the damage. It's the setup for credential theft that happens weeks later, against people who never heard of Ribon.

And there's a second question nobody has answered publicly: what did the injected scripts do? BigCommerce's statement says "malicious scripts." A script on a storefront page can read what the shopper types into that page. Master of Malt says payment details live in a separate system, which usually means a hosted payment step on a different origin. If that's true for every affected store, card data was out of reach. If some of those "hundreds of stores" took card input on a page where Ribon's script also ran, the answer could be different. I'd want to see that confirmed per merchant, not per platform.

"A small number of merchant storefronts"

Small compared to what?

Master of Malt told customers Ribon was on hundreds of stores. BigCommerce says a small number had scripts injected. Both can be true: the key may have opened every store, and the attackers may have chosen a handful. That's actually the more worrying reading. It means they had a list, and they picked targets.

From the defender's side, it also means the blast radius wasn't defined by the attacker's restraint. It was defined by the scopes. An app that needs to place a script on your storefront and read customer records holds the two permissions a skimming crew most wants. When I review app grants for customers, those two together are the pair I flag first. Most merchants approve them because the app's marketing dashboard needs customer data to show "personalized" recommendations. Fair enough. But you should know you've approved it, and you should know when you last checked.

Here's an edge case I keep hitting in tenant reviews: the app is still installed, but nobody on the current team installed it. The marketing manager who trialled it left two years ago. The vendor got acquired, as Be A Part Of was by Fastr, and the app now reports to a company you never assessed. The scopes still work. That's a credential with no human owner on your side, which is the exact class of identity we keep warning about in posts like SalesBleed and the agent identity problem.

"There is no ongoing compromise"

This is the one Master of Malt passed on from BigCommerce, and I believe it as far as the Ribon key goes. The app is gone. That specific credential can't touch the store.

But think about what the merchant actually learned, and when. Access began on a Sunday evening. The merchant found out Friday. That's not a criticism of Master of Malt; there's nothing in a standard merchant setup that would have told them sooner. The calls came through a legitimate app, with a legitimate token, against legitimate API endpoints. Rate limits weren't the issue. Authentication succeeded. Every log line looks like Ribon doing Ribon's job.

This is where I think most incident write-ups go wrong. They frame detection as a logging problem: if only the merchant had pulled API logs into a SIEM. Fine, do that. But tell me what rule you'd write. "Alert when an installed, authorized app reads customer records" fires every day the app works. "Alert when an app adds a storefront script" fires every time the vendor ships an update. You'd end up tuning both into silence, and the attacker would be inside that silence.

The only signals that cleanly separate an attacker from the app are ones the real app would never produce.

Where a decoy beats a log

That's the deception argument, and this breach makes it unusually concrete.

Seed customer records that no real process should ever contact. Create a handful of decoy customers in your store: real-looking names, delivery addresses at locations you control, and email addresses and phone numbers on mailboxes and lines you monitor and that exist nowhere else. No real marketing campaign targets them, because you exclude them from every segment. If one of those inboxes gets a "delivery failed" phish, the data left your store, and you know which store and roughly when. You'd also have your own evidence, instead of waiting for the vendor's notice to reach you. In a four-day window like Ribon's, that inbox could plausibly light up before the platform's email does, because phishing crews move fast once a customer list exists.

Plant a canary credential where your vendors' credentials live. If your team keeps app keys, API tokens or webhook secrets in a password manager vault, a shared drive or a CI config, put a decoy key next to them. Mine2's honeytokens and decoy credentials are built for this: nothing legitimate ever uses them, so a single authentication attempt is a confirmed incident, not a maybe. You can't put a decoy inside Fastr's infrastructure. You can put one everywhere your own copies of third-party secrets sit, which is where most of these thefts actually start.

Watch for script changes you didn't schedule. This one isn't a decoy, it's a tripwire. Keep a known-good inventory of storefront scripts and diff it daily. When an app vendor ships an update, you'll get a change you expected. When someone else ships one, you'll get a change you didn't.

The first two produce zero noise by design. That matters more than it sounds. The BigBear 2.0 kit we covered in September actually tries to detect and strip canary tokens, which tells you attackers already treat decoys as a real threat to their operations. They wouldn't write that code otherwise.

What I'd do this week if I ran a BigCommerce store

Not a framework. Five things, in order:

1. Export your installed app list and put a name next to each one. If no current employee can say why an app is there, uninstall it. The token dies with the install.
2. Read the scopes. Any app with both storefront script access and customer read access goes on a shortlist. For each one, ask whether the feature you actually use needs both.
3. Ask each shortlisted vendor three questions in writing: where is our store's token stored, who can read it, and how will you tell us if it's exposed? Silence is an answer.
4. Baseline your storefront scripts and set up the daily diff.
5. Seed decoy customer records with monitored contact details, excluded from every marketing segment.

If you were a Ribon customer, add a sixth: assume the customer list is out there, and warn shoppers now about order-themed phishing that uses their real details. Telling them which store and which week is more useful than a generic "be vigilant."

The part that bothers me

The Ribon key did what it was built to do. It authenticated, it read customer data, it placed scripts on storefronts. The attacker didn't need an exploit, an encoded path or a zero-day. They needed one secret, held by a vendor most of those merchants probably hadn't thought about since installation day.

We've built a whole industry around stopping people from breaking in. Third-party app keys are the clearest case I know of where nobody has to. The merchant's best chance is to own a few things that only an intruder would ever touch, and to hear about it the minute they do. If you want to see what that looks like for your own store and vendor credentials, book a Mine2 demo and we'll walk through placing the first decoys with your team.