## Description A JWT issued to an Org 1 account is accepted on the Org 2 API and can read the admin-only GraphQL `participantDetails` field for an Org 2 participant. The same trust-boundary problem also affects API-user authentication: an Org 1 API user can use a JWT on the Org 1 host and replay that JWT to the Org 2 API to read Org 2 participant personal data and reach Org 2's `proposal.answer` mutation path. ## Technical description The current host selects the Decidim organization context, but JWT-backed API authentication is not sufficiently bound to that host organization. As a result, the API can process a request in Org 2's context while still trusting an authenticated principal from Org 1. Reproduction steps: 1. Use an API key provided by the system administrator that is assigned to organization 1 to create the JWT token or get the JWT token shown in the response when logged in as the organization admin. <img width="1080" height="1119" alt="decidim-jwt-01" src="https://github.com/user-attachments/assets/6195a250-faef-41d5-8f64-4d77d4077e96" /> 2. When using this JWT token it is possible to retrieve details from other organisations. Notice the change of the host header in the request below to that of another tenant `org2.localhost:3001` <img width="1085" height="1047" alt="decidim-jwt-02" src="https://github.com/user-attachments/assets/d40825e3-0d36-44f3-bede-86d247bbe6d0" /> Note that using a participant-generated JWT did not allow showing these results. ### Impact A JWT issued for one organization can be replayed successfully against another organization's API and used to retrieve sensitive details from that organization. ### Patches See https://github.com/decidim/decidim/pull/16673 and https://github.com/decidim/decidim/pull/16756 ### Workarounds Disable JWT credentials on system panel (`/system`) ### References OWASP A01:2021 Broken Access Control ### Credits This issue was discovered in a security audit organized by the [Decidim Association](https://decidim.org) and made by [Radically Open Security](https://www.radicallyopensecurity.com/) against Decidim financed by [NGI](https://ngi.eu/).
## Description A JWT issued to an Org 1 account is accepted on the Org 2 API and can read the admin-only GraphQL `participantDetails` field for an Org 2 participant. The same trust-boundary problem also affects API-user authentication: an Org 1 API user can use a JWT on the Org 1 host and replay that JWT to the Org 2 API to read Org 2 participant personal data and reach Org 2's `proposal.answer` mutation path. ## Technical description The current host selects the Decidim organization context, but JWT-backed API authentication is not sufficiently bound to that host organization. As a result, the API can process a request in Org 2's context while still trusting an authenticated principal from Org 1. Reproduction steps: 1. Use an API key provided by the system administrator that is assigned to organization 1 to create the JWT token or get the JWT token shown in the response when logged in as the organization admin. <img width="1080" height="1119" alt="decidim-jwt-01" src="https://github.com/user-attachments/assets/6195a250-faef-41d5-8f64-4d77d4077e96" /> 2. When using this JWT token it is possible to retrieve details from other organisations. Notice the change of the host header in the request below to that of another tenant `org2.localhost:3001` <img width="1085" height="1047" alt="decidim-jwt-02" src="https://github.com/user-attachments/assets/d40825e3-0d36-44f3-bede-86d247bbe6d0" /> Note that using a participant-generated JWT did not allow showing these results. ### Impact A JWT issued for one organization can be replayed successfully against another organization's API and used to retrieve sensitive details from that organization. ### Patches See https://github.com/decidim/decidim/pull/16673 and https://github.com/decidim/decidim/pull/16756 ### Workarounds Disable JWT credentials on system panel (`/system`) ### References OWASP A01:2021 Broken Access Control ### Credits This issue was discovered in a security audit organized by the [Decidim Association](https://decidim.org) and made by [Radically Open Security](https://www.radicallyopensecurity.com/) against Decidim financed by [NGI](https://ngi.eu/).
Update decidim to 0.31.5; decidim to 0.32.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanDecidim: JWT-backed authentication can be replayed across organizations affects decidim (rubygems), decidim (rubygems). Severity is high. ## Description A JWT issued to an Org 1 account is accepted on the Org 2 API and can read the admin-only GraphQL `participantDetails` field for an Org 2 participant. The same trust-boundary problem also affects API-user authentication: an Org 1 API user can use a JWT on the Org 1 host and replay that JWT to the Org 2 API to read Org 2 participant personal data and reach Org 2's `proposal.answer` mutation path. ## Technical description The current host selects the Decidim organization context, but JWT-backed API authentication is not sufficiently bound to that host organization. As a result, the API can process a request in Org 2's context while still trusting an authenticated principal from Org 1. Reproduction steps: 1. Use an API key provided by the system administrator that is assigned to organization 1 to create the JWT token or get the JWT token shown in the response when logged in as the organization admin. <img width="1080" height="1119" alt="decidim-jwt-01" src="https://github.com/user-attachments/assets/6195a250-faef-41d5-8f64-4d77d4077e96" /> 2. When using this JWT token it is possible to retrieve details from other organisations. Notice the change of the host header in the request below to that of another tenant `org2.localhost:3001` <img width="1085" height="1047" alt="decidim-jwt-02" src="https://github.com/user-attachments/assets/d40825e3-0d36-44f3-bede-86d247bbe6d0" /> Note that using a participant-generated JWT did not allow showing these results. ### Impact A JWT issued for one organization can be replayed successfully against another organization's API and used to retrieve sensitive details from that organization. ### Patches See https://github.com/decidim/decidim/pull/16673 and https://github.com/decidim/decidim/pull/16756 ### Workarounds Disable JWT credentials on system panel (`/system`) ### References OWASP A01:2021 Broken Access Control ### Credits This issue was discovered in a security audit organized by the [Decidim Association](https://decidim.org) and made by [Radically Open Security](https://www.radicallyopensecurity.com/) against Decidim financed by [NGI](https://ngi.eu/).
AI coding agents often install or upgrade packages automatically in rubygems. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| decidimrubygems | <0.31.5 | 0.31.5 |
| decidimrubygems | >=0.32.0.rc1,<0.32.0 | 0.32.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate decidim to 0.31.5; decidim to 0.32.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanDecidim: JWT-backed authentication can be replayed across organizations affects decidim (rubygems), decidim (rubygems). Severity is high. ## Description A JWT issued to an Org 1 account is accepted on the Org 2 API and can read the admin-only GraphQL `participantDetails` field for an Org 2 participant. The same trust-boundary problem also affects API-user authentication: an Org 1 API user can use a JWT on the Org 1 host and replay that JWT to the Org 2 API to read Org 2 participant personal data and reach Org 2's `proposal.answer` mutation path. ## Technical description The current host selects the Decidim organization context, but JWT-backed API authentication is not sufficiently bound to that host organization. As a result, the API can process a request in Org 2's context while still trusting an authenticated principal from Org 1. Reproduction steps: 1. Use an API key provided by the system administrator that is assigned to organization 1 to create the JWT token or get the JWT token shown in the response when logged in as the organization admin. <img width="1080" height="1119" alt="decidim-jwt-01" src="https://github.com/user-attachments/assets/6195a250-faef-41d5-8f64-4d77d4077e96" /> 2. When using this JWT token it is possible to retrieve details from other organisations. Notice the change of the host header in the request below to that of another tenant `org2.localhost:3001` <img width="1085" height="1047" alt="decidim-jwt-02" src="https://github.com/user-attachments/assets/d40825e3-0d36-44f3-bede-86d247bbe6d0" /> Note that using a participant-generated JWT did not allow showing these results. ### Impact A JWT issued for one organization can be replayed successfully against another organization's API and used to retrieve sensitive details from that organization. ### Patches See https://github.com/decidim/decidim/pull/16673 and https://github.com/decidim/decidim/pull/16756 ### Workarounds Disable JWT credentials on system panel (`/system`) ### References OWASP A01:2021 Broken Access Control ### Credits This issue was discovered in a security audit organized by the [Decidim Association](https://decidim.org) and made by [Radically Open Security](https://www.radicallyopensecurity.com/) against Decidim financed by [NGI](https://ngi.eu/).
AI coding agents often install or upgrade packages automatically in rubygems. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| decidimrubygems | <0.31.5 | 0.31.5 |
| decidimrubygems | >=0.32.0.rc1,<0.32.0 | 0.32.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard