CVE-2026-108865 in Unla
Summary
by MITRE • 10/11/2026
AmoyLab Unla through 0.10.0 contains an authentication bypass vulnerability that allows unauthenticated attackers to obtain valid access tokens because the OAuth2 server never authenticates a resource owner. Attackers can register a client, request a code from /authorize, and exchange it at /token to access OAuth2-protected MCP prefixes, proxied upstream APIs and injected credentials.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in AmoyLab Unla versions through 0.10.0 represents a critical failure in the implementation of the OAuth2 authentication protocol, specifically within the resource owner password flow or implicit grant mechanisms depending on the specific configuration. The core technical flaw lies in the server's inability to properly validate the identity of the user attempting to obtain access tokens. In a standard OAuth2 workflow, when an application requests authorization from a resource owner, the authorization endpoint must present a login interface that requires valid credentials before issuing any codes or tokens. However, in this vulnerable implementation, the authentication step is entirely bypassed, allowing the server to issue valid access tokens without verifying who the user actually is. This fundamental misconfiguration effectively turns the OAuth2 provider into an open proxy for identity assertion, where anyone can impersonate any legitimate user by simply following the token exchange procedure.
From a technical perspective, the exploitation path involves three distinct steps that leverage this authentication gap. First, an attacker registers a malicious client application with the authorization server to obtain valid client credentials or identifiers required for subsequent requests. Second, the attacker initiates an authorization request against the /authorize endpoint. Because the system fails to authenticate the resource owner, it proceeds to generate and return an authorization code without prompting for username and password inputs. Finally, the attacker exchanges this unauthorized authorization code at the /token endpoint to receive a valid access token. This sequence allows the attacker to bypass all intended security controls associated with user identity verification, resulting in full authentication as any target account simply by manipulating the request parameters during the initial flow initiation.
The operational impact of this vulnerability is severe and multifaceted, extending beyond simple unauthorized access to encompass broader system compromise risks. Once an attacker obtains a valid access token through this bypass, they gain the ability to interact with OAuth2-protected Model Context Protocol prefixes that are intended to be restricted to authenticated users. Furthermore, because these tokens grant access to proxied upstream APIs, attackers can execute actions on behalf of legitimate users against backend services, potentially leading to data exfiltration, unauthorized transactions, or modification of critical system states. The mention of injected credentials in the vulnerability description suggests that this bypass may also facilitate credential harvesting or lateral movement within connected systems where these tokens are used for service-to-service communication or API integration, thereby amplifying the blast radius of a single authentication failure across multiple dependent services and data stores.
This flaw aligns directly with CWE-287 Improper Authentication, as the software does not adequately verify that an entity is who it claims to be before granting access privileges. Additionally, from a threat modeling perspective using MITRE ATT&CK frameworks, this vulnerability facilitates Initial Access via Valid Accounts (T1078) and potentially Credential Access if the bypass allows for further credential manipulation or theft during the session establishment phase. The lack of multi-factor authentication enforcement or strict binding of authorization codes to specific user sessions exacerbates the risk, allowing automated tools to rapidly enumerate and compromise multiple accounts without detection by standard login monitoring systems that typically look for failed password attempts rather than successful token exchanges via bypassed flows.
To mitigate this vulnerability, immediate remediation is required in the form of a software update to version 0.10.1 or later where the authentication logic has been corrected. In the interim, if an upgrade is not immediately feasible, administrators should implement strict input validation and session binding at the /authorize endpoint to ensure that user identity is verified before any authorization code is generated. Enforcing multi-factor authentication for all resource owners can also provide a secondary layer of defense even if the primary password check fails. Additionally, deploying Web Application Firewalls with rules specifically targeting OAuth2 token endpoints may help detect and block anomalous patterns associated with unauthenticated token requests. Regular security audits focusing on identity and access management configurations are essential to prevent similar misconfigurations in other parts of the application infrastructure that rely on external authorization servers for secure access control.