CVE-2026-91774: Yao Authorization Bypass Vulnerability

CVE-2026-91774 Overview

Yao, an open-source application engine, contains a missing authorization vulnerability [CWE-862] in versions through v1.0.0-rc22. The GET /user/teams/:id endpoint authenticates callers but does not verify membership or ownership before returning team records. Any authenticated user who supplies a known or guessable team identifier can retrieve the full team object, including name, description, owner information, and settings. The flaw is categorized as Broken Access Control and exposes sensitive tenant metadata across organizational boundaries.

Critical Impact

Authenticated attackers can enumerate team identifiers and read arbitrary team records without membership verification, exposing owner details and configuration data.

Affected Products

• YaoApp Yao through v1.0.0-rc22
• OpenAPI user team endpoint (openapi/user/team.go)
• OAuth user team provider (openapi/oauth/providers/user/team.go)

Discovery Timeline

• 2026-09-15 - CVE-2026-91774 published to the National Vulnerability Database
• 2026-09-17 - Last updated in NVD database

Technical Details for CVE-2026-91774

Vulnerability Analysis

The vulnerability affects the OpenAPI team retrieval flow in Yao. When a request reaches GET /user/teams/:id, the handler validates the caller's authentication token but never checks whether the caller is a member, owner, or administrator of the requested team. As a result, the endpoint returns the complete team record for any valid id value supplied by a logged-in user.

The exposed fields include the team name, description, owner identity, and internal settings. In multi-tenant deployments, this breaks isolation between tenants and enables cross-tenant reconnaissance. Attackers who register a low-privilege account can iterate team identifiers to harvest data belonging to other organizations.

Root Cause

The root cause is missing authorization logic between authentication and data retrieval. The handler in openapi/user/team.go (lines 80-149) executes the database read using only the URL parameter, without joining against a membership table or comparing the requested team owner to the authenticated subject. Authentication is treated as sufficient authorization, which is the classic [CWE-862] pattern.

Attack Vector

Exploitation requires only a valid session and network access to the OpenAPI surface. An attacker authenticates to the Yao instance, then issues sequential requests such as GET /user/teams/1, GET /user/teams/2, and so on. Each successful response discloses another team record. No user interaction, elevated privileges, or specialized tooling is required beyond an HTTP client.

The vulnerability mechanism is described in the VulnCheck Advisory on Yao and tracked upstream in YaoApp GitHub Issue #1553. See the YaoApp User Team Code for the vulnerable handler.

Detection Methods for CVE-2026-91774

Indicators of Compromise

• Sequential or enumerative GET requests to /user/teams/:id from a single authenticated session
• Access log entries showing successful 200 responses to team identifiers the requesting account does not own
• Spikes in read volume against the OpenAPI team endpoint from non-administrative accounts

Detection Strategies

• Correlate authenticated user identity with the team_id parameter and alert when a user retrieves records for teams they are not a member of
• Add server-side telemetry that logs the authenticated subject, requested team_id, and authorization decision for every OpenAPI team call
• Build rate-based rules that flag rapid iteration over the /user/teams/:id path from any single session or source IP

Monitoring Recommendations

• Forward Yao OpenAPI access logs to a centralized analytics platform for cross-tenant access review
• Baseline normal team read patterns per user role and alert on deviations
• Review historical logs for prior enumeration attempts against /user/teams/ prior to patching

How to Mitigate CVE-2026-91774

Immediate Actions Required

• Inventory all Yao deployments and identify instances running v1.0.0-rc22 or earlier
• Restrict network exposure of the OpenAPI surface to trusted clients until a fixed release is applied
• Rotate any secrets or configuration values that may have been exposed through team settings fields
• Review access logs for prior enumeration of /user/teams/:id and notify affected tenants where warranted

Patch Information

At the time of publication, the fix is tracked in YaoApp GitHub Issue #1553. Monitor the YaoApp GitHub Repository for a release beyond v1.0.0-rc22 that adds membership verification to the team retrieval handler. Apply the patched build as soon as it is published and validate that authorization checks reject cross-team reads.

Workarounds

• Place an API gateway or reverse proxy in front of Yao that enforces per-user allowlists for team identifiers
• Disable or block the GET /user/teams/:id route at the network layer if the endpoint is not required in your deployment
• Limit account registration and require administrator approval to reduce the pool of authenticated users who could exploit the flaw

# Example nginx block to restrict the vulnerable endpoint to internal networks
location ~ ^/user/teams/[0-9]+$ {
    allow 10.0.0.0/8;
    deny all;
    proxy_pass http://yao_backend;
}