Third-Party App Key Opens Door to BigCommerce Data Theft

For a few days in September, an attacker held a working key to customer data inside hundreds of BigCommerce stores — and used it to download records page by page. The key belonged not to the platform itself but to Ribon, a third-party storefront app installed by merchants, making the incident a textbook example of how a weak link in a supply chain can expose information far beyond the vendor that was initially compromised.

A Third-Party Key, A Direct Path To Data

BigCommerce is a software-as-a-service provider that hosts online stores and handles much of the backend infrastructure for its merchants. Those merchants can extend their storefronts with third-party applications, and BigCommerce supports more than 1,200 such apps. One of them was Ribon, a shopping experience optimization tool owned by Be A Part Of, a Fastr company.

According to BigCommerce, attackers compromised API credentials belonging to Ribon and Ribon 1.5. The company said the compromise originated in a Fastr system, not in BigCommerce’s own environment. “The credentials were used to inject malicious scripts into a small number of merchant storefronts,” BigCommerce told SecurityWeek. “This was not a breach of Commerce systems or the BigCommerce platform.”

That distinction matters for how the incident is classified, but the practical effect for affected stores was the same: data held inside BigCommerce became accessible to someone outside the merchant relationship.

How The Intrusion Unfolded

Master of Malt, a UK spirits vendor, published a technical write-up describing the sequence from a merchant’s perspective. The company said the hackers used the compromised key between September 13 and September 17, accessing customer data that included names, email addresses, phone numbers, and addresses.

According to Master of Malt, the attackers downloaded customer data working “page by page” until the key was revoked on September 17 — one day after the Ribon developers became aware of its misuse. The write-up describes a methodical extraction rather than a smash-and-grab, with the attacker continuing to pull records while the credential remained valid.

BigCommerce began notifying merchants of the incident on September 18, after the key had been disabled and the targeted Ribon applications uninstalled. The sequence suggests the window between detection and revocation was short, but the data had already left the building.

BigCommerce’s Account Of The Response

BigCommerce confirmed to SecurityWeek that the compromised credentials belonged to Ribon, and detailed its response in a statement. “On September 17, 2026, Commerce confirmed that API 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 due to a Fastr system compromise.”

“While the Ribon applications are third-party apps independently installed by the merchant where the relationship occurs between the merchant and the third-party application, Commerce acted in the best interest of our customers and their shoppers by uninstalling the application from affected stores to revoke the attacker’s access and limit harm, notifying affected merchants directly, and providing log data to support the developer’s own investigation.”

— BigCommerce, in a statement to SecurityWeek

The company’s framing separates its own platform from the third-party app ecosystem, but its actions — uninstalling the app, notifying merchants, supplying logs — show it treated the incident as something that required direct intervention. The statement also notes that the credentials were used to inject malicious scripts into “a small number” of storefronts, without specifying how many.

What Master Of Malt Saw

Master of Malt’s account offers one of the few detailed merchant-side views of the incident. The vendor said the attack targeted Ribon, “which was installed on hundreds of BigCommerce stores.” Once the attackers had an access key from Ribon, they used it to access data held inside BigCommerce.

That phrasing is important: the data at issue was stored within BigCommerce’s environment, but the entry point was a third-party application’s credential. The distinction between where data lives and who can reach it is exactly the kind of gap that supply chain attacks exploit. Master of Malt’s write-up also notes that the key was revoked on September 17, one day after Ribon’s developers learned it was being misused.

The incident affected customer records rather than payment card data, according to the details available. Names, email addresses, phone numbers, and physical addresses are the kind of information that fuels phishing and social engineering campaigns long after the breach itself is contained.

Silence From Ribon And Fastr

Neither Be A Part Of nor Fastr has publicly acknowledged the incident. It remains unclear how Ribon was compromised and whether other entities were also affected. SecurityWeek said it emailed both companies for additional information and would update its article if they respond.

That silence leaves several open questions. Was the Fastr system compromise limited to Ribon’s credentials, or did it touch other applications? Were other merchants outside the BigCommerce ecosystem affected? The lack of public statements means those answers are not yet available.

The Numbers Behind The Incident

• September 13–17: the period during which attackers used the compromised key to access customer data.
• September 17: the day the key was revoked, one day after Ribon developers became aware of its misuse.
• September 18: the day BigCommerce began notifying merchants.
• 1,200+: the number of third-party applications BigCommerce supports.
• Hundreds: the number of BigCommerce stores on which Ribon was installed, according to Master of Malt.

Those figures sketch a timeline that was, by breach standards, relatively short. But the attacker had several days of access, and the data categories involved — names, emails, phone numbers, addresses — are the building blocks of convincing follow-on attacks.

Why A Key From One App Reached So Far

Third-party applications in e-commerce platforms are often granted broad permissions to read and modify store data. That is what allows them to optimize storefronts, manage marketing, or personalize shopping experiences. But it also means a single compromised credential can provide a path to customer records that the platform itself holds.

In this case, the credential belonged to Ribon, an app that was installed on hundreds of BigCommerce stores. The attacker did not need to breach BigCommerce directly; the key did the work. According to BigCommerce, the credentials were used to inject malicious scripts into storefronts, which suggests the attacker was not only reading data but also altering what shoppers saw.

The incident echoes other recent supply chain compromises, including the CrowdSec source code theft and the Gyazo data breach affecting 23 million user records. In each case, the initial point of compromise was not the primary platform but a connected service or dependency.

What Merchants Should Take From This

For merchants running stores on hosted platforms, the incident is a reminder that their security posture extends to every app they install. BigCommerce uninstalled the affected Ribon applications to revoke access, but that happened after data had already been accessed. Merchants may want to review which third-party apps have access to customer data, what permissions they hold, and whether those permissions are still necessary.

For platform providers, the challenge is balancing an open app ecosystem with the ability to limit damage when one app’s credentials are compromised. BigCommerce’s statement emphasizes that this was not a breach of its platform, but its response — uninstalling apps, notifying merchants, sharing logs — shows that platform-level action was still required to contain the fallout.

The lack of public comment from Ribon’s owners means the full scope of the Fastr system compromise is not yet known. Until more details emerge, merchants and shoppers alike are left with a familiar lesson: data security in e-commerce is only as strong as the weakest credential in the chain.