On August 18, 2026, a threat actor, Satanic, published sensitive data from hundreds of Stripe payment platform users on the underground forum, pwnforums. This data included sensitive customer information, transaction and invoicing records, as well as 662 valid API keys that iCOUNTER could confirm. API key compromise is a supply chain risk, because they rarely sit in isolation. They are used to connect systems. When an organization’s key leaks, every other enterprise’s data and infrastructure connected to that API are potentially exposed. A single leaked key in one vendor's codebase can cascade across every customer and partner in that vendor’s ecosystem.
Key takeaways:
• Exposed API keys are a way for attackers to compromise critical vendors, putting account information and other data at risk and jeopardizing companies that rely on those vendors
• Companies can leverage iCOUNTER to identify live threats to APIs and other risks in near real-time
• Through iCOUNTER's CTOS™, third parties are provided the critical remediation support needed to counter those threats, better protecting the third-parties and their customers
According to Hudson Rock, the threat actor possesses 20,000 compromised APIs, suggesting that other releases may occur. In addition to the original release being posted to pwnforums, the data has also proliferated to Dark forums, Spear, Satanic Cloud Telegram channel and others, as well as the file being hosted at bite blob and ur0.
Of all the data published, the exposure of API keys is of most concern, because they allow threat actors to access the vendor’s Stripe account automatically with no manual effort. Depending on the permissions associated with the key, potential attackers could not only view sensitive customer data but initiate unauthorized refunds or payments or change account settings.
The direct threat of the exposed Stripe account keys includes direct financial abuse for those keys allowing broad programmatic access to the merchant accounts, creating fraudulent payment links, modifying web hooks, phishing and social engineering using names, contacts, and purchase history, and abusing promotional codes.
API keys are commonly leaked via hardcoded keys in public repositories, unmasked CI/CD logs, publicly accessible config files, misconfigured storage or servers, exposed environment files, client-side code shipping secret keys to browsers, and info stealer malware harvesting developer machines.
Keys are often forgotten. They are committed to since defunct repositories, embedded in an old build, or sitting in a forgotten log. They can also lack expiration, so a leaked key may still be valid long after. Finally, because using a valid key looks like normal traffic, compromise is hard to detect.
Poor or incomplete remediation extends the exploitation window. Key revocation is often mismanaged where an organization may rotate keys without revoking old ones. Therefore, the exposed API stays live even after the organization thinks it has remediated.
iCOUNTER helps counter live API risks for critical third-parties at scale
For iCOUNTER customers, an event like this raises one urgent questions: which of my critical third parties are affected and how does the compromised third-party impact my operations or data? Not every vendor connected to compromise is affected the same way - some may have their own keys exposed, others are simply connected as a critical platform. iCOUNTER is built to surface that distinction automatically, so customers know exactly where to focus and their third-parties are given critical information about the exposure and remediation actions needed.
Leaked Sensitive Data - surfacing which of your vendors had their own keys exposed
If a customer has a vendor whose live API key or credential appeared in data dump, iCOUNTER flags that vendor under Leaked Sensitive Data - the category built specifically for cases where a monitored third party's own sensitive artifacts, such as API keys, credentials, source code, configuration files, surface in a leak.
For the customer, this is the direct compromise signal on their own vendor: that vendor's key is out in the open, and it's on them to push for remediation - rotate the key, audit access logs, assess blast radius - before it's exploited.
Associated Data Leak Exposure -surfacing when your vendor is implicated through its own customers
If a customer has a vendor whose business name appeared in a data dump - but the API key or sensitive data actually exposed belongs to that vendor's own customer, not the vendor itself -iCOUNTER flags that vendor under Associated Data Leak Exposure. This category is specifically for cases where a monitored third party is referenced within a leak that does not pertain to its own data, but contains information tied to its end-users or associated parties.
For the customer, this is the indirect exposure signal on their own vendor: the vendor's own systems and credentials were not compromised, but its customer base has been exposed through its platform relationship and that carries real reputational, contractual, and regulatory risk the vendor still needs to account for, even without a direct breach on their end.
.avif)