CVE-2026-81027: one-api through 0.6.10 Missing Authorization on URL-Parameter Channel Pinning
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
one-apito a version that resolves this vulnerability.Fixed in 0.6.10Patch Missing Authorization on URL-Parameter Channel Pinning - Configuration
Ensure the URL path parameter channelid pinning path (c.Param("channelid")) requires the same operator-configured authorization checks as the API-key suffix path, preventing any authenticated API token from selecting arbitrary channels.
middleware/auth.go channel pinning authorization = enforce role check for URL path parameter branch - Configuration
When loading the selected channel by integer identifier from the provided channelid, scope the lookup to the caller’s user/group (or otherwise verify the caller is allowed). Only set the outbound Authorization header using a stored key for a channel the caller is permitted to access.
distributor (channel loading + outbound Authorization) channel scoping for selected-channel = no cross-user/group channel selection
Event History
Frequently Asked Questions
Who can exploit this issue?
Any authenticated one-api account with a valid API token can reach the affected route. The account does not need administrator privileges, membership in the target channel's group, or permission to use the target channel's configured models.
What access does an attacker gain by selecting another channel?
The attacker can cause one-api to send upstream requests to an arbitrarily selected channel using that channel's stored provider key. This can bypass per-group channel restrictions and the channel's model allowlist, potentially consuming or accessing provider-backed capabilities assigned to another channel.
Are unauthenticated deployments affected?
The affected route is behind token authentication, so an unauthenticated attacker cannot use this path based on the available information. Deployments should treat every valid API token, including tokens issued to low-privilege users, as capable of triggering the issue.
How could an administrator identify possible exploitation?
Look for requests that specify channel identifiers in the URL path and compare the requesting token's account or group permissions with the selected channel. Suspicious activity includes low-privilege users selecting channels outside their assigned groups or invoking models that the selected channel would normally disallow for them.