Adobe Data Breach 2026: Why Marketo, AEP, and AJO B2B Users Should Read Their Support History

A threat actor going by “Mr. Raccoon” claims to have accessed Adobe’s customer support database via a third-party BPO vendor in India, reportedly exporting 13 million support tickets, 15,000 employee records, and the contents of Adobe’s HackerOne vulnerability programme. Adobe has not officially confirmed the breach as of the date of this article.

Most coverage of this story has focused on the scale of the alleged data exposure and the attack mechanics. That is all relevant. But there is a layer that enterprise marketing leaders - specifically teams running Adobe Marketo Engage, Adobe Experience Platform, or Adobe Journey Optimizer B2B Edition - should be thinking about that most commentary has missed.

The platform data itself was not breached. Your contacts, campaigns, and segments are not in that database. But your support tickets are. And support tickets are not as generic as they sound.

Not sure whether your organisation is exposed? There is a free 11-question exposure check further down this page - results appear immediately, no email required.

What actually lives in enterprise support tickets

When a Marketo Engage practitioner opens a support ticket, they are not describing a vague problem. They are sharing context. In practice, that means:

• Integration configurations - field mappings between Marketo and your CRM, webhook endpoint URLs, sync filter logic
• API credentials submitted in error logs or troubleshooting exchanges
• Smart list definitions that reveal segmentation logic and data structure
• Lead scoring rule details, threshold configurations, and programme architecture
• Email template code with embedded personalisation tokens and data references
• Custom object schemas and custom field naming conventions
• Personal data of EU data subjects - this is where the GDPR dimension enters. Adobe's support guidance asks for "links to specific leads that are examples of the issue" and recommends uncropped screenshots from your CRM. Technically those could be anonymised test records - but teams without a representative staging environment routinely use real records to reproduce issues quickly. The result is that personal data of real contacts ends up in support correspondence not through carelessness, but through the path of least resistance in a pressure situation.

For teams using Adobe Experience Platform, support tickets are often where schema troubleshooting happens. That means XDM schema definitions, data ingestion configurations, identity stitching logic, and Real-Time CDP segment definitions may have been discussed in that correspondence. The same applies to Adobe Journey Optimizer B2B Edition: buying group configurations, account scoring logic, and channel integration details all surface in technical support conversations.

For EU organisations, that last point has a regulatory dimension that deserves separate treatment. But at the technical infrastructure level: this is the blueprint of your marketing stack. In the wrong hands, it reduces the effort required to craft a targeted attack on your specific stack configuration significantly. It also exposes intellectual property: the segmentation and scoring logic that your team has built over years is documented there.

How the attack happened - and why it matters

According to published reports, the attacker did not penetrate Adobe’s core infrastructure. They started with a phishing email to a support agent at an outsourced BPO firm in India, installed a remote access tool on the agent’s workstation, and then used the compromised account to send a second phishing email to the agent’s manager - gaining admin-level access to Adobe’s support platform. From there, the entire ticket database was reportedly exported in a single query, with no rate limiting, DLP trigger, or SOC alert firing.

The scope of the Remote Access Tool is worth noting separately. According to posts reviewed by multiple security researchers, the RAT gave the attacker access not only to the agent’s files and browser sessions, but also to the agent’s webcam and WhatsApp messages. This extends the exposure well beyond the ticket export: internal BPO team communications, client-facing messaging threads, and potentially internal coordination on specific customer accounts may all be in scope.

This is worth sitting with. The attack surface was not Adobe’s product. It was the vendor relationship that keeps the product running. The support layer - the connection between your organisation and your platform vendor - is itself infrastructure. It carries sensitive information. And it lives outside your governance perimeter.

If the BPO firm had been a partner in your own supply chain, your security and compliance teams would likely have audited it. The support relationship tends not to receive the same scrutiny, because it feels like a service, not a system.

The HackerOne exposure is a separate risk

The claim that Adobe’s HackerOne vulnerability submissions were also included in the breach is the most serious element of the story if verified. Security researchers who disclose vulnerabilities through bug bounty programmes do so under the assumption of responsible coordination with the vendor - not public circulation.

