Vulnerabilities in AEM Forms

The Searchlight Cyber Research Team discovered and disclosed three critical vulnerabilities in Adobe Experience Manager Forms to Adobe in late April 2025.

As of writing this research post, 90 days have passed since our disclosure to Adobe. During this time, Adobe has only released a patch for one of the three critical vulnerabilities, the insecure deserialization vulnerability leading to command execution (CVE-2025-49533). Their official advice for this vulnerability can be found here.

The remaining two vulnerabilities, including the authentication bypass to RCE chain via Struts2 devmode (SL-AEM-FORMS-1) and the XXE within AEM Forms web services (SL-AEM-FORMS-2), do not have publicly available patches or remediation advice.

We strongly recommend restricting access to Adobe Experience Manager Forms from the external internet when deployed as a standalone application.

Update August 6, 2025:

Adobe has published a fix for the remaining two vulnerabilities, tracked as CVE-2025-54253 (RCE via Struts DevMode) and CVE-2025-54254 (XXE). The security bulletin with update instructions can be found here.

The Aura of Default Deployment Pages

When examining an attack surface, we often encounter situations where the technologies deployed on an asset are not immediately apparent. We see this frequently when assets expose the default IIS page or the default Tomcat page. Whenever we come across assets like these, we usually find some obscure technology that has been nested several levels deep in a directory structure perspective.

These technologies are often tricky to fingerprint and pose a significant blind spot on most attack surfaces. Due to this, we've taken a keen interest in uncovering some of these technologies and spending time to investigate the security of applications deployed in a way that most traditional scanners would miss.

Identifying Adobe Experience Manager Forms

Since our technology detection goes beyond just the document root for our customers' assets, we identified that this asset was running Adobe Experience Manager Forms via a request made to /lc/libs/livecycle/core/content/login.html, which returns the login interface for this product. Similarly, a call to /edcws/ reveals several exposed web services specific to AEM Forms.

Adobe Experience Manager Forms can be deployed in two different ways: either it is co-deployed with your standard AEM installation, or it is deployed standalone on a J2EE-compatible server. The vulnerabilities we detail in this blog are primarily applicable to standalone deployments of AEM Forms via a J2EE-compatible server such as JBoss.

A Fairly Standard Insecure Deserialization Vulnerability (CVE-2025-49533)

In a JBoss environment, application bundles are typically deployed in the format of .EAR files. These files contain a mapping for each WAR file and their location accessible on the web server. This mapping file is typically found at META-INF/application.xml. For the case of AEM forms, as we systematically worked through the WAR files and their exposed servlets, we came across the following module:

<module> <web> <web-uri>adobe-forms-res.war</web-uri> <context-root>/FormServer</context-root> </web></module>

The web.xml of this FormServer module had the following entry:

<servlet> <servlet-name>GetDocumentServlet</servlet-name> <servlet-class>com.adobe.formServer.GetDocumentServlet</servlet-class></servlet>

This servlet's doGet method reads a serDoc request parameter, base64-decodes and gunzips it, then passes the result into an ObjectInputStream.readObject() call with no validation of the incoming class types — a classic Java insecure deserialization sink.

To exploit this, the research team used ysoserial to generate a CommonsBeanutils1 gadget chain payload. An initial attempt failed because a required Xalan class was not on the classpath in its default namespace; passing the -DproperXalan=true flag to ysoserial resolved this by targeting the correct package. The resulting payload, sent to the GetDocumentServlet endpoint via the serDoc parameter, triggered an out-of-band DNS callback confirming remote code execution.

All in all, this was a fairly standard Java insecure deserialization issue that resulted in command execution. Besides the encoding and the use of an additional flag when calling ysoserial to enable "properXalan", it was surprising to us that this vulnerability had been lurking in this codebase for so long.

An Even More Standard XXE (SL-AEM-FORMS-1)

Given the straightforward nature of the deserialization to RCE chain, we were confident that this product had additional security issues. As we worked through the various exposed web applications, we started to get curious about the Axis-based web services exposed for AEM Forms. We started looking at edc-webservice.war, which is mapped to /edcws on AEM Forms standalone servers.

Although this module utilizes Apache Axis, its authentication handling is entirely custom. Unfortunately, the authentication mechanism for the web services themselves loaded an XML document in an insecure manner, making this XXE vulnerability exploitable without authentication. The SecurityCheckHandler class parses an EDCSecurity SOAP header value directly with a namespace-aware DOM parser, without disabling external entity resolution.

The team exploited this by crafting a SOAP request containing a malicious DOCTYPE declaration within the EDCSecurity header, using an external DTD to trigger an out-of-band XXE that read local files (such as C:\Windows\win.ini) and leaked their contents back through a SOAP fault error message in the HTTP response.

Struts2 Devmode in 2025?! (SL-AEM-FORMS-2)

As we audited all the different modules inside AEM Forms, we identified a relatively simple authentication bypass vulnerability within one of the filters used for enforcing authentication. Despite the name of the filter being com.adobe.framework.SecurityFilter, it allowed any request whose URL contained the timeout page, fail page, or the string "login." to pass straight through without authentication.

This "security filter" was the only real thing preventing access to the endpoints of the adminui.war module, deployed under /adminui. To make matters worse, the Struts config of this module indicated that Struts2 Devmode had been left enabled (presumably forgotten about by the developers at Adobe), before shipping this product to enterprise customers.

Combining the authentication bypass vulnerability and the fact that Struts devmode had been left enabled, OGNL expressions became executable through the debug command interface of the admin UI. It is trivial to escalate this to remote command execution through the many public sandbox bypasses available for Struts OGNL injection. In this case, the team was dealing with a rather complex WAF, and since the payload was within the GET request's first line component, some creativity was required to achieve RCE.

Conclusion

All the vulnerabilities disclosed in AEM Forms are not complex. Instead, these issues are what we would expect to have been discovered years ago. Previously known as LiveCycle, this product line has been in use by enterprises for almost two decades. That raises the question of why these simple vulnerabilities had not been caught by others or fixed by Adobe. Seeing Struts DevMode enabled in an enterprise application by default was also a surprise to us, given how easily it can be escalated to RCE.

Given the numerous vulnerabilities discovered and the lack of patches for the XXE and authentication bypass vulnerabilities leading to a RCE chain, we strongly recommend that customers using AEM Forms in standalone mode restrict access to this application to internal users/networks only.

Update August 6, 2025:

Adobe has published a fix for the remaining two vulnerabilities, tracked as CVE-2025-54253 (RCE via Struts DevMode) and CVE-2025-54254 (XXE). The security bulletin with update instructions can be found here.

Timeline

• 28th April 2025: We send our initial disclosure to Adobe via psirt@adobe.com
• 13th May 2025: We send a follow-up & additional notes to Adobe
• 13th May 2025: Reached out-of-band to an Adobe employee on their security team, asking for them to take a look at the reported issues
• 14th May 2025: Adobe assigns VULN-31606 to the AEM Forms reports
• 11th June 2025: Adobe responds to email chain with details about a patch for a completely different set of vulnerabilities
• 11th June 2025: We ask for clarification about what vulnerabilities they are referring to, as they are not related to AEM Forms
• 13th June 2025: Adobe apologizes and provides a status on the reported vulnerabilities for AEM Forms (in progress)
• 22nd July 2025: We remind Adobe of the 90-day disclosure deadline for the AEM Forms bugs
• 26th July 2025: We remind Adobe again of the upcoming disclosure since we received no response
• 28th July 2025: We remind Adobe for the last time of the upcoming disclosure since we received no response
• 5th August 2025: Adobe publishes a security bulletin with fixes for the remaining vulnerabilities