CISA has added CVE-2025-54253 to its exploited vulnerabilities list. The flaw exists in Adobe Experience Manager (AEM). It is rated CVSS 10.0, which is the maximum possible severity. Adobe confirmed that versions 6.5.23.0 and earlier of AEM Forms on JEE are affected. The company fixed the bug in AEM 6.5.0-0108 together with CVE-2025-54254.
The issue originates in the /adminui/debug servlet. This component accepts user input and processes it through the Object-Graph Navigation Language (OGNL) engine. The servlet fails to sanitize that input. As a result, it interprets the text as Java code. Because this endpoint has no authentication, anyone can send a crafted request and trigger remote command execution.
CISA has already observed exploitation in the wild. Federal agencies must patch their AEM instances before November 5, 2025.
Mechanism of Exploitation
This weakness results from improper input validation and unsafe OGNL evaluation. OGNL allows dynamic Java method calls. In AEM, the debug servlet uses it for internal testing. However, it does not verify the source or content of the input. Attackers can inject Java commands through OGNL syntax.
When AEM receives a malicious payload, the servlet evaluates it as code. That evaluation runs directly on the host system. The attacker does not need valid credentials. A single HTTP POST to the debug servlet can execute commands with full system privileges.
An exploit needs knowledge of Java classes and methods, but public proof-of-concepts already reveal the structure. Anyone can weaponize those details to compromise vulnerable AEM servers.
Threat Impact and Exposure
If exploited, this flaw grants total control over the AEM server. An attacker can read or alter sensitive data, add new administrator accounts, or deploy web shells. In production environments, this means attackers can access customer records or push malicious content to websites.
The flaw’s simplicity and public availability make it especially dangerous. Attackers can scan for exposed debug endpoints and exploit them automatically. Any unpatched instance of AEM connected to the Internet is at immediate risk.
Detection and Monitoring
Administrators should check access logs for suspicious traffic to /adminui/debug. Look for POST requests with OGNL or system command syntax. Example payloads often contain characters like #, {}, or @java.lang.Runtime@getRuntime().
Monitor the AEM process for unusual activity. Unexpected child processes or shell commands spawned by the Java process may indicate exploitation. Endpoint Detection and Response tools can catch command injections that launch system shells.
It also helps to deploy a Web Application Firewall that detects and blocks OGNL expressions. Correlate network logs with process activity to confirm intrusion attempts early.
Update AEM to version 6.5.0-0108 or later. Adobe confirmed that this patch fixes both CVE-2025-54253 and CVE-2025-54254. Disable or restrict access to /adminui/debug if you do not need it. Restrict access to trusted IP ranges only.
You can add server-side input validation to reject OGNL syntax and special characters. Enable strict filtering on all servlet parameters. Consider disabling OGNL evaluation entirely in non-development environments.
Apply a runtime application self-protection (RASP) tool or security agent to intercept malicious OGNL execution. Isolate AEM servers from internal databases or identity systems to limit damage.
Context and Lessons Learned
Adobe often fixes several AEM flaws at once. Security Bulletin APSB25-90 addresses these latest bugs. The new RCE issue resembles older Java web-framework vulnerabilities. For example, OGNL injection bugs in Apache Struts 2 (CVE-2017-9805) had similar execution paths.
Attackers continue to target enterprise content-management systems because they expose large attack surfaces. Debugging interfaces are particularly risky. They often remain enabled after deployment, providing direct access to system internals.
Organizations running AEM should adopt a strict configuration-review policy. Disable diagnostic endpoints and restrict access to administrative consoles.
Begin by listing all AEM servers in your environment. Check version numbers and confirm whether /adminui/debug is exposed. Patch all vulnerable systems within 24 hours.
After patching, verify that the endpoint no longer executes OGNL payloads. Over the next 48 hours, review access controls, enable logging, and enforce input filters. Continue to monitor server and network logs daily. Prepare forensic tools and backups in case new exploit variants appear.
FAQ
Q1: Can attackers exploit this flaw without logging in?
Yes. The debug servlet is open and does not require credentials.
Q2: Which AEM versions are vulnerable?
All releases up to 6.5.23.0 are affected. Adobe patched it in 6.5.0-0108.
Q3: Is there a public exploit?
Yes. Proof-of-concept code is available, and CISA confirms active attacks.
Q4: How can admins detect exploitation?
Review logs for suspicious POST requests to /adminui/debug and watch for unusual Java process activity.
Q5: What immediate step should defenders take?
Apply the latest Adobe patch and restrict or disable the debug endpoint.
One thought on “Understanding the AEM OGNL Remote Code Execution Flaw”