Description

Decidim is a participatory democracy framework. Prior to 0.31.5 and in 0.32.0.rc1 before 0.32.0.rc2, JWT-backed API authentication is not bound to the organization selected by the current host, allowing a JWT issued for one tenant to be replayed against another tenant’s API to read participantDetails data and reach the proposal.answer mutation path. This issue is fixed in versions 0.31.5 and 0.32.0.rc2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.5",
  "pubDate": "2026-08-06T22:17:06.873Z",
  "pubdate": "2026-08-06T22:17:06.873Z",
  "executiveSummary": "A cross-tenant authentication vulnerability exists in the Decidim participatory democracy framework, specifically within its JWT-backed API authentication mechanism. The root cause stems from the failure to cryptographically or logically bind JSON Web Tokens to the specific organization context determined by the current host during requests.\nThis architectural oversight allows an attacker in possession of a valid JWT issued for one multi-tenant organization to successfully replay that token against a completely different tenant's API endpoint.\nSuccessful exploitation of this flaw grants unauthorized access to sensitive participantDetails data and permits interaction with restricted GraphQL mutation paths such as proposal.answer, effectively subverting tenant isolation boundaries within the application.\nThe vulnerability affects Decidim versions prior to 0.31.5 and version 0.32.0.rc1 prior to 0.32.0.rc2. The risk implications include unauthorized cross-tenant data disclosure and unauthorized administrative or state-changing actions via exposed API mutations.\nAttack capabilities require the initial possession of a valid JWT from any tenant instance, which is then leveraged against target tenants exposed via the network. No specific exploitation requirements beyond valid token acquisition and crafted API requests are mandated by the vulnerability design.",
  "technicalDetails": "The vulnerability resides within the JWT-backed API authentication subsystem of the Decidim participatory democracy framework, affecting versions prior to 0.31.5 and version 0.32.0.rc1 prior to 0.32.0.rc2.\nThe root cause of the flaw is the absence of multi-tenant validation checks during the token validation lifecycle. Specifically, the API authentication handler validates the cryptographic signature and expiration of the incoming JWT but fails to verify whether the organization identifier embedded in or implied by the token matches the organization context determined by the current host header or request routing logic.\nThe vulnerable components include the API authentication middleware and resolvers that process participantDetails data retrieval and execute the proposal.answer mutation path.\nThe attack flow proceeds as follows: First, an attacker authenticates legitimately against a compromised, malicious, or accessible tenant instance within the Decidim deployment to acquire a valid JWT. Second, the attacker crafts an API request directed at a completely separate, victim tenant instance hosted on the same Decidim deployment. Third, the attacker injects the previously acquired JWT into the authorization header of the request targeting the victim tenant. Fourth, because the backend API subsystem lacks organization-binding validations, the JWT is accepted as valid for the victim tenant context. Fifth, the attacker queries the participantDetails endpoint to harvest sensitive user information or invokes the proposal.answer mutation path to manipulate proposal states across the tenant boundary.\nThe exploitation method relies entirely on token replay across trust boundaries. The network exposure is inherent to any publicly accessible Decidim instance utilizing JWT-backed API authentication. Authentication is technically required, but it is bypassed logically because a token from a different tenant satisfies the minimal authentication check. Privilege requirements are limited to holding any standard user or adversary-obtained token that passes basic signature verification. Payload behavior involves standard GraphQL queries and mutations directed at unauthorized organizational nodes.\nThe post-exploitation impact includes severe compromise of tenant data segregation, unauthorized exposure of participant metadata, and unauthorized data modification through exposed mutation paths."
}