A stolen Ribon app key pulled BigCommerce shopper data in one evening, then stayed live almost four days

Four and a half hours to take the records, four days to switch off the key

At one UK retailer, the attacker's download took 4 hours 27 minutes. Master of Malt's technical timeline says someone used a stolen key belonging to the Ribon app to page through its customer records between 6:21pm and 10:48pm BST on Sunday 13 September 2026. The same timeline says the key was switched off at 10:12pm on Thursday 17 September. That is 95 hours 24 minutes after the download finished, and 25 hours 27 minutes after the app's developer, by the retailer's account, already knew the key had been misused.

BigCommerce, the ecommerce platform the retailer runs on, told BleepingComputer that credentials for the third-party apps Ribon and Ribon 1.5, operated by Be A Part Of, a Fastr company, were compromised and "used to inject malicious scripts into a small number of merchant storefronts". BigCommerce says its own systems were not breached, that it uninstalled the app from affected stores and notified those merchants, and that passwords and payment card data are stored separately and were not exposed.

This briefing sets out what each party has actually said, how a marketplace app on BigCommerce gets to shopper data in the first place, why the merchant could not have switched the key off itself, and what a UK merchant that is the data controller should take from the contract it signed.

What is on the record, and from whom

Four parties have something to say about this incident, and only two have said it in public. The table separates what each has stated from what it has left out.

Who has said what about the Ribon incident, as of 22 September 2026. Sources: BigCommerce statement to BleepingComputer (21 September), Master of Malt's notice and technical page (updated 19 and 20 September), Emery Reddy (18 September).

