#thirdpartyrisk

Read Time:3 Minute, 30 Second

Double Counter, the company behind a widely used Discord moderation and anti-spam bot, has disclosed a breach that exposed records on tens of millions of accounts after an intruder found a way into its cloud infrastructure on October 4, 2026. The company says Discord’s own systems were never touched — the compromise was entirely on Double Counter’s side — but the scale of exposed data and the attacker’s ability to briefly impersonate the bot itself make this a notable supply-chain-style incident for anyone running third-party bots in their servers.

An Old Server Became the Doorway InAccording to Double Counter’s account, the intrusion didn’t start with a clever new exploit. It started with a forgotten one: an old server hosted at OVH, left over from a previous hosting arrangement, was still running a publicly reachable instance of the analytics tool Metabase. A flaw in how that instance handled sessions let the attacker forge administrator access and reach credentials stored on that same host — including a cloud admin service-account key and a saved administrative command-line session. Double Counter has not tied the incident to a specific published CVE, so the exact root cause within Metabase remains unconfirmed.

Because the attacker used those stolen, legitimate credentials rather than creating new accounts, the activity blended in with normal administrative traffic for longer than a brand-new login would have. Once inside, the intruder added their own SSH key, exported a database copy to a cloud storage bucket, and opened a shell inside one of the bot’s running containers — a move that exposed the live Discord bot token itself.

A Few Hours of Chaos on the Support ServerWith the token in hand, the attacker used the bot’s own identity to grant themselves administrator rights on Double Counter’s official support server, reverse a staff member’s ban, and send unsolicited invitations to roughly 50 large Discord communities. Double Counter’s incident response team tried to cut the attacker off by revoking the token and issuing a replacement — but the intruder read the new token within minutes, apparently because the deeper service-account compromise was still active. A second attempt to revoke the service-account key also failed, since the attacker had already pivoted to the stolen administrative session. Access was only fully terminated later that day once every related session was revoked at once.

What Was Actually ExposedDouble Counter’s own disclosure lists the exposed data in granular terms: roughly 28 million Discord user IDs and usernames, about 27 million IP address and approximate location records, user-agent hashes tied to roughly 25 million accounts, and around one million unique email addresses — with heavy overlap between these groups rather than 81 million distinct people. Have I Been Pwned has already indexed roughly 275,000 unique emails from data that circulated publicly. The company states that Discord account passwords and payment card numbers were not exposed, and that cold-storage records covering a further 58 million users were untouched. Separately, a stolen Stripe API key tied to the breach was used to charge about $7,316 fraudulently against an unrelated company account; two legitimate customer charges were refunded.

Cleanup and the Bigger LessonIn its remediation, Double Counter says it decommissioned the old OVH server entirely, revoked all cloud access, rotated every credential involved, deleted webhooks the attacker could have planted, and moved its databases behind private networking rather than public endpoints. The bot’s authentication token now lives in dedicated secrets storage with logging on every access attempt, alongside new continuous monitoring.

For Discord server administrators, the practical takeaway isn’t really about Double Counter specifically — it’s about the dozens of third-party bots most communities run without a clear view of how those vendors secure their own backends. A bot’s permissions inside your server are only as trustworthy as the infrastructure behind it, and this incident shows how a single forgotten analytics server, left running years after its intended purpose ended, can cascade into tens of millions of exposed records and a hijacked support channel. Server owners relying on third-party bots should periodically review what permissions those integrations hold and watch for official breach disclosures from the vendors behind them.

Read Time:3 Minute, 18 Second

Ernst & Young has notified individuals that an intrusion into a platform supporting its tax services exposed personal and financial information associated with several clients, including Goldman Sachs and Man Group. The incident did not originate inside either financial company’s network, but it still placed their customers’ data in the hands of an unauthorized party.

The disclosure expands the known reach of an event EY first reported in July. According to notices sent in late September, an intruder accessed the affected environment between March 28 and April 12, 2026, and downloaded documents linked to multiple EY clients. The exposed material included names, postal and email addresses, tax identification numbers and financial details.

A support platform became the weak linkThe compromised system supported EY teams carrying out tax work. Support tickets could contain attachments with sensitive client tax documents, meaning valuable information sat in an operational workflow outside the networks of the organizations whose customers were affected. An attacker therefore did not need to breach Goldman Sachs or Man Group directly to obtain data connected to their clients.

EY attributed the initial access to a vulnerability in Checkmarx software, although public reporting has not identified a CVE, a vulnerable version or the precise exploitation method. That lack of detail makes it difficult for defenders to map this case to their own environments. It also underlines the importance of obtaining concrete technical evidence from vendors rather than relying only on general assurances.

The timeline leaves another important question. EY detected unusual activity on April 23, eleven days after the reported access window ended. By then, investigators later determined, documents had already been taken. The gap demonstrates why systems used for customer support and professional services need monitoring that is proportionate to the sensitivity of the files they handle.

Financial firms say their own systems were not breachedGoldman Sachs said its infrastructure was unaffected and that client assets remained secure. Man Group likewise described the incident as involving software used by EY, rather than a compromise of Man Group systems. Those distinctions matter: the event is a data exposure involving clients of the financial firms, not evidence that attackers entered their trading or banking platforms.

Goldman Sachs also told clients that EY had hired an independent cybersecurity company to confirm the affected systems were secure. Its technology risk team requested objective evidence and third-party validation that remediation had worked. Public reports do not establish that Man Group made the same demand.

EY said the event did not affect its wider enterprise systems or interrupt operations. It reported the breach to regulators in California, Texas, Massachusetts and Vermont, and offered affected people credit monitoring and identity-protection services. The firm previously said it had found no evidence that the stolen data was misused or that specific individuals were deliberately selected, but an absence of observed misuse is not a guarantee that it will never occur.

What affected people and organizations should doTax identifiers and financial details can remain useful to criminals long after a breach. People receiving a legitimate notice should verify it through an official channel, enroll in monitoring if appropriate and treat unexpected messages about investments, tax refunds or account problems with caution. Requests that reference accurate personal details can still be fraudulent.

Watch financial and credit reports for unfamiliar activity.

Use unique passwords and phishing-resistant multifactor authentication on email and financial accounts.

Confirm urgent requests through a known phone number rather than links in messages.

Preserve breach notices and document any suspicious activity for banks or regulators.

For enterprises, the lesson is broader than this single product. Data inventories should include ticketing, support and professional-services platforms, not just primary databases. Contracts should set expectations for logging, incident notification and evidence-based remediation. Sensitive attachments should be minimized, encrypted and retained only as long as necessary. A supplier may sit outside the corporate perimeter, but the data it holds remains part of the organization’s exposure.