CVE-2026-80208 in APITable
Summary
by MITRE • 08/27/2026
APITable through 1.13.0-beta.1 annotates both getUserHistories and closePausedUserAccount in InternalUserController with requiredLogin = false. ResourceInterceptor honours that annotation by returning before any session or API key is validated, and the nginx gateway shipped with the product proxies every /api request to the backend server, so both endpoints are reachable by any unauthenticated client that can reach the gateway. An attacker can POST to /api/v1/internal/getUserHistories to enumerate the accounts sitting in the 30-day cooling-off period that follows a deletion request, then POST to /api/v1/internal/users/{userId}/close for each one. The closure path clears the account's email address, phone number and nickname, cancels its space subscriptions, removes its space memberships and deletes its OAuth bindings, so the cooling-off window that exists to let a user reverse a deletion request is bypassed and the account cannot be recovered.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability in APITable versions through 1.13.0-beta.1 stems from an improper access control configuration within the InternalUserController component, specifically affecting the getUserHistories and closePausedUserAccount endpoints. These internal API methods were incorrectly annotated with a requiredLogin parameter set to false, signaling that authentication is not mandatory for their execution. The application's ResourceInterceptor logic respects this annotation by bypassing session validation and API key verification steps entirely when these specific routes are accessed. This architectural flaw creates a critical security gap because the nginx gateway included in the product distribution proxies all incoming requests directed at /api paths to the backend server without applying additional authentication checks for internal endpoints. Consequently, any unauthenticated client with network connectivity to the gateway can directly invoke these sensitive administrative functions, effectively treating protected internal operations as public-facing services.
The operational impact of this misconfiguration allows an attacker to perform a destructive account enumeration and forced closure attack sequence that bypasses intended safety mechanisms. By sending POST requests to /api/v1/internal/getUserHistories, an adversary can retrieve data regarding user accounts currently in the thirty-day cooling-off period following a deletion request. This window is designed as a grace period allowing users to reverse their decision to delete their account and recover their data. However, because the endpoint is accessible without authentication, attackers can enumerate these vulnerable accounts. Subsequently, by issuing POST requests to /api/v1/internal/users/{userId}/close for each identified user ID, the attacker triggers an immediate closure process that permanently destroys the account state. This action clears sensitive personally identifiable information including email addresses, phone numbers, and nicknames, cancels all space subscriptions, removes memberships from shared spaces, and deletes associated OAuth bindings.
This vulnerability represents a severe breach of data integrity and availability principles within the application's security model. The ability to forcibly close accounts during their recovery window undermines user trust and can lead to permanent loss of critical business data stored within APITable workspaces. From an industry standard perspective, this flaw aligns with CWE-284 Improper Access Control, as the system fails to enforce proper authorization checks on sensitive internal endpoints. Furthermore, it relates to CWE-601 URL Redirection to Untrusted Destination in the context of how the gateway proxies requests without validating their origin or intent for internal routes. In terms of adversarial tactics, this behavior corresponds to ATT&CK technique T1078 Valid Accounts, where an attacker leverages valid but unauthenticated access paths to perform unauthorized actions that compromise account integrity and data confidentiality.
To mitigate this vulnerability, immediate remediation is required by correcting the authentication annotations on the InternalUserController methods. The getUserHistories and closePausedUserAccount endpoints must be configured with a mandatory login requirement or restricted via IP whitelisting if they are intended for internal service-to-service communication only. Additionally, the nginx gateway configuration should be updated to enforce strict access controls on /api/internal paths, ensuring that requests targeting these routes require valid authentication tokens regardless of backend annotations. Implementing rate limiting and monitoring for unusual patterns of account closure operations can also help detect potential abuse in real-time while permanent fixes are deployed.