Safeguard
Vulnerability Analysis•

CVE-2026-93014: High RosarioSIS Path Traversal File Deletion

CVE-2026-93014: RosarioSIS before 12.9 lets logged-in users delete files outside the upload folder via a filename parameter. High (7.1). Upgrade to 12.9.

Safeguard Security Team
3 min read

CVE-2026-93014 is a path traversal flaw in RosarioSIS before version 12.9. In the Users and Students modules, a logged-in user can delete files outside the upload directory by tampering with a filename parameter. NVD scores it High (7.1). Upgrade RosarioSIS to 12.9.

What's affected

The reporter's write-up says RosarioSIS 12.8 and earlier are affected and 12.9 is the fixed version. The NVD record says before 12.9. The write-up rates severity as High and says an authenticated account is required. The fix is in the project's commit history on GitLab.

The weakness is CWE-22, path traversal. The record's vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L: network reachable, low privileges, with integrity as the main impact and some availability loss.

The write-up names two handlers, in the Users and Students modules. It says extension checks and a real-path check existed, but they did not reject the traversal syntax itself, so the traversal happened before they were applied. Only files with extensions that the application accepts could be removed.

How to check if you're exposed

Find your RosarioSIS version in the application or from the release you installed, and compare it with 12.9. Anything at 12.8 or earlier is in scope.

Also think about what could be lost. The write-up lists uploaded documents, user and student images, PDF records, ZIP archives or backups, and CSS, static and JSON resources. If your backups live inside the web application's file tree, they are within reach. Make sure you have a copy of them elsewhere.

Paste a lockfile or SBOM into the free in-browser dependency scan to see whether this package is in your tree, including as a transitive dependency. Safeguard's reachability analysis can then show whether your code actually calls the affected path, which helps you order the work.

What to do now

  1. Upgrade RosarioSIS to 12.9 or later.
  2. Keep backups outside the application directory and outside the web server's write permissions.
  3. Run the web server with the least write access it needs, so a bad path reaches fewer files.
  4. Review accounts that can use the Users and Students modules.
  5. The write-up also says the delete action lacked adequate CSRF protection, so keep administrators from browsing untrusted sites while logged in until you have upgraded.

Why it matters

The vulnerable code built a file path from a request parameter and passed it to a delete routine. A parameter that contains parent-directory sequences climbs out of the folder the developer had in mind. The checks that came afterwards looked at the extension and at the resolved path, but the write-up says they did not reject traversal syntax first, and that general input cleaning such as stripping tags is not a defense against it.

File deletion is an integrity and availability problem: school records and backups could vanish. The record's KEV flag is false and the sources do not report exploitation. The fix class is to reject path separators and parent references in names, or to use only a name taken from a trusted list.

Quick check

Which version fixes it?

RosarioSIS 12.9, per the reporter's write-up.

Can an outsider exploit this?

No. The record and the write-up say an authenticated user is required.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.