Authentication Bypass in APITable InternalUserController

APITable versions up to and including 1.13.0-beta.1 contain an authentication bypass vulnerability in the InternalUserController class. The endpoints getUserHistories and closePausedUserAccount are incorrectly annotated with requiredLogin = false. The application's ResourceInterceptor honors this annotation by skipping session or API key validation for these routes. Because the product's bundled nginx gateway proxies all /api requests to the backend, these sensitive administrative functions are exposed to any unauthenticated client with network access to the gateway. An attacker can exploit this to enumerate accounts awaiting permanent deletion and finalize the removal process, thereby bypassing the 30-day account recovery cooling-off period. This leads to irreversible data loss for targeted users.

Attack Chain

1. Attacker performs network reconnaissance to identify an APITable instance reachable via HTTP/HTTPS.
2. Attacker probes the /api/v1/internal/ path to determine if the InternalUserController endpoints are exposed without authentication.
3. Attacker sends a POST request to /api/v1/internal/getUserHistories to retrieve a list of all user accounts currently in a 30-day cooling-off (deleted/paused) state.
4. Attacker parses the response to extract valid userId values for the identified target accounts.
5. Attacker iterates through the collected userId values.
6. Attacker sends a POST request to /api/v1/internal/users/{userId}/close for each identified account.
7. The backend processes the closure, clearing PII, canceling subscriptions, and deleting OAuth bindings.
8. Account recovery is successfully prevented, resulting in permanent data destruction for the targeted user.

Impact

Successful exploitation results in the permanent loss of user accounts that are otherwise protected by a 30-day recovery window. This vulnerability impacts the integrity and availability of user data within the APITable platform. While the scope of impact depends on the number of accounts currently in the cooling-off period, unauthorized access to administrative internal APIs constitutes a critical breach of the platform's security boundary.

Recommendation

Prioritized, concrete actions for detection engineering teams:

• Implement monitoring on web server logs for HTTP POST requests to /api/v1/internal/ originating from untrusted or non-administrative source IPs.
• Patch APITable to a version beyond 1.13.0-beta.1 that corrects the requiredLogin annotation for the InternalUserController.
• Restrict network access to the /api/v1/internal/ path at the nginx gateway or firewall level to ensure only authorized management IPs can access these administrative endpoints.