Adobe, 13 Million Tickets Exfiltrated: The "Mr. Raccoon" Breach and the Lesson Nobody Wants to Learn About Support Supply Chain

On April 12, 2026 an actor going by "Mr. Raccoon" posted on a cybercrime forum the claim of having stolen 13 million Adobe support tickets, together with the personal data of the customers who opened them. The claimed batch also includes 15,000 Adobe employee records, the entire archive of HackerOne bug bounty submissions, internal documents at various levels, and a series of screenshots that, if authentic, would confirm prolonged access to the vendor's support environment. Adobe, at the time of writing, has not released a public confirmation. Independent analyses by Cybernews, SecurityOnline, GBHackers, and The CyberSec Guru confirm the technical plausibility of the claim and reconstruct the attack chain convergently.

The typical reaction to news like this is to focus on the number — 13 million makes headlines — or on the embarrassment of the hit brand. We think the useful reading is different. The Adobe breach, if confirmed in the claimed terms, is a particularly clean case study on three themes that every Italian organization should already have on its threat list but too many ignore: (1) outsourced support supply chain as the preferred attack vector, (2) infostealers as enterprise breach enablers, (3) lack of rate-limiting and approval on massive data exports as a fatal architectural vulnerability. Let us go through them one by one.

The Attack Chain: Lateral Phishing and BPO as Entry Point

The first thing to fix is that Mr. Raccoon did not breach Adobe in the classic sense — they did not compromise an Adobe Active Directory domain, they did not set foot in the vendor's core infrastructure. They breached an Indian Business Process Outsourcing provider that handles part of Adobe's customer support, and from there exploited the legitimate access that provider has to the Adobe ticketing system to exfiltrate everything the system let them see. This is a crucial distinction: Adobe's actual attack surface does not stop at Adobe's perimeter — it extends to every employee of every external partner with an authenticated account on Adobe systems.

The reconstructed technical chain is as follows. First: malicious email sent to a BPO employee, with an attachment or link that installed an infostealer or Remote Access Tool on the endpoint. Second: from the compromised endpoint, observation of the user's workflow, collection of credentials stored in browser and password managers, mapping of internal contacts. Third: lateral phishing from the compromised device toward the employee's manager — an email coming from a legitimate internal address bypasses perimeter defenses and has far higher click-through rates than external phishing. Fourth: once the manager was compromised, expansion of access to higher privilege levels in the Adobe support system, up to an agent account with export permissions.

The Big Fish: The Mass Export Design Bug

All the rest of the chain — infostealer, lateral phishing, privilege escalation — is painful but ordinary. What happens next is what makes this case a masterclass in what not to do in enterprise ticketing design. According to Cybernews and SecurityOnline, a support agent authenticated on the Adobe ticketing platform could request an export of all system tickets in a single operation, without volume limits, rate-limiting, supervisor approval, or alerting threshold on anomalous volumes.

This is a design bug, not an implementation one. It is not a badly-written regex or a forgotten bound-check: it is an architectural choice that "an authorized agent can read all tickets, so they can also export them all at once". The choice probably stems from a business-requested feature — "I want to download a monthly report with all closed tickets" — and progressively expanded to any export of any volume without ever being reconsidered. The result is that when a single agent account is compromised, the damage is not limited to that agent's or their team's tickets: it is the entire history of 13 million system tickets, with the personal data of all customers who opened them.

The missing principle is "operational least astonishment": an operation that, if successful, compromises an order of magnitude of data far beyond a user's daily work must not be available with the same click used to answer a ticket. It must have per-account rate-limits (e.g. max 1,000 tickets/day), an absolute volume cap (e.g. max 10,000 tickets/export), automatic alerting on anomalous volumes, and out-of-band secondary approval above threshold. None of these controls were in place. When control is missing, a single weak link in the human chain is enough to turn an endpoint incident into a headline data breach.

The Bitter Surprise: HackerOne Submissions

Among the data claimed by Mr. Raccoon is an element that should make the vulnerability disclosure community pause: the entire archive of HackerOne submissions from Adobe's bug bounty program. For those unfamiliar: when a security researcher finds a vulnerability and responsibly reports it via HackerOne to Adobe, they generate a report with full technical details — proof-of-concept code, vulnerable endpoints, reproduction instructions. These reports typically include both already-fixed vulnerabilities and still-open ones in triage, patch, or coordinated disclosure phases.

If the HackerOne archive has actually been exfiltrated, the value to third-party attackers is enormous: every still-open vulnerability becomes immediately exploitable with full technical details, bypassing the discovery phase that is usually the most expensive. This is why mature organizations keep HackerOne reports in an environment segregated from the rest of the support infrastructure, with distinct access controls and separate logs. The fact that the bug bounty archive ended up in the same perimeter as customer ticketing suggests this segregation was not implemented, or was bypassable with the privileges of the compromised support account. For Adobe, beyond the direct reputational damage, this entails the concrete risk of a second wave of incidents on not-yet-patched vulnerabilities in the weeks following the leak publication.

