What is the CVSS score of CVE-2026-45330?

CVE-2026-45330 has a CVSS 3.1 base score of 4.9 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.3%.

Is there a patch available for CVE-2026-45330?

Yes, a patch is available for CVE-2026-45330. Update the affected software to the latest version immediately.

decidim-verifications CVE-2026-45330

MEDIUM

Information Exposure (CWE-200)

2026-07-13 https://github.com/decidim/decidim

GHSA-86fh-w43w-338c

Information Disclosure

4.9

CVSS 3.1 · Vendor: https://github.com/decidim/decidim

Severity by source

Vendor (https://github.com/decidim/decidim) PRIMARY

4.9 MEDIUM

AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N

vuln.today AI

5.5 MEDIUM

PR:H required as attacker must be an authenticated platform admin; I:L added over vendor score because cross-tenant approve/reject modifies victim authorization state.

3.1 AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:N

4.0 AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/decidim/decidim).

CVSS VectorVendor: https://github.com/decidim/decidim

Attack Vector

Network

Attack Complexity

Low

Privileges Required

High

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Jul 13, 2026 - 19:39 vuln.today

Analysis Generated

Jul 13, 2026 - 19:39 vuln.today

DescriptionCVE.org

Description

The verification admin mutation flow allows accessing, verifying, and rejecting participants records from another tenant.

Technical description

The verification admin controllers loads pending_authorization_id with a raw Authorization.find(...) and then authorizes the record without checking whether it belongs to current_organization.

Reproduction steps:

An org2 participant uploads their ID:

An admin from another organisation, in this case org1, is able to open the ID from org2 by opening request 35, e.g http://localhost:3001/admin/id_documents/pending_authorizations/35/confirmations/new

The admin then approves this request by looking up the ID in the picture (not shown in this image, but a real ID would expose this)

Now the request has been approved, which can be seen from the org2 participant authorizations page:

Impact

A tenant admin can access, reject or approve another tenant's id_documents requests.

Patches

See https://github.com/decidim/decidim/pull/16666

Workarounds

Disable the "Identity documents" verification

Reference

OWASP A01:2021 Broken Access Control

Credits

This issue was discovered in a security audit organized by the Decidim Association and made by Radically Open Security against Decidim financed by NGI.

AnalysisAI

Cross-tenant IDOR in Decidim's verification admin flow exposes government-issued identity documents belonging to participants of one organization to administrators of a different tenant on the same instance. An authenticated admin of any tenant can enumerate sequential pending_authorization_id integers in the admin URL to view, approve, or reject ID document and postal-letter verification requests that belong to entirely separate organizations. The vulnerability was confirmed through a formal security audit and detailed reproduction steps are published in the GitHub advisory; no CISA KEV listing or independent exploit code exists at time of analysis.

Technical ContextAI

Decidim is an open-source Ruby on Rails participatory democracy platform deployed in multi-tenant mode where multiple organizations share a single database. The affected package is decidim-verifications (pkg:rubygems/decidim-verifications). The root cause is CWE-200 (Exposure of Sensitive Information): the admin controllers for id_documents confirmations, id_documents rejections, and postal_letter postages all load authorization records with a global unscoped ActiveRecord call - Authorization.find(params[:pending_authorization_id]) - rather than scoping the query to current_organization. Because authorization IDs are sequential integers shared across all tenants in the same database, any admin can reference another tenant's record by ID. The fix in PR #16666 introduces a new PendingAuthorizationLoader concern that replaces the bare find with Authorizations.new(organization: current_organization, name:, granted: false).query.find(id), enforcing tenant boundary at the query layer. The OWASP classification is A01:2021 Broken Access Control.

RemediationAI

Upgrade decidim-verifications to a patched release: version 0.30.9 for deployments on the 0.30.x line, 0.31.5 for the 0.31.x line, or 0.32.0 for the 0.32.x line. The fix is tracked in PR #16666 (https://github.com/decidim/decidim/pull/16666), which introduces the scoped PendingAuthorizationLoader concern across all three affected controllers. If an immediate gem upgrade is not feasible, the vendor-documented workaround is to disable the 'Identity documents' verification method in the Decidim system admin panel; this removes the vulnerable endpoint entirely but eliminates ID-document-based participant verification for all tenants on the instance as a side effect. The postal_letter verification controller carries the same flaw and is patched in the same PR, so both verification methods should be treated together when applying the workaround.