OpenWISP Controller EUVD-2026-111234

Requires an authenticated OpenWISP Controller account that is an organization manager holding CA view (model) permission (PR:L), and a multi-tenant deployment containing at least one CA in an organization the attacker does not manage so cross-organization enumeration of sequential integer CA IDs is meaningful. The vulnerable path is specifically GET /api/v1/controller/ca/<integer-id>/crl handled by CrlDownloadView.retrieve; the sibling CA detail endpoint is correctly scoped and returns 404. Limiting factors that reduce real-world impact: the leak is confined to CRL contents (CA issuer data and revoked certificate serial numbers) with no private-key disclosure and no modification; and per the advisory, django-x509 serves CRLs publicly by default unless DJANGO_X509_CRL_PROTECTED=True, so only deployments that have explicitly enabled CRL protection experience a genuine new confidentiality exposure from this REST API behavior.

This is a genuine but low-severity authorization flaw (CWE-862, Missing Authorization) rather than a high-urgency issue. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N, 5.3 Medium) is self-consistent with the description: network-reachable, low attack complexity, but requiring PR:L - an authenticated organization manager holding CA view permission - with only low confidentiality impact and no integrity or availability impact. No EPSS score, SSVC automatable/technical-impact decision, or KEV status was supplied; the only priority signal is the vuln.today Decision label 'this_month', which aligns with a patch-this-cycle posture rather than act_now/emergency. There is no KEV listing and no PoC or exploit reference among the inputs, so exploitation is not demonstrated. Critically, the vendor advisory notes django-x509 exposes CRLs publicly by default unless DJANGO_X509_CRL_PROTECTED=True, meaning default deployments gain no new confidentiality exposure from this bug - the real exposure is confined to multi-tenant deployments that have explicitly enabled CRL protection. Net: a real authorization-boundary defect worth patching on a normal cycle, not a high-CVSS-but-overrated emergency.

A legitimate organization manager in a multi-tenant OpenWISP Controller instance, holding CA view permission for organization A, enumerates sequential integer CA IDs against GET /api/v1/controller/ca/<id>/crl and requests a CA belonging to organization B. Because the CRL endpoint resolves the CA directly rather than through the organization-scoped queryset, the attacker receives organization B's CRL, disclosing CA issuer information and revoked certificate serial numbers. No public exploit identified at time of analysis; exploitation requires valid authenticated manager credentials and the attack complexity is low once authenticated.