BigCommerce Merchants

Attackers used compromised credentials for the Ribon app, an integration available to merchants on the BigCommerce platform, to reach customer data across multiple retailers. Master of Malt is among the merchants that disclosed.

BigCommerce itself was not breached, and neither were the individual shops. The compromise sat in a third-party application that merchants had installed and granted access to their store data, which means the blast radius was defined by the app's permissions rather than by any one retailer's security.

Customer full names, email addresses, phone numbers and shipping addresses.

No payment data, which matters. What remains is a verified purchase relationship: this person bought from this specific retailer and had it delivered here. For a merchant selling anything a customer might not want publicised, the fact of the purchase is itself the sensitive item, independent of the fields.

Customers of every affected merchant, who installed nothing and agreed to nothing. They bought from a shop they chose and had no visibility into which applications that shop had connected to its store.

The retailers are harmed too, and asymmetrically. Each one must notify its own customers about a breach it did not cause, in an app it selected from a marketplace, with no ability to tell its customers how the credentials were taken.

App marketplaces are how small and medium merchants get capability they could never build. Installing a vetted integration from the platform's own marketplace is the recommended path, not a shortcut.

The assumption is that marketplace presence implies security review. Listing standards vary, and in most cases the merchant grants broad access to customer records at install time and never revisits it. The permission granted in thirty seconds persists for years.

Which apps held customer data, and what each one could read. Most merchants can name their platform. Far fewer can list every integration currently holding a token into their customer database, and fewer still can say which fields each one touches.

That inventory is the control that would have bounded this. Instead the scope was set by an app's permissions, discovered after the fact, across an unknown number of stores.

This is the sixth vendor-boundary incident in this series. The pattern does not change: the breached organisation can describe its own systems and cannot immediately describe what a connected party holds on its behalf.

No group has been named publicly and the method of credential compromise has not been established in reporting. There is no leak site listing and no ransom demand reported.

Compromised app credentials used to pull customer records across many tenants is a supply chain pattern rather than a targeted attack on any single merchant. Each affected shop was reached because of what it had installed, not because of who it was.

Auditing installed app permissions on a schedule, and removing integrations nobody uses. An app granted access three years ago for a campaign that ended is still a live path into the customer database.

Second, scoping what each app can read. Most integrations need a narrow slice of order data. They are routinely granted the full customer record because that is the default option at install, and the default is what gets exercised when the app is compromised.