Listen to this Post
How CVE‑2026‑45330 Works
Decidim is a participatory democracy framework built on Ruby on Rails, commonly deployed in multi‑tenant environments where each organization (tenant) maintains its own isolated data. The platform includes an identity document verification workflow that allows administrators to review and approve or reject participant‑uploaded IDs.
The vulnerability resides in the verification admin mutation flow. When an admin accesses the pending authorization interface, the controller loads a specific `pending_authorization_id` using a raw `Authorization.find(…)` call. This lookup retrieves the record directly from the database without any additional scope that would tie it to the current organization (tenant). The subsequent authorization check — which is supposed to enforce permissions — does not verify that the fetched authorization record actually belongs to the same organization as the admin making the request.
Because the tenant context is not validated, an administrator from Organization A can manually craft a URL pointing to a pending authorization record from Organization B. For example, by navigating to /admin/id_documents/pending_authorizations/35/confirmations/new, the admin can view the ID document uploaded by a participant of Organization B. The controller loads the record with ID 35, performs no cross‑tenant ownership check, and presents the document for review.
The admin can then approve or reject the request, effectively making a decision on a verification that belongs to a different tenant. Once approved, the participant from Organization B sees their request as verified, even though the decision was made by an unauthorized admin from another organization.
This broken access control violates the fundamental isolation expected in a multi‑tenant system. The issue is rooted in the use of a raw `find` method instead of a scoped query such as current_organization.authorizations.find(...). No check is made to ensure that the `pending_authorization_id` parameter corresponds to a record owned by the current tenant.
The vulnerability affects all Decidim installations that have the “Identity documents” verification enabled and are running vulnerable versions. It was discovered during a security audit organized by the Decidim Association and performed by Radically Open Security, with funding from NGI. The weakness is classified under OWASP A01:2021 (Broken Access Control).
Patches have been released in versions 0.30.9, 0.31.5, and 0.32.0. As a workaround, administrators can disable the “Identity documents” verification feature until the upgrade is applied.
DailyCVE Form:
| Field | Value |
|–||
| Platform | Decidim |
| Version | 0.30.x, 0.31.x, 0.32.0rc |
| Vulnerability | Broken Access Control |
| Severity | Moderate |
| Date | 2026-07-13 |
| Prediction | Patched 2026-07-13 |
What Undercode Say: (Analytics)
> Verify your Decidim version
> “`bash
> bundle show decidim | grep -E “decidim-[0-9]+\.[0-9]+\.[0-9]+”
> “`
or check `Gemfile.lock` for the decidim gem version.
Check if the Identity Documents verification is enabled
> “`bash
> rails c
> Decidim::Verifications::IdentityDocuments::Admin::Permissions.new(user, {})
> “`
Curl test to see if a pending authorization from another tenant is accessible
> (Replace `:org1_admin_session` and `:pending_id` with actual values)
> “`bash
curl -X GET “http://localhost:3001/admin/id_documents/pending_authorizations/35/confirmations/new” \
> -H “Cookie: _decidim_session=:org1_admin_session”
> “`
> Check logs for unauthorized access attempts
> “`bash
> grep “pending_authorizations” log/development.log | grep “35”
> “`
Exploit
- Identify a pending authorization ID from another tenant (e.g., by enumerating IDs or observing error messages).
- Craft the URL –
http://<target>/admin/id_documents/pending_authorizations/<id>/confirmations/new. - Authenticate as an admin of your own tenant (Organization A).
- Navigate to the crafted URL – the controller loads the authorization record using `Authorization.find(
)` without any tenant scope. - View the ID document of the participant from Organization B.
- Approve or reject the request – the action succeeds because the permission check does not verify tenant ownership.
- Result – the participant from Organization B sees their verification status changed, even though the decision was made by an admin from a different organization.
Example curl exploit (after obtaining a valid admin session cookie):curl -X POST "http://localhost:3001/admin/id_documents/pending_authorizations/35/confirmations" \ -H "Cookie: _decidim_session=<org1_admin_session>" \ -d "confirmation[bash]=approved"
Protection
- Upgrade to a patched version: 0.30.9, 0.31.5, or 0.32.0 (or later).
- If an immediate upgrade is not possible, disable the “Identity documents” verification module entirely via the admin panel or by commenting out the relevant engine in your
Gemfile. - Apply the fix manually by modifying the controller to use a tenant‑scoped query, e.g., replace `Authorization.find(params[:pending_authorization_id])` with
current_organization.authorizations.find(params[:pending_authorization_id]). - Review admin access logs for any suspicious activity targeting
/admin/id_documents/pending_authorizations/. - Restrict network access to the admin panel (e.g., via VPN or IP whitelisting) as a defense‑in‑depth measure.
Impact
A tenant administrator can access, reject, or approve identity document verification requests that belong to any other tenant on the same Decidim instance. This breaks the fundamental isolation between organizations, allowing:
– Unauthorized data exposure – viewing ID documents (which may contain sensitive personal information) of participants from other tenants.
– Verification tampering – approving or rejecting verifications for users outside the admin’s own organization, potentially affecting their ability to participate in processes.
– Loss of trust – undermining the integrity of the verification system, as decisions can be made by unauthorized parties.
– Compliance risks – violating data protection regulations (e.g., GDPR) by exposing personal data across tenant boundaries.
The vulnerability is rated Moderate in severity but can have serious consequences in multi‑tenant deployments where data isolation is critical.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
