Security Patch - September 2025 - Jahia 8.1

Vulnerabilities

Jahia is impacted by recently disclosed vulnerabilities in the following libraries:

• Apache Commons Beanutils – [CVE-2025-48734]: Remote Code Execution
• Apache Tomcat
  • [CVE-2025-48988]: Denial of Service on crafted multipart requests
  • [CVE-2025-52520]: Denial of Service on crafted multipart upload
• Apache Commons FileUpload – [CVE-2025-48976]: Denial of Service on file upload

• Jackson Core – [CVE-2025-52999]: Denial of Service in YAML processing

It was also discovered that Jahia was vulnerable to:

• A risk of DoS related to file upload. Not directly related to Apache Commons FileUpload CVE, this vulnerability is related to the way Jahia is handling file upload and could make Jahia vulnerable to DoS attacks.
• A CSRF vulnerability in the /modules/api/bundles endpoint

• A risk of DoS with GraphQL introspection

Affected versions

• Jahia 8.1: All versions up to and including 8.1.8.3

Versions of Jahia released in or after August 2025 are not affected.

Addressing the vulnerability

The recommended method for addressing the vulnerability is to upgrade to Jahia 8.1.9.0 or Jahia 8.2.2.0.

These two releases of Jahia are specifically oriented towards security. Jahia 8.1.9.0 is expected to be easy to adopt for environments running Jahia 8.1, while Jahia 8.2.2.0 can be adopted following our upgrade guide.

Partial Mitigation

A partial mitigation is available for environments needing more time to adopt a recent release of Jahia.

This mitigation was tested with Jahia 8.1.3.1, 8.1.5.0, 8.1.6.2, 8.1.7.3, 8.1.8.3

Vulnerability	Mitigation Available
Apache Commons Beanutils	✅ YES
Apache Tomcat	✅ YES
DoS risk related to file upload	✅ YES
DoS risk related to GraphQL introspection	❌ NO
DoS risk related to Jackson Core	❌ NO
CSRF vulnerability in /modules/api/bundles	✅ YES

Vulnerability in Apache Commons Beanutils

This operation is to be performed on every single node of your cluster.

1. Download commons-beanutils-1.11.0.jar (MD5: 32ed51f196dfda19e0dc1ce53eeed29e)
2. Make sure to have a proper backup
3. Stop tomcat
4. Remove common-beanutils-*.jar lib files from the tomcat/webapps/ROOT/WEB-INF/lib folder
5. Add commons-beanutils-1.11.0.jar into the tomcat/webapps/ROOT/WEB-INF/lib folder
6. Start tomcat

Verifying the update

 To verify the Apache Commons Beanutils upgrade, you need to verify that version 1.11.0 is present on your system.

To do so, open the Groovy console in the tools  (/modules/tools/groovyConsole.jsp) and execute the following Groovy script, which will display the version in use:

Class beanutilsClass = org.apache.commons.beanutils.BeanUtils.class
String classPath = beanutilsClass.getResource(beanutilsClass.getSimpleName() + ".class").toString()
println("Lib: " + classPath.substring(0, classPath.lastIndexOf("!")))

Vulnerability Apache Tomcat

Upgrade to Apache Tomcat 9.0.107 by following the Tomcat Upgrade Documentation available on the academy.

DoS risk related to file upload

A dedicated module, called guest-multipart-filter was released to provide a mitigation by preventing guest users (unauthenticated) from making multipart requests.

1. Download guest-multipart-filter 1.0.0 from Jahia maven repository (MD5: c15841e8bb3733d27003b5f4673dde7a)
2. Using Jahia module manager (or provisioning API), install it on your environment

Once installed, an HTTP code 403 will be returned when uploading files without authentication. 

Verifying the fix

The fix will prevent files from being uploaded to Jahia's tmp directory.

Open the Groovy console in the tools (/modules/tools/groovyConsole.js) and execute the following Groovy script, which will display the path to Jahia tmp directory:

return SettingsBean.getInstance().getTmpContentDiskPath();

To verify the fix, update the commands below to match your environment, specifically:

• by providing a valid URL (any URL is fine, it does not have to contain a file upload form).
• by replacing myFile.txt with a file present in the directory. Make sure to use a file big enough to be able to monitor its progress during upload, a size of 200MB should be sufficient.

Verify that authenticated calls are not rejected

Begin by executing this curl command (adjust username/password accordingly)

curl -X POST \
  -u "user:password" \
  -F "file=@myFile.txt" \
  http://localhost:8080/sites/mySite/home.html

While the curl command is running, check for the presence of a temporary file in Jahia tmp directory (using the path you collected when executing the Groovy script), you will notice that this file continuously grow as the upload progress and will be automatically deleted from the tmp directory once the upload is complete.

Verify that anonymous calls are rejected

Now repeat the same procedure but without providing credentials.

curl -X POST \
 -F "file=@myFile.txt" \
 http://localhost:8080/sites/mySite/home.html

This time, the request should be rejected immediately and no file should be present in Jahia tmp directory.

CSRF vulnerability in /modules/api/bundles

It is advised to block access to the API URL /modules/api/bundles . This can be achieved, for example, by using a proxy (HAProxy, Apache2, etc.)

If you use this endpoint to deploy modules, here are some suggestions:

• If possible, consider using the provisioning API instead of the bundles API (cf this documentation) so you won't be impacted by the blocking
• If your CI/CD pipeline is triggered from specific and identifiable IP addresses, it is possible to keep the endpoint /modules/api/bundles open only for those specific IP addresses. It is probably the quickest and easiest mitigation, as long as you can restrict the access to only a handful of IP addresses.