RosarioSIS EUVD-2026-81683

Requires an authenticated RosarioSIS account of any privilege level (PR:L) - realistically an insider, a compromised student/teacher/staff credential, or an attacker who can self-register. Exploitation targets the file-deletion functionality of the Users and Students modules specifically, by supplying a filename request parameter containing parent-directory ('../') traversal sequences. No user interaction beyond the attacker's own request is needed and no special non-default configuration is required, but the account requirement is the primary limiting factor - this is not remotely exploitable by fully unauthenticated attackers. Affects RosarioSIS versions before 12.9; upgrading to 12.9 remediates.

This is a moderate-priority, authentication-gated integrity/availability issue rather than a critical remote-code flaw. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L) scores 7.1 and is internally consistent with the description: network-reachable, low complexity, but requiring an authenticated low-privileged account (PR:L). Impact is data destruction (arbitrary file deletion), not disclosure or code execution - VC:N confirms no confidentiality loss. No EPSS score, no CISA KEV listing, and no vendor-confirmed active exploitation were provided, so there is no signal of widespread automated exploitation. However, a public gist (kazisabu) and a specific vendor patch commit are referenced, meaning working exploit detail is effectively public even though it is not formally tracked as a POC feed entry. SSVC-style read: exploitation is 'proof-of-concept level' (public write-up exists, not confirmed in-the-wild), automatable given it is a simple parameterized request, and technical impact is partial (destructive but not full system takeover). The key limiting factor is the PR:L requirement - an attacker needs a valid RosarioSIS account, which sharply narrows the realistic threat to insiders, compromised student/staff credentials, or self-registration scenarios. This tempers the 7.1 score in practice.

An authenticated RosarioSIS user (e.g., a student, teacher, or staff account) submits a request to the Users or Students file-management endpoint with a crafted filename parameter containing '../' parent-directory sequences. The application fails to validate the path, so the deletion escapes the intended upload directory and removes arbitrary allow-listed files - CSS, XML, JSON resources, or other users' uploaded documents - anywhere in the installation. A public write-up (gist by kazisabu) documenting the technique exists, though this is a public analysis rather than a KEV-confirmed exploitation.