The incident brings together two reported consequences: access to existing customer records and unauthorized changes to storefronts. Those consequences require separate attention. Establishing which shopper information was accessed does not, by itself, establish what an injected script did.
For affected merchants, BigCommerce’s removal of the applications is the documented containment action. For shoppers, the information currently reported as exposed is contact and address data—not passwords or payment-card details, according to BigCommerce. Neither finding should be expanded beyond what the investigation has established.
BigCommerce revoked Ribon access after confirming stolen credentials
In its statement to BleepingComputer, BigCommerce identified the compromised applications as Ribon and Ribon 1.5, owned and operated by Be A Part Of, a Fastr company. The company said it confirmed the credential compromise on September 17 and found that the credentials had been used to inject malicious scripts into “a small number of merchant storefronts.”
BigCommerce said it uninstalled the application from affected stores to revoke the attacker’s access, notified those merchants directly, and was providing log data to support the developer’s investigation. This is a specific response to an integration compromise; the reporting does not describe a platform-wide shutdown or a requirement for every BigCommerce merchant to remove every third-party application.
Master of Malt, the UK-based spirits retailer, is one named recipient of a BigCommerce notification. According to BleepingComputer’s account of the retailer’s updates, unauthorized access to shopper information occurred between September 13 and September 17. Master of Malt attributed that access to a compromised BigCommerce application key held by Ribon.
The documented sequence is therefore:
| Date | Reported development |
|---|---|
| September 13, 2026 | Unauthorized access began, according to the retailer notifications described in the reporting. |
| September 17, 2026 | BigCommerce confirmed compromised Ribon credentials and removed the affected applications to revoke access. |
| September 21, 2026 | BleepingComputer published BigCommerce’s statement identifying Ribon and Ribon 1.5 and confirming malicious-script injection. |
A September 18 notice from law firm Emery Reddy also described retailer notifications giving the September 13–17 access window and September 17 application removal. That page is a solicitation for potential claimants, however, and its account relies on retailer notifications; it is not an independent forensic investigation. It supports the existence of customer-facing breach notices without establishing the incident’s full scope.
The total number of affected merchants and shoppers has not been established in the available reporting. BleepingComputer reports that Master of Malt warned the incident might extend to hundreds of other stores, but that is a potential reach, not a confirmed count. BigCommerce’s description of a “small number” specifically concerns storefronts receiving malicious scripts; it should not be treated as a count of every merchant whose customer records may have been accessed.
The Ribon breach crossed an application boundary, not a confirmed platform breach
The central mechanism described by the reporting is the misuse of an application credential. Ribon had a BigCommerce application key, and an attacker obtained credentials that allowed access through that integration. The public account does not establish how the credentials were stolen or disclose the precise permissions attached to them.
That explains how BigCommerce can report that its platform was not breached while merchants still report customer-data exposure. The security boundary at issue was the third-party application’s access to store resources. BigCommerce’s statement that uninstalling the application revoked the attacker’s access directly connects its containment measure to that boundary.
There are nevertheless two distinct findings to preserve. Master of Malt’s account concerns access to shopper records. BigCommerce’s statement confirms malicious scripts in some storefronts. The available evidence does not establish that every affected merchant experienced both, nor does it describe the scripts’ behavior in sufficient detail to identify what each one collected or changed.
That matters particularly when comparing this incident with the 2024 ZAGG breach. BleepingComputer previously reported that attackers compromised the third-party FreshClick application and injected code designed to capture payment-card data entered during checkout. In the Ribon incident, its reporting instead identifies access to existing customer records through a compromised application key, alongside BigCommerce’s separate confirmation of script injection.
The earlier case is a useful comparison of the access path, but it cannot supply missing findings about Ribon. Malicious-script injection does not, on its own, establish payment-card theft in this incident. The reported data categories and BigCommerce’s statements must govern that conclusion.
The same discipline applies to remediation. BigCommerce says application removal revoked access. Its quoted statement does not provide a store-by-store account of script removal or validation. Merchants therefore need to distinguish confirmation that the compromised connection was disabled from confirmation of the final state of their storefront. That is an evidence requirement, not a claim that malicious code remains active.
Master of Malt’s exposed contact data still creates a practical risk
According to BleepingComputer, Master of Malt identified the affected shopper information as full names, email addresses, telephone numbers, and shipping postal addresses. The retailer also reported the incident to the UK Information Commissioner’s Office. These are the reported categories for the named merchant; they should not automatically be treated as a complete inventory for every affected store.
BigCommerce says passwords and payment-card information are stored separately and were not exposed. Emery Reddy’s account similarly says retailer notices excluded passwords and payment information, while explicitly acknowledging that the firm had not independently verified those representations. The exclusion should therefore remain attributed rather than presented as an independently established forensic finding.
Contact information still has practical value to an impersonator. A message using a shopper’s real name, telephone number, and delivery address may appear more credible than an untargeted scam. Emery Reddy’s notice warns about phishing by email, text, and telephone using the exposed information. This is a plausible follow-on risk, not evidence that a particular scam campaign has already followed the breach.
For notified shoppers, the useful precaution is to verify unexpected contact through a retailer channel they already trust, rather than through a link or telephone number supplied in the unexpected message. Knowing a delivery address does not authenticate someone claiming to resolve a shipping problem. Requests for passwords, payment details, or urgent account verification deserve particular scrutiny.
The current reporting does not establish a universal requirement to replace payment cards or reset passwords because of this incident. Advice should remain proportionate to the data reportedly exposed and any subsequent merchant-specific findings. A retailer’s own notice may contain information about an individual customer’s circumstances that the broader public reporting does not.
Affected BigCommerce merchants should separate containment from impact assessment
Merchants notified by BigCommerce should establish what happened in their own store before treating the application’s removal as the end of the incident. The immediate decision is whether their evidence shows customer-record access, storefront modification, or both—not whether BigCommerce as a whole can be described as breached.
Historical installation information matters here. Because BigCommerce says it removed affected applications, a current application list without Ribon is not enough to establish that the integration was never present. A merchant’s notification and records of its earlier application connections are more useful for that question.
The September 13–17 window reported by Master of Malt provides a starting point for investigation, but it should not be declared the definitive access period for every merchant without store-specific confirmation. Likewise, BigCommerce’s statement that it is supplying logs to the developer does not establish that identical logs are directly available to every merchant or specify which administrative screen exposes them.
No public, Ribon-specific cleanup procedure, script indicators, log-field checklist, or safe reinstallation criteria are established in the available evidence. It would be misleading to turn the incident into a universal sequence of console clicks or key-rotation commands. Merchants can still organize their response around concrete questions supported by the findings:
- Establish whether Ribon or Ribon 1.5 was connected during the relevant period, using historical records and BigCommerce’s notification rather than relying only on the current application list.
- Obtain store-specific confirmation of the access revocation BigCommerce describes, and retain the notification and investigation records.
- Ask whether the store experienced customer-data access, malicious-script injection, or both, and seek evidence supporting the answer.
- Determine which customer fields and records were affected before issuing a notice that makes broader claims about exposure or exclusions.
- Where storefront modification is confirmed, obtain confirmation of what was changed and how its removal was validated, alongside the application-access findings.
- Give customers guidance matched to the established exposure, including warnings about impersonation, without describing payment-card theft or password compromise as confirmed.
BigCommerce’s documented intervention cut off the compromised application access. The remaining work is merchant-specific: establish the records exposed, account for any storefront changes, and communicate those findings accurately. This incident demonstrates why a hosted platform’s security and an integration’s security must be assessed separately—and why a statement that the platform was not breached does not settle the consequences for the stores using it.