Why This Case Concerns Italian Companies Too

The first reaction of many Italian security teams to a news like this is: "we are not Adobe, we do not have 13 million tickets". The second, sharper: "but we outsourced customer support to Infosys / TCS / Wipro / Accenture, and they have access to our systems". The third, sharper still: "and we have dozens of other integrations with partners holding authenticated accounts on our environments". The truth is that the Adobe breach model is perfectly replicable on medium and large Italian organizations that have outsourced at least one operational function to a BPO, an IT partner, or a managed service provider.

The Italian public sector in particular shows significant exposure. AGID, MEF, INPS, Agenzia delle Entrate — each of these bodies operates with a dense network of external providers holding authenticated access to non-trivial portions of public information systems. The Equalize case (documented by AEGIDA on April 10) had already shown what happens when this trust in providers is betrayed from within. The Adobe case shows the worse variant: when trust is not betrayed from within but simply exploited from outside through a compromise chain endpoint → lateral → privilege escalation that none of the traditional controls detects in time.

What To Do: Seven Controls to Verify Today

1. 1.Up-to-date inventory of external partners with authenticated access to your systems, with for each: scope of access, number of accounts, privilege level, accessible data flows. Many organizations lack this inventory. Build it now.
2. 2.Review of mass export permissions on every system containing personal or commercially sensitive data: CRM, ticketing, DMS, data warehouse. For each system, verify existence of rate-limits, absolute volume cap, alerting on anomalous exports, two-eyes approval above threshold.
3. 3.BPO and IT partner contracts revised to include specific obligations: enterprise EDR on all endpoints, phishing-resistant MFA for every access to client systems, compromise notification for single endpoint within 24 hours, periodic right-to-audit.
4. 4.Segregation of vulnerability management environments (bug bounty, VDP, security tickets) from the rest of support platforms. If your security ticket system lives in the same Jira/ServiceNow as the generalist help desk, it is likely too accessible.
5. 5.Dedicated threat hunting on BPO breach patterns: logins from known BPO geographies (India, Philippines, Eastern Europe) at off-shift hours, export queries at above-average volumes, lateral movements from BPO accounts to internal manager accounts.
6. 6.Specific training for partner employees with access to client systems: lateral phishing works because the operator receiving a mail from their own manager does not suspect the manager is compromised. Tailored simulations raise resilience.
7. 7."Partner incident" response plan: many Italian incident response plans lack specific runbooks for the case "the provider has an infostealer on an endpoint accessing our systems". Write it before you need it.

The Hidden Fragility of the Modern BPO Model

There is a structural aspect the Adobe case highlights that deserves to be named explicitly. The economic model of Business Process Outsourcing, particularly the Indian model that today serves a significant share of customer support and IT services for large Western companies, is built on optimization of cost per ticket. Narrow margins, high turnover, standardized training, employee-side security controls typically lower than those the same vendor would apply on its own direct employees. This is not a moral judgment on BPO providers: it is a description of a market model that to work at those prices must compress what is not strictly necessary to contractually measured productivity.

When the client vendor — Adobe, here — delegates to the BPO a function with authenticated access to its systems, it is transferring a substantial part of its attack surface to an environment whose security posture is designed for a different risk profile. The result is predictable: the effective security level of the outsourced function is the BPO's security level, not the vendor's. The Adobe case demonstrates this particularly sharply, but it is not an exception — it is the rule for all outsourced functions where contractual controls are not matched by technical and operational controls equivalent to internal ones.

Conclusion: This Is Not Adobe's Breach. It Is Your Next Breach.

The temptation when reading news like this is to treat it as an observer event — "poor Adobe", "13 million is a lot", "wonder how they will react". The reality is that the Mr. Raccoon attack profile — infostealer on external partner, lateral phishing, privilege escalation in client environment, mass export exploiting an absent architectural control — is a scheme replicable on virtually any organization of a certain size that has outsourced support, IT management, or any administrative function with access to internal systems. It means the probability that the next case has the initials of an Italian company is non-negligible.

The good news is that the seven controls listed above are neither exotic nor particularly expensive. They are known controls, often already partially in place, that primarily require being extended beyond the internal perimeter to the entire ecosystem of partners with authenticated access. The bad news is that doing so takes time — inventory, contract review, SIEM integration — and that the time available before the next Italian case of this category is probably short. April 2026 is the month in which geopolitics and cybercrime have all accelerated simultaneously. The Adobe breach is just one of the signals; ignoring it means waiting to be the next case study.