CISA has added one new vulnerability to its Known Exploited Vulnerabilities (KEV) Catalog, based on evidence of active exploitation.
Executive summary
- What happened: The Cybersecurity and Infrastructure Security Agency (CISA) added CVE‑2025‑54253 — a critical remote code‑execution vulnerability in Adobe Experience Manager (AEM) Forms — to its Known Exploited Vulnerabilities (KEV) Catalog.
- Why it matters: CVE‑2025‑54253 carries a Critical / CVSS 10.0 rating and allows unauthenticated, network‑accessible arbitrary code execution against AEM Forms installations up to and including 6.5.23.0. The vulnerability has a public proof‑of‑concept and has been widely discussed by vendor and vendor‑agnostic trackers.
- Immediate action: Organizations that run AEM Forms must treat this as a top‑priority remediation item — patch to the vendor‑supplied fixed version (AEM Forms on JEE 6.5.0‑0108) or apply vendor‑recommended mitigations and network isolation until patched.
Table of contents
- The KEV addition and operational impact
- What CVE‑2025‑54253 is — technical anatomy
- Timeline: discovery → advisory → public PoC → KEV listing
- Who’s affected and what to inventory now
- Recommended immediate steps (patching, mitigations, detection)
- Longer‑term risk management and hardening for AEM deployments
- What defenders should watch for (IOCs, TTPs, actor behavior)
- Closing analysis: why KEV matters and how organizations should respond
1) The KEV addition and operational impact
CISA’s Known Exploited Vulnerabilities (KEV) Catalog is a policy‑backed, operational list of CVEs for which there is credible evidence of exploitation in the wild; its purpose is to focus remediation efforts where exploitation is active and imminent. Under Binding Operational Directive (BOD) 22‑01, Federal Civilian Executive Branch (FCEB) agencies must remediate KEV‑listed vulnerabilities according to the catalog’s deadlines; although the legal directive applies to federal civilian agencies, the KEV list is a de‑facto prioritization signal for the private sector as well.
CISA’s action to add CVE‑2025‑54253 places this vulnerability into that operational spotlight. The practical consequences are immediate for organizations that host affected AEM Forms instances: accelerated patching timelines, prioritized tickets, and — where immediate patching is not possible — application of network restrictions or other compensating controls. The KEV addition should be treated as an “operate now” event for security and operations teams.
2) What CVE‑2025‑54253 is — technical anatomy
Vendor advisory — Adobe’s security bulletin (APSB25‑82) describes two critical issues in AEM Forms JEE: CVE‑2025‑54253 (a misconfiguration that permits arbitrary code execution) and CVE‑2025‑54254 (an XXE that permits arbitrary file read). For CVE‑2025‑54253 specifically, Adobe’s bulletin classifies the flaw as Misconfiguration (CWE‑16) and assigns a Critical, maximum‑impact rating (CVSS 10.0 in the vendor/NVD reports). The company published updates and recommended customers upgrade to the fixed AEM Forms on JEE release.
Independent vulnerability trackers and vulnerability databases (NVD, Tenable, CVE aggregators) concur: CVE‑2025‑54253 affects AEM Forms on JEE versions 6.5.23.0 and earlier, is remotely exploitable without authentication, and permits arbitrary command execution (full confidentiality/integrity/availability loss) when successfully weaponized.
How the exploit works (high level)
- Root cause: A misconfiguration in AEM’s Forms/JEE deployment — specifically, risky developer/Struts2 settings and/or deserialization handling combined with admin UI functionality — allows unauthenticated requests to reach functionality that processes serialized input or OGNL/expressions without proper validation.
- Attack vector: Network‑accessible HTTP requests to AEM Forms endpoints (e.g., a servlet in the FormServer/admin UI) carry specially crafted payloads (serialized Java payloads or expression content) that trigger serverside deserialization/expression evaluation, enabling remote code execution. Exploitation requires no user interaction and requires no prior privileges.
3) Timeline: discovery → advisory → public PoC → KEV listing
- Discovery and vendor advisory: Adobe published APSB25‑82 on August 5, 2025, documenting CVE‑2025‑54253 and CVE‑2025‑54254 and releasing a security update for AEM Forms on JEE. In that advisory Adobe explicitly noted awareness of publicly available proof‑of‑concept (PoC) code for both CVEs.
- Public analysis and research posts: Security researchers (including the named reporters listed in the Adobe bulletin) and several security vendors published technical analyses and PoC descriptions in August 2025. Independent posts described deserialization/Struts2 dev‑mode exploitation chains and sample ysoserial payloads in lab testing.
- Cataloging and tracking: NVD and other vulnerability trackers published CVE metadata in early August 2025 and recorded the maximum technical severity and affected product versions.
- KEV listing: CISA’s KEV Catalog now includes the vulnerability entry; CISA’s KEV announcements and related agency bulletins explain that catalog additions are evidence‑based actions intended to protect the federal enterprise. (The text you supplied is consistent with CISA’s enterprise alerts and the KEV process.)
4) Who’s affected and what to inventory now
Affected product: Adobe Experience Manager (AEM) Forms on Java EE — versions up to and including 6.5.23.0 — in standalone JEE deployments (AEM Forms on JEE). If you operate AEM Forms in that configuration, you are in scope. Adobe’s advisory lists the affected component versions and the fixed release to which you must upgrade.
Inventory checklist (high priority)
- List every environment running AEM/AEM Forms (on‑prem, private cloud, managed).
- Identify exact AEM Forms version numbers (6.5.23.0 and earlier are affected).
- Determine exposure: is the AEM Forms admin UI or FormServer endpoint reachable from untrusted networks (Internet, DMZ)? If so, treat as high risk.
- Check for risky configuration flags (developer/Struts2 dev mode enabled, endpoints that deserialize input, unsecured debug functionality).
- Identify whether any mitigations (network ACLs, WAF rules, reverse proxy blocks) are already in place. If not, plan immediate containment.
5) Recommended immediate steps (patching, mitigations, detection)
A. Patch / update (highest priority)
- Apply Adobe’s security update for AEM Forms (AEM Forms on JEE 6.5.0‑0108 or vendor‑specified fixed release) as soon as possible. Adobe classified these as Priority 1 (highest) updates. If you cannot apply the patch immediately, follow the compensating controls below.
- Block inbound access: Restrict network access to AEM Forms admin and FormServer endpoints so that only trusted admin IPs can reach them. If the instance is externally reachable, remove external access until patched.
- WAF / reverse proxy rules: Create and deploy WAF (web application firewall) rules to block requests containing obvious serialized payloads, OGNL expression patterns, or suspicious debug parameters. Note: WAF rules are a stopgap, not a replacement for patching.
- Disable risky dev/debug modes: If possible and safe to do in production, disable Struts developer mode, admin debug endpoints, and any unneeded developer utilities. Many real‑world incidents leverage developer flags left enabled in production.
- Search logs for suspicious inbound GET/POST requests that contain long base64 strings, serialized Java blobs, ysoserial‑style payload signatures, or unusual OGNL/Expression parameters to admin endpoints.
- Use vendor or commercial signatures (Qualys, Tenable, Wiz, etc.) to scan for the vulnerability and flag vulnerable hosts; Qualys and other scanners have added detections/QIDs for this issue.
- Hunt for post‑exploit indicators: web shells, new scheduled tasks, unusual outbound callbacks, or processes spawned by the AEM user. Given the nature of RCE, defenders should expect potential privilege escalation or persistence attempts.
- If you find evidence of exploitation (unexpected webshells, commands run, or outbound callbacks), invoke your incident response plan: isolate compromised hosts, preserve forensic images, and coordinate with legal and threat‑intelligence teams. Given CISA’s KEV addition, federal agencies have mandatory actions; private organizations should treat this as a highly actionable incident.
6) Longer‑term risk management and hardening for AEM deployments
- Configuration hardening: Treat Struts and any component that supports developer/debug modes as security‑sensitive. Ensure production images do not include developer flags, sample code, or unneeded modules. Perform baseline configuration reviews and automated checks.
- Patch cadence & automation: Implement an enterprise patching cadence for middleware/Java app stacks and vendor‑supplied CMS components. Where possible, automate detection of out‑of‑date AEM instances and orchestrate patch rollout windows.
- Network segmentation: Place AEM Forms instances behind restricted management networks; separate public web tiers from admin/management interfaces and limit cross‑tier communication.
- Application security testing: Include deserialization and expression injection tests in CI/CD and pre‑production pentests. Regularly run SCA/DAST/SAST for server‑side Java components and frameworks (Struts, etc.).
7) What defenders should watch for (IOCs, TTPs, actor behavior)
- Public PoC activity: Several PoCs were posted and discussed in August 2025; attackers commonly convert publicly available PoC into automated exploit scanners. Expect scanning and opportunistic attacks targeting internet‑exposed AEM Forms endpoints.
- Exploit patterns observed in research blogs: serialized Java payloads constructed with tools like ysoserial, URL‑encoded blobs delivered via HTTP GET/POST, and callbacks initiated when simple deserialization payloads succeed. Detection rules should look for these patterns.
- Post‑exploit behaviors: creation of web shells, unusual process spawning by the AEM user, persistence routines, outbound connections to command‑and‑control IPs, and lateral movement attempts. These are standard observables for RCE exploitation and should be part of your hunt playbook.
8) Closing analysis: why KEV matters and how organizations should respond
CISA’s KEV catalog exists to convert observed exploitation into operational urgency. When an entry like CVE‑2025‑54253 is added, the signal is clear: exploitation is credible and operationally relevant. Even organizations outside the federal remit should align their vulnerability management with KEV priorities because attackers rarely distinguish between federal and private targets.
Key takeaways
- Treat this as an immediate remediation priority. Apply Adobe’s patch (AEM Forms on JEE 6.5.0‑0108) where possible, and if you cannot patch immediately, use network isolation, WAF rules, and configuration changes to reduce exposure.
- Inventory and detect. Confirm every AEM Forms instance, check exposure and configuration, and scan with vendor‑supplied detection signatures.
- Assume scanning and opportunistic exploitation. With public PoCs available, the attack surface is actively probed; rapid, prioritized remediation is required to reduce risk.
- Produce a one‑page remediation checklist your IT and security teams can use to triage and patch AEM Forms instances (includes CLI commands, config checks, and WAF rule examples).
- Draft a short notification template for external hosting providers / MSPs to request patch confirmation and mitigation status.
- Create detection/signature examples (WAF rules, Sigma rules, YARA for web shells) tailored to the PoC patterns described in the research.
- Adobe security bulletin APSB25‑82 (AEM Forms advisory; vendor patch and technical details).
- NVD / CVE entry for CVE‑2025‑54253 (technical metadata and publication history).
- Qualys ThreatProtect analysis summarizing technical exploitation and mitigation recommendations.
- Multiple vulnerability trackers and vendor advisories (Tenable, Wiz, CVE aggregators) confirming severity, affected versions, and public PoC availability.
- CISA KEV process and recent KEV announcements; the CISA addition you referenced (CISA alert listing the KEV entry) and KEV/BOD context.
- I attempted to fetch the live CISA news/alert page at the exact URL you provided; the site returned a “Page Not Found” when retrieved programmatically at the time of the check. The text you provided matches standard CISA KEV alert wording and is consistent with the agency’s KEV process; corroboration for the vulnerability itself and its operational severity comes from Adobe’s APSB25‑82 advisory and multiple independent vulnerability trackers cited above. If you need, I can re‑attempt live retrieval of the CISA page or fetch archived copies to capture the exact KEV listing text and the formal remediation due date (KEV entries usually include a remediation deadline for federal agencies).
Horizontal rule
Thank you — if you’d like, I will:
- Generate the concise remediation checklist now (recommended for ops teams), or
- Draft email and bulletin templates for communicating this to stakeholders (managed hosting, application owners, SOC/IR), or
- Build hunting queries (Splunk/Sigma/ELK) and WAF rule examples tuned to the public PoC payload patterns.
Source: CISA CISA Adds One Known Exploited Vulnerability to Catalog | CISA
