CVE-2026-81027 in one-api
Summary
by MITRE • 08/26/2026
one-api gates one of its two channel-pinning paths and not the other. middleware/auth.go permits a request to name a specific channel either through a suffix on the API key or through a URL path parameter. The suffix path is reached only after model.IsAdmin succeeds and otherwise rejects the caller, while the path-parameter branch sets the selected-channel value from c.Param("channelid") with no role check at all. The route carrying that parameter sits behind token authentication only, so any account holding a valid API token reaches it. The value flows to the distributor, which loads the channel by integer identifier with no scoping to the caller's user or group, and then sets the outbound Authorization header to that channel's stored key and directs the request at the channel's base URL. A low-privilege account can therefore pin any channel by incrementing an identifier, causing the server to make upstream requests bearing an operator-configured provider key the account was never granted, and bypassing both the per-group restriction and the channel's model allowlist.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability described constitutes a critical authorization bypass within the one-api gateway infrastructure, specifically targeting its channel-pinning mechanism. This flaw arises from an inconsistent implementation of access control checks across two distinct code paths that handle user-specified channel selection. The middleware responsible for authentication and routing, located in auth.go, exposes two methods for clients to designate a specific backend provider or channel: appending the channel identifier as a suffix to the API key itself, or passing it via a URL path parameter named channelid. While both mechanisms ultimately direct traffic through the same distribution logic, they are gated by fundamentally different security controls, creating an exploitable asymmetry that allows unauthorized escalation of privileges and data exposure.
The first code path, which processes the API key suffix, is correctly secured. It requires the calling account to possess administrative privileges, verified by a successful execution of model.IsAdmin before proceeding with channel selection. This ensures that only trusted operators can manually pin requests to specific backend channels using this method. However, the second path, triggered when the client provides the channelid parameter in the URL route, lacks any equivalent role-based access control check. The middleware simply extracts the integer identifier from the request parameters and passes it directly into the distribution logic without verifying whether the authenticated user has permission to use that specific resource. This oversight means that any account holding a valid API token, regardless of its privilege level or group membership, can arbitrarily select which backend provider handles their requests.
The operational impact of this vulnerability is severe due to how the selected channel identifier is processed downstream. The distributor component loads the target channel using the provided integer ID without performing any scoping checks against the caller's user profile, assigned groups, or organizational boundaries. Once loaded, the gateway replaces the outbound Authorization header with the secret key stored in that specific channel configuration and routes the request to the provider's base URL. Consequently, a low-privilege user can enumerate valid channel identifiers by incrementing the ID value until they find one associated with an operator-configured provider key. By doing so, the attacker effectively hijacks the identity of the backend service, causing the server to make upstream API calls bearing credentials that the attacker was never granted access to use.
This flaw leads directly to a violation of confidentiality and integrity principles as defined by industry standards such as CWE-269, which covers Improper Privilege Management, and specifically aligns with CWE-862 regarding Missing Authorization checks. Furthermore, from an offensive security perspective mapped against the MITRE ATT&CK framework, this vulnerability facilitates lateral movement within the API gateway ecosystem and enables unauthorized access to sensitive backend services, akin to techniques observed in T1078 Valid Accounts or T1556 Credential Hijacking if the provider keys contain further credentials. The attacker bypasses both per-group restrictions that limit which channels a user group can utilize and model allowlists designed to restrict usage of specific AI models through unauthorized providers.
To mitigate this vulnerability, immediate remediation is required in the middleware layer to enforce consistent authorization checks across all channel-selection paths. Specifically, the code branch handling the channelid URL parameter must be updated to validate that the authenticated user or their associated group has explicit permission to access the requested channel identifier before allowing the request to proceed to the distributor. This should involve querying a permissions database or checking role-based access control lists tied to the specific resource ID provided in the request. Additionally, implementing strict input validation and range checks on the channelid parameter can help prevent enumeration attacks by limiting the scope of valid identifiers returned to clients who do not have administrative privileges. Regular security audits focusing on API gateway routing logic are recommended to ensure that all entry points adhere to the principle of least privilege.