Description

APITable through 1.13.0-beta.1 annotates the create handler of InternalNotifyController 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 POST /api/v1/internal/notification/create is reachable by any unauthenticated client that can reach the gateway. An attacker can persist arbitrary notifications in apitable_player_notification against any user ID they name, and because fromUserId can be set to 0 the message is stored with the system sender and renders in the victim's inbox as a legitimate system notification. The body extras content is stored verbatim and forwarded to the frontend.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-27T17:20:50.113Z",
  "pubdate": "2026-08-27T17:20:50.113Z",
  "executiveSummary": "A critical improper access control vulnerability exists in APITable versions up to 1.13.0-beta.1. The flaw allows unauthenticated remote attackers to inject arbitrary notifications into the system via the InternalNotifyController.\nThe vulnerability originates from an incorrect security configuration where the create handler is annotated with requiredLogin = false. This configuration causes the ResourceInterceptor to bypass authentication and API key validation protocols.\nBecause the Nginx gateway facilitates direct routing to the backend API, the /api/v1/internal/notification/create endpoint is exposed to the public network. An attacker can leverage this exposure to spoof system notifications by manipulating the fromUserId parameter, effectively impersonating the system sender.\nThis impact is significant as it allows for the mass dissemination of fraudulent or malicious notifications to any user within the system, potentially facilitating phishing campaigns or social engineering attacks. The risk is considered high due to the lack of authentication requirements and the ability to target any user ID.",
  "technicalDetails": "The root cause of this vulnerability is an insecure configuration within the InternalNotifyController of the APITable backend. Specifically, the create handler is explicitly annotated with 'requiredLogin = false', which instructs the ResourceInterceptor to skip the standard security verification sequence for incoming requests.\nIn a standard deployment, the ResourceInterceptor acts as a gatekeeper, ensuring that session tokens or API keys are validated before the controller processes the request. By setting this annotation, the application bypasses these checks, treating the request as authorized regardless of the caller's identity. Furthermore, the accompanying Nginx gateway configuration lacks adequate request filtering, proxying requests directly to the backend.\nThe exploitation flow begins with an attacker targeting the publicly reachable endpoint 'POST /api/v1/internal/notification/create'. Because the gateway passes this request directly to the application, an attacker can submit a crafted JSON payload without providing any authentication credentials. The 'fromUserId' field within the payload can be set to '0', which the application interprets as a system-level sender.\nOnce the payload is processed, the system persists the notification in the 'apitable_player_notification' database table. Because the system renders notifications from sender '0' as legitimate administrative messages, the recipient perceives these notifications as coming from a trusted source. The 'extras' content field is stored and rendered verbatim in the victim's frontend interface, introducing a persistent XSS vector if the frontend fails to sanitize this input properly.\nThis allows an attacker to inject arbitrary content into any user's notification stream. The attacker can target specific user IDs, effectively conducting authenticated-looking social engineering without needing to compromise any actual administrative credentials. The vulnerability remains effective across all versions up to 1.13.0-beta.1, necessitating immediate configuration changes or updates to restrict access to internal API endpoints at the gateway level."
}