OpenWISP Controller CA CRL REST API does not scope requests to managed organizationsGHSA-9gh4-xw24-9xh5
Fix: openwisp/openwisp-controller@90ded78GHSA-9gh4-xw24-9xh5 is a CWE-862 vulnerability in openwisp-controller. A fix is available for openwisp-controller — see the affected versions and patch details below.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
openwisp-controllerReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The authenticated REST API endpoint for downloading a CA Certificate Revocation List resolves the requested CA without applying the organization-scoped queryset used by the rest of the PKI API.
An organization manager with CA view permission can request another organization's sequential CA ID and receive that CA's CRL. The endpoint is intended to be authenticated and organization-scoped, so it should use the same access-control path as GET /api/v1/controller/ca/<id>/.
Affected endpoint
GET /api/v1/controller/ca/<integer-id>/crl
CrlDownloadView inherits ProtectedAPIMixin, which requires an authenticated organization manager with the relevant model permission. However, retrieve() resolves the CA with get_object_or_404(Ca, pk=kwargs["pk"]). This bypasses FilterByOrganizationManaged and does not perform an object-level permission check.
Consequently, a manager of organization A can enumerate CA integer IDs and retrieve the CRL for a CA belonging to organization B. The sibling CA detail endpoint is correctly organization-scoped and returns 404 for the same cross-organization request.
Impact
The endpoint returns only the CRL, including CA issuer information and revoked certificate serial numbers. It does not disclose CA private keys and does not permit modification.
django-x509 exposes CRLs publicly by default unless DJANGO_X509_CRL_PROTECTED = True. Therefore, the default configuration does not gain a new confidentiality exposure from this REST API behavior. Nonetheless, the endpoint is part of the authenticated, organization-scoped REST API and does not enforce its intended authorization boundary.
Deployments that explicitly protect CRLs have a stronger expectation that this endpoint will scope access to the requester's managed organizations. The practical impact is low, but the authorization behavior should be corrected for consistency and defense in depth.
Remediation
Resolve the CA through the view's organization-scoped queryset. Set queryset = Ca.objects.all(), replace the direct get_object_or_404(Ca, pk=kwargs["pk"]) lookup with self.get_object(), and add a regression test that a same-organization manager receives 200 while a manager of another organization receives 404.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | openwisp-controller | ≥ 1.0.0&&< 1.3.2 | 1.3.2pip install --upgrade 'openwisp-controller==1.3.2' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for openwisp-controller, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update openwisp-controller to 1.3.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9gh4-xw24-9xh5 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-9gh4-xw24-9xh5 in your dependencies?
Find it across PyPI, including transitive dependencies.