CVE-2026-116677 in Controller
Summary
by MITRE • 10/27/2026
OpenWISP Controller is a network and WiFi controller for provisioning, configuration management, updates, and PKI management. From 1.0.0 until 1.3.2, the GET /api/v1/controller/ca/<integer-id>/crl endpoint allows an authenticated organization manager with CA view permission to retrieve another organization's certificate revocation list by requesting its sequential CA identifier. CrlDownloadView.retrieve resolves the CA directly instead of using the organization-scoped object retrieval enforced by FilterByOrganizationManaged, bypassing the endpoint's intended authorization boundary. The response can disclose CA issuer information and revoked certificate serial numbers, but it does not expose CA private keys or allow modification. This issue is fixed in version 1.3.2.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified within OpenWISP Controller versions ranging from 1.0.0 to 1.3.2 represents a critical failure in object-level authorization controls, specifically affecting the Certificate Revocation List retrieval mechanism. As a network and WiFi controller designed for provisioning, configuration management, updates, and Public Key Infrastructure operations, maintaining strict isolation between organizational data is paramount. The flaw resides within the GET /api/v1/controller/ca/<integer-id>/crl endpoint, which was intended to serve certificate revocation lists exclusively to authorized users of the specific organization owning that Certificate Authority. However, the implementation failed to enforce these boundaries correctly during the retrieval process.
The technical root cause lies in how the CrlDownloadView.retrieve method resolves the target resource. Instead of leveraging the FilterByOrganizationManaged mixin or similar authorization frameworks that scope database queries and object access to the current user's organization context, the view directly resolved the Certificate Authority using the provided integer identifier from the URL path. This architectural oversight means that if an authenticated organization manager possesses CA view permissions for their own entity, they can simply manipulate the sequential ID parameter in the request to target a different organization's CA. The system does not validate whether the requested CA belongs to the requester's organization before proceeding with the retrieval operation.
This flaw constitutes an Insecure Direct Object Reference vulnerability, commonly categorized under CWE-639. By bypassing the intended authorization boundary, an attacker can perform unauthorized data access across organizational silos. While the impact is limited in scope compared to full system compromise, it allows for significant information disclosure. The retrieved Certificate Revocation List contains sensitive operational intelligence, including CA issuer details and the serial numbers of revoked certificates. This information aids adversaries in mapping out the PKI infrastructure of a target organization, potentially facilitating further attacks such as certificate forgery analysis or targeted denial-of-service against specific revoked entities.
The ATT&CK framework classifies this behavior under T1078 Valid Accounts for initial access and more specifically within data exfiltration techniques where sensitive information is gathered from external resources. Although the vulnerability does not expose CA private keys nor allow for modification of certificates, preserving confidentiality integrity to some degree, it violates the principle of least privilege by granting cross-tenant visibility that should be strictly prohibited in a multi-tenancy environment. The operational impact includes potential compliance violations if customer data is exposed and reputational damage due to perceived security weaknesses in the isolation mechanisms.
Mitigation for this vulnerability requires immediate upgrade to version 1.3.2 or later, where the issue has been resolved by correcting the object resolution logic to respect organizational boundaries. For environments unable to patch immediately, administrators should implement strict access control lists at the network perimeter level if possible and audit logs for unusual patterns of CA identifier enumeration. Future development practices must ensure that all API endpoints utilizing direct object references are rigorously tested against authorization bypass scenarios using automated security testing tools integrated into the CI/CD pipeline.