Party	What it has stated	What it has not stated
BigCommerce (now trading under parent brand Commerce)	Ribon and Ribon 1.5 credentials compromised, confirmed 17 September; scripts injected into a small number of storefronts; app uninstalled from affected stores; merchants notified; log data given to the developer; platform not breached; passwords and card data stored separately	How many stores; which scopes Ribon held; what the scripts did; whether customer records were read through its APIs; any public notice to merchants on its own site
Master of Malt (UK merchant)	Key used 13 September 6:21pm to 10:48pm BST to download names, emails, phones, addresses; key revoked 17 September 10:12pm; told by BigCommerce by email at 1:30am on 18 September; customers emailed and ICO told the same day	How the key was stolen (it says it does not know); how many of its customers were affected
Be A Part Of / Fastr (developer)	No public statement found. Master of Malt reports an email from the Fastr chief executive at 6:55pm on 18 September confirming the compromise	Root cause, scope, number of installs, timeline of its own detection
Emery Reddy (US law firm)	Several retailers are notifying customers; seeks claimants	Names of the retailers; any figure it has verified (it says it has not independently verified the retailers' claims)

BleepingComputer's report also says the attacker accessed shopper data "between September 13 and September 17". That span is the window during which the key was live. Master of Malt's own logs put the actual download at its store inside a single evening. The broader window matters for other merchants, who should search their own logs across all five days, not only on the Sunday evening.

Two different harms under one headline

Read side by side, the two public accounts describe two different things done with the same stolen credential.

BigCommerce describes script injection. Its statement says the credentials were used to inject malicious scripts into storefronts. BigCommerce's Scripts API documentation explains how an app does this legitimately: an app can add up to 10 scripts of its own to a storefront, placed on all pages, storefront pages, checkout or the order confirmation page, and associating a script with checkout needs the "Modify Checkout Content" scope. Scripts an app adds can only be modified by the API account that created them, though control panel users can delete them in Script Manager. BigCommerce has not said where the malicious scripts were placed or what they collected.

Master of Malt describes a bulk read. Its technical page says the key was used "to download customers' personal data, working through them page by page". That is an API read of stored records, not a script running in a shopper's browser. It lists what was not taken: passwords, card numbers, the products in each order, and delivery addresses where these differed from the billing address. Master of Malt does not mention script injection on its own storefront, but lists new automated alerting on any script change among its fixes.

Our inference, labelled as such: the data set Master of Malt lists, contact and billing details without order line items or separate delivery addresses, is consistent with a read of customer or order header records through the REST management APIs. Neither company has named the endpoints or scopes, so this is a reading of the published field list, not a finding.

How a marketplace app gets to shopper data

BigCommerce says it supports more than 1,200 third-party applications and integrations. The mechanics that let any one of them read a store's customers are set out in BigCommerce's own developer documentation, and they explain most of what happened next.

Install is all or nothing. The app authentication guide says the OAuth consent view "requires them to approve all the scopes to install the app" and that "merchants cannot pick and choose scopes". A merchant who wants a personalisation widget accepts whatever customer, order or content permissions the developer has configured.

The developer holds the token, not the merchant. On install, BigCommerce runs a grant code flow and returns an access token unique to that store, which the app saves on its own infrastructure. The guide calls it "semi-permanent". An app installed on, say, 500 stores therefore holds 500 live tokens, plus the client secret that identifies the app. Master of Malt's phrase, "a BigCommerce Application key held by Ribon", fits either the secret or a token store; which one leaked is not stated.

Tokens do not expire, and cannot be revoked by hand. The API accounts guide says access tokens "do not expire based on time and cannot be manually invalidated", and for app-level accounts that "There is no way to manually revoke or force-regenerate" the tokens. A refresh is triggered only when the store owner's email changes or the developer changes the app's scopes, after which the merchant is asked to reauthorise. That is why BigCommerce's remedy was to uninstall the app from affected stores: removing the installation is the lever that exists.

Put together, the model concentrates standing access to many merchants' customer data in the app developer's environment. The merchant can see an app's scripts in Script Manager and can uninstall the app, but, by Master of Malt's account, could not see the key being used: "Only the app's developer or BigCommerce could see that it was being misused, or switch it off."

Three comforting phrases, and what each one covers

Each party's statement contains a phrase that is accurate and still leaves the reader less informed than it sounds.

Comforting labels in the Ribon statements, and the gap each one leaves. Sources: BigCommerce statement to BleepingComputer; Master of Malt notices; Be A Part Of website; BigCommerce developer documentation.

Label	What it establishes	What it does not establish
"Our systems or the BigCommerce platform were not breached" (BigCommerce)	No intrusion into BigCommerce infrastructure is claimed	That the platform did not serve the data. Its APIs answered a valid token as designed; the control that failed was around the token
"Passwords and payment card information are stored separately" (BigCommerce, Master of Malt)	The records read through the API did not include them	What injected storefront scripts could observe while live; BigCommerce has not said where they ran
"Certified BigCommerce Partner since 2009" (Be A Part Of's website)	A long commercial relationship with the platform	Anything about how the developer stored app credentials, monitored their use, or how fast it revokes
"Curated" app marketplace (how 2024 press coverage described it)	The app was listed through BigCommerce's process	That listing checks the developer's operational security after approval

None of these labels is a control. The controls that would have changed the outcome are scope minimisation, token storage and rotation at the developer, anomaly detection on bulk reads, and a revocation path the merchant can pull. Master of Malt's post-incident list reads like that inventory: it is auditing every other app's permission scope and has added alerts for bulk customer downloads, new source networks, and script changes.

Where the hours went

Master of Malt published an unusually precise timeline. We have taken its technical page as the reference and computed the gaps between steps.

Three gaps stand out. Detection: 74 hours 24 minutes passed between the first request and the developer being aware of misuse, and nothing in the record says who detected it. Containment: a further 25 hours 27 minutes passed before the key was switched off. Notification: the merchant learned 111 hours 31 minutes after the first request, by an email sent at 1:30am that Master of Malt says was not marked high priority, with no phone call. Master of Malt's own response, once it knew, was quick: customers were emailed 7 hours 53 minutes after it opened BigCommerce's email, and the ICO report went in within about 9 hours.

This shape has happened before

The pattern of a trusted integration's credentials being turned against every customer that installed it is not new, on BigCommerce or elsewhere.

FreshClick on BigCommerce, 2024. According to ZAGG's customer letter as quoted by BleepingComputer in December 2024, an unknown actor injected code into the FreshClick app that scraped card data at checkout on zagg.com between 26 October and 7 November 2024. BigCommerce said then that it had verified the app was compromised and "immediately uninstalled the app in their stores". We could not reach ZAGG's regulator filing directly, so this rests on secondary reporting of its letter. The remedy, uninstall across stores, was the same as in September 2026.

Salesloft Drift and Salesforce, 2025. Google Threat Intelligence reported on 26 August 2025 that the actor it tracks as UNC6395 used compromised OAuth tokens for the Salesloft Drift integration to export large volumes of data from numerous corporate Salesforce instances between 8 and 18 August 2025, and then searched the haul for secrets such as AWS keys and Snowflake tokens. It states that on 20 August 2025 Salesloft, with Salesforce, "revoked all active access and refresh tokens with the Drift application". Salesloft's trust centre summary of Mandiant's investigation puts the intrusion timeline from 22 March to 5 September 2025, including use of Salesloft GitHub personal access tokens and exfiltration of environment variable secrets.

Three integration compromises compared. Sources: Google Threat Intelligence and Salesloft trust centre for Drift; BleepingComputer's reporting of ZAGG's letter for FreshClick; BigCommerce and Master of Malt for Ribon.

Incident	What the attacker held	How access was cut	Root cause published?
FreshClick, BigCommerce, 2024	A path to inject code into the app's storefront script	BigCommerce uninstalled the app from stores	Not stated in the sources we reached
Salesloft Drift, Salesforce, 2025	OAuth access and refresh tokens held by Drift	Salesloft and Salesforce revoked all Drift tokens on 20 August 2025	Yes: Mandiant summary, GitHub tokens and exfiltrated secrets
Ribon, BigCommerce, 2026	A BigCommerce application key held by Ribon	BigCommerce uninstalled the app; key revoked 17 September	No: developer still investigating

The comparison is about mechanism, not blame. In each case the platform's own authentication worked as designed; the credential sat with a third party whose environment was the weak point. The difference in the Salesforce case is that the platform and vendor could revoke every token for the integration in one action. BigCommerce's documentation describes no equivalent revocation for app tokens, so uninstalling was the path it took.

The UK angle: whose processor is Ribon?

A common assumption is that an app installed from the platform's marketplace sits under the platform's data processing terms, as a sub-processor. BigCommerce's contract says otherwise. The Commerce data processing addendum, last revised 14 May 2026, defines Subprocessor as an entity appointed by a Commerce entity and "excludes ... third-party apps in a Commerce entities app marketplace". It also says a Commerce entity "shall not be liable for any Security Incident caused by Customer or by any third-party integrations or services elected by Customer". Its own 72-hour incident notice commitment covers incidents in the processing it does.

The consequence for a UK merchant is that its relationship with Ribon's developer is its own. Under UK GDPR the merchant is the controller for its shoppers' data. An app that processes that data on the merchant's behalf is, in the ordinary analysis, the merchant's processor, and Article 28 requires a written contract with it. Whether any given merchant had such terms with Be A Part Of, and whether the developer's terms cast it as processor or independent controller, is not public and will vary.

The ICO's breach guidance is plain on the duties. A controller must report a notifiable breach "without undue delay, but not later than 72 hours after becoming aware of it", and must tell individuals without undue delay where there is a high risk. A processor that suffers a breach "must inform you without undue delay as soon as it becomes aware" under Article 33(2).

How UK GDPR roles map onto the Ribon chain. Sources: Commerce DPA (revised 14 May 2026); ICO personal data breaches guide; Master of Malt timeline.

Question	What the documents say	What they leave open
Is the merchant the controller?	Yes: the DPA says Customer acts as Controller and the Commerce entity as Processor	Nothing material
Is Ribon BigCommerce's sub-processor?	No: the DPA definition excludes marketplace apps	Whether BigCommerce owes merchants anything for marketplace vetting
Who owed the merchant prompt notice?	A processor must tell its controller without undue delay (Article 33(2))	Whether the developer is a processor under its terms; Master of Malt says its first contact from Fastr came 46 h 10 min after the developer knew
When did the merchant's 72-hour clock start?	On becoming aware of the breach	Whether awareness ran from the 1:30am email or the 9:52am reading; Master of Malt reported within about 9 hours of reading, inside either reading

Master of Malt also frames the issue as a platform design question. It says it will work with BigCommerce to "implement more granular access control via their API, as no 3rd party application should have been able to access customer data in this way". That is the merchant's view and a fair one to raise; the developer documentation already offers read-only and modify variants for each scope, so the question is less about whether granularity exists and more about whether merchants can see, refuse or narrow what an app requests.

Method, not accusation

It is worth being clear about who is saying what and why. BigCommerce has an interest in the finding that its platform was not breached, and on the facts published that is accurate. Master of Malt has an interest in being seen to respond well, and it has published more detail, faster, than anyone else in the chain; its account is also the only one with timestamps, and it has not been independently corroborated. Emery Reddy is soliciting claimants, and says it has not verified the retailers' claims. Be A Part Of and Fastr have said nothing publicly, which leaves the root cause, the true install count and their detection timeline unknown.

We do not suggest wrongdoing by any party. The point is structural: when a credential with standing access to many merchants lives with one developer, detection, containment and notification all depend on that developer, and the merchants who carry the legal duty learn last.

What to do, in order

The question that exposes the gap

A merchant can uninstall an app, delete a script and audit its own logs. What it cannot do, on the model BigCommerce documents, is see a developer's key being used against its store, revoke that key itself, or rely on the platform's contract to bind the developer to tell it quickly. So the question for every merchant, and for the platform, is this: when an app you installed is holding a standing key to your customers, who is watching that key, and how many hours will pass before they tell you?

Key facts