CVE-2026-64866 in New API
Summary
by MITRE • 08/17/2026
New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. From 0.9.1.3 until 1.0.0-rc.7, AdminResetPasskey in controller/passkey.go lacks the canManageTargetRole authorization check for DELETE /api/user/:id/reset_passkey, allowing a lower-privileged administrator to remove a passkey from a same-level or higher-privileged account, including a root account. This issue is fixed in version 1.0.0-rc.7.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability identified within the New API platform, specifically affecting versions ranging from 0.9.1.3 through 1.0.0-rc.7, represents a critical failure in access control mechanisms governing administrative functions related to authentication assets. The system operates as an LLM gateway and AI asset management tool, where maintaining strict separation of privileges is essential for the integrity of user accounts and associated security credentials. The specific flaw resides within the AdminResetPasskey endpoint located at controller/passkey.go, which handles HTTP DELETE requests targeting the reset passkey functionality for a specified user identified by their unique identifier in the URL path. This function was designed to allow administrators to manage or remove passkeys associated with user accounts, presumably as part of routine administrative maintenance or security remediation procedures.
The core technical deficiency is an absence of proper authorization verification within this specific API handler. When a request is made to delete a passkey for a target user account, the system fails to validate whether the requesting administrator possesses the canManageTargetRole permission required for that action. Consequently, any authenticated user with administrative privileges, regardless of their actual privilege level relative to the target account, can execute this operation. This lack of horizontal and vertical access control enforcement means that an administrator with lower or equal privileges compared to a root-level admin can successfully strip authentication credentials from higher-privileged accounts. The vulnerability exploits the assumption that all administrators have unrestricted authority over user security assets, ignoring the principle of least privilege which dictates that users should only have access to resources necessary for their specific role.
The operational impact of this flaw is severe, as it directly compromises the availability and integrity of administrative authentication mechanisms. By allowing a lower-privileged administrator to remove passkeys from root or higher-level accounts, an attacker can effectively lock out senior administrators if no alternative recovery methods are available. This creates a denial-of-service condition for high-value accounts, disrupting critical operations within the AI asset management system. Furthermore, this capability facilitates privilege escalation scenarios where malicious actors might use account disruption as a vector to force password resets or exploit other authentication flows that may have weaker security controls than passkey-based systems. The ability to manipulate credentials of higher-privileged users undermines the trust model of the application and exposes sensitive administrative functions to abuse by insiders or compromised lower-level accounts.
This vulnerability aligns with CWE-269, which classifies Improper Privilege Escalation, specifically highlighting cases where a user gains capabilities beyond their assigned role through insufficient access control checks. It also maps closely to MITRE ATT&CK technique T1078, Valid Accounts, as the exploitation relies on using legitimate administrative credentials that are not properly scoped for specific actions. The flaw represents a classic example of broken object level authorization (BOLA) or insecure direct object reference in the context of role-based access control, where the system fails to enforce boundaries between different privilege tiers during sensitive operations involving user identity management.
To mitigate this vulnerability, organizations must upgrade immediately to version 1.0.0-rc.7 or later, which includes the necessary code corrections to enforce proper authorization checks on the AdminResetPasskey endpoint. For systems that cannot be upgraded instantly due to operational constraints, implementing a compensating control such as an API gateway rule can help by validating user roles against specific resource permissions before allowing requests to reach the application logic. Additionally, security teams should review other administrative endpoints within the New API platform for similar authorization gaps, ensuring that all sensitive operations involving user data or credentials are protected by robust role-based access controls. Regular penetration testing focused on horizontal and vertical privilege escalation is recommended to identify and remediate such flaws before they can be exploited in production environments.