If vulnerability reports including proof-of-concept exploits are now in circulation, that changes the risk posture for all Adobe Experience Cloud products. Patches for known vulnerabilities are typically issued on a schedule. Unverified PoC exploits in circulation compress that window considerably. Adobe has not addressed this aspect of the claim publicly at the time of writing.

Why your team shared that data - and what GDPR means for you

There is a trust dimension here that most breach analyses skip. Enterprise teams submit detailed, sensitive information to Adobe support not because they are careless - but because Adobe’s own support guidelines ask them to. Standard instructions for reproducing a Marketo sync issue or an AEP ingestion failure routinely include: share an uncropped screenshot of the affected lead record, provide the specific lead URL, attach the full API request and response, include the error log in its entirety. Following those instructions means submitting real prospect names, real email addresses, real company data. Compliant behaviour produced the exposure.

This matters for how you respond internally. The conversation with your legal or compliance team is not “did we make a mistake.” It is “did we follow our vendor’s instructions, and if yes, what does that mean for our obligations.”

Under GDPR Article 33, the 72-hour notification obligation to your supervisory authority sits with the data controller - your organisation, not Adobe. Adobe is the processor in this context. If the breach is confirmed and personal data of EU data subjects was included in the exposed tickets, the obligation to assess and potentially notify falls on your side. Adobe notifying its own regulator does not discharge your obligation.

The practical question for your DPO or legal team is narrow and answerable: review your support case history and determine whether any submitted tickets contained personal data of EU data subjects. The honest answer for many teams is that it depends on whether real records or test records were used to reproduce issues - Adobe's own guidance asks for links to specific lead records and uncropped CRM screenshots, which creates that ambiguity. If personal data was included and breach confirmation arrives, the 72-hour clock starts from the point of your own awareness.

Four things to do before Adobe confirms anything

The incident is alleged and unverified. That is not a reason to wait. The four actions below carry zero downside if the breach turns out to be smaller than claimed.

1. Audit what your team has shared in support tickets. Ask your Marketo Engage admin and AEP architects to review recent support cases. Look specifically for tickets where credentials, API keys, or detailed integration specifications were included. Most enterprise support portals maintain a full case history.

2. Rotate credentials that appeared in support correspondence. Marketo Engage API keys, launchpoint service credentials, Adobe Experience Platform authentication tokens, and any webhook URLs or CRM sync credentials shared in troubleshooting conversations should be rotated as a precaution. This is low-effort and has no operational downside.

3. Establish a support hygiene protocol going forward. This incident is a useful prompt to create a simple policy: before submitting a support ticket to any major platform vendor, strip or anonymise sensitive configuration details and personal data. Share credentials through secure channels or on a need-to-know basis with the assigned support engineer only. This applies to Salesforce, HubSpot, and other platform support relationships as well - not just Adobe.

4. Brief your DPO and legal team now - before confirmation arrives. Ask them to review whether your submitted support tickets contain personal data of EU data subjects. If the breach is confirmed, GDPR Article 33 gives you 72 hours from awareness to notify your supervisory authority if a notification is required. That assessment takes time. Starting now means you are not scrambling at the point where Adobe releases a statement.

A note on what this illustrates

The Value Gravity framework describes where durable value accumulates in an enterprise marketing stack. The dense, governed base - identity, data architecture, integration logic - is where switching costs are highest and where strategic decisions tend to be made once and then lived with for years.

What this breach makes visible is that risk accumulates in the same place. The integration configurations, schema logic, and scoring architecture that give a Marketo or AEP instance its commercial value are exactly what end up documented in support correspondence. When that support layer sits outside your governance perimeter - handled by a vendor’s outsourced BPO partner - the risk surface extends further than most organisations have mapped.

This is not an argument for avoiding platform vendors or their support functions. It is an argument for treating the support relationship as infrastructure rather than a service call. The governance question is not only what data your platform holds. It is what data your vendor’s support chain holds about your platform.