One Phishing Email Walked Out With 13 Million Adobe Support Tickets—And Every Bug Bounty Adobe Hadn't Patched Yet

The Attack Chain Did Not Touch Adobe Itself

Mr. Raccoon's account, corroborated across SQ Magazine and The CyberSec Guru, is that he never compromised Adobe's primary infrastructure. He compromised a single Indian Business Process Outsourcing vendor that handled Adobe's customer support tier.

The chain, in his telling:

1. A phishing email reached a junior support agent at the BPO. The agent clicked, and the attacker installed a remote management tool on the agent's workstation.
2. Privilege escalation by spear phishing the agent's manager. Once Mr. Raccoon had the manager's credentials, he had administrative access to the support ticketing platform.
3. One bulk export. Adobe's helpdesk platform allowed an authenticated agent to export every ticket in a single request, with no rate limit, no alert, no break glass approval, and no anomaly detection on the size of the response.

No zero day. No malware that ever touched Adobe's network. The attacker said as much directly: he exported the entire support database "in one request from an agent" using legitimate functionality.

The Crunchyroll Pattern Repeats

If the chain sounds familiar, it should. The Crunchyroll TELUS BPO breach disclosed two weeks earlier followed almost exactly the same script: a single call center agent's laptop got infected, the attacker pivoted into the customer support platform, and 6.8 million users' email addresses spilled out within 24 hours. The Mr. Raccoon claim is the same pattern at roughly twice the scale.

The attractive thing about a BPO from an attacker's perspective is the asymmetry: the BPO holds production access to enormous customer datasets but operates under a fraction of the security controls the parent company uses on its own infrastructure. Workstations are often standardized images managed by a vendor, agents log into a contractor managed VPN, and the customer's own security team has limited visibility into the BPO's endpoint telemetry. When the breach happens, the parent company's incident response team has to negotiate access to logs through a contract relationship.

What's in 13 Million Support Tickets

A support ticket database is one of the highest leverage targets a SaaS vendor maintains. Customers open tickets when something is broken, which means they describe specifics: account email addresses, the actual error messages they received, machine identifiers, screenshots, license keys, billing problems, and—frequently, despite policy—passwords pasted into the ticket body before the agent has a chance to scrub them.

Combine 13 million such tickets with the email addresses they reference, and you have a phishing dataset that's better than most. An attacker doesn't need to guess what software a victim uses. The ticket says "Photoshop 24.5 keeps crashing on my M2 Mac." A spear phishing email that opens with "We saw your support ticket about Photoshop crashes on your Mac and have a fix" is going to work on a meaningful fraction of recipients.

The same dataset enables a different scam: pretending to be Adobe support for a callback. The attacker has the customer's case ID, the agent's name, the original problem description—all of which the victim can verify match their actual ticket. Once trust is established, the script asks for "verification" via remote desktop access. The same callback phishing pattern already runs at industrial scale through dedicated AI vishing platforms.

The HackerOne Theft Is the Quiet Disaster

The 13 million tickets generate the headlines. The HackerOne archive does the structural damage.

A bug bounty platform's queue is, by definition, a list of vulnerabilities the receiving company knows about but has not fully remediated. Some are scheduled for the next patch cycle. Some are blocked on a redesign. Some are sitting in a triage backlog. Each entry has reproduction steps, often with proof of concept code, written by the researcher to make exploitation as easy as possible for the security engineer who has to verify the bug.

A copy of that queue in adversary hands is a turnkey exploitation kit for whichever Adobe products the queue covers. The bugs that have already been patched still threaten any customer who hasn't applied the patch. The bugs still open are weapons for as long as they remain open. Adobe's security team is now in the position of having to assume that every entry on the HackerOne side is being scanned for usability against unpatched installations in the wild, while simultaneously continuing the patch work as if the queue were still private.

Adobe Has Not Confirmed

As of the most recent reporting on April 4, 2026, Adobe had not publicly confirmed or denied the breach. Cybernews labeled the claims unverified, while noting that researchers who reviewed sample data described the claims as "plausible." The samples reportedly included internal file storage screenshots and employee device captures—the kind of artifacts that are difficult to fabricate in volume.

The legal calculus for a company in Adobe's position is grim. If the breach is confirmed quickly, customer notifications under GDPR's 72 hour rule and the various US state breach laws kick in immediately, and the company faces lawsuit exposure proportional to the dataset's size. If the breach is denied or delayed and the data later proves authentic, the company faces both the original liability and additional regulatory action for the cover up. The middle path—the carefully worded "we are aware of the claims and are investigating"—buys time but doesn't change the underlying math.

If You're an Adobe Customer

The defensive moves are concrete:

• Treat any unsolicited "Adobe support" email as suspicious. If you've ever opened a support ticket, an attacker may know your case ID and original problem description. Initiate support yourself by going to adobe.com directly—do not click links in inbound email.
• Reset your Adobe ID password. Even though the support tickets reportedly didn't contain hashed passwords, customers who pasted credentials into ticket text are exposed. A new password and MFA reset closes that door.
• Enable phishing resistant MFA on your Adobe account. Hardware security keys or platform passkeys defeat the credential capture campaigns this dataset is going to enable.
• Watch for fraud alerts on the credit card on file. Billing fields in support tickets typically include the last four digits, but operators can use the dataset to confirm a victim's primary card and time fraud against billing renewals.
• Patch your Adobe applications immediately and stay current. The HackerOne archive theft means the window between disclosure and exploitation just shrank for any bug researchers have submitted to Adobe. Auto update is the safer setting.

The Lesson Is Structural

The pattern Mr. Raccoon describes—phish a BPO, escalate to admin, bulk export—is not novel. It's the same pattern ShinyHunters used against Carnival, against Canada Life via Salesforce, against ADT, and now—if confirmed—against Adobe. The variable in each case is which third party held the data and how loose the bulk export controls were.

For SaaS vendors, the question to ask is no longer "is our infrastructure secure" but "what would happen if any of our outsourcing vendors got phished tomorrow"—and what the bulk export controls look like on every customer dataset that lives outside the corporate perimeter. The answer, often, is that those controls don't exist. An agent can export everything because the platform was designed for an agent who needed to. Mr. Raccoon needed to as well.