Stud.IP CVE-2026-51346

Exploitation requires network access to a Stud.IP instance running 6.0.x before 6.0.3 or 5.4.x before 5.4.12 and the ability to reach a request path that feeds attacker-controlled input into one of the vulnerable store() persistence functions. The supplied CVSS vector rates this PR:N/UI:N (no authentication, no user interaction), but because store() operations are persistence routines typically invoked within a logged-in session, defenders should verify whether a valid low-privilege account is actually needed - this is the main factor that would limit real-world exploitation. There is no user-interaction or non-default-configuration requirement stated; the primary limiting factors are network exposure of the instance and the still-unconfirmed authentication prerequisite.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:N, score 9.1) describes network-reachable, low-complexity, unauthenticated exploitation with high confidentiality and integrity impact - a serious profile. However, the vulnerable sink is described as store() functions, which in an LMS typically execute within an authenticated persistence workflow, so the PR:N (unauthenticated) rating is worth verifying against the vendor advisory; the description and CVSS diverge on whether a session is required. No EPSS score, SSVC decision, or KEV entry was supplied, so exploitation probability cannot be quantified from the input, and there is no evidence of active exploitation - the strongest exploitation signal is a public technical write-up. Even a mid-sized university IT team should treat this as urgent because a working SQLi write-up materially lowers the barrier to exploitation and the integrity/RCE impact threatens the whole database and potentially the host. Net assessment: genuine high priority for anyone running the affected branches, tempered by unconfirmed authentication prerequisites and no confirmed in-the-wild activity.

An attacker sends a crafted HTTP request to a Stud.IP endpoint that routes user input into a store() function, injecting SQL that extracts credentials or session data and manipulates records. Following the technique described in the public researcher write-up, the attacker chains the injection into file-write or code-execution primitives to run arbitrary code on the LMS host, compromising all student and course data. Low attack complexity and network reachability make this practical against exposed instances.