Scoold EUVD-2026-102313

Requires the attacker to possess one of the server signing secrets - app_secret_key or para_secret_key - which are not normally exposed; this is the primary limiting factor. Given the secret, the attacker forges a JWT (no registered API-key jti required) and targets the /api/config or /api/stats endpoints, which are mapped to the hardcoded administrative API_USER. Crucially, these checks run even when scoold.api_enabled is false, so disabling the API is NOT a mitigation. An ordinary user login-session token is explicitly insufficient - only a secret-signed token works. The definitive fix is upgrading to 1.69.1, which gates /api/config behind configEditingEnabled() and no longer accepts such tokens unconditionally.

This is a medium-severity authentication bypass (input CVSS 6.1) whose real-world risk is heavily gated by a single hard precondition: the attacker must already possess one of the server-side signing secrets (app_secret_key or para_secret_key). With that secret, exploitation is trivial (network-reachable, low complexity, no user interaction actually needed) and yields administrative read/write to configuration and server logs. Without it, the flaw is not exploitable, which keeps aggregate risk below what a C:H/I:H impact alone would suggest. Signal completeness is poor: no EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active or widespread exploitation - exploitation status is 'no public exploit identified at time of analysis.' Two input-data concerns should be verified: the supplied CVSS vector includes UI:R (user interaction required), but the described attack is a direct forged-token API call with no victim interaction, so UI:R appears inconsistent - treat it as UI:N. Secondly, the vector's PR:H is better understood as 'possession of a server signing secret' than as a normal authenticated account, since the advisory explicitly states an ordinary login-session token is NOT sufficient. A notable aggravating factor: the vulnerable special-endpoint checks execute even when scoold.api_enabled is false, so disabling the API does not mitigate the issue.

An attacker who has obtained either signing secret (e.g., from a leaked configuration file, exposed environment variable, or source/CI artifact) forges a JWT signed with that secret and sends it to /api/config or /api/stats. Scoold maps the forged token to the hardcoded administrative API_USER, granting access to sensitive configuration and server logs even when the API is disabled. No public exploit code was identified, but the mechanics are fully described in the vendor advisory and patch commits.