Vulnerabilities handling at Jahia

Published a year ago November 20, 2023

Some context on 3rd party libraries

As with the vast majority of modern software projects (if not all), Jahia depends on 3rd party libraries for its operation. The choice to integrate a 3rd party library is never taken lightly, the product team always ensures that a candidate library can demonstrate a certain degree of community adoption, is meeting basic Open-Source project criteria, and shows signs of maintainability in the long term.

Throughout its lifetime, a 3rd party library is likely to go through various stages of development, with multiple releases, discovered vulnerabilities, and sometimes, end-of-project maintenance. Once a 3rd party library is integrated into Jahia, the product team will, based on various triggers (such as the need for a new feature or a bugfix, security vulnerability, addressing technical debt, …), upgrade 3rd party libraries to more recent versions.

Upgrading a 3rd party library version is not necessarily easy and the need for such a change is always weighted against our customers' needs and the overall product roadmap.

Changing the version of a third-party library can have a significant impact on our customer’s implementations, for example when the next version of a particular library is introducing breaking changes. There are also situations in which updating to a newer version of a library is not necessarily relevant for the product; for example, if the library is integrated into part of the codebase due to be refactored, if the timing is not appropriate (requiring a new major Jahia version soon after the previous one), if the team is considering moving to an alternative library, ...

Security vulnerabilities

Nevertheless, and disrespecting of Jahia’s roadmap for a particular library, we constantly scan our codebases and their dependencies for known security vulnerabilities. We implemented tooling and processes to handle the discovery of a new vulnerability (we currently use dependencytrack to centralize results).

Every week, our security lead will meet with our delivery managers to discuss new non-critical vulnerabilities made public during the week (critical vulnerabilities are escalated right away).

These vulnerabilities are reviewed, analyzed, and assessed against a risk management framework (scoring elements such as threats to confidentiality, integrity, and availability). From there, a decision is made regarding the handling of that vulnerability:

  • If Jahia is deemed exposed, a specific process is triggered, assembling stakeholders at multiple levels of the company and resulting in a security patch being issued.
  • If Jahia is deemed not exposed, the team will evaluate our ability to upgrade the library to a more recent version and prioritize its upgrade in our roadmap.

These processes are audited every year in the context of Jahia ISO 27001 certification.

False positives in 3rd party libraries

A vulnerability in a 3rd party library is always a source for concern, but such a vulnerability does not always translate into the product using that library being itself vulnerable. In some instances, there are safeguards in place or documented best practices to prevent that vulnerability from spreading to the parent project.

For example, earlier this year we reviewed a high score CVE-2023-39017 impacting Quartz < 2.3.2. This vulnerability is only impacting Quartz JMS, a feature of Quartz that Jahia itself does not use, yet the whole library is marked vulnerable. Yes, Jahia uses this version of Quartz but Jahia is not impacted since the JMS feature is not used.

There are other situations when a 3rd party library is needed for building the product, but is not used at runtime. For example, we use a particular solr-core utility function for our faceting search, that version of solr-core has 13 vulnerabilities, but a Solr server is not started nor are other solr libs deployed. After investigation, it was confirmed that Jahia was not exposed to these particular vulnerabilities.

Finally, and especially with Javascript libraries, false positives are sometimes detected in transitive dependencies (a dependency of a dependency), with situations where the vulnerable dependency is declared into the “yarn.lock” but does not even make it to our built artifacts (and neither to Jahia runtime).

When dealing with false positives, it’s always in our best interest to upgrade libraries to more recent versions (without vulnerabilities), but this is weighted against other items in our roadmap considering that in this particular situation, the main benefit (aside from addressing technical debt) is for not having these show up in external vulnerability reports.

Long term approach

We are currently working on improving our communication around vulnerable libraries. However, as with any security analysis, we are very cautious not to increase our customer’s exposure by publicly communicating our analysis.

We are also reflecting on providing a precise software bill of materials (SBOM), that would only contain libraries we use at Jahia runtime (less false positives), as well as a VEX report containing our analysis, this is currently in our security roadmap but this is a complex item to implement.

Overall, we are confident that the tooling and processes we currently have in place ensure our team is alerted about public vulnerabilities and that these vulnerabilities get regularly analyzed by our team. But if you have any source of concerns about a particular vulnerability, we encourage you to contact our team and we will be happy to provide more details about its potential impact (or lack thereof) on your environment.

Spring deprecation and vulnerabilities

Spring is deprecated in Jahia, starting with version 8.2. No new Jahia development will utilize Spring, and we are actively phasing out its existing use. We strongly advise you to do the same in your custom code.

Critical security concerns: Jahia core and its supported modules currently use very old versions of the Spring library. These versions are known to contain multiple vulnerabilities, including some rated as critical and high severity. We regularly check if Jahia core and our officially supported modules are affected by newly reported Spring vulnerabilities:

  • If we find that Jahia core or a supported module is vulnerable, we will either backport fixes to our forked Spring version or provide alternative mitigations. These solutions will be communicated to you through security notifications, similar to other vulnerability reports.
  • If we determine that Jahia core or a supported module is not directly exposed to a specific vulnerability (because we do not use the vulnerable Spring features), we will not take immediate action. However, this does not guarantee your Jahia instance is safe.

Customer Responsibility: Even if Jahia core and supported modules are not directly exposed, your custom modules and code might still be vulnerable. Because we cannot upgrade the core spring libraries, you are responsible for mitigating risks. We recommend you take the following actions:

  • Thoroughly examine your custom codebase to determine if it uses any vulnerable Spring features or methods.
  • Upgrading the Spring library within Jahia is not a viable solution: we strongly recommend you remove Spring from your custom code.
  • Stay informed about Spring vulnerabilities by regularly checking spring.io/security.

To determine the Spring version currently used by your Jahia instance, navigate to Administration > Server > System > System information and search for "spring-core-".

Clarification on Module Checks: Please note that our vulnerability checks are limited to Jahia core and officially supported modules. We do not check for vulnerabilities in:

  • Community modules
  • Test modules
  • Previous demo modules
  • Modules that were previously supported but are no longer supported
  • Modules created by our service/support team without product support
  • Proof-of-concept modules

Therefore, you must independently verify the security of any modules not explicitly listed as "officially supported."

In summary: Jahia's Spring usage poses significant security risks. We are taking steps to mitigate vulnerabilities within our core and supported modules, but you bear the ultimate responsibility for securing your custom code. We strongly recommend migrating away from Spring as soon as possible.