Summary
- BigCommerce says credentials belonging to the Ribon and Ribon 1.5 applications were compromised and used to inject malicious scripts into a small number of storefronts.
- UK retailer Master of Malt says customer names, email addresses, phone numbers, and shipping addresses were accessed.
- BigCommerce says its own platform was not breached and removed the affected applications to revoke the attacker’s access.
Compromised credentials belonging to third-party applications on BigCommerce were used to access merchant data and inject malicious scripts into storefronts, affecting customers including UK retailer Master of Malt.
BigCommerce said credentials belonging to Ribon and Ribon 1.5, applications owned and operated by Be A Part Of, a Fastr company, had been compromised and used against a small number of merchant storefronts.
The ecommerce platform said its own systems and core BigCommerce platform were not breached. The access instead came through credentials assigned to independently operated applications integrated with merchant stores.
BigCommerce confirmed the credential compromise on 17 September and removed the affected applications to prevent continued access. The known malicious activity took place between 13 and 17 September.
Master of Malt disclosed that customer information had been accessed. The affected data included full names, email addresses, phone numbers, and shipping postal addresses. BigCommerce said account passwords and payment-card data were stored separately and were not exposed through this incident.
The root cause of the compromise affecting the application provider has not been established publicly. That leaves the mechanism through which the Ribon credentials were obtained, and the complete scope of the upstream incident, unresolved.
The separation between BigCommerce and its application ecosystem is technically important, but the merchant impact crosses that organisational boundary. Third-party ecommerce applications can legitimately require access to customer records, storefront configuration, marketing data, or other platform functions in order to operate.
Those permissions become an inherited dependency when credentials are compromised outside the platform itself. A merchant can maintain its own BigCommerce account securely while still being exposed through an application authorised to reach the same data.
BigCommerce supports more than 1,200 third-party applications and integrations. An ecosystem of that size gives merchants flexibility, but it also distributes security responsibility across developers and providers operating different infrastructure, identity systems, monitoring practices, and development environments.
The incident follows other recent cases in which trusted software relationships became the path into another organisation. The TanStack supply chain compromise exposed private CrowdSec repositories after a trusted dependency encountered malicious code. The mechanism differs, but both incidents show why external integrations can become part of an organisation’s effective security boundary.
Third-party applications can also persist after the business reason for installing them has changed. That creates an inventory problem as well as an incident-response problem: organisations need to know which applications retain access, what information each can reach, and which party can revoke that access quickly when a provider is compromised.
BigCommerce was able to remove the affected applications from merchant environments and revoke the credential path. That is an important platform-level control even where the original compromise occurs elsewhere.
The remaining questions concern the cause of the Ribon credential compromise and whether additional merchants had data accessed before the applications were removed. Until further evidence is published, the incident should not be described as a breach of the BigCommerce platform itself.
