68bd095bc05b2341db318a063e05e644

Save kazisabu/68bd095bc05b2341db318a063e05e644 to your computer and use it in GitHub Desktop.

Vulnerability: Path Traversal / Arbitrary File Deletion CWE: CWE-22 — Improper Limitation of a Pathname to a Restricted Directory Affected Version: RosarioSIS 12.8 and earlier Fixed Version: 12.9 Severity: High Authentication: Required Disclosure Status: Public disclosure after vendor remediation

A path traversal vulnerability was identified in RosarioSIS 12.8 that could allow an authenticated user to delete files outside the intended user-upload directory.

The vulnerable file deletion handlers accepted a user-controlled filename parameter and constructed the target path without preventing directory traversal sequences.

The issue affected file deletion functionality in:

modules/Users/User.php

modules/Students/Student.php

The deletion routine subsequently performed extension and path validation, but the traversal could occur before those checks were applied.

The vulnerable code constructed the file path using a user-controlled filename:

Input containing parent-directory traversal sequences could therefore alter the resolved filesystem location.

For example, conceptually:

Although RosarioSIS performed extension whitelisting and realpath() checks, those controls did not originally reject traversal syntax itself.

The global request sanitization also did not provide sufficient protection because operations such as strip_tags() and database escaping are not filesystem path-traversal defenses.

Depending on the deployment layout and file permissions, an attacker could potentially delete files with extensions accepted by RosarioSIS.

Potential consequences included:

Deletion of uploaded documents

Removal of user/student images

Deletion of ZIP archives or backups

Removal of CSS/static resources

Loss of JSON/localization resources

Availability and integrity impact to the application

The issue required an authenticated account with access to the affected functionality.

The affected operation did not provide adequate CSRF protection.

Consequently, in configurations where an administrator could be induced to submit the request, the vulnerability could potentially be chained with CSRF to perform the deletion using the administrator's authenticated session.

This increases the practical impact, although the underlying vulnerability remains the path traversal in the file deletion handler.

The primary root cause was accepting a filesystem path component directly from an HTTP request without enforcing that the resulting path remained inside the intended directory.

Database escaping and HTML sanitization are not appropriate controls for filesystem paths.

The correct security boundary must be enforced immediately before filesystem operations.

The issue was reported privately to the RosarioSIS maintainer.

The maintainer implemented a security fix in commit:

The fix was scheduled for RosarioSIS 12.9 .

The affected report was subsequently closed and kept confidential during the remediation period.

The vendor modified FileDelete() to explicitly reject path traversal sequences:

The function also validates the resolved path against the application's legitimate file-storage locations, including:

$AssignmentsFilesPath

$PortalNotesFilesPath

This provides an additional filesystem-boundary check after resolving the path.

Recommended Security Practice

Applications handling user-controlled filenames should avoid treating the supplied filename as a filesystem path.

A safer approach is to either:

Reduce the input to a filename component using an appropriate filename validation strategy, or

Resolve the canonical path and verify that it is strictly contained within the intended directory before performing the filesystem operation.

Path-boundary validation should account for canonicalization and directory-prefix collisions rather than relying only on string matching.

The vendor-provided fix was tested against the reported behavior.

Reported: ~4 months before public disclosure

Vendor acknowledged: François Jacquet / RosarioSIS maintainer

Fix implemented: Commit 701f9c07

Fixed release: RosarioSIS 12.9

Disclosure: Public after the vendor-requested remediation period

Researcher: Kazi Sabbir Handle: @kazisabu

Thanks to François Jacquet and the RosarioSIS project for reviewing the report and implementing the fix.

RosarioSIS:

CWE-22:

This write-up intentionally omits a weaponized one-request exploit/CSRF payload. The vulnerability has been remediated in RosarioSIS 12.9, and the technical root cause, affected components, impact, and defensive fix are documented above.

Vendor Acknowledged: May 2026

Fix Implemented: 2026 — Commit 701f9c07

Fixed Version: RosarioSIS 12.9

Public Disclosure: September 2026

Disclosure Period: ~3 months after the fix, per the maintainer's request