Security Patch - March 2025

October 29, 2025

A new vulnerability was uncovered in the external-provider 4.7.0.

Jahia 8.2.0.0 shipped with version 4.7.0 of external-provider which introduced a new endpoint to create VFS mount points. An incorrect configuration of the privileges made it possible for any user capable of accessing the Jahia edit mode to create VFS mount points.

When this security patch page was written, no exploits were published for Jahia.

Affected versions

  • external-provider 4.7.0

Earlier and later versions of the module are not affected.

Jahia 8.1.x is not affected by the vulnerability since it shipped with earlier version of the module not affected by the vulnerability.

Patched versions

The vulnerability has been addressed in external-provider 4.8.0 and above. 

With version 4.8.0 and above:

  • GraphQL nodes located under "query.admin.mountPoints.*" and "mutation.admin.mountPoint.*" were marked as deprecated and now require the graphqlAdminQuery permission (for queries) or  graphqlAdminMutation permission (for mutations)
  • Graphql nodes are now located under "query.admin.jahia.mountPoints.*" and "mutation.admin.jahia.mountPoint.*" and require the graphqlAdminQuery permission (for queries) or  graphqlAdminMutation permission (for mutations)

Jahia 8.2.1.0 and above will ship with external-provider 4.8.0+.

Addressing the vulnerability

To apply the mitigation, you are recommended to upgrade to:

This new version of the module is already included in Jahia 8.2.1.0

Upgrading external-provider should be performed during a maintenance window as it will trigger a restart of dependents modules (such as ldap-provider or cmis-provider) with downtime during the operation.

Verifying

In Jahia Administration, open the module manager and verify that the version of external-provider installed is different from 4.7.0.

Mitigation

As an alternative to upgrading external-provider, services in front of Jahia (such as haproxy) can be used to deny GraphQL queries and mutations to "query.admin.mountPoints.*" and "mutation.admin.mountPoint.*". This will prevent creation/edition/deletion of mount points.

Please do not hesitate to reach out to Jahia Support if you have any questions or concerns.

Mitigation

A first mitigation is to use pagination in the results page. Here's an example with Jahia components:

<c:set var="pagesizeParamName" value="pagesize${currentNode.identifier}"/>
<c:choose>
    <c:when test="${not empty param[pagesizeParamName]}">
        <c:set var="pageSize" value="${param[pagesizeParamName]}"/>
    </c:when>
    <c:when test="${not empty param.src_itemsPerPage}">
        <c:set var="pageSize" value="${param.src_itemsPerPage}"/>
    </c:when>
    <c:otherwise>
        <c:set var="pageSize" value="5"/>
    </c:otherwise>
</c:choose>
  
<template:initPager totalSize="${moduleMap.listTotalSize}" id="${currentNode.identifier}" pageSize="${pageSize}"/>
<template:displayPagination/> 
<c:choose>
    <c:when test='${searchMap[hitsName] eq null}'>
        <s:results var="resultsHits" approxCountVar="listApproxSize">
            <c:set target="${moduleMap}" property="listTotalSize" value="${count}"/>
            <c:set target="${moduleMap}" property="resultsHits" value="${resultsHits}"/>
            <c:set target="${moduleMap}" property="listApproxSize" value="${listApproxSize}"/>
            <c:if test='${searchMap == null}'>
                <jsp:useBean id="searchMap" class="java.util.HashMap" scope="request"/>
            </c:if>
            <c:set target="${searchMap}" property="${hitsName}" value="${resultsHits}"/>
            <c:set target="${searchMap}" property="${hitsCountName}" value="${count}"/>
            <c:set target="${searchMap}" property="listApproxSize" value="${listApproxSize}"/>
        </s:results>
    </c:when>
    <c:otherwise>
        <c:set target="${moduleMap}" property="listTotalSize" value="${searchMap[hitsCountName]}"/>
        <c:set target="${moduleMap}" property="resultsHits" value="${searchMap[hitsName]}"/>
        <c:set target="${moduleMap}" property="listApproxSize" value="${searchMap[listApproxSize]}"/>
    </c:otherwise>
</c:choose>

<template:displayPagination/>
<template:removePager id="${currentNode.identifier}"/>

Another mitigation is to block the search without any term. This can be achieved, for example, by using the following URL rewrite rule to detect the sensitive URLs to block:

<urlrewrite>
    <rule>
        <name>Prevent blank term parameter value in search results</name>
        <note>Set error status</note>
        <condition type="parameter" name="src_terms[0].term">^$</condition>
        <from>recherche.html(/.*)?$</from>
        <set type="status">404</set>
        <to>null</to>
    </rule>
</urlrewrite>

Please note that this last one is only mitigation means as it prevents people from outside of your organization from exploiting such vulnerability to access the tools. In any case, it does not replace the need of upgrading to Shiro 1.10.0.

Mitigation

It is advised to block the access to the tools from outside your organization. This can be achieved, for example, by using a proxy (HAProxy, Apache2, etc.) and the following regular expression to detect the sensitive URLs to block:

.+modules.+tools.+

Please note that is only a mitigation mean as it prevents people from outside of your organization from exploiting such vulnerability to access the tools. In any case, it does not replace the need of upgrading to Shiro 1.10.0.