Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.2",
  "pubDate": "2026-08-27T17:20:50.273Z",
  "pubdate": "2026-08-27T17:20:50.273Z",
  "executiveSummary": "APITable versions through 1.13.0-beta.1 contain a critical authentication bypass vulnerability affecting internal administrative endpoints. Specifically, the 'getUserHistories' and 'closePausedUserAccount' functions within the 'InternalUserController' are incorrectly annotated with 'requiredLogin = false', allowing unauthenticated remote access.\nThe vulnerability is exposed via the default nginx gateway configuration, which proxies all '/api' requests directly to the backend. This flaw permits unauthorized actors to enumerate users currently in a 30-day deletion cooling-off period and trigger immediate, permanent account closure for those users.\nThe impact is severe, as it enables malicious actors to bypass account recovery mechanisms, leading to irreversible data loss and unauthorized service disruption for targeted users. Exploitation requires no authentication or specific privileges, relying solely on network accessibility to the gateway. This represents a significant risk to user data integrity and platform availability, necessitating immediate remediation to enforce proper authentication controls on sensitive internal API routes.",
  "technicalDetails": "The root cause of this vulnerability lies in an improper configuration of security annotations within the 'InternalUserController' component. In APITable versions through 1.13.0-beta.1, the functions 'getUserHistories' and 'closePausedUserAccount' are explicitly marked with 'requiredLogin = false'. The application's 'ResourceInterceptor' honors this annotation, causing the application to return a response before validating any session tokens or API keys.\nBecause the standard nginx gateway configuration forwards all traffic routed to the '/api' prefix directly to the backend server, these internal-only endpoints are exposed to the public network. An attacker can reach these endpoints without providing valid authentication credentials.\nThe exploitation flow is as follows: 1) The attacker performs an unauthenticated POST request to '/api/v1/internal/getUserHistories'. Because the interceptor bypasses authentication, the server returns a list of accounts currently pending deletion (the 30-day cooling-off period). 2) The attacker iterates through the identified 'userId' values and sends unauthenticated POST requests to '/api/v1/internal/users/{userId}/close'. 3) The 'closePausedUserAccount' function executes, performing a hard closure of the account.\nThe payload behavior and post-exploitation impact are highly destructive. The closure process acts as a permanent purge: it clears the user's primary identifiers (email, phone number, and nickname), terminates all space subscriptions, revokes memberships, and deletes all linked OAuth bindings. By triggering this flow, an attacker effectively renders the 30-day recovery grace period moot, as the account's original state and recovery path are destroyed.\nThe vulnerability is limited to unauthenticated access to the defined '/api/v1/internal/' path. Since the nginx gateway lacks internal/external request segregation, the attack surface includes any client capable of routing traffic to the gateway. No specific session or elevated privilege is required to initiate these calls, as the logic relies entirely on the flawed 'requiredLogin' annotation to bypass the security stack."
}