For several days in mid-September, the credentials for the Ribon and Ribon 1.5 apps, operated by Be A Part Of, a Fastr company, were in the wrong hands. BigCommerce confirmed the compromise on 17 September, uninstalled the apps from affected stores, and started notifying merchants the following day.
No user was phished. Nobody's password was guessed. A key that belonged to an application did the work.
What Happened
Here is the sequence, newest first, as reported by SecurityWeek, BleepingComputer and the affected merchant Master of Malt, whose technical write-up is the most detailed account so far.
- 22 September: SecurityWeek reports it is still unclear how Ribon was compromised. Neither Be A Part Of nor Fastr had publicly acknowledged the incident.
- 18 September: BigCommerce begins notifying merchants, after the key is disabled and the Ribon apps are uninstalled.
- 17 September: the compromised key is revoked, a day after Ribon's developers became aware of misuse. BigCommerce confirms the credential compromise.
- 13–17 September: attackers use the compromised key to access customer data, pulling records down page by page.
The exposed fields were names, email addresses, phone numbers and addresses. BigCommerce has said account passwords and payment card details were not exposed. The credentials were also used to inject malicious scripts into a small number of storefronts. The apps were installed on hundreds of stores, out of more than 1,200 third-party apps the platform supports. BigCommerce attributes the compromise to a Fastr system compromise and maintains that its own platform was not breached.
Why This Is an Identity Problem, Not a Retail One
An application key is a non-human identity with standing access. It has no password to phish, no MFA prompt, no device to check and no working day. It authenticates correctly every time it is used, from wherever it is used.
That is what makes this hard to see. Every request was authenticated. Every request was, as far as the platform could tell, authorised. A bulk pull of customer records by an installed app looks a lot like an installed app doing its job, unless someone is watching how much it reads and in what pattern.
The compromised credentials were used for two quite different things: reading customer data, and changing what runs on storefront pages. Those are very different powers. It is worth asking whether a shopping-experience app needs both on one credential.
Accountability is split, too. BigCommerce's position is that these apps are independently installed by merchants, with the relationship sitting between merchant and app. It also uninstalled the apps, notified merchants directly and provided log data to support the developer's investigation. Both can be reasonable. The practical result is that a merchant inherits the risk of a vendor it chose at install time, and usually has little visibility into how that vendor protects the keys it holds.
The Questions This Should Put on Your List
These are worth asking on Monday morning, by a CISO or by a board:
- How many third-party apps and integrations hold credentials into our core platforms, and who owns each one?
- What can each of them read and write, and does it need all of it?
- Where do their keys live, and when were they last rotated?
- Would we notice an authorised app pulling records in bulk, in order, at an odd hour?
- How quickly can we cut one app's access everywhere, and how would we know what it touched?
- What do we ask of an app vendor before it is allowed near customer data?
Five Practical Priorities
1. Inventory delegated access
Every OAuth grant, app key and API token that reaches a core platform, with an owner, a scope and a last-used date. Unused grants are the cheapest risk you will ever remove.
2. Scope to the task
Prefer read-only where the app only reads. Where an app needs both data access and the ability to change what runs on a page, ask whether those can sit on separate credentials.
3. Favour short-lived over long-lived
Rotate keys on a schedule you can defend, keep them in a vault, and use short-lived tokens where the platform supports them. A key that has been valid for three years has had three years to leak.
4. Watch authorised behaviour, not just failed logins
Baseline how much each app normally reads and when. Bulk, sequential reads, new source addresses, or activity outside the app's usual hours deserve an alert even when every call is valid.
5. Practise revocation
Keep a runbook for cutting one app's access across every platform it touches, plus a way to see afterwards what it read and changed. For storefronts and customer-facing pages, review injected script entries and keep an allow-list of script sources, so an unexpected one stands out.
The Trevonix Perspective
At Trevonix, we treat third-party access as an identity problem first. An app key, a service account and an AI agent's connector are the same thing in different clothes: a non-human identity that needs an owner, a purpose, a lifecycle and an expiry date. Most organisations govern their people carefully and their third-party and supply chain identities much less so.
The pattern will not stay confined to e-commerce plug-ins. Every integration approved for a CRM, an identity provider or an AI assistant adds another credential that someone else is responsible for protecting. As that list grows, the useful question moves from "who logged in" to "what is allowed to act on our behalf, and who knows about it". That is the ground covered by identity for AI and non-human identities.
Key Takeaways
- Attackers used compromised credentials for two third-party apps, Ribon and Ribon 1.5, to access customer data and inject scripts into BigCommerce storefronts.
- BigCommerce says its own platform was not breached and attributes the compromise to a Fastr system compromise.
- Access ran from 13 to 17 September, when the key was revoked.
- App keys are identities. They need owners, scopes, rotation and behavioural monitoring.
- Revocation speed, and knowing what an app touched, matter as much as prevention.
Source Credits: SecurityWeek, BleepingComputer, Master of Malt, SC Media
