CVE-2026-80208: APITable through 1.13.0-beta.1 Missing Authentication on the Internal Account Closure Endpoints
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.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to exploitation?
Any APITable deployment through 1.13.0-beta.1 where an unauthenticated client can reach the product's nginx gateway is exposed. The shipped gateway proxies every /api request to the backend, making the affected internal endpoints reachable without credentials.
What does an attacker need to exploit this issue?
The attacker needs only network access to the APITable gateway; no account, session, API key, or user interaction is required. They can enumerate accounts in the 30-day deletion cooling-off period and submit a closure request for each account identifier.
What is the impact on affected accounts?
Exploitation bypasses the cooling-off period intended to allow reversal of a deletion request. The closure process clears account contact and profile data, cancels space subscriptions, removes space memberships, deletes OAuth bindings, and leaves the account unrecoverable.