Jahia 8.1 - Security update

  Written by The Jahia Team
   Estimated reading time:

Jahia 8.1 is a feature release focusing on improving the security of the platform. Many libraries used by Jahia have been updated to benefit from their latest security fixes, and we have also improved the security filter so it can be accurately configured.

For some libraries, we had to change their major version, which came with breaking changes. If you are relying on these libraries in your module, you will need to update them in order to upgrade to Jahia 8.1. You will find in this document the exhaustive list of changes we made that may affect your code.

Alpha version

To help you anticipate any breaking change in Jahia 8.1.0, you can already download Jahia 8.1.0 alpha. This alpha version contains all the library upgrades listed below. You can use it to test your modules and validate your changes already.

Please report to us any issue you may encounter with this alpha version, through your Jira project.

Library upgrades requiring module recompilation

Updated libraries

GraphQL v13

GraphQL dependencies have been updated to the following versions:

  • Graphql-java v13
  • Graphql-java-servlet v9.1
  • Graphql-java-annotations v7.2.1

with graphql-dxm-provider upgraded to 2.7.0 for the dependency upgrades.

Semantic versioning requires the import-package directive to be regenerated, but no code change should be expected in most of the cases. See Applying the changes.

Any code references to graphql.servlet.GraphQLContext will need to be refactored. When trying to get a reference to servlet request/response from the GraphQL environment context, you can use (assuming you have a graphql-dxm-provider 2.7.0 dependency):

  • org.jahia.modules.graphql.provider.dxm.util.ContextUtil.getHttpServletRequest(environment.getContext())
  • org.jahia.modules.graphql.provider.dxm.util.ContextUtil.getHttpServletResponse(environment.getContext())

Guava 30

The version of guava bundled with jahia is now 30.1.1-jre . Modules depending on the provided guava will have to be recompiled with this new version. Semantic versioning requires the import-package directive to be regenerated, but no code change should be expected. See Applying the changes.

Hibernate 5.5

Jahia now uses Hibernate 5.5.3  Modules depending on the provided hibernate library will have to be recompiled with this new version. Semantic versioning requires the import-package directive to be regenerated, but no code change should be expected in most of the cases. See Applying the changes.

Hibernate Validator 6.2.0 and validation-api

Hibernate Validator has been upgraded to 6.2.0 and validation-api-1.1.0.Final.jar has been replaced by jakarta.validation-api-2.0.2.jar. Modules depending on the provided hibernate validator and/or the bean validation API will have to be recompiled with this new version. Semantic versioning requires the import-package directive to be regenerated, but no code change should be expected in most of the cases. See Applying the changes.

The impact is that security vulnerable operations are dropped or disabled with this new version:

  • @SafeHtml constraint dropped
  • Expression Language disabled for custom violations by default
  • Expression Language Bean methods execution disabled for constraints by default

HttpClient 5

HttpClient 3 has been replaced by HttpClient 5 in Jahia. Please note that HttpClient 4 is still available for use.

                If a module is using and importing HttpClient 3 from the core ( org.apache.commons.httpclient.* ), it will no longer run. The code has to be updated to work with HttpClient 5. See the Http Components Client documentation.

As a temporary solution, it is still possible to embed HttpClient 3 in the module itself but we strongly encourage you to have a plan to migrate to HttpClient 5 in the near future. See Applying the changes.

Transitive dependencies

It is possible that some of your modules are using HttpClient as a transitive dependency. If it is the case and that you explicitly excluded it in the pom.xml file (see example), you need to either remove the exclusion, so the module will provide its own version of the library, or you need to update your module to use a newer version of the library that needs this dependency..

How to identify which modules are concerned?

By analyzing each module before the upgrade

Before upgrading, you can verify for each of your modules their import packages, and see if any is concerned by our library upgrades:

  • Install bnd tools (command line)
  • Execute one of the following commands:
    • bnd print -i <jar file>
    • java -jar biz.aQute.bnd-{VERSION}.jar print -i <jar file>
  • Check if any import is part of the list of the updated libraries:
    • httpclient3: org.apache.commons.httpclient.*
    • guava: com.google.commons.*
    • graphql: graphql.*
    • hibernate validator: org.hibernate.validator.*
    • bean validation: javax.validation.*
    • hibernate: org.hibernate.*

By using a karaf command: headers

This method requires you to first deploy your modules on the target Jahia version: 8.1.0 in our case. Then, you can:

  • Deploy your modules on a target Jahia version: 8.1.0
  • Run the following command in the karaf OSGi console:
    headers <module name or bundle id>
  • Check for any red entry in the Import-Package section
The diag command can also give some information about the reasons why the module cannot be started.

Applying the changes

Choose one of the following procedures to regenerate the import-package directives after recompilation.

Preferred way: update the parent version to

The easiest and preferred way to ensure that your modules are built using the updated versions of the previous libraries is to update the parent version to in the pom.xml file:


When updating the parent version to, it is not necessary to explicitly specify the import packages.

If you are using the Jahia alpha version, you need to use as the parent version. In such a case, you will have to wait for the official release to be able to use and release your modules.

 Alternative: specify an import package in the pom.xml

If your modules need to remain compatible with Jahia 8.0, you can add an import-package statement in their pom. Here is an example for graphql-annotations:


