Koollab LMS CVE-2026-63231

Exploitation requires a valid authenticated Koollab LMS account (CVSS PR:L) and network reachability to the face-to-face runs update endpoint (AV:N/AC:L, no user interaction). The specific trigger is attacker-controlled input to that face-to-face runs update function, which the description confirms is injectable as an error-based SQL oracle. Limiting factors: the attacker must first obtain credentials, so exploitation is gated by how easily accounts can be created or acquired; there is no availability impact; and per SSVC the attack is not automatable, meaning it is a manual, request-by-request extraction rather than a mass-exploitable flaw. Confirmed affected configuration is Koollab LMS 5.3.2.

Signals are largely consistent and point to a genuine but not emergency-level priority. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N) shows a network-reachable, low-complexity attack requiring only low privileges (any authenticated account), with high confidentiality and integrity impact but no availability impact - matching the description of a post-authentication data-read leading to token theft. SSVC reinforces this: technical impact 'total' aligns with full-database read, but 'Exploitation: none' and 'Automatable: no' temper urgency, and there is no KEV listing and no public exploit identified. EPSS is low (0.25%, 17th percentile), consistent with the absence of public exploit code and the authentication prerequisite. The main caveat: the PR:L requirement for a valid account is the key limiter - in an LMS with self-service or widely distributed student/staff accounts that barrier is low, so effective risk rises where account provisioning is loose. No major conflicts between sources are present.

An attacker holding any low-privilege Koollab LMS account (e.g., a student or instructor login) sends crafted input to the face-to-face runs update endpoint, using database error responses as a boolean/error oracle to iteratively extract table contents. Over many requests they reconstruct stored credentials and JWT tokens, then replay a valid administrator token to take over privileged accounts. No public exploit code is identified and the attack is not automatable per SSVC, so it requires deliberate, iterative manual effort.