BigCommerce has confirmed that attackers stole credentials belonging to the third-party Ribon and Ribon 1.5 applications and used them to access shopper data across merchant storefronts between September 13 and September 17, 2026. The platform says it confirmed the compromise on September 17 and uninstalled the apps from affected stores the same day to revoke access. UK spirits retailer Master of Malt, one of the notified merchants, began warning its own customers on September 22 that names, email addresses, phone numbers and shipping addresses were exposed. No source in this set publishes a record count or a merchant count, and BigCommerce has described the storefront script injection only as affecting "a small number" of retail storefronts.
What Happened
Ribon is a shopping-experience optimization app listed in BigCommerce's marketplace, which BleepingComputer and several other outlets put at more than 1,200 third-party applications and integrations. The app is owned and operated by Be A Part Of, described consistently across sources as a brand of the digital commerce company Fastr.
BigCommerce told BleepingComputer: "On September 17, 2026, Commerce confirmed that credentials belonging to third-party applications Ribon and Ribon 1.5, owned and operated by 'Be A Part Of,' a Fastr company, had been compromised and used to inject malicious scripts into" merchant storefronts. Hitechub's rendering of the same statement specifies "a small number of retail storefronts." The stolen credentials were used two ways: to inject scripts into storefront pages, and to access shopper records.
The timeline is the most consistent element across all eight sources. Unauthorized access began Sunday, September 13, 2026, and ran until Thursday, September 17, when the key was revoked and BigCommerce's security team uninstalled the app from retailer stores. BreachHistory adds that BigCommerce notified affected merchants directly and began supplying log data to support the app developer's investigation. Retailers then began issuing their own customer notifications, with Master of Malt's warnings landing by September 22.
One genuine discrepancy is worth flagging. BigCommerce's own statement, as reported by BleepingComputer, says the attacker accessed shopper data "in BigCommerce environments." Master of Malt's notification, quoted by TechRadar and Hitechub, says hackers compromised a BigCommerce application key held by Ribon and used it "to gain access to customer data held on their system," which the law firm Emery Reddy reads explicitly as data stored on Ribon's system. Those are different data locations with different downstream implications, and the accounts have not been reconciled publicly. Treat the storage location as unsettled.
What Was Taken
Every source describes the same PII categories, drawn from merchant notification emails: full names, email addresses, phone numbers, and shipping postal addresses. News4Hackers renders the last item as "shipping postal codes" rather than full addresses, which appears to be a narrowing against the majority of accounts and the underlying Master of Malt language.
BigCommerce states that account passwords and payment card information are held in separate systems and were not exposed. That claim is repeated by BleepingComputer, TechRadar, Hitechub, DeafNews and BreachHistory, all sourcing it back to the company. Emery Reddy notes pointedly that it "has not independently verified this claim and is reporting it as the retailers' own representation." For defenders, that is the correct posture: the no-cards assertion is the vendor's, not an independent finding.
On volume, there is nothing to range between. No source publishes a number of affected shoppers, a number of affected merchants, or a number of stores running Ribon. TechRadar states plainly that it is not known how many stores use the app. For scale context only, TechRadar cites a late 2024 SEC filing listing 5,884 accounts with at least one unique enterprise plan subscription, and a 2025 BigCommerce press release claiming use by "tens of thousands of B2C and B2B companies across 150 countries." Neither figure describes breach scope.
Why It Matters
This is a trusted-integration compromise, not a platform vulnerability. BigCommerce's core systems were not breached and there is no CVE to patch. The attacker authenticated with valid credentials issued to a vendor that merchants had voluntarily authorized, which means the activity looked like normal API traffic from a normal app.
Security Arsenal makes the sharpest version of that argument: controls keyed on vulnerability management, WAF signatures or endpoint detection would have surfaced nothing, because from a telemetry perspective the API calls were legitimate. That analysis is a single OTHER-tier source and should be read as informed commentary rather than confirmed incident detail, but the underlying structural point is consistent with what BigCommerce itself confirmed.
The blast radius also illustrates the multiplication effect of SaaS marketplaces. One set of stolen app credentials reached the customer records of every retailer that had the app installed, without the attacker ever touching a retailer's own infrastructure. Merchants inherited a breach from a conversion-optimization tool.
DeafNews notes that the case mirrors the 2024 FreshClick breach on the same platform, another third-party credential compromise with storefront impact and no direct BigCommerce breach. That comparison comes from one OTHER-tier source, but it points at a recurring pattern in this ecosystem rather than a one-off.
The Attack Technique
What is confirmed by BigCommerce: credentials for Ribon and Ribon 1.5 were compromised, used to inject malicious scripts into a small number of merchant storefronts, and used to access shopper data in BigCommerce environments between September 13 and 17.
What is not confirmed: what the injected scripts actually did. DeafNews is explicit that BigCommerce's statement "does not specify the technical nature of the 'malicious scripts' injected, nor whether they had functionality beyond data access." Security Arsenal characterizes the incident as a classic digital skimming or Magecart-style pattern and warns that merchants accepting card data during the exposure window may face PCI-DSS reportable compromise, card brand fines and mandatory notification obligations. That is an inference from attack shape, attributed to a single OTHER-tier source, and it sits in tension with BigCommerce's position that payment card data was never exposed. Both positions belong in your risk assessment; neither is settled.
Initial access to the credentials themselves is unexplained. No source in this set says how the attacker obtained the Ribon application key, whether through the developer's environment, a code repository, a compromised employee account, or another route. Attribution is also absent: no threat actor, group, or infrastructure has been named by any source.
On the regulatory side, TechRadar reports that the UK Information Commissioner's Office was notified, and that a law firm has warned of elevated phishing risk for customers of affected retailers. Emery Reddy is soliciting affected consumers for a case review, which is the usual early signal of US class action activity forming around a notified breach.
What Organizations Should Do
-
Inventory every third-party app with storefront or customer-data scope. Pull the full list of installed integrations on your BigCommerce store, note which hold script-modification or customer-read permissions, and remove anything not actively earning its access. Ribon and Ribon 1.5 specifically should be confirmed absent or uninstalled.
-
Treat this as an active IR scenario if Ribon was installed. Pull BigCommerce logs for September 13 through 17, look for API activity attributed to the app outside normal patterns, and inspect storefront page source and checkout flows for injected or unfamiliar scripts and unexpected outbound domains.
-
Do not rely solely on the vendor's payment-data assurance. BigCommerce's statement that cards and passwords sit in separate, unexposed systems is a company claim, and at least one source has flagged it as unverified. If your store processed card data during the exposure window, run the PCI-DSS assessment path in parallel rather than closing on the vendor statement alone.
-
Rotate and re-scope app credentials on a schedule. OAuth and API keys issued to integrations are long-lived by default and rarely rotated. Set an expiry and rotation cadence, and grant the narrowest permission set the integration actually needs.
-
Build alerting on integration behavior, not just vulnerabilities. Baseline normal API call volume and endpoints per installed app, and alert on deviation. This incident produced no malware and no exploit, so behavioral anomaly detection on trusted API access was the only realistic detection surface.
-
Get ahead of the phishing wave with customer comms. The exposed combination of name, email, phone and delivery address is exactly what makes fake delivery and order-problem lures convincing. Notify affected shoppers, state clearly what was and was not taken, and tell them your staff will never request payment details by phone or email.
-
Confirm your regulatory clock. If you serve UK or EU customers, check your ICO or equivalent notification obligation and deadline now rather than waiting on the app developer's investigation to conclude.
Sources: BigCommerce warns customers of potential data leaks following cyber... | BigCommerce alerts merchants of data breach linked to Ribon apps | BigCommerce Merchant Breach via Compromised Ribon App Credentials:... | BigCommerce Ribon Apps Breach: Shopper PII Exposed — BreachHistory | BigCommerce Data Breach: Customer Data Exposed via Third-Party App... | BigCommerce Breach via Ribon App Exposes Merchant Store Customer…... | BigCommerce Warns Merchants of Data Breach Linked to Ribon App - Hi... | BigCommerce Ribon App Data Breach Lawsuit Emery Reddy