Please note that when using this method, you need to ensure that there are no breaking changes, or changes that will affect your module, between the versions included in the specified range.

Temporary solution: package the old version of the library in your module

You can also decide on packaging the old version of the libraries you use in your modules, to prevent any incompatibility with the versions provided by Jahia. However, by doing so, you will not benefit from future updates.

Library upgrades requiring testing

The following libraries have been upgraded. Depending on the usage you make of them, you may, or may not, have to update your modules. So we advise you to identify and test your modules that may be concerned, and to modify them accordingly if needed.

Groovy 3

Jahia now uses the Groovy 3 script engine.
We have not identified breaking changes affecting Jahia, however if you are relying on Groovy scripts, you may be impacted by breaking changes. In such case we advise you to consult the Groovy 3 release notes, and to execute your scripts in a pre-production environment to validate their compatibility with Groovy 3.0.

Log4j 2

This does not apply to Jahia Cloud customers

After upgrading to Jahia 8.1, a new configuration file log4j2.xml is added for log4j2 to the folder /WEB-INF/etc/config/. Ensure that custom logging-entries are migrated to the new file, and that the old one gets properly removed.

Plexus Utils 3.1.0

Plexus-utils has been updated from 3.0.22 to 3.1.0. There is a breaking change in org.codehaus.plexus.util.PropertyUtils.loadProperties as it no longer catches all exceptions inside, but throws them out. For instance if the properties file to be loaded does not exist, an exception will be thrown while it was previously ignored.

Spring Webflow 2.4.8

We have upgraded Spring Webflow from 2.4.1 to 2.4.8.
If you are using Spring Webflow in your modules, you will need to manually test them in order to identify the potential changes you would need to do in your code.

Other library upgrades

The following libraries have also been upgraded but do not introduce breaking changes:

  • Apache Tika and dependencies:
    • tika-core-1.27.jar
    • tika-parsers-1.27.jar
    • bcmail-jdk15on-1.69.jar
    • bcpkix-jdk15on-1.69.jar
    • bcprov-jdk15on-1.69.jar
    • bcutil-jdk15on-1.69.jar
    • fontbox-2.0.24.jar
    • pdfbox-2.0.24.jar
    • pdfbox-tools-2.0.24.jar
    • preflight-2.0.24.jar
    • xmpbox-2.0.24.jar
    • asm-9.2.jar
    • isoparser-
    • apache-mime4j-core-0.8.4.jar
    • apache-mime4j-dom-0.8.4.jar
    • commons-compress-1.21.jar
    • woodstox-core-6.2.6.jar
  • Xstream
    • xstream-1.4.17.jar
  • Jodconverter
    • jodconverter-core-4.4.2.jar
    • jodconverter-local-4.4.2.jar
    • jodconverter-remote-4.4.2.jar
    • fluent-hc-4.5.13.jar
    • httpmime-4.5.13.jar
  • Jackson
    • jackson-annotations-2.10.5.jar
    • jackson-core-2.10.5.jar
    • jackson-databind-

New version of the security filter

Github readme

The Jahia API security config and filter module has been improved to protect APIs in a more safe and configurable way.

Consult the Academy documentation and Github readme file to learn more about the configuration of the security filter.

  • The module comes with a legacy mode, which is unchanged from previous versions. This mode is useful, as it will help you sequence your upgrade operation, as you can focus on upgrading Jahia to 8.1.0 before adjusting the security filter configuration.
  • To simplify the configuration, you can also enable some additional logging, which will compare for each API call the behavior (allowed/denied) between the legacy and the new configuration.

In other words, when upgrading to Jahia 8.1, we suggest to:

  • Enable the legacy mode
  • Enable the migration reporting logs

This way, your system will work as before while logging the difference you will have if you were to switch to the new configuration. So you can adjust your configuration along the way, until you do not see calls that would be denied when they should not. This is a better approach than a try and fail approach.

Elasticsearch connector / Elasticsearch Connector 7

You are only concerned by this section if you are currently relying on Elasticsearch Connector 7.

 To help with consistency and facilitate future upgrades we decided to retire Elasticsearch Connector 7 in favor of Elasticsearch Connector (without the ‘7’). New versions of Elasticsearch Connector give you access to more recent versions of the Elasticsearch client (Elasticsearch Connector 3.0.0 ships with Elasticsearch client v7.13.2).

Upgrading your modules to use Elasticsearch Connector should be straight forward since the latest version of Elasticsearch Connector 7 (v7.4.5) and the recent versions of Elasticsearch Connector (v.3.0.0) have an almost identical codebase. 

How to upgrade to Elasticsearch connector?

  • In your modules relying on elasticsearch-connector-7:
    • Change the dependency in the pom.xml
    • Rename packages from org.jahia.modules.elasticsearchconnector7 to org.jahia.modules.elasticsearchconnector
    • Change database type from ELASTICSEARCH7 to ELASTICSEARCH, when filtering services, for example:
      Collection<servicereference<elasticresthighlevelclient>&gt; serviceReferences = 
                 String.format("(&(databaseType=ELASTICSEARCH)(databaseId=%s))", settings.getEsConnectionId())); </servicereference<elasticresthighlevelclient>
  • Deploy the latest version of elasticsearch-connector and your modules in your environment
  • Remove the elasticsearch-connector-7 module(s)