Adobe Experience Manager faces critical security vulnerabilities that demand immediate patching, though the specific claim of affecting 45 million sites cannot be verified from official sources. Two actively exploited vulnerabilities—CVE-2025-54253 (a Remote Code Execution flaw in AEM Forms) and CVE-2025-54254 (an XML External Entity injection)—pose genuine risks to organizations running affected versions.
For example, a company using Adobe AEM Forms on JEE version 6.5.23.0 or earlier without the August 2025 patch exposes itself to attackers who can execute arbitrary code and bypass authentication controls without requiring user interaction. The vulnerabilities stem from misconfigurations in Adobe AEM Forms on JEE where Apache Struts “devMode” remains enabled, creating a gateway for remote attackers. The Cybersecurity and Infrastructure Security Agency (CISA) has mandated that federal civilian agencies patch these vulnerabilities by November 5, 2025, underscoring the severity of these flaws in mission-critical systems.
Table of Contents
- What Are These Adobe AEM Vulnerabilities and Why Should You Care?
- Which Versions of Adobe AEM Are Vulnerable?
- How Are These Vulnerabilities Being Exploited in Practice?
- What Should Web Developers and Site Administrators Do Right Now?
- What Are the Potential Consequences of Leaving Systems Unpatched?
- Industry Context and Historical Parallels
- Looking Forward—Building Resilience Beyond Patching
- Conclusion
- Frequently Asked Questions
What Are These Adobe AEM Vulnerabilities and Why Should You Care?
CVE-2025-54253 represents a remote code execution vulnerability arising from a dangerous combination of misconfigurations. The vulnerability exists where the Apache Struts framework’s development mode remains active in production deployments, coupled with an authentication bypass mechanism that allows attackers to access functions they shouldn’t reach. Unlike vulnerabilities that require user interaction—such as phishing attacks or malicious file downloads—this flaw allows attackers to penetrate systems silently and with precision. Real-world exploitation has already been documented in the wild, meaning threat actors are actively weaponizing this vulnerability against unprepared organizations. CVE-2025-54254 compounds the problem through XML External Entity (XXE) injection, another pathway to arbitrary code execution.
XXE vulnerabilities exploit how XML parsers process external entity definitions, potentially allowing attackers to read sensitive files, execute commands, or launch denial-of-service attacks. The combination of these two CVEs creates a layered attack surface: if one vector is blocked, a second remains available. This redundancy makes patching essential rather than optional. The limitation of existing reports is that while these vulnerabilities are confirmed and actively exploited, the aggregate impact across all affected organizations remains difficult to quantify precisely. Security researchers and Adobe itself have not published verified statistics on the total number of websites or systems affected globally, making broad claims about “45 million sites” speculative without primary source documentation.
Which Versions of Adobe AEM Are Vulnerable?
Adobe AEM Forms on JEE versions 6.5.23.0 and earlier contain both critical vulnerabilities. Organizations running AEM 6.5.0 through 6.5.23.0 are at risk, while those who have already updated to version 6.5.0-0108 or later have the necessary patches applied. This version boundary is important because legacy systems deployed years ago may still run versions from the 6.5.x line and could easily fall into the vulnerable range. The August 6, 2025 patch date marks when Adobe issued security bulletin APSB25-82, publicly disclosing the vulnerabilities and providing fixes. However, the existence of a publicly available patch does not guarantee that all affected organizations have applied it.
Many enterprises operate under change management protocols that require testing periods, maintenance windows, and stakeholder approval before deploying security updates—processes that can delay patching for weeks or months. During this window, unpatched systems remain exposed to active exploitation. A critical warning: organizations cannot assume their AEM deployment is secure based solely on running AEM 6.5.x. The specific minor version number determines vulnerability status. A site running 6.5.15.0 is vulnerable, while one running 6.5.0-0108 is protected. This granular version distinction means that organizations must verify their exact patch level rather than relying on general version assumptions.
How Are These Vulnerabilities Being Exploited in Practice?
Public Proof-of-Concept (PoC) code has been released for CVE-2025-54254, allowing security researchers and malicious actors alike to test systems for vulnerability. The availability of PoC exploits significantly lowers the barrier to entry for attackers, as they no longer need to develop custom attack code from scratch. Instead, they can download, modify, and deploy published exploits against target organizations. This is particularly dangerous for smaller organizations or those with limited security budgets, as they face the same sophisticated attack tools as enterprise targets. Real-world exploitation patterns suggest attackers are scanning the internet for AEM instances, identifying those running vulnerable versions, and attempting to deploy web shells or establish persistence mechanisms.
A typical attack flow involves using the devMode authentication bypass to reach administrative functions, then leveraging XXE injection to read configuration files containing database credentials or other sensitive data. Once attackers gain initial access, they can escalate privileges, move laterally through the network, or exfiltrate valuable data. The threat extends beyond direct code execution. Compromised AEM instances often serve as launch points for attacks against downstream systems, including databases, user directories, and internal networks. An attacker who gains access to an AEM instance used for customer-facing content delivery could also inject malicious code into web pages, effectively compromising all visitors to affected websites.
What Should Web Developers and Site Administrators Do Right Now?
Organizations must prioritize three immediate actions: inventory all AEM deployments and document their exact version numbers, test patches in staging environments to ensure compatibility with existing extensions and content, and schedule patching across production systems according to their change management protocols. Unlike some security updates that can wait, the active exploitation of these vulnerabilities argues for accelerating timelines where possible. The federal government’s November 5, 2025 deadline for civilian agencies provides a reference point, but commercial organizations should not wait until that date. Every day an unpatched system remains in production increases the likelihood of compromise.
The tradeoff between rapid deployment and thorough testing can be balanced by prioritizing customer-facing AEM instances first, followed by internal-only systems, then development and staging environments. For organizations using managed AEM services or cloud deployments, patching responsibility may rest partially with the hosting provider. However, site administrators should verify patch status directly rather than assuming protection. Contact your hosting provider or system administrator to confirm the exact patch level running in your environment.
What Are the Potential Consequences of Leaving Systems Unpatched?
Organizations that fail to patch face tangible risks: data breaches exposing customer information, website defacement, installation of persistent malware, intellectual property theft, and service disruptions. In regulated industries like finance, healthcare, or government, a breach stemming from an unpatched known vulnerability carries additional legal and compliance consequences. Regulators and auditors increasingly scrutinize organizations for delayed patching of critical vulnerabilities, particularly when public exploits exist.
A significant limitation in many organizations’ security posture is the gap between awareness and action. Security teams may be aware of the vulnerability, but procurement delays, testing complications, or organizational bureaucracy can create months-long delays in patching. This window of vulnerability is where most exploitation occurs. Additionally, organizations running custom extensions or heavily modified AEM configurations may encounter compatibility issues during patching, forcing them to choose between security and functionality—a situation that requires careful planning and testing.
Industry Context and Historical Parallels
Adobe products have been frequent targets for vulnerability exploitation, from Flash vulnerabilities to recent ColdFusion flaws. The AEM vulnerabilities follow a similar pattern: enterprise software with complex configurations, numerous deployment variations, and large user bases means patches cannot be deployed instantaneously across all affected systems.
Historical data from previous critical vulnerabilities shows that exploitation typically accelerates 2-3 weeks after patch release and public disclosure, then remains elevated for months or years as new systems come online and legacy systems remain unpatched. An informative comparison: organizations that quickly patched Log4Shell vulnerabilities (CVE-2021-44228) within days or weeks avoided most exploitation, while those that delayed months faced breaches. The lesson applies directly here—rapid patching of critical, actively exploited vulnerabilities yields better security outcomes than delayed patching cycles.
Looking Forward—Building Resilience Beyond Patching
While patching addresses the immediate vulnerability, organizations should implement complementary controls: network segmentation to limit lateral movement if AEM systems are compromised, web application firewalls to detect and block exploit attempts, security monitoring to identify suspicious AEM activity, and regular vulnerability scanning to catch other weaknesses before they’re exploited. These layers don’t replace patching but significantly reduce the damage potential if a breach occurs.
The broader lesson is that vulnerabilities in widely-deployed enterprise software like Adobe AEM warrant expedited patching even before supply-chain risks materialize. Building a security culture that treats critical patches as urgent maintenance rather than optional updates protects organizations from becoming victims of easily preventable breaches.
Conclusion
Adobe Experience Manager vulnerabilities CVE-2025-54253 and CVE-2025-54254 represent genuine, actively exploited security risks for organizations running AEM Forms on JEE versions 6.5.23.0 and earlier. While the specific claim of affecting 45 million sites lacks verification from official sources, the fact that CISA mandated patching for federal agencies underscores the seriousness of these flaws. The available patch (version 6.5.0-0108 and later) and established patch date (August 6, 2025) provide clear remediation guidance.
Organizations should verify their current AEM version, test patches in controlled environments, and deploy updates according to their risk tolerance and change management procedures. Delaying patching of actively exploited critical vulnerabilities is a high-risk strategy with potential consequences ranging from data loss to regulatory penalties. The time to patch is now, not November.
Frequently Asked Questions
How do I check which version of Adobe AEM I’m running?
Access your AEM instance’s administration console or check the instance properties. The version number is typically displayed in the system information or instance settings section. Document the exact version (including any service pack or hotfix numbers), as this determines your vulnerability status.
Can I patch AEM without downtime?
Most patching approaches require taking the AEM instance offline, though the specific downtime depends on your deployment configuration and the patch installation method. Consult Adobe’s patching documentation and test the process in staging environments to estimate actual downtime for your organization.
What if I’m using a managed AEM cloud service?
Contact your hosting provider or Adobe support to confirm patch status. Managed services may patch automatically or require explicit action from your organization. Verify in writing that your instances have been patched to version 6.5.0-0108 or later.
Are AEM instances on Java versions other than JEE vulnerable?
These specific CVEs affect AEM Forms on JEE. Verify your exact AEM deployment type and Java stack with your system administrator to confirm vulnerability status for your specific configuration.
What if I’ve already been compromised?
Contact your incident response team or a security professional immediately. Patching alone won’t remove existing malware or attacker access. A full security investigation, threat hunting, and remediation process is necessary.
Why hasn’t my provider notified me about this vulnerability?
Hosting providers vary in their notification practices. Proactively contact your provider rather than waiting, especially if you cannot verify your patch status through your own administrative access.
