GHSA-86fh-w43w-338c Decidim: Verification admins can access supplied IDs from other organizations

• RubyGems decidim-verifications: < 0.30.9 → fixed in 0.30.9 • RubyGems decidim-verifications: >= 0.31.0.rc1, < 0.31.5 → fixed in 0.31.5 • RubyGems decidim-verifications: >= 0.32.0.rc1, < 0.32.0 → fixed in 0.32.0

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: 1. An org2 participant uploads their ID: 2. 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` 3. 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) 4. 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.