CVE-2025-54254

What it actually does

Adobe Experience Manager 6.5.23 and earlier contain an XML External Entity (XXE) parsing flaw caused by insufficient restriction of external entity references during XML processing. A remote attacker can submit crafted XML that causes the server-side parser to resolve attacker-controlled external entities, allowing arbitrary local file reads from the AEM host under the privileges of the AEM process. Because the issue has changed scope, sensitive local data exposed through the vulnerable AEM instance may affect resources beyond the originally requested component or security boundary. Exploitation does not require user interaction.

Why it matters to the business

Successful exploitation can expose sensitive files stored on the AEM server, such as configuration files, application secrets, credentials, certificates, repository metadata, or operating system files. For organizations using AEM to host public-facing sites, authoring environments, or digital experience platforms, this can lead to credential theft, follow-on compromise of connected systems, data disclosure, regulatory exposure, and operational disruption. Although it is not listed in CISA KEV and no mature public exploit is indicated, the EPSS score is high, suggesting a meaningful likelihood of exploitation in the wild; the issue has also been public for an extended period, increasing the urgency to verify remediation.

How an attack unfolds

An attacker identifies an Adobe Experience Manager instance running version 6.5.23 or earlier and locates functionality that accepts or processes XML. The attacker sends a crafted XML document containing a Document Type Definition and external entity references that point to local files using file-based URI schemes. If the vulnerable parser resolves those entities, the contents of targeted local files are embedded into the application response, error output, downstream processing result, or an attacker-observable out-of-band interaction. The attacker then uses the disclosed file contents to harvest secrets, understand the deployment, obtain credentials, or plan additional attacks against AEM, the underlying host, or integrated services.

How to fix it

Upgrade Adobe Experience Manager to a vendor-supported fixed release newer than 6.5.23, following Adobe’s security bulletin and release notes for this vulnerability. If immediate upgrade is not possible, reduce exposure by restricting access to XML-processing endpoints, disabling or hardening features that accept untrusted XML, enforcing authentication and authorization on administrative and authoring interfaces, and blocking unnecessary outbound network access from AEM servers to reduce out-of-band XXE exfiltration. Ensure XML parsers and custom AEM components disable DTDs, external general entities, external parameter entities, and external schema resolution. Review custom integrations, OSGi bundles, and third-party packages that parse XML and apply secure parser configurations consistently.

How to confirm the fix worked

Confirm all Adobe Experience Manager instances are running a fixed version newer than 6.5.23 or have the vendor patch level that remediates this issue. Validate version and patch status from AEM product consoles, package inventory, deployment manifests, container images, and software asset records. Perform a configuration review of custom XML parsing code to ensure external entity resolution and DTD processing are disabled. Where authorized, conduct controlled security testing against XML ingestion paths using benign XXE canaries to confirm that external entities are not resolved and that the server does not make unexpected outbound requests. Review network egress controls to ensure AEM servers cannot freely reach arbitrary external hosts.

Typical attack path

1. Identify an exposed Adobe Experience Manager instance and determine whether it may be running version 6.5.23 or earlier.
2. Find an AEM feature, API, upload workflow, integration point, or content-processing path that accepts XML input.
3. Submit XML containing external entity declarations that reference local files or attacker-controlled external resources.
4. Observe whether file contents, parser errors, or outbound callbacks indicate that external entities were resolved.
5. Read sensitive local files accessible to the AEM process, such as configuration, credential, certificate, or operating system files.
6. Use disclosed secrets or system information for lateral movement, privilege escalation, repository access, or further compromise.

How to detect it

Investigate for prior exploitation by reviewing AEM request, access, error, audit, application, dispatcher, reverse proxy, WAF, DNS, proxy, and firewall logs. Look for HTTP requests containing XML DTD declarations, ENTITY definitions, file:// URI references, references to sensitive local paths, and unusual parser errors. Pay particular attention to requests to XML upload, import, integration, content ingestion, package, servlet, or API endpoints followed by 4xx/5xx responses, unusually large responses, or outbound DNS/HTTP connections from AEM servers to unfamiliar external domains. In AEM filesystem logs, review crx-quickstart/logs/error.log, request.log, access.log, audit.log, and any custom application logs for XML parser exceptions, DOCTYPE processing, external entity resolution, or failed attempts to open local files. If blind XXE is suspected, correlate inbound XML submissions with outbound egress from the same host shortly afterward. Treat any evidence of local file disclosure as potential credential exposure and perform secret rotation and incident response scoping.

• <!DOCTYPE
• <!ENTITY
• SYSTEM "file://
• SYSTEM 'file://
• PUBLIC "-//
• file:///etc/passwd
• file:///etc/shadow
• file:///proc/self/environ
• file:///proc/self/cmdline
• file:///proc/version
• file:///var/log/
• file:///opt/
• file:///home/
• file:///root/.ssh/
• file:///etc/hostname
• file:///etc/hosts
• file:///etc/issue
• file:///etc/os-release
• file:///etc/resolv.conf
• file:///etc/ssl/
• file:///etc/krb5.conf
• file:///etc/ldap/
• file:///etc/nginx/
• file:///etc/httpd/
• file:///etc/apache2/
• file:///usr/local/
• file:///crx-quickstart/
• file:///opt/aem/
• file:///opt/adobe/
• file:///var/aem/
• file:///C:/Windows/win.ini
• file:///C:/Windows/System32/drivers/etc/hosts
• file:///C:/boot.ini
• file:///C:/Users/
• file:///C:/Program Files/Adobe/
• file:///C:/Program Files/Adobe Experience Manager/
• java.io.FileNotFoundException
• SAXParseException
• DOCTYPE is disallowed
• External Entity
• external entity
• entity was referenced
• crx-quickstart/logs/error.log
• crx-quickstart/logs/request.log
• crx-quickstart/logs/access.log
• crx-quickstart/logs/audit.log

What your security team should do

• Prioritize patching all Adobe Experience Manager 6.5.23 and earlier deployments because the vulnerability has high severity, high EPSS likelihood, requires no user interaction, and has been publicly known for an extended period.
• Inventory internet-facing, author, publish, dispatcher-adjacent, staging, and development AEM deployments to identify any instances still running vulnerable versions.
• Restrict access to AEM administrative and XML-processing functionality until remediation is complete, especially on internet-facing systems.
• Review AEM logs, web access logs, reverse proxy logs, WAF logs, and outbound DNS/proxy/firewall logs for XXE payload patterns and suspicious file-read attempts.
• Harden XML parsing in custom AEM code and integrations by disabling DTDs and external entity resolution across all parser libraries.
• Limit outbound network access from AEM servers to approved destinations only, reducing the ability to perform blind XXE exfiltration.
• Rotate credentials and secrets stored on AEM hosts if exploitation is suspected or confirmed, because arbitrary file read may have exposed them.
• Add SIEM detections for XML entity declarations, file URI references, sensitive local file paths, and unusual outbound requests from AEM servers following XML submissions.