CVE-2025-54253

What it actually does

Adobe Experience Manager 6.5.23 and earlier contains a critical misconfiguration that can allow an unauthenticated or low-privileged remote attacker to bypass intended security controls and execute arbitrary code on the server. Successful exploitation changes security scope because code runs in the context of the affected AEM/AEM Forms application or underlying Java application server, potentially allowing command execution, web shell deployment, data access, lateral movement, and persistence.

Why it matters to the business

A vulnerable internet-facing Adobe Experience Manager deployment can be taken over remotely without user interaction. Because this issue has a CVSS score of 10.0, high EPSS likelihood, and is listed in CISA KEV with active exploitation observed in the wild, organizations should treat exposure as an urgent incident-risk condition. Compromise can disrupt customer-facing digital experience platforms, expose hosted content and form data, enable credential theft, and provide attackers a foothold into connected enterprise systems. CISA-listed systems should be remediated by the KEV due date of 2025-11-05 or sooner.

How an attack unfolds

An attacker first identifies an exposed Adobe Experience Manager or AEM Forms instance running version 6.5.23 or earlier. They then send crafted HTTP requests to an affected application endpoint that abuses the misconfiguration to bypass normal security checks. Once the bypass succeeds, the attacker causes the server-side Java application to execute attacker-controlled code. From there, the attacker may run operating-system commands, write a web shell or malicious package, enumerate local configuration files and secrets, access repository content, create persistence through bundles or scheduled tasks, and pivot using credentials available to the application. Public reporting and KEV inclusion indicate active exploitation of the Adobe Experience Manager Forms code execution vulnerability, so exposed systems should be assessed for compromise, not only patched.

How to fix it

Upgrade Adobe Experience Manager and AEM Forms to a vendor-supported fixed release or apply the Adobe security update/hotfix that remediates this vulnerability; versions 6.5.23 and earlier should be considered vulnerable. If exact fixed package versions are managed separately, verify against Adobe’s security bulletin and deploy the latest applicable AEM 6.5 service pack/cumulative fix pack and AEM Forms add-on/JEE patches. Remove direct internet exposure for author, admin, package manager, CRX, Felix console, AEM Forms administration, and application-server management endpoints. Enforce authentication, network allowlisting, reverse-proxy controls, and WAF rules for administrative and form-processing paths. Disable unnecessary consoles, debug functionality, sample applications, and legacy endpoints. Rotate secrets and service credentials stored on or accessible from affected hosts if compromise is suspected. Because active exploitation is reported, perform compromise assessment before returning patched systems to normal service.

How to confirm the fix worked

Confirm all AEM and AEM Forms nodes report a version newer than 6.5.23 or show the Adobe security fix level that remediates the issue. Validate both author and publish tiers, all dispatcher-connected instances, and any AEM Forms on JEE nodes. Review installed packages, OSGi bundles, service packs, and application-server deployments to ensure the patch is consistently applied across clustered nodes. From an external network position, verify that administrative endpoints such as CRX, package manager, Felix console, AEM Forms administration, and application-server consoles are not publicly reachable. Run authenticated configuration checks to confirm debug or insecure administrative features are disabled. After patching, monitor logs for failed exploit attempts and run file-integrity or EDR checks to ensure no suspicious web shells, bundles, startup scripts, or unauthorized packages remain.

Typical attack path

1. Scan the internet or target address ranges for exposed Adobe Experience Manager or AEM Forms services.
2. Fingerprint the service version, exposed endpoints, response headers, login pages, or AEM-specific paths.
3. Send crafted requests that abuse the misconfiguration to bypass security controls.
4. Trigger server-side code execution under the AEM, AEM Forms, or Java application server process account.
5. Run discovery commands to identify OS user, hostname, file paths, network access, and secrets.
6. Deploy persistence such as a web shell, malicious OSGi bundle, modified package, startup script, or scheduled task.
7. Access or exfiltrate repository content, form data, configuration files, keys, tokens, or service credentials.
8. Use stolen credentials or network reachability to move laterally to connected systems.

How to detect it

Hunt across web server, reverse proxy, WAF, load balancer, AEM request/access logs, AEM error logs, application-server logs, EDR telemetry, OS audit logs, and file-integrity monitoring. Focus on unexpected requests to AEM administrative or AEM Forms endpoints, especially from unfamiliar external IPs, requests with encoded payloads, command syntax, scripting language fragments, or abnormal POST activity. Review AEM logs such as request.log, access.log, error.log, audit logs, package installation logs, OSGi bundle events, and application-server stdout/stderr for exceptions or execution traces around suspicious requests. On hosts, look for Java processes spawning shells, PowerShell, cmd.exe, bash, sh, curl, wget, certutil, python, perl, or other utilities not normally launched by AEM. Inspect repository and filesystem locations for newly created JSPs, WARs, JARs, OSGi bundles, packages, or modified startup scripts. Review authentication and authorization events for new users, changed groups, new service accounts, or unexplained administrative actions. Because public reporting names active exploitation of the Adobe Experience Manager Forms code execution vulnerability, correlate suspicious web requests with subsequent process creation, file writes, outbound network connections, and credential access from the same host.

• POST /crx/packmgr/service.jsp
• POST /crx/packmgr/service/.json
• GET /crx/de/index.jsp
• POST /crx/de/index.jsp
• GET /system/console/bundles
• POST /system/console/bundles
• GET /system/console/configMgr
• POST /system/console/configMgr
• GET /libs/granite/core/content/login.html
• /adminui/
• /lc/
• /soap/services/
• /rest/services/
• java.lang.Runtime.getRuntime().exec
• java.lang.ProcessBuilder
• cmd.exe /c
• powershell -enc
• powershell -EncodedCommand
• /bin/bash -c
• /bin/sh -c
• curl http
• wget http
• certutil -urlcache
• java spawned cmd.exe
• java spawned powershell.exe
• java spawned /bin/sh
• java spawned /bin/bash
• .jsp?cmd=
• cmd=
• whoami
• id; uname -a
• /crx-quickstart/install/
• /crx-quickstart/launchpad/felix/
• /crx-quickstart/repository/
• /crx/packmgr/index.jsp
• /system/console
• /etc/packages/

What your security team should do

• Immediately inventory all Adobe Experience Manager and AEM Forms deployments, including author, publish, dispatcher, and JEE/application-server nodes.
• Prioritize any internet-facing instance running 6.5.23 or earlier for emergency patching or isolation.
• Meet or beat the CISA KEV remediation deadline of 2025-11-05 for applicable systems; do not wait for routine maintenance windows on exposed systems.
• If patching cannot be completed immediately, restrict access to AEM administrative and AEM Forms endpoints by VPN, private network, IP allowlist, or reverse-proxy policy.
• Perform retrospective threat hunting for exploitation because the issue is known to be actively exploited in the wild and has a high EPSS probability.
• Review Java process lineage for suspicious child processes and investigate any shell, PowerShell, curl, wget, or scripting activity spawned by the AEM/application-server process.
• Inspect AEM packages, OSGi bundles, repository changes, web roots, and application-server deployment directories for unauthorized modifications.
• Rotate application secrets, repository credentials, service-account passwords, API keys, and downstream integration credentials if exploitation cannot be ruled out.
• Add WAF/SIEM detections for suspicious requests to AEM administrative, package, CRX, Felix, and AEM Forms paths, especially requests containing command-execution syntax or encoded payloads.
• Preserve logs and forensic artifacts before rebuilding or cleaning systems suspected of compromise.