Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.5",
  "pubDate": "2026-08-26T16:16:45.253Z",
  "pubdate": "2026-08-26T16:16:45.253Z",
  "executiveSummary": "The one-api application suffers from an Insecure Direct Object Reference (IDOR) vulnerability within its channel-pinning mechanism, leading to unauthorized privilege escalation.\nThe vulnerability resides in the request routing logic where one-api fails to enforce authorization checks when a user specifies a channel via a URL path parameter.\nAny authenticated user possessing a valid API token can interact with channels they are not authorized to access, including those restricted to administrative use or specific groups.\nBy manipulating the 'channelid' parameter, an attacker can coerce the application into acting as a proxy, forwarding requests to upstream model providers using the operator's sensitive provider keys.\nThis bypasses the platform's multi-tenancy controls, model allowlists, and group-based access restrictions.\nThe impact is significant, as it allows low-privilege accounts to perform unauthorized model inference operations at the operator's expense and potentially gain access to sensitive provider configurations.\nThe flaw stems from an inconsistent security implementation where one path enforces 'model.IsAdmin' checks while the path-parameter branch bypasses all authorization logic, assuming the presence of a valid token is sufficient for access.",
  "technicalDetails": "The vulnerability exists in 'middleware/auth.go' within the one-api codebase. The application supports two distinct mechanisms for pinning a channel to a request: an API key suffix or a URL path parameter.\nThe API key suffix method correctly invokes 'model.IsAdmin' to verify the caller's privileges before allowing the channel selection to proceed. In contrast, the path-parameter branch, which extracts the channel ID from 'c.Param(\"channelid\")', fails to perform any verification of user roles or group membership.\nThe attack flow begins when an authenticated user sends a request to the vulnerable endpoint with a manipulated 'channelid' parameter. Since the route is only guarded by generic token authentication, the request proceeds to the distributor.\nThe distributor component retrieves the channel configuration based on the provided integer identifier without scoping the lookup to the authenticated user's session or organizational group. Upon successfully loading the channel record, the application replaces the outbound 'Authorization' header with the credentials stored for that specific channel.\nThe request is then forwarded to the channel's upstream provider base URL. Because the application blindly trusts the 'channelid' input, an attacker can perform enumeration by incrementing the integer identifier to identify and utilize other existing channels defined in the system.\nThis behavior results in a complete bypass of the 'model allowlist' and 'per-group' restrictions. The attacker effectively masquerades as the system, utilizing the operator-configured credentials stored in the one-api database to execute arbitrary requests against third-party model providers.\nThe root cause is the lack of authorization enforcement in the controller logic handling 'channelid'. The system assumes that if a user is authenticated, they have implicit authority to interact with any channel defined in the system, failing to validate ownership or administrative scope."
}