Jahia 8.2.2 Release Notes

Jahia 8.2.2 is a maintenance release primarily addressing security-related issues detailed in:

• 8.2.2.0: September 2025 Security patch page
• 8.2.2.2: July security patch page.

Adopting this release is expected to be simple for environments already running Jahia 8.2.1.

Rolling Upgrade Compatibility — Jahia 8.2.2.x

Supported combinations

Rolling upgrade from 8.2.2.x to 8.2.2.3 is supported, but requires the following modules to be upgraded on the cluster before starting the Jahia node upgrade, while all nodes are still running 8.2.2.x:

• graphql-dxm-provider 3.7.0 (download)
• tasks 8.3.0 (download), if starting from Jahia 8.2.2.0
• rolesmanager 8.8.0 (download)
• security-filter-tools 2.6.1 (download)
• server-availability-manager 3.5.0 (download)
• personal-api-tokens 1.9.0 (download)

This release includes changes that could be considered breaking, depending on your environment, make sure to review these carefully.

Modifications of Guest user read access for LIVE workspace (Jahia 8.1.9.3+, 8.2.2.3+ & 8.2.3.2+)

Starting with this release, read access to the following nodes is now denied for the Guest (unauthenticated) user in the LIVE workspace:

• /users
• /groups
• /settings
• /imports
• /sites/*/users
• /sites/*/groups

No changes for the EDIT workspace, access was and remains denied.

Impact: Content referencing user or group nodes (e.g., blog post authors, comments, forum posts) will no longer resolve for unauthenticated visitors unless explicit read permissions are granted.

Default permission for the editor role for LIVE and EDIT workspaces (Jahia 8.1.9.3+, 8.2.2.3+ & 8.2.3.2+)

Users assigned the Editor or Editor in Chief roles in Jahia were previously granted the Modify access control default permission (jcr:modifyAccessControl). This allowed them to modify permissions through the Live Roles and Edit Roles menus under Advanced options, as well as through API calls.

Starting with these Jahia patch modules, this permission is no longer granted by default to users assigned the Editor or Editor in Chief roles. These users can still view node permissions, but they can no longer modify them unless this permission is explicitly granted.

An important point to consider is that a user with the Modify access control default permission (jcr:modifyAccessControl) can modify permissions broadly, including their own. This means that, if misused, it could allow a user to grant themselves elevated privileges, including site administration privileges.

In these updated versions of Jahia, this permission remains available and can still be granted to users if needed. However, it should be assigned with caution and limited to users who explicitly require this level of access.

It is also important to note that this kind of privilege escalation is not directly facilitated by the UI: a connected user would need to intentionally perform such an action. Nevertheless, this still represents a security risk, particularly if a user account is compromised or if a user intentionally attempts to misuse their access.

Removal of the publish permission from the owner role (Jahia 8.1.9.3+, 8.2.2.3+ & 8.2.3.2+)

As part of a privilege-escalation hardening effort, the capabilities granted to users on their own user node (the owner role) have been reduced. Previously, the owner role granted broad repository control, including the ability to publish content.

Starting with this release, the owner role no longer grants the publish permission. It now grants only a minimal set of capabilities: read, edit own properties, add/remove child nodes, manage mixins, access to the personal dashboard, the standard content view tabs, and API reachability. Capabilities such as publishing, node deletion, access-control management, locking, versioning, and lifecycle or retention management are no longer included.

Customers who rely on users publishing content from within their own user section will find that this no longer works. This is recoverable without a code change: an administrator can re-grant the publish permission to the owner role from the Roles administration UI if a specific use case requires it. This permission should be assigned with caution and limited to cases that explicitly require it.

Impact of these changes to UGC ownership and default role assignment

In versions prior to this patch, authenticated users (including those with the jahiaapp, Reviewer, Editor, or Editor in Chief roles) were automatically assigned the owner role on User-Generated Content (UGC) they created — such as blog entries, wiki pages, or forum posts. As the owner of that content, the user could create, edit, and delete their own UGC. Additionally, users with the Editor in Chief role were granted the actions permission for any content in both the EDIT and LIVE workspaces, allowing them to create, edit, and delete UGC authored by other users.

Starting with this patch releases, authenticated users are no longer automatically assigned the owner role on the content they create. Instead, they will only have the permissions explicitly granted to their role under Administration → Permissions on Modules → Actions → Blog (or the equivalent section for other UGC modules). This change may affect sites that rely on UGC features such as blogs, wikis, or forums.

Impact: If your site uses UGC features, users may lose the ability to manage their own content after upgrading. To restore the previous behavior, review and explicitly grant the required permissions to the relevant roles under the Administration UI. If you need to re-enable automatic owner role assignment for authenticated users, set the following Jahia property:

jahia.autoAssignRole.disabled=false

This property is set to true by default in Jahia 8.2.3.2+ (or 8.2.2.3+, 8.1.9.3+). It should be set with caution: re-enabling automatic owner assignment restores the broader content-management capabilities that were previously granted by the owner role, including those restricted as part of the privilege-escalation hardening described above.

Password update security (Jahia 8.2.2.1 only)

