Unauthenticated notification injection via /api/v1/internal/notification/create

reported via email on 25 May 2026 - no response:

I am reporting a second missing authentication vulnerability in APITable (all versions through commit 88b24ce / docker tag latest). This issue allows an unauthenticated remote attacker to inject in-application notifications into any user's notification inbox.

The InternalNotifyController class exposes POST /api/v1/internal/notification/create with requiredLogin = false. Because the nginx gateway proxies all /api requests to the backend-server, this endpoint is reachable by any unauthenticated HTTP client.

Reproduction (no credentials required):

POST /api/v1/internal/notification/create HTTP/1.1
Host: [target.example.com](http://target.example.com/)
Content-Type: application/json

[{"toUserId":["2058868888842764290"],"fromUserId":"0","templateId":"common_system_notify","body":{"extras":{"content":"Injected by unauthenticated attacker"}}}]

Response: {"success":true,"code":200,"message":"SUCCESS","data":null}

The notification is persisted in apitable_player_notification with from_user = 0 (system sender), making it appear as a legitimate system message. The body extras field is stored verbatim and is forwarded to the frontend. Existing system notifications include action callbacks (window_open_url(), mark_cur_notice_to_read()) in this field, indicating the field is interpreted rather than displayed literally.

The root cause is the requiredLogin = false annotation on the endpoint, which causes ResourceInterceptor to bypass all authentication checks.

CVSS 3.1 base score: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N = 5.3 Medium CWE-306: Missing Authentication for Critical Function

I reproduced this against docker tag apitable/backend-server:latest (commit 88b24ce) on 2026-05-25.