CVE-2026-92750 in Harness
Summary
by MITRE • 09/16/2026
Harness through 3.3.0 omits access control validation in the infrastructure provider read endpoint, allowing authenticated users to retrieve provider configurations from spaces they do not belong to. Attackers can query the GET /api/v1/infraproviders endpoint with arbitrary space identifiers to expose sensitive provider metadata including Docker endpoints, TLS certificate paths, and cloud project identifiers.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in Harness versions up to 3.3.0 represents a critical failure in server-side access control mechanisms within the infrastructure provider management subsystem. Specifically, the GET /api/v1/infraproviders endpoint fails to validate whether the authenticated user requesting data has legitimate membership or authorization for the specific space associated with the requested resource. This flaw allows an attacker who possesses valid credentials for any account within the Harness environment to bypass logical access controls by manipulating input parameters. By supplying arbitrary space identifiers in API requests, the application erroneously returns configuration details for infrastructure providers located in spaces where the user has no permissions or visibility rights.
From a technical perspective, this issue stems from an insecure direct object reference pattern where the server trusts client-supplied identifiers without cross-referencing them against the authenticated session's permission set. The endpoint exposes sensitive operational metadata that is intended to be isolated per space for security and organizational reasons. Exposed data includes Docker registry endpoints, which may reveal internal container infrastructure details; TLS certificate paths, which can aid in further reconnaissance or potential man-in-the-middle attacks if combined with other vulnerabilities; and cloud project identifiers such as AWS account IDs or Azure subscription names. This information disclosure significantly expands the attack surface by providing adversaries with a map of the underlying cloud architecture and configuration specifics without requiring elevated privileges.
The operational impact of this vulnerability is substantial, particularly in multi-tenant environments where strict isolation between teams or projects is required. The leakage of provider configurations can facilitate further attacks such as credential stuffing against exposed Docker registries, targeted phishing campaigns using known organizational structures, or lateral movement within cloud accounts if the disclosed identifiers are linked to other vulnerable services. Furthermore, this breach violates fundamental principles of data confidentiality and integrity, potentially leading to non-compliance with regulatory standards that mandate strict access controls for sensitive infrastructure data.
This vulnerability aligns closely with CWE-284 Improper Access Control and CWE-1065 Inconsistent Interpretation of HTTP Requests in the Common Weakness Enumeration framework. It also maps directly to MITRE ATT&CK technique T1078 Valid Accounts, as it exploits legitimate credentials to access unauthorized resources, and potentially T1005 Data from Local System if used for broader reconnaissance within a compromised environment. To mitigate this risk, organizations running Harness versions prior to 3.4.0 should upgrade immediately to the latest patched version where these access control validations have been enforced at the server level. Additionally, until an upgrade is performed, administrators can implement network-level controls such as Web Application Firewalls to monitor and restrict unusual patterns of space identifier enumeration or limit API exposure to trusted internal networks only.