deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

Compromised Ribon app credentials enabled malicious script injection into BigCommerce storefronts

Compromised credentials for the third-party Ribon app let attackers read merchant customer records and inject malicious JavaScript into BigCommerce storefronts between September 13 and 17, 2026.

Compromised Ribon app credentials enabled malicious script injection into BigCommerce storefronts

What happened

BigCommerce has notified merchants of a breach that originated not in its own platform but in a third-party app. According to a BleepingComputer report summarized in a dev.to security write-up, credentials for the Ribon app (including a version listed as Ribon 1.5) were compromised, and an attacker used the app's key to read existing customer records belonging to some merchants and to inject malicious JavaScript into a small set of storefronts. The attacker's access to shopper data took place between September 13 and 17, 2026.

BigCommerce has stated that its core platform was not compromised. The company also said account passwords and payment card data are stored separately and were not exposed. It has uninstalled the affected apps, revoked their access, and supplied relevant logs to affected merchants.

How the attack chain worked

Per the write-up, the intrusion relied entirely on legitimacy rather than on exploiting a software vulnerability:

  • Attackers obtained the Ribon application's credentials.
  • They entered merchant environments using the app's valid key, which carried permissions to read customer records and modify storefront scripts.
  • They read existing customer records and added malicious JavaScript to some storefronts.

The injected script could be delivered from the storefront to shoppers' browsers. Whether it was actually served to shoppers, executed in any browser, or transmitted data anywhere has not been publicly disclosed. The write-up maps the intrusion to MITRE ATT&CK technique T1199 (Trusted Relationship) with high confidence and T1213 (Data from Information Repositories) with medium confidence. The threat actor remains unidentified, as does the initial pathway by which the credentials were stolen.

What data was exposed

The retailer Master of Malt confirmed that the attacker accessed customer names, email addresses, phone numbers and shipping addresses, according to the write-up. No password or payment card exposure has been reported. The practical risk for affected shoppers is phishing and social engineering built on accurate contact and shipping details, since messages that reference real orders or addresses tend to be far more convincing than generic spam.

What merchants should check

The write-up lists indicators administrators can look for: abnormal application-key usage, unauthorized customer-record reads, and unexpected changes to storefront scripts. Merchants should review the logs BigCommerce provided, hunt for Ribon app activity and customer-record access between September 13 and 17, and correlate any storefront script changes with proxy, DNS or Content Security Policy report data if shopper-side execution is suspected.

On containment and hardening, the recommendations are to uninstall or revoke unused third-party apps, rotate related credentials, restrict remaining apps to the narrowest possible permission scopes, apply change control to storefront scripts, and deploy a Content Security Policy so that unauthorized script origins are blocked or at least flagged.

Why it matters

This incident is a textbook supply-chain abuse of trust: nothing in BigCommerce's platform was broken, yet merchants and their customers were affected because a single third-party app held powerful credentials. Two factors amplified the blast radius: the app could both read customer data and modify storefront code, and those permissions persisted until they were revoked.

For any merchant running on a platform with an app ecosystem, the lesson is to treat every installed app as part of your own attack surface. Audit what is installed, demand minimal scopes, and monitor storefront script integrity continuously, because injected storefront scripts are the same class of technique used in card-skimming campaigns. No browser-side execution has been confirmed in this case, but the gap between a script being injected and a script being executed is exactly what log correlation needs to close quickly.

  • #ecommerce
  • #security
  • #supply-chain
  • #bigcommerce
  • #javascript

Related posts