In Jahia 8.2.2.1 a short-lived server-side validation window was introduced: after a successful current-password verification, a password change may be performed without re-supplying the current password, provided it occurs within the same request / thread context and within the allowed time window (configurable, defaults to 10s). 

The fixes implement a window during which a password can be modified after having been first verified. If your code already follows the pattern verifyPassword(currentPassword) followed by setPassword(newPassword) in the same thread, no changes are required.

If you perform the two operations in different threads, or separated requests without re-verification, you must refactor your code. A sample implementation of a valid password change is available in the jahia user dashboard (code).

It remains possible to restore previous behaviour by setting jahia.user.passwordUpdate.currentPasswordRequired property to false.

Stricter file upload validations (introduced in Jahia 8.2.2.0)

This release introduces stricter file upload checks configurable via the property jahiaSecuredFileUpload in the jahia.properties file.

In Jahia 8.1.9.0, this property is set to true by default. Make sure to review the documentation available in the jahia.properties file to determine if and how you are impacted. This documentation is also accessible here. 

CSRF protection in /modules/api/bundles (introduced in Jahia 8.2.2.0)

In this release, we removed the ability for /modules/api/bundles to rely on sessions for authentication, which typically means that it will not be possible to call this endpoint from Web UIs.

We expect this use case to be extremely rare (if not inexistent) since this endpoint was primariraly created to support Jahia orchestration use cases, which are unaffected by this change. This endpoint is still reachable via other Jahia authentication mechanism (token, basic auth).

No modules were updated between Jahia 8.2.1.0 and Jahia 8.2.2.0

Updated modules

The following modules were updated between Jahia 8.2.1.0, Jahia 8.2.2.1 and Jahia 8.2.2.3

The following librairies were updated between Jahia 8.2.1.0, Jahia 8.2.2.0 and Jahia 8.2.2.3

No libraries were updated between Jahia 8.2.2.0 and Jahia 8.2.2.1

Jahia 8.2.2.3

Jahia 8.2.2.3 is a patch release centered around security. You can find more details about the discovered vulnerabilities in the two security advisories posted here and here. 

Security

• ✨ Moved JWT service in a separate module, to use JWT you need to have the security-filter-tools module started.
• ✨ Added security.profile=off to allow disabling all Jahia-provided security profiles for deployments that supply their own authorization configuration. 
• ✨ Protected jnt:user deletion via decorator (system-only), restored jcr:write on owner, introduced security filter permission config allowing to extends jnt:user child node types.
• 🐛 Hardened remember-me cookie handling to reject malformed cookie values before processing authentication.
  The remember-me token is now stored under the user property `j:cookieToken` instead of `cookieauth`. Existing remember-me sessions will be invalidated on upgrade, requiring users to log in again. 
• 🐛 Secured Atmosphere RPC endpoint by restricting HTTP methods to HEAD/GET requests only.
• 🐛 Hardened authorization scopes so that unknown keys in grant blocks are no longer silently ignored, preventing APIs from being unintentionally left open due to misconfigured rules.
• 🐛 Tightened default permissions on internal content paths for unauthenticated sessions. 
• 🐛 Hardened authorization scopes so that unknown keys in node or api grant blocks are no longer silently registered as open rules. 
• 🐛 Hardened access to site users and groups so that only site administrators can manage them. New sites include this restriction by default, and existing sites are updated automatically on upgrade. 
• 🐛 Revoked jcr:modifyAccessControl default permission from the editor role; site administrators retain this permission to manage access control on site pages and contents. 
• 🐛 Enforced jcr:modifyAccessControl permission on ACL/ACE node operations to prevent unauthorized access control manipulation.
• 🐛 Restrict node types allowed as children of a jnt:user node, configurable using jahia.properties new prop: jahia.user.allowedChildNodeTypes
• 🐛 Enforce privilege check on move operation
• 🐛 Validate jnt:user node placement
• 🐛 Minimize the built-in owner role permissions
• 🐛 Restrict the auto-assign-role parameter of the render POST action

Configuration

• 🐛 Fixed YAML configuration files so they now retain their leading comments when the configuration manager writes them back after a configuration update. 

Misc

• ✨ Updated description for editor in chief role and modifyAccessControl permissions following changes in behavior.

Jahia 8.2.2.2

Jahia 8.2.2.2 has not be publicly released as it contained a regression preventing rolling upgrade fixed in 8.2.2.3. See Jahia 8.2.2.3 for the full list of changes.

Jahia 8.2.2.1

Jahia 8.2.2.1 patch release includes the following additional fixes, you can find details about the corrected vulnerabilities on this page.

• ✨ Introduction of a password change window
• 🐛 Better handle exceptions to prevent log flooding
• ✨ Addressed two XSS vulnerabilities in Jahia Administration

Aside from security fixes, this patch release also include the following change:

• 🐛 Fixed a compatibility issue between JDK 17 and Jahia Proxy handling

Jahia 8.2.2.0

Docker

• ✨ Simplified Jahia configuration during startup of the Docker images and removed unnecessary dependencies

Security

• ✨ Introduced a stricter mechanism to validate file uploads, configurable using the jahiaSecuredFileUpload property. This configuration is true by default. Please see the "Breaking Changes" section of this document.