As part of our security review process, we constantly review new vulnerabilities in 3rd party libraries used in our ecosystem of products.
The goal of this page is to communicate the results of our investigations, it provides a summary of known vulnerabilities (CVEs) identified in third-party libraries included with products built by Jahia.
It is important to note that a CVE on a third party library means that the library is affected by a vulnerability. But the presence of a vulnerable library does not necessarily mean the product itself using this library is vulnerable. In many cases, the affected part of the library is not used at all by our software.
The primary content available on this page is a table of all of the open and analyzed CVEs present in current versions of our products, including versions currently in development. These are CVEs we reviewed, analyzed, and for which we've evaluated their impact on our products. The scope of our analysis (what is analyzed, what is not) is detailed on this page.
The table and report are refreshed automatically and regularly, we do our best to provide detailed and up-to-date information about our review of publicly known vulnerabilities. If you have questions or need clarification on any analysis, please don't hesitate to contact our support team for assistance.
To facilitate readability, our analysis are classified in four levels:
✅ Not Affected: The vulnerability detailed in the CVE is not affecting Jahia or its product.
⚠️ Affected: The product is affected by the vulnerability
⚠️ Please review: Although the product itself is not vulnerable your own implementation or own deployment might be. It is recommended to review the analysis.
⏳ In Progress: The CVE is currently under review and/or is currently being addressed by our team.
Detailed, machine-readable and up-to-date informations including exploitability and product status are available in this page dedicated to VEX files.
Analyzed CVEs
The table below contains a list of CVEs currently present in latest versions of our products and for which an analysis is available.
This table is a subset of all CVEs currently in our system, the entire list can be obtained by downloading this report.
When "development" is present next to a product name, it means this CVE is currently still present in the development version of the product (it was not addressed as of the time the table was generated).
Generated on: October 29, 2025 at 9:36 AM | Total CVEs: 138
This CVE is disputed and represents a theoretical vulnerability in misconfigured custom implementations, not a real security risk for standard GraphiQL usage like ours.
Our webpack configuration includes broad Node.js polyfills "just in case", but our actual code doesn't use crypto functionality. Core GraphQL functionality and authentication don't depend on these vulnerable crypto implementations
Low risk: CAS client processes limited, trusted certificate chains. Exposure would require malicious certificates from CAS server.
jahia-eedevelopment
jahia-ee 8.2.2.x
jahia-ee 8.2.1.x
jahia-ee 8.1.9.x
jahia-ee 8.1.8.x
✅ Not Affected
BouncyCastle in the Jahia core is a transitive dependency of Apache Tika, Camel and Karaf, but reachability analysis has shown that the vulnerable code is not used in these libraries. Since BouncyCastle’s packages are exposed to modules, customers should verify whether the vulnerability is accessible through code in their own modules. If so, it is recommended to package a newer version of BouncyCastle directly within those modules.
jcustomer jcustomer-2.6.x
jcustomer 2.6.2
✅ Not Affected
The exploitability risk in jCustomer is low to negligible. Upgrading the affected library is not possible in jCustomer 2.x due to a dependency on Karaf. However, the library has been upgraded in jCustomer 3.x.
saml-authentication-valvedevelopment
saml-authentication-valve 3.0.0
saml-authentication-valve 2.6.0
⏳ In Progress
Practical exploitation risk is MEDIUM, because SAML typically validates certificates from trusted IdP metadata. Certificate validation usually occurs with known/trusted certificate sources. Attack requires sophisticated certificate crafting and delivery mechanism.
BouncyCastle in the Jahia core is a transitive dependency of Apache Tika, Camel and Karaf, but reachability analysis has shown that the vulnerable code is not used in these libraries. Since BouncyCastle’s packages are exposed to modules, customers should verify whether the vulnerability is accessible through code in their own modules. If so, it is recommended to package a newer version of BouncyCastle directly within those modules.
Looking at the changed code of Jackrabbit, it only affects cases where privileges are set via XML files. Jahia core and supported modules do not have any such cases, and this configuration is neither documented nor supported.
An Error is handled by Jahia, so a StackOverflowError will not cause the application to stop. Typically, the String parameter passed to ClassUtils.getClass(...) does not come from untrusted user input. However, if it does, a recommended mitigation would be to validate the input to prevent extremely long values.
jcustomerdevelopment
jcustomer jcustomer-2.6.x
jcustomer 2.6.2
✅ Not Affected
The library is shaded in pax-url-aether-2.6.17.jar. There is limited attack surface due to shading, as it cannot be used outside that jar. There is no evidence of ClassUtils usage in the codebase of that jar.
jexperiencedevelopment
jexperience 3.6.2
jexperience 3.3.x
✅ Not Affected
No real-world exploitability as the jExperience module does not use Java object serialization/deserialization mechanisms.
saml-authentication-valvedevelopment
saml-authentication-valve 3.0.0
saml-authentication-valve 2.6.0
⏳ In Progress
The library should be upgraded, but the exploitability risk is minimal. Vulnerable code is encapsulated within bundle boundaries and there is no evidence of direct commons-beanutils usage in SAML code. There is just a limited attack surface: it is a transitive dependency of velocity-tools, which is used only for internal XML/template processing, not user-controlled data.
Medium risk: Likelihood: Low to Medium - depends on CAS server security. The CAS client processes JSON responses with deeply nested JSON from the CAS server. There is no direct user-controlled JSON input to Jackson. Mitigation: Attack requires ability to influence CAS server responses or intermediate JSON processing. CAS deployments typically have network-level protections and the infrastructure is usually monitored for anomalies.
html-filteringdevelopment
html-filtering 2.0.0
✅ Not Affected
The module is safe from CVE-2025-52999 due to its specific usage pattern of Jackson for properties parsing rather than JSON parsing.
jahia-eedevelopment
jahia-ee 8.2.2.x
jahia-ee 8.2.1.x
jahia-ee 8.1.9.x
jahia-ee 8.1.8.x
✅ Not Affected
Since Jahia version 8.1.2.0 (released in June 2022), Jahia no longer deploys jackson-core versions older than 2.13.0. However, some vulnerability scanners incorrectly report that Jahia has jackson-core version 2.11.2 installed. This is a false positive, resulting from scanning the hazelcast-3.12.13.jar, which references that version but actually uses the version provided by Jahia.
jahia-oauthdevelopment
⏳ In Progress
The OSGI isolation (vulnerable jackson library is just in the jahia-oauth module) and ScribeJava's simple usage patterns significantly reduce the practical exploitability of all listed Jackson CVEs. While technically vulnerable, the actual attack surface is minimal due to the limited Jackson feature usage and controlled context (JSON comes from OAuth providers, not arbitrary user input). Jackson is a transitive dependency of scribejava, which wil...
The OSGI isolation (vulnerable jackson library is just in the jahia-oauth module) and ScribeJava's simple usage patterns significantly reduce the practical exploitability of all listed Jackson CVEs. While technically vulnerable, the actual attack surface is minimal due to the limited Jackson feature usage and controlled context (JSON comes from OAuth providers, not arbitrary user input). Jackson is a transitive dependency of scribejava, which will be upgraded in the next release (>3.3.x).
Our webpack configuration includes broad Node.js polyfills "just in case", but our actual code doesn't use crypto functionality. Core GraphQL functionality and authentication don't depend on these vulnerable crypto implementations
Our webpack configuration includes broad Node.js polyfills "just in case", but our actual code doesn't use crypto functionality. Core GraphQL functionality and authentication don't depend on these vulnerable crypto implementations
Since Jahia version 8.1.2.0 (released in June 2022), Jahia no longer deploys jackson-core versions older than 2.13.0. However, some vulnerability scanners incorrectly report that Jahia has jackson-core version 2.11.2 installed. This is a false positive, resulting from scanning the hazelcast-3.12.13.jar, which references that version but actually uses the version provided by Jahia.
jahia-oauthdevelopment
⏳ In Progress
The OSGI isolation (vulnerable jackson library is just in the jahia-oauth module) and ScribeJava's simple usage patterns significantly reduce the practical exploitability of all listed Jackson CVEs. While technically vulnerable, the actual attack surface is minimal due to the limited Jackson feature usage and controlled context (JSON comes from OAuth providers, not arbitrary user input). Jackson is a transitive dependency of scribejava, which wil...
The OSGI isolation (vulnerable jackson library is just in the jahia-oauth module) and ScribeJava's simple usage patterns significantly reduce the practical exploitability of all listed Jackson CVEs. While technically vulnerable, the actual attack surface is minimal due to the limited Jackson feature usage and controlled context (JSON comes from OAuth providers, not arbitrary user input). Jackson is a transitive dependency of scribejava, which will be upgraded in the next release (>3.3.x).
No real-world exploitability as the jExperience module does not use Java object serialization/deserialization mechanisms.
saml-authentication-valve 3.0.0
saml-authentication-valve 2.6.0
⏳ In Progress
The library should be upgraded, but the exploitability risk is minimal. Vulnerable code is encapsulated within bundle boundaries and there is no evidence of direct commons-beanutils usage in SAML code. There is just a limited attack surface: it is a transitive dependency of velocity-tools, which is used only for internal XML/template processing, not user-controlled data.
Jahia does not use WebDataBinder.disallowedFields in supported modules and only supports English, French, and German locales. If customers, although unlikely, use the Spring version provided in Jahia for such a use case, they may need to implement their own mitigations. Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
The Felix Web Console is accessible only to administrator users. There is no known URL that could be exploited with malicious input to cause reflected XSS. Nevertheless, Jahia plans to upgrade the library in a future release.
Jahia does not use a SOLR server, nor does it use its FileSystemConfigSetService. Instead, Jahia only utilizes SOLR's utility methods to create index fields for faceting in Jackrabbit's Lucene index.
Jahia does not use or deploy Spring WebFlux, but we do deploy and use Spring WebMVC. However, we do not use the functional endpoint WebMvc.fn, which is part of the org.springframework.web.servlet.function package. The version of Spring WebMVC deployed by Jahia (3.2.18) does not include this feature or package, as it became available only with Spring WebMVC 5.2.x.
In Jahia, sensitive GraphQL queries and mutations are protected by access controls. Introspection queries remain enabled in production for now. Even if they were disabled, attackers could still discover aspects of the API structure through other means. That said, we plan to place introspection queries behind access control in an upcoming release.
Jahia does not use WebDataBinder.disallowedFields in supported modules and only supports English, French, and German locales. If customers, although unlikely, use the Spring version provided in Jahia for such a use case, they may need to implement their own mitigations. Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
On a default Jahia server, the Jetty-related classes in question are not instantiated or loaded, since the EHCache configuration does not enable the REST management server feature. These vulnerable packages/classes are only accessible via EHCache’s internal classloading and are not available to other application code.
jcustomerdevelopment
jcustomer jcustomer-2.6.x
jcustomer 2.6.2
✅ Not Affected
jCustomer/Unomi are not vulnerable, as there is no direct use of the HttpURI class.
Jahia does not use org.apache.commons.io.input.XmlStreamReader in its core or supported modules. If customers use this class in their own modules, they should upgrade to a safe version directly within the module and avoid using the provided one.
GWT uses a repackaged version of protobuf-java under the package com.google.gwt.dev.protobuf. According to responses in their GitHub issues, the vulnerability is not exposed to untrusted network calls. The code is used to read source maps from disk. To exploit this, an attacker would need to modify the contents of our WAR file or deploy server resources. If they can alter files like that, there are far more attack vectors than just these protobuf...
GWT uses a repackaged version of protobuf-java under the package com.google.gwt.dev.protobuf. According to responses in their GitHub issues, the vulnerability is not exposed to untrusted network calls. The code is used to read source maps from disk. To exploit this, an attacker would need to modify the contents of our WAR file or deploy server resources. If they can alter files like that, there are far more attack vectors than just these protobuf CVEs. Therefore, for Jahia, we are classifying these vulnerabilities as false positives. See: https://github.com/gwtproject/gwt/issues/9752 , https://github.com/gwtproject/gwt/issues/9790 , https://github.com/gwtproject/gwt/issues/9778
Jahia conducted several penetration tests and found no evidence that Jahia is exploitable by external attackers through Spring Expression Language (SpEL) in manipulated requests. SpEL is not executed in this manner; it would only be triggered if the parameter were passed directly to a <spring:> tag, which would then evaluate the expression. Jahia does not use <spring:> tags in its code. Using Spring Framework in custom Jahia modules has been depr...
Jahia conducted several penetration tests and found no evidence that Jahia is exploitable by external attackers through Spring Expression Language (SpEL) in manipulated requests. SpEL is not executed in this manner; it would only be triggered if the parameter were passed directly to a <spring:> tag, which would then evaluate the expression. Jahia does not use <spring:> tags in its code. Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
Jahia 8.2.1.0+ uses Oracle GraalVM for JDK 17.0.12 (and the corresponding 23.0.5 languages SDK version), where this vulnerability is reported to be fixed.
jCustomer/Unomi only accepts JSON through its OpenAPI endpoints and does not process XML input. The exploitability risk is VERY LOW, as there is no direct user input vector.
Jahia only uses the websocket client part of the library. The vulnerable websocket server from that library is not used, so Jahia is not affected by the CVE.
BouncyCastle in the Jahia core is a transitive dependency of Apache Tika, Camel and Karaf, but reachability analysis has shown that the vulnerable code is not used in these libraries. Since BouncyCastle’s packages are exposed to modules, customers should verify whether the vulnerability is accessible through code in their own modules. If so, it is recommended to package a newer version of BouncyCastle directly within those modules.
Medium risk: CAS client makes HTTPS requests to CAS server. Mitigation: Attack requires local access and precise timing measurements. Monitor for unusual network patterns.
jahia-eedevelopment
jahia-ee 8.2.2.x
jahia-ee 8.2.1.x
jahia-ee 8.1.9.x
jahia-ee 8.1.8.x
✅ Not Affected
BouncyCastle in the Jahia core is a transitive dependency of Apache Tika, Camel and Karaf, but reachability analysis has shown that the vulnerable code is not used in these libraries. Since BouncyCastle’s packages are exposed to modules, customers should verify whether the vulnerability is accessible through code in their own modules. If so, it is recommended to package a newer version of BouncyCastle directly within those modules.
jcustomer jcustomer-2.6.x
jcustomer 2.6.2
✅ Not Affected
The exploitability risk in jCustomer is low to negligible. Upgrading the affected library is not possible in jCustomer 2.x due to a dependency on Karaf. However, the library has been upgraded in jCustomer 3.x.
Low risk: CAS typically uses standard RSA certificates. Exposure would require specially crafted EC certificates from CAS server.
jahia-eedevelopment
jahia-ee 8.2.2.x
jahia-ee 8.2.1.x
jahia-ee 8.1.9.x
jahia-ee 8.1.8.x
✅ Not Affected
BouncyCastle in the Jahia core is a transitive dependency of Apache Tika, Camel and Karaf, but reachability analysis has shown that the vulnerable code is not used in these libraries. Since BouncyCastle’s packages are exposed to modules, customers should verify whether the vulnerability is accessible through code in their own modules. If so, it is recommended to package a newer version of BouncyCastle directly within those modules.
jcustomer jcustomer-2.6.x
jcustomer 2.6.2
✅ Not Affected
The exploitability risk in jCustomer is low to negligible. Upgrading the affected library is not possible in jCustomer 2.x due to a dependency on Karaf. However, the library has been upgraded in jCustomer 3.x.
Medium risk: CAS client validates server certificates. Mitigation: Attack requires DNS control + man-in-the-middle. Ensure proper DNS security and certificate pinning.
jahia-eedevelopment
jahia-ee 8.2.2.x
jahia-ee 8.2.1.x
jahia-ee 8.1.9.x
jahia-ee 8.1.8.x
✅ Not Affected
BouncyCastle in the Jahia core is a transitive dependency of Apache Tika, Camel and Karaf, but reachability analysis has shown that the vulnerable code is not used in these libraries. Since BouncyCastle’s packages are exposed to modules, customers should verify whether the vulnerability is accessible through code in their own modules. If so, it is recommended to package a newer version of BouncyCastle directly within those modules.
jcustomer jcustomer-2.6.x
jcustomer 2.6.2
✅ Not Affected
The exploitability risk in jCustomer is low to negligible. Upgrading the affected library is not possible in jCustomer 2.x due to a dependency on Karaf. However, the library has been upgraded in jCustomer 3.x.
Jahia 8.2.1.0+ uses Oracle GraalVM for JDK 17.0.12 (and the corresponding 23.0.5 languages SDK version), where this vulnerability is reported to be fixed.
Jahia has backported the fix for this high severity vulnerability to its own spring-web fork and created a patched spring-web artifact. This artifact is used in place of the original spring-web version (see https://academy.jahia.com/customer-center/jahia/patches/security-patch-april-2024-updated-july-2024 ). Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
Jahia has backported the fix for this high severity vulnerability to its own spring-web fork and created a patched spring-web artifact. This artifact is used in place of the original spring-web version (see https://academy.jahia.com/customer-center/jahia/patches/security-patch-april-2024-updated-july-2024 ). Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
Currently, Jahia does not use permissions for Hazelcast client operations. Hazelcast is only used for cluster synchronization. The cluster must operate behind a firewall that does not expose Hazelcast ports.
Jahia has backported the fix for this high severity vulnerability to its own spring-web fork and created a patched spring-web artifact. This artifact is used in place of the original spring-web version (see https://academy.jahia.com/customer-center/jahia/patches/security-patch-april-2024-updated-july-2024 ). Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
Only affects v5.1.0 until v5.4.1, jCustomer uses an older version and does not use the vulnerable constructor. The CVE is also disputed as it requires a developer to supply invalid arguments. Never encountered in production environments.
Jahia has backported the fix into a forked GitHub repository and, starting from versions 8.1.8.0 and 8.2.1.0, deploys a drools-core version that is no longer vulnerable.
Jahia 8.2.1.0+ uses Oracle GraalVM for JDK 17.0.12 (and the corresponding 23.0.5 languages SDK version), where this vulnerability is reported to be fixed.
Jahia 8.2.1.0+ uses Oracle GraalVM for JDK 17.0.12 (and the corresponding 23.0.5 languages SDK version), where this vulnerability is reported to be fixed.
Currently, Jahia does not use Hazelcast executor services with client permissions. Hazelcast is only used for cluster synchronization. The cluster must operate behind a firewall that does not expose Hazelcast ports.
This vulnerability is not exploitable, as Jahia does not use BouncyCastle in connection with LDAP. Since BouncyCastle’s packages are exposed to modules, customers should verify whether the vulnerability is accessible through code in their own modules. If so, it is recommended to package a newer version of BouncyCastle directly within those modules.
jcustomer jcustomer-2.6.x
jcustomer 2.6.2
✅ Not Affected
The exploitability risk in jCustomer is low to negligible. Upgrading the affected library is not possible in jCustomer 2.x due to a dependency on Karaf. However, the library has been upgraded in jCustomer 3.x.
The messages of the notifications in jExperience through the angular-ui-notifications are coming from the i18n files, but placeholders get replaced with user input. We saw that XSS script got executed in the notifications, however only in the session of the attacker. Due to input validation the malicious script could not get stored.
Jahia conducted several penetration tests and found no evidence that Jahia is exploitable by external attackers through Spring Expression Language (SpEL) in manipulated requests. SpEL is not executed in this manner; it would only be triggered if the parameter were passed directly to a <spring:> tag, which would then evaluate the expression. Jahia does not use <spring:> tags in its code. Using Spring Framework in custom Jahia modules has been depr...
Jahia conducted several penetration tests and found no evidence that Jahia is exploitable by external attackers through Spring Expression Language (SpEL) in manipulated requests. SpEL is not executed in this manner; it would only be triggered if the parameter were passed directly to a <spring:> tag, which would then evaluate the expression. Jahia does not use <spring:> tags in its code. Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
This vulnerability could potentially be exploited in jExperience on the pages used to configure imports and exports. Access to those pages requires an authenticated Jahia session and the appropriate jExperience permissions.
The vulnerability is not exploitable in jExperience. While $resource is used in some parts of the code, the parameter values are not user-controllable and cannot be modified by an attacker.
Jahia conducted several penetration tests and found no evidence that Jahia is exploitable by external attackers through Spring Expression Language (SpEL) in manipulated requests. SpEL is not executed in this manner; it would only be triggered if the parameter were passed directly to a <spring:> tag, which would then evaluate the expression. Jahia does not use <spring:> tags in its code. Using Spring Framework in custom Jahia modules has been depr...
Jahia conducted several penetration tests and found no evidence that Jahia is exploitable by external attackers through Spring Expression Language (SpEL) in manipulated requests. SpEL is not executed in this manner; it would only be triggered if the parameter were passed directly to a <spring:> tag, which would then evaluate the expression. Jahia does not use <spring:> tags in its code. Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
Medium risk: Likelihood: Low - requires specific JsonNode serialization usage patterns. CAS client processes JSON responses from CAS server. There is no direct user-controlled JSON input to Jackson. Mitigation: Attack requires ability to influence CAS server responses or intermediate JSON processing. CAS deployments typically have network-level protections and the infrastructure is usually monitored for anomalies.
jahia-oauthdevelopment
⏳ In Progress
The OSGI isolation (vulnerable jackson library is just in the jahia-oauth module) and ScribeJava's simple usage patterns significantly reduce the practical exploitability of all listed Jackson CVEs. While technically vulnerable, the actual attack surface is minimal due to the limited Jackson feature usage and controlled context (JSON comes from OAuth providers, not arbitrary user input). Jackson is a transitive dependency of scribejava, which wil...
The OSGI isolation (vulnerable jackson library is just in the jahia-oauth module) and ScribeJava's simple usage patterns significantly reduce the practical exploitability of all listed Jackson CVEs. While technically vulnerable, the actual attack surface is minimal due to the limited Jackson feature usage and controlled context (JSON comes from OAuth providers, not arbitrary user input). Jackson is a transitive dependency of scribejava, which will be upgraded in the next release (>3.3.x).
The vulnerability is only possible with Kafka Connect >=2.3.0. jCustomer does NOT use Kafka Connect - only client libraries, and the Kafka version is not in the vulnerable range.
GWT uses a repackaged version of protobuf-java under the package com.google.gwt.dev.protobuf. According to responses in their GitHub issues, the vulnerability is not exposed to untrusted network calls. The code is used to read source maps from disk. To exploit this, an attacker would need to modify the contents of our WAR file or deploy server resources. If they can alter files like that, there are far more attack vectors than just these protobuf...
GWT uses a repackaged version of protobuf-java under the package com.google.gwt.dev.protobuf. According to responses in their GitHub issues, the vulnerability is not exposed to untrusted network calls. The code is used to read source maps from disk. To exploit this, an attacker would need to modify the contents of our WAR file or deploy server resources. If they can alter files like that, there are far more attack vectors than just these protobuf CVEs. Therefore, for Jahia, we are classifying these vulnerabilities as false positives. See: https://github.com/gwtproject/gwt/issues/9752 , https://github.com/gwtproject/gwt/issues/9790 , https://github.com/gwtproject/gwt/issues/9778
GWT uses a repackaged version of protobuf-java under the package com.google.gwt.dev.protobuf. According to responses in their GitHub issues, the vulnerability is not exposed to untrusted network calls. The code is used to read source maps from disk. To exploit this, an attacker would need to modify the contents of our WAR file or deploy server resources. If they can alter files like that, there are far more attack vectors than just these protobuf...
GWT uses a repackaged version of protobuf-java under the package com.google.gwt.dev.protobuf. According to responses in their GitHub issues, the vulnerability is not exposed to untrusted network calls. The code is used to read source maps from disk. To exploit this, an attacker would need to modify the contents of our WAR file or deploy server resources. If they can alter files like that, there are far more attack vectors than just these protobuf CVEs. Therefore, for Jahia, we are classifying these vulnerabilities as false positives. See: https://github.com/gwtproject/gwt/issues/9752 , https://github.com/gwtproject/gwt/issues/9790 , https://github.com/gwtproject/gwt/issues/9778
Jahia core does not connect to FTP servers. If customers use this library for such a use case, they may need to implement a mitigation. For instance: package a newer version of commons-net directly in their modules.
GWT uses a repackaged version of protobuf-java under the package com.google.gwt.dev.protobuf. According to responses in their GitHub issues, the vulnerability is not exposed to untrusted network calls. The code is used to read source maps from disk. To exploit this, an attacker would need to modify the contents of our WAR file or deploy server resources. If they can alter files like that, there are far more attack vectors than just these protobuf...
GWT uses a repackaged version of protobuf-java under the package com.google.gwt.dev.protobuf. According to responses in their GitHub issues, the vulnerability is not exposed to untrusted network calls. The code is used to read source maps from disk. To exploit this, an attacker would need to modify the contents of our WAR file or deploy server resources. If they can alter files like that, there are far more attack vectors than just these protobuf CVEs. Therefore, for Jahia, we are classifying these vulnerabilities as false positives. See: https://github.com/gwtproject/gwt/issues/9752 , https://github.com/gwtproject/gwt/issues/9790 , https://github.com/gwtproject/gwt/issues/9778
Medium risk: Likelihood: Low - requires specific configuration Custom deserialization choices in CAS client, which processes JSON responses from CAS server. There is no direct user-controlled JSON input to Jackson. Mitigation: Only vulnerable with specific customized deserialization configurations.
jahia-oauthdevelopment
jcustomer jcustomer-2.6.x
jcustomer 2.6.2
✅ Not Affected
For this vulnerability to be exploitable the non-default DeserializationFeature must be enabled.
Medium risk: Likelihood: Low - requires specific configuration Custom deserialization choices in CAS client, which processes JSON responses from CAS server. There is no direct user-controlled JSON input to Jackson. Mitigation: Only vulnerable with specific customized deserialization configurations.
jahia-oauthdevelopment
jcustomer jcustomer-2.6.x
jcustomer 2.6.2
✅ Not Affected
For this vulnerability to be exploitable the non-default DeserializationFeature must be enabled.
Jahia has backported the fix into a forked GitHub repository and, starting from versions 8.1.8.0 and 8.2.1.0, deploys a drools-core version that is no longer vulnerable.
Jahia has backported the fix for this critical vulnerability to its own Spring fork and created a patched spring-beans artifact. This artifact is used in place of the original spring-beans version. Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
Access to $locale.NUMBER_FORMATS.PATTERNS is not exposed in our implementation. The posPre value is statically defined in the files located in the following directory and does not change at runtime: https://github.com/Jahia/jexperience/tree/10f9f89fda93bb471ec24164189b8c039fe35e34/core/src/main/resources/javascript/jexperience/vendor/ngLocale
Jahia does not use disallowedFields on a DataBinder in its code. If customers are affected by this vulnerability, they may need to implement their own mitigations. Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
Jahia has backported the fix for this critical vulnerability to its own Spring fork and created a patched spring-beans artifact. This artifact is used in place of the original spring-beans version. See https://academy.jahia.com/customer-center/jahia/patches/security-patch-april-2022 Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
Jahia conducted several penetration tests and found no evidence that Jahia is exploitable by external attackers through Spring Expression Language (SpEL) in manipulated requests. SpEL is not executed in this manner; it would only be triggered if the parameter were passed directly to a <spring:> tag, which would then evaluate the expression. Jahia does not use <spring:> tags in its code. Using Spring Framework in custom Jahia modules has been depr...
Jahia conducted several penetration tests and found no evidence that Jahia is exploitable by external attackers through Spring Expression Language (SpEL) in manipulated requests. SpEL is not executed in this manner; it would only be triggered if the parameter were passed directly to a <spring:> tag, which would then evaluate the expression. Jahia does not use <spring:> tags in its code. Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
The module already uses jackson-databind v2.13.0, in which the vulnerability has been fixed.
jahia-oauthdevelopment
⏳ In Progress
The OSGI isolation (vulnerable jackson library is just in the jahia-oauth module) and ScribeJava's simple usage patterns significantly reduce the practical exploitability of all listed Jackson CVEs. While technically vulnerable, the actual attack surface is minimal due to the limited Jackson feature usage and controlled context (JSON comes from OAuth providers, not arbitrary user input). Jackson is a transitive dependency of scribejava, which wil...
The OSGI isolation (vulnerable jackson library is just in the jahia-oauth module) and ScribeJava's simple usage patterns significantly reduce the practical exploitability of all listed Jackson CVEs. While technically vulnerable, the actual attack surface is minimal due to the limited Jackson feature usage and controlled context (JSON comes from OAuth providers, not arbitrary user input). Jackson is a transitive dependency of scribejava, which will be upgraded in the next release (>3.3.x).
GWT uses a repackaged version of protobuf-java under the package com.google.gwt.dev.protobuf. According to responses in their GitHub issues, the vulnerability is not exposed to untrusted network calls. The code is used to read source maps from disk. To exploit this, an attacker would need to modify the contents of our WAR file or deploy server resources. If they can alter files like that, there are far more attack vectors than just these protobuf...
GWT uses a repackaged version of protobuf-java under the package com.google.gwt.dev.protobuf. According to responses in their GitHub issues, the vulnerability is not exposed to untrusted network calls. The code is used to read source maps from disk. To exploit this, an attacker would need to modify the contents of our WAR file or deploy server resources. If they can alter files like that, there are far more attack vectors than just these protobuf CVEs. Therefore, for Jahia, we are classifying these vulnerabilities as false positives. See: https://github.com/gwtproject/gwt/issues/9752 , https://github.com/gwtproject/gwt/issues/9790 , https://github.com/gwtproject/gwt/issues/9778
GWT uses a repackaged version of protobuf-java under the package com.google.gwt.dev.protobuf. According to responses in their GitHub issues, the vulnerability is not exposed to untrusted network calls. The code is used to read source maps from disk. To exploit this, an attacker would need to modify the contents of our WAR file or deploy server resources. If they can alter files like that, there are far more attack vectors than just these protobuf...
GWT uses a repackaged version of protobuf-java under the package com.google.gwt.dev.protobuf. According to responses in their GitHub issues, the vulnerability is not exposed to untrusted network calls. The code is used to read source maps from disk. To exploit this, an attacker would need to modify the contents of our WAR file or deploy server resources. If they can alter files like that, there are far more attack vectors than just these protobuf CVEs. Therefore, for Jahia, we are classifying these vulnerabilities as false positives. See: https://github.com/gwtproject/gwt/issues/9752 , https://github.com/gwtproject/gwt/issues/9790 , https://github.com/gwtproject/gwt/issues/9778
Jahia does not use a SOLR server, nor does it use the SaslZkACLProvider or VMParamsAllAndReadonlyDigestZkACLProvider. Instead, Jahia only utilizes SOLR's utility methods to create index fields for faceting in Jackrabbit's Lucene index.
This vulnerability affects applications that allow untrusted users to upload or modify Velocity templates running Apache Velocity Engine versions up to 2.2. Jahia does not allow untrusted users to upload or modify Velocity templates.
Jahia does not include the camel-jmx and camel-management JARs and has JMX services disabled by default. See also: https://academy.jahia.com/documentation/knowledge-base/jmx-java-monitoring-extensions and https://academy.jahia.com/customer-center/jahia/patches/security-patch-august-2023
jcustomerdevelopment
jcustomer jcustomer-2.6.x
jcustomer 2.6.2
✅ Not Affected
jCustomer does not include the camel-jmx and camel-management JARs and has JMX services disabled by default.
Jahia does not use a SOLR server, nor does it use a Solr cluster. Instead, Jahia only utilizes SOLR's utility methods to create index fields for faceting in Jackrabbit's Lucene index.
Jahia does not use Java deserialization of untrusted data with the Spring framework. Specifically, we do not use HttpInvokerServiceExporter, SimpleHttpInvokerServiceExporter, or RemoteInvocationSerializingExporter, as mentioned in https://blog.gypsyengineer.com/en/security/detecting-dangerous-spring-exporters-with-codeql.html . Customers can use the CodeQL tool referenced in the URL to check their projects. If customers, although unlikely, use th...
Jahia does not use Java deserialization of untrusted data with the Spring framework. Specifically, we do not use HttpInvokerServiceExporter, SimpleHttpInvokerServiceExporter, or RemoteInvocationSerializingExporter, as mentioned in https://blog.gypsyengineer.com/en/security/detecting-dangerous-spring-exporters-with-codeql.html . Customers can use the CodeQL tool referenced in the URL to check their projects. If customers, although unlikely, use these exporters in their own use cases, they may need to implement a mitigation. Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
This is a mixup, because wstx-asl is not Solr (see vulnerability description).
jahia-eedevelopment
jahia-ee 8.2.2.x
jahia-ee 8.2.1.x
jahia-ee 8.1.9.x
jahia-ee 8.1.8.x
✅ Not Affected
Jahia does not use a SOLR server, nor does it use an update handler. Instead, Jahia only utilizes SOLR's utility methods to create index fields for faceting in Jackrabbit's Lucene index.
Jahia does not use a SOLR server, nor does it use its DataImportHandler. Instead, Jahia only utilizes SOLR's utility methods to create index fields for faceting in Jackrabbit's Lucene index.
Jahia does not use the XML-based job creation affected by this CVE; instead, it creates schedulers through Spring bean configuration. If customers are using the Jahia-provided Quartz version for XML-based job creation, they may need to consider alternative mitigation options.
Jahia does not use a SOLR server, nor does it use the "shards" parameter. Instead, Jahia only utilizes SOLR's utility methods to create index fields for faceting in Jackrabbit's Lucene index.
Jahia CMIS provider does not use the legacy com.sun.net.ssl stack, which can be set with a system property. It uses the default modern SSL/TLS implementation in Java and properly performs hostname verification.
Jahia does not expose STOMP over WebSocket endpoints, nor does it deploy the necessary JARs for that (spring-websocket and spring-messaging). If customers, although unlikely, use the Spring version provided in Jahia for such a use case, they may need to implement their own mitigations. Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
Jahia does not expose STOMP over WebSocket endpoints, nor does it deploy the necessary JARs for that (spring-websocket and spring-messaging). If customers, although unlikely, use the Spring version provided in Jahia for such a use case, they may need to implement their own mitigations. Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
Jahia does not use a SOLR server, nor does it use its DataImportHandler. Instead, Jahia only utilizes SOLR's utility methods to create index fields for faceting in Jackrabbit's Lucene index.
Jahia does not expose STOMP over WebSocket endpoints, nor does it deploy the necessary JARs for that (spring-websocket and spring-messaging). If customers, although unlikely, use the Spring version provided in Jahia for such a use case, they may need to implement their own mitigations. Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
Jahia does not have a use case where Spring MVC is configured to serve static resources (e.g., CSS, JS, images) from a file system on Windows. If customers, although unlikely, use Spring for such a use case, they may need to implement their own mitigation. Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
Jahia’s code does not have a use case like this: "When the server application (Server A) receives input from a remote client and uses that input to make a multipart request to another server (Server B)." If customers, although unlikely, use Spring for such a use case, they may need to implement their own mitigation. Using Spring Framework in custom Jahia modules has been deprecated in Jahia since version 8.2.
Jahia's CMIS provider is a pure client that connects to CMIS servers and only makes outbound HTTP/REST calls. It does NOT expose any web services, does NOT act as a service provider and does not process incoming SOAP/REST requests. The vulnerability is NOT APPLICABLE, because we don't expose web services that could receive malicious attachment headers.
It is very unclear from reading articles, what the exact problem is. Fact is that tickets like XERCESJ-1748, XERCESJ-1756, XERCESJ-1758 are not moving forward since a long time. We are using the latest available version of xercesImpl. The project seems dead and we are planning to get rid of the library in a next major release. There is no currently known exploit in Jahia.
Jahia does not use a SOLR server, nor does it use its index replication feature. Instead, Jahia only utilizes SOLR's utility methods to create index fields for faceting in Jackrabbit's Lucene index.
Jahia does not use a SOLR server, nor does it use its Admin UI. Instead, Jahia only utilizes SOLR's utility methods to create index fields for faceting in Jackrabbit's Lucene index.
Jahia does not use a SOLR server, nor does it use its Admin UI. Instead, Jahia only utilizes SOLR's utility methods to create index fields for faceting in Jackrabbit's Lucene index.
Jahia has backported the fix into a forked GitHub repository and, starting from versions 8.1.8.0 and 8.2.1.0, deploys a drools-core version that is no longer vulnerable.
Jahia does not use a SOLR server, nor does it use the UpdateRequestHandler or XPathEntityProcessor. Instead, Jahia only utilizes SOLR's utility methods to create index fields for faceting in Jackrabbit's Lucene index.
Jahia does not use a SOLR server, nor does it use the UpdateRequestHandler. Instead, Jahia only utilizes SOLR's utility methods to create index fields for faceting in Jackrabbit's Lucene index.
Jahia does not use a SOLR server, nor does it use the SolrResourceLoader. Instead, Jahia only utilizes SOLR's utility methods to create index fields for faceting in Jackrabbit's Lucene index.
Jahia does not use a SOLR server, nor does it use the DocumentAnalysisRequestHandler. Instead, Jahia only utilizes SOLR's utility methods to create index fields for faceting in Jackrabbit's Lucene index.