Apitable
Monthly
Unauthenticated access to the internal organization loadOrSearch endpoint in APITable through 1.13.0-beta.1 exposes complete workspace member directories-including names, email addresses, and team hierarchy-to any remote attacker who possesses a valid space identifier. Space identifiers are trivially obtainable from shared links or public templates, making this effectively a zero-prerequisite information disclosure against any APITable deployment with sharing enabled. No public exploit code or active exploitation has been identified at time of analysis, but the attack requires only standard HTTP tooling and no credentials.
Unauthenticated remote destruction of pending-deletion accounts is possible in APITable through 1.13.0-beta.1, where two internal user-management endpoints are reachable by any network client without credentials. The InternalUserController annotates both getUserHistories and closePausedUserAccount with requiredLogin = false, causing ResourceInterceptor to skip all session and API-key validation; the bundled nginx gateway forwards every /api request to the backend, giving external attackers a direct path. An attacker can enumerate accounts in the 30-day deletion cooling-off window and then permanently destroy each one - wiping PII, cancelling subscriptions, removing space memberships, and revoking OAuth bindings - with no possibility of recovery. No public exploit code or CISA KEV listing has been identified at time of analysis.
Cross-space information disclosure in APITable through 1.14.0-beta lets any authenticated, low-privileged user read node descriptions from other spaces by sending GET /node/{nodeId}/description with a user-controlled nodeId that skips space-membership and node-permission checks (CWE-639). The flaw has the greatest effect on multi-tenant or shared deployments, where descriptions can expose datasheet, folder, and form metadata belonging to another organization. The assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, indicating a bounded, confidentiality-only issue; no public exploit identified at time of analysis, and no vendor-released patch version was identified at time of analysis, although a technical write-up and a VulnCheck advisory are available.
Unauthenticated notification injection in APITable through 1.13.0-beta.1 permits any network-reachable client to write arbitrary messages into any user's inbox by exploiting a missing-authentication annotation on the internal notification create endpoint. The InternalNotifyController marks its create handler with requiredLogin = false, causing ResourceInterceptor to skip all session and API key validation; because the nginx gateway bundled with the product proxies every /api path to the Java backend, the endpoint POST /api/v1/internal/notification/create is fully exposed to unauthenticated callers. Setting fromUserId to 0 makes injected messages render as legitimate system notifications, enabling platform-wide social-engineering attacks; no public exploit code has been identified at time of analysis, though the flaw is documented in a public GitHub issue (no KEV listing).
Unauthenticated access to the internal organization loadOrSearch endpoint in APITable through 1.13.0-beta.1 exposes complete workspace member directories-including names, email addresses, and team hierarchy-to any remote attacker who possesses a valid space identifier. Space identifiers are trivially obtainable from shared links or public templates, making this effectively a zero-prerequisite information disclosure against any APITable deployment with sharing enabled. No public exploit code or active exploitation has been identified at time of analysis, but the attack requires only standard HTTP tooling and no credentials.
Unauthenticated remote destruction of pending-deletion accounts is possible in APITable through 1.13.0-beta.1, where two internal user-management endpoints are reachable by any network client without credentials. The InternalUserController annotates both getUserHistories and closePausedUserAccount with requiredLogin = false, causing ResourceInterceptor to skip all session and API-key validation; the bundled nginx gateway forwards every /api request to the backend, giving external attackers a direct path. An attacker can enumerate accounts in the 30-day deletion cooling-off window and then permanently destroy each one - wiping PII, cancelling subscriptions, removing space memberships, and revoking OAuth bindings - with no possibility of recovery. No public exploit code or CISA KEV listing has been identified at time of analysis.
Cross-space information disclosure in APITable through 1.14.0-beta lets any authenticated, low-privileged user read node descriptions from other spaces by sending GET /node/{nodeId}/description with a user-controlled nodeId that skips space-membership and node-permission checks (CWE-639). The flaw has the greatest effect on multi-tenant or shared deployments, where descriptions can expose datasheet, folder, and form metadata belonging to another organization. The assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, indicating a bounded, confidentiality-only issue; no public exploit identified at time of analysis, and no vendor-released patch version was identified at time of analysis, although a technical write-up and a VulnCheck advisory are available.
Unauthenticated notification injection in APITable through 1.13.0-beta.1 permits any network-reachable client to write arbitrary messages into any user's inbox by exploiting a missing-authentication annotation on the internal notification create endpoint. The InternalNotifyController marks its create handler with requiredLogin = false, causing ResourceInterceptor to skip all session and API key validation; because the nginx gateway bundled with the product proxies every /api path to the Java backend, the endpoint POST /api/v1/internal/notification/create is fully exposed to unauthenticated callers. Setting fromUserId to 0 makes injected messages render as legitimate system notifications, enabling platform-wide social-engineering attacks; no public exploit code has been identified at time of analysis, though the flaw is documented in a public GitHub issue (no KEV listing).