Skip to main content

Jahia 8.2.3.2

November 12, 2026

Jahia 8.2.3.2 is a patch release centered around security. You can find more details about the discovered vulnerabilities in the Security section of Jahia Academy.

Upgrading from a version earlier than 8.2.3.0? Make sure to review Jahia 8.2.3.0 release notes as well as all intermediary patch releases.

Read before you upgrade

Breaking changes

Breaking changes are documented on the page of the release that introduced them. If you are upgrading across more than one version, review the breaking changes of every release between the version you are currently running and the version you are upgrading to.

Modifications of Guest user read access for LIVE workspace

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.

Am I impacted?
Yes, if your site has content referencing user or group nodes, such as blog post authors, comments or forum posts. That content will no longer resolve for unauthenticated visitors unless explicit read permissions are granted.

Default permission for the editor role for LIVE and EDIT workspaces

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

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.

Am I impacted?
Yes, if your site uses UGC features: users may lose the ability to manage their own content after upgrading.

What do I need to do?
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.

Other notices

  • 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. (Commit: fb7f8e2)
  • The JWT service moved to a separate module: to use JWT you need to have the security-filter-tools module started. (Commit: 33690de)

How to upgrade

Customers can always use the In-Place or Blue-Green upgrade procedure regardless of their current version. The rolling upgrade prerequisites below only apply to the rolling upgrade procedure.

Rolling upgrade to Jahia 8.2.3.2

Rolling upgrade to 8.2.3.2 from any version earlier than 8.2.3.0 is not supported. Rolling upgrade from 8.2.3.0 to 8.2.3.2 is supported, but requires the following modules to be upgraded on the cluster before starting the Jahia node upgrade:

Note: Depending of the version of Jahia you are upgrading from, some modules might already be in the required version.

Failing to upgrade these modules beforehand WILL result in instability during the rolling upgrade window when nodes are running different Jahia versions. Downgrading IS NOT supported.

If you are using Jahia installer, you can download fixAppliers corresponding to your Jahia version here.

Components updated in Jahia 8.2.3.2

Modules

ComponentJahia 8.2.3.0Jahia 8.2.3.2
graphql-dxm-provider 📝3.5.13.7.0
macros 📝8.3.08.4.0
personal-api-tokens 📝1.7.01.9.0
rolesmanager 📝8.7.08.8.0
security-filter-tools 📝2.5.02.6.1
server-availability-manager 📝3.4.13.5.0

Only components whose version changed in Jahia 8.2.3.3 are listed above.

The full list of Jahia modules and their versions can be found in the Jahia 8.2.3.2 tag in GitHub.

Database drivers

No changes to database drivers in this version.

The full list of Database drivers and their versions can be found in the Jahia 8.2.3.2 tag in GitHub.

Libraries

ComponentJahia 8.2.3.0Jahia 8.2.3.2
Apache Tomcat 📝9.0.1139.0.118

Only components whose version changed in Jahia 8.2.3.2 are listed above.

The full list of embedded Jahia libraries can be found in the Jahia 8.2.3.2 tag in GitHub.

Changelog

Security

  • 🛡️ Moved JWT service in a separate module, to use JWT you need to have the security-filter-tools module started (Commit: 33690de)
  • 🛡️ Added security.profile=off to allow disabling all Jahia-provided security profiles for deployments that supply their own authorization configuration. (Commit: 71c65ff)
  • 🛡️ 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. (Commit: 0224ff3)
  • 🛡️ 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. (Commit: fb7f8e2)
  • 🛡️ Secured Atmosphere RPC endpoint by restricting HTTP methods to HEAD/GET requests only. (Commit: fb7f8e2)
  • 🛡️ 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. (Commit: 658c024)
  • 🛡️ Tightened default permissions on internal content paths for unauthenticated sessions. (Commit: c6410af, 9129489)
  • 🛡️ Hardened authorization scopes so that unknown keys in node or api grant blocks are no longer silently registered as open rules. (Commit: f4deb66)
  • 🛡️ 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. (Commit: e7efb47)
  • 🛡️ Revoked jcr:modifyAccessControl default permission from the editor role; site administrators retain this permission to manage access control on site pages and contents. (Commit: b133db0)
  • 🛡️ Enforced jcr:modifyAccessControl permission on ACL/ACE node operations to prevent unauthorized access control manipulation. (Commit: a333ad1)
  • 🛡️ Restrict node types allowed as children of a jnt:user node, configurable using jahia.properties new prop: jahia.user.allowedChildNodeTypes (Commit: 6970a3)
  • 🛡️ Enforce privilege check on move operation (Commit: 62f74fb)
  • 🛡️ Validate jnt:user node placement (Commit: c8e910e)
  • 🛡️ Minimize the built-in owner role permissions (Commit: 03613b1)
  • 🛡️ Restrict the auto-assign-role parameter of the render POST action (Commit: 13a5f91)

Configuration

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

Misc

  • ✨ Updated description for editor in chief role and modifyAccessControl permissions following changes in behavior (Commits: 3cb5b2c, b662f79, 1f4b9bf)
  • 🐛 When an area was defined at the template level and the areaAsSubNode option was enabled, any content nodes part of the template placed under that area were silently ignored and not rendered. Content is now correctly resolved and rendered in all cases. (Commits: 574ee09)

Legend (icons): ✨ Improvements & new features, 🐛 Bugs, 🛡️ Security fixes, 📚 Documentation, 📦 Packaging, 🛠 Change to Jahia build, ⚙️ Changes to CI, ♻️ chores