It’s time for every organization running Adobe Experience Manager Forms (AEM Forms) to sit up and take stock. Two critical vulnerabilities, CVE-2025-54253 (CVSS 10.0) and CVE-2025-54254 (CVSS 8.6), have emerged from misconfiguration and insecure XML handling (Adobe, 2025).
One allows unauthenticated remote code execution. The other permits arbitrary file reads from the host system. Combined, they create a low-friction, high-impact path into enterprise infrastructure.
The issue is buried in how AEM Forms on JEE versions 6.5.23 and earlier manage authentication and expose development configurations. Specifically, the Struts DevMode feature was left active in many production environments, effectively bypassing authentication and allowing unauthenticated remote code execution (RCE) via OGNL injection. It’s the kind of architectural oversight that only becomes fatal when paired with administrative exposure, and that’s precisely what’s happened here. The accompanying vulnerability, CVE-2025-54254, compounds the risk by enabling arbitrary file read through improperly restricted XML External Entities (XXE). Together, the vulnerabilities form a dual-threat vector: initial access via RCE, followed by lateral movement or data exfiltration using XXE. These are textbook preconditions for ransomware staging or persistence implants.
In response, the Cybersecurity & Infrastructure Security Agency (CISA) has added CVE-2025-54253 to its Known Exploited Vulnerabilities (KEV) catalog and issued a directive giving U.S. federal civilian agencies until November 5, 2025, to remediate or otherwise mitigate the threat (CISA, 2025). Meanwhile, Adobe Systems Incorporated released an out-of-band hot-fix (version 6.5.0-0108) on August 5, 2025, covering both vulnerabilities for AEM Forms deployments.
Searchlight Cyber disclosed both flaws in April. Adobe patched one (CVE-2025-49533) but delayed addressing the others for over 90 days, until after public proof-of-concept (PoC) exploits emerged in July (Searchlight Cyber, 2025). That gap between disclosure and patch allowed threat actors ample time to operationalize attack paths. By August, exploit attempts were seen in scanning traffic. By mid-October, CISA had confirmed in-the-wild exploitation and added CVE-2025-54253 to its Known Exploited Vulnerabilities (KEV) catalog.
Why does this matter beyond the patch bulletin? AEM Forms is embedded deep in public and private digital infrastructure. It’s used by governments to manage citizen-facing workflows, by healthcare systems to handle e-forms for patient records, and by financial institutions for onboarding and compliance. In many environments, AEM Forms has privileged API access, file system visibility, and trust relationships with back-end systems, making it a high-value breach point.
The consequences aren’t limited to defacement or denial-of-service. Exploiting CVE-2025-54253 means executing arbitrary code with the permissions of the AEM process, often root or admin, inside application tiers that bridge user interaction and core services. This opens pathways to database tampering, data exfiltration, or deploying persistence mechanisms in Java-based infrastructure.
Start by identifying every instance of AEM Forms on JEE (version 6.5.23.0 or earlier) across your environment: production, staging, test, or partner-managed. Apply the latest Adobe patch (6.5.0-0108) without delay. If immediate patching isn’t feasible, isolate exposed endpoints, especially admin UIs, and disable Struts DevMode to reduce exposure. Review your configurations thoroughly: disable XML entity resolution, harden input handling, and lock down default settings. Set up monitoring for serialized payloads, OGNL expression usage, and unusual file access patterns that could signal active exploitation.
Then zoom out to understand what systems AEM Forms integrates with, what data it touches, and what downstream workflows could be affected. If service providers or vendors operate your AEM Forms, confirm their patch and response status. Finally, frame the risk clearly for leadership: this is a zero-click, publicly known vulnerability with proof-of-concept exploits in circulation.
Patch speed is only one part of resilience. The greater challenge lies in identifying which tools operate below the visibility threshold: rethinking how such tools are architected, segmented, and monitored. Organizations that assume “nothing here is internet‑facing” or “this is just a forms engine” risk being caught off guard.