CVE-2026-121732 in RosarioSIS
Summary
by MITRE • 11/04/2026
RosarioSIS before 12.9 contains an improper authorization vulnerability that allows school-scoped administrators to assign fees and payments to students of other schools via MassAssignFees.php and MassAssignPayments.php. Attackers can substitute foreign student IDs in the student[] POST array of a modfunc=save request to alter other schools' student billing balances, breaking school isolation.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in RosarioSIS versions prior to 12.9 represents a critical failure in access control mechanisms, specifically categorized under CWE-862 as Missing Authorization. This flaw resides within the administrative modules responsible for managing financial records, namely MassAssignFees.php and MassAssignPayments.php. The core technical issue stems from an insufficient validation of user privileges relative to the data being modified. While the application correctly restricts general access based on school-scoped administrator roles, it fails to enforce this boundary when processing bulk assignment operations. Consequently, a legitimate actor authenticated as an administrator for one specific educational institution is granted excessive permissions that allow them to interact with and modify records belonging to entirely different institutions within the same system instance.
The exploitation vector relies on manipulating HTTP POST requests directed at the affected endpoints. An attacker can intercept these network communications or craft custom requests using tools such as Burp Suite or OWASP ZAP. By altering the student[] array in the request payload, the adversary substitutes valid student identifiers belonging to their own school with foreign student IDs associated with other schools. Because the backend logic does not verify that the target students belong to the requesting administrator's authorized scope, the system processes these changes as legitimate administrative actions. This allows for the arbitrary assignment of fees and payments to external entities, effectively bypassing the intended isolation boundaries between different educational institutions sharing the platform infrastructure.
The operational impact of this vulnerability is severe due to its direct effect on financial integrity and data confidentiality. School-scoped administrators can artificially inflate or deflate billing balances for students in other schools, leading to significant discrepancies in institutional accounting records. This manipulation can result in incorrect invoicing, loss of revenue through waived fees, or unjustified charges imposed on unrelated parties. Beyond the immediate financial implications, this breach undermines trust among participating institutions and violates data sovereignty principles often required by educational compliance frameworks. The ability to alter billing balances without detection poses a substantial risk to institutional reputation and operational stability, potentially triggering audits or legal liabilities related to mishandled student financial data.
From a threat intelligence perspective, this vulnerability aligns with the MITRE ATT&CK technique T1078 Valid Accounts, as it leverages legitimate credentials for unauthorized actions, and specifically relates to privilege escalation within application logic rather than system-level privileges. It also reflects CWE-269 Improper Privilege Management, where the principle of least privilege is violated by allowing users to perform operations outside their designated domain scope. To mitigate this risk, immediate patching to version 12.9 or later is required as it addresses these authorization checks. In environments where upgrading is not immediately feasible, administrators should implement strict input validation on the student[] array parameters to ensure that all referenced IDs belong exclusively to the current user's school context. Additionally, deploying a Web Application Firewall with rules targeting mass assignment patterns and enforcing server-side session-based scope verification can provide an additional layer of defense against such exploitation attempts.