GHSA-9GH4-XW24-9XH5
Vulnerability from github – Published: 2026-10-30 22:58 – Updated: 2026-10-30 22:58Summary
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": [
{
"package": {
"ecosystem": "PyPI",
"name": "openwisp-controller"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.3.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-116677"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-30T22:58:10Z",
"nvd_published_at": "2026-10-27T18:17:35Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe 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.\n\nAn organization manager with CA view permission can request another organization\u0027s sequential CA ID and receive that CA\u0027s 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/\u003cid\u003e/`.\n\n## Affected endpoint\n\n```text\nGET /api/v1/controller/ca/\u003cinteger-id\u003e/crl\n```\n\n`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.\n\nConsequently, 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.\n\n## Impact\n\nThe 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.\n\ndjango-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.\n\nDeployments that explicitly protect CRLs have a stronger expectation that this endpoint will scope access to the requester\u0027s managed organizations. The practical impact is low, but the authorization behavior should be corrected for consistency and defense in depth.\n\n## Remediation\n\nResolve the CA through the view\u0027s 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`.",
"id": "GHSA-9gh4-xw24-9xh5",
"modified": "2026-10-30T22:58:10Z",
"published": "2026-10-30T22:58:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openwisp/openwisp-controller/security/advisories/GHSA-9gh4-xw24-9xh5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-116677"
},
{
"type": "WEB",
"url": "https://github.com/openwisp/openwisp-controller/commit/90ded783267aa11b89768b0ec9ae69895cc3730c"
},
{
"type": "WEB",
"url": "https://github.com/openwisp/openwisp-controller/commit/9e1869e17734a0f34bc428622d463c1a8c230720"
},
{
"type": "PACKAGE",
"url": "https://github.com/openwisp/openwisp-controller"
},
{
"type": "WEB",
"url": "https://github.com/openwisp/openwisp-controller/releases/tag/1.3.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenWISP Controller CA CRL REST API does not scope requests to managed organizations"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.