CVE-2026-80207
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.
Predictions
Heuristic predictions, AS-IS, for prioritization only.
Mitigations
No mitigations published for this CVE yet.
The vendor-content worker queues fetches as references arrive (check back in a few minutes). Or — if you've already worked around this in production — publish your fix to the community-verified tier.
Propose a mitigation on Community Mitigations published via the community go through AI scoring + 2 human reviewers + 7-day silent objection window before landing here withsource_tier=community-verified.
References
- https://github.com/apitable/apitable
- https://github.com/apitable/apitable/blob/88b24ce9f359cc434778be75d03603182882dc76/backend-server/application/src/main/java/com/apitable/internal/controller/InternalNotifyController.java#L50
- https://github.com/apitable/apitable/issues/1813
- https://www.vulncheck.com/advisories/apitable-through-1.13.0-beta.1-missing-authentication-on-the-internal-notification-create-endpoint
CWEs
CWE-306
Community-verified mitigations for this CVE will appear above when contributors publish them.
Verify integrity in audit chain (admin only). AS-IS.