CVE-2026-119619 in cak-filemanagement-system
Summary
by MITRE • 10/30/2026
A vulnerability was found in 37954679 cak-filemanagement-system up to 5e6433246475e66462e1fea980688de96a049297. This affects the function mysqli_query of the file admin/save_student.php. Performing a manipulation of the argument date/department/subject/forwarded_to/action_taken_by/section/password results in sql injection. The attack is possible to be carried out remotely. The exploit has been made public and could be used. The project was informed of the problem early through an issue report but has not responded yet.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The identified vulnerability resides within the cak-filemanagement-system, specifically affecting versions up to commit hash 5e6433246475e66462e1fea980688de96a049297. This software component is designed for managing academic records and student data, a domain that inherently requires strict adherence to data integrity and confidentiality standards. The core of the issue lies in the file admin/save_student.php, which serves as an endpoint for processing administrative actions related to student information updates. Within this script, the application utilizes the PHP mysqli_query function to interact with the underlying database. However, the implementation fails to properly sanitize or parameterize user-supplied input before incorporating it into SQL commands. This architectural flaw creates a direct pathway for attackers to inject malicious SQL code, compromising the security of the entire system.
The technical nature of this vulnerability is classified as an Injection flaw, specifically aligning with CWE-89: Improper Neutralization of Special Elements used in an SQL Command. The attack vector involves manipulating specific arguments passed through HTTP requests, including date, department, subject, forwarded_to, action_taken_by, section, and password fields. Because these parameters are directly concatenated into the database query string without adequate validation or escaping mechanisms, an attacker can craft a malicious payload that alters the intended logic of the SQL statement. This allows for unauthorized data retrieval, modification, or deletion within the database. The presence of the password field in the list of vulnerable arguments is particularly critical, as it suggests potential exposure of credential hashes or even direct authentication bypass if the query structure permits such manipulation.
From an operational perspective, this vulnerability poses a severe risk to the confidentiality and integrity of sensitive academic records. Since the attack can be carried out remotely over the network without requiring prior authentication in some configurations, or by exploiting lower-privileged accounts that have access to these administrative endpoints, it represents a significant threat surface. The fact that public exploits are available further exacerbates the situation, as automated scanning tools and opportunistic attackers can easily leverage this flaw to compromise systems running affected versions. Successful exploitation could lead to full database takeover, allowing adversaries to extract student personal information, alter grades or disciplinary records, and potentially pivot to other internal network resources if the database server is accessible from broader network segments.
This vulnerability maps directly to several techniques within the MITRE ATT&CK framework. It aligns with T1190: Exploit Public-Facing Application, as it targets a web application exposed to potential external access. Furthermore, depending on the specific outcome of the injection, it may relate to T1059: Command and Scripting Interpreter if the attacker leverages SQL commands like xp_cmdshell or similar database-specific extensions for remote code execution. It also falls under T1078: Valid Accounts if authentication is required but can be bypassed through the injection technique itself. The lack of response from the project maintainers despite early notification indicates a potential gap in security maintenance practices, leaving users exposed to known risks without timely patches or workarounds provided by the vendor.
Mitigation strategies must focus on immediate remediation and defensive hardening until an official patch is released. Developers should refactor the affected code in admin/save_student.php to use prepared statements with parameterized queries instead of direct string concatenation for SQL operations. This approach ensures that user input is treated strictly as data rather than executable code, effectively neutralizing injection attempts. Additionally, implementing strict input validation on all fields involved in database interactions can provide an additional layer of defense. For system administrators unable to immediately patch the source code, deploying a Web Application Firewall with rules specifically tuned to detect SQL injection patterns targeting these parameters can help block malicious requests at the network perimeter. Regular security audits and static application security testing should be integrated into the development lifecycle to prevent similar oversights in future releases.