HIGH 7.3

CVE-2026-11474: Unrestricted File Upload in Kushan2k Student Management System

A file upload vulnerability has been discovered in Kushan2k's student-management-system that allows attackers to upload files without restriction. The flaw resides in the registration endpoint's service code and is triggered by manipulating the 'stimg' parameter. Because the vulnerability requires no authentication and can be exploited remotely with minimal complexity, it poses an immediate risk to exposed instances. Public exploit code is already available, elevating the likelihood of opportunistic attacks.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.3 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
Weaknesses (CWE)
CWE-284, CWE-434
Affected products
0 configuration(s)
Published / Modified
2026-06-08 / 2026-06-17

NVD description (verbatim)

A security flaw has been discovered in Kushan2k student-management-system up to f16a4ceaddd6729c4b306ed4641cda3176c1ef2a. Affected is an unknown function of the file service/RegisterService.php of the component Registration Endpoint. Performing a manipulation of the argument stimg results in unrestricted upload. The attack may be initiated remotely. The exploit has been released to the public and may be used for attacks. This product uses a rolling release model to deliver continuous updates. As a result, specific version information for affected or updated releases is not available. The project was informed of the problem early through an issue report but has not responded yet.

6 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-11474 is an unrestricted file upload vulnerability affecting the Registration Endpoint in service/RegisterService.php. The vulnerability stems from insufficient input validation on the 'stimg' parameter, allowing remote unauthenticated attackers to upload arbitrary files. This bypasses access controls that should govern file storage operations, as indicated by the CWE-284 (Improper Access Control) and CWE-434 (Unrestricted Upload) classifications. The CVSS 3.1 score of 7.3 reflects network accessibility, low attack complexity, and the confidentiality, integrity, and availability impacts of arbitrary file upload.

Business impact

Unrestricted file uploads can lead to remote code execution if the uploaded files are executable or interpreted by the web server. Attackers could deface the student management system, steal sensitive educational records, deploy malware, or pivot to broader network compromise. For educational institutions relying on this system, operational disruption, regulatory violations (e.g., FERPA for student data), and reputational harm are significant concerns. The presence of public exploits increases the window of exposure for unpatched deployments.

Affected systems

Kushan2k student-management-system installations up to commit f16a4ceaddd6729c4b306ed4641cda3176c1ef2a are affected. The project uses a rolling release model without discrete version numbers, making it difficult to identify precisely which deployed instances are vulnerable. Any organization running this system should assume their deployment is at risk unless they have explicitly updated past the vulnerable commit.

Exploitability

Exploitation is straightforward: an unauthenticated remote attacker can craft a request to the registration endpoint, manipulate the 'stimg' parameter to inject a malicious file, and trigger the upload. No user interaction is required. The availability of public exploit code and the low technical barrier to weaponization mean that both opportunistic and targeted attacks are probable. The vulnerability is not currently tracked in CISA's Known Exploited Vulnerabilities (KEV) catalog, but public disclosure has already occurred.

Remediation

The development team must implement strict file upload controls, including whitelist-based file type validation, file storage outside the web root, and verification that uploaded content matches declared file types. Until an official patch is available, organizations should implement network-level restrictions to limit access to the registration endpoint, disable the registration feature if operationally feasible, or run the application behind a Web Application Firewall (WAF) with rules to detect and block suspicious file uploads.

Patch guidance

Because the Kushan2k project uses continuous rolling releases without traditional versioning, consult the project repository directly to confirm whether your deployment includes commits dated after the vulnerability discovery (June 8, 2026). Monitor the project's issue tracker and commit history for security fixes. As the vendor has not yet responded to the early disclosure, verify whether a fix has been merged and test it thoroughly in a staging environment before production deployment. If no patch is forthcoming within a reasonable timeframe, consider migrating to an alternative, actively maintained student management system.

Detection guidance

Monitor web server logs for POST requests to the registration endpoint with unusual or suspicious 'stimg' parameter values, particularly those containing encoded payloads, executable extensions (.php, .jsp, .exe), or system commands. Monitor the upload directory for newly created files with unexpected names, timestamps, or types. Implement intrusion detection rules to flag attempts to upload files with double extensions or null-byte injection. Review file permissions on the upload directory to ensure the web server process cannot execute stored files. Conduct file integrity monitoring on the upload location to detect unauthorized additions.

Why prioritize this

This vulnerability merits immediate attention due to its HIGH CVSS severity, unauthenticated remote exploitability, confirmed public exploitation, and potential for rapid compromise. The lack of vendor response and the rolling-release model add urgency—you cannot rely on a forthcoming patch. File upload vulnerabilities are frequently leveraged in attack chains leading to code execution and full system compromise, particularly in web applications handling sensitive data like student records.

Risk score, explained

The CVSS 3.1 score of 7.3 reflects a network-accessible vulnerability (AV:N) with low attack complexity (AC:L) that requires no privileges (PR:N) or user interaction (UI:N). The impact spans confidentiality, integrity, and availability (C:L/I:L/A:L), as arbitrary file uploads can lead to data exfiltration, system modification, and service disruption. The score appropriately elevates the risk from the base impact; however, the real-world threat is amplified by public exploit availability and the educational value of student management systems as targets for data theft.

Frequently asked questions

Our institution uses Kushan2k student-management-system. How do we know if we're vulnerable?

If you are running any version of the system with commits up to f16a4ceaddd6729c4b306ed4641cda3176c1ef2a (the vulnerability was discovered June 8, 2026), you are vulnerable. Because the project uses rolling releases, check your deployment's exact commit hash in the application's version file or Git history. If the hash is the same as or earlier than the vulnerable commit, patch immediately.

Can this vulnerability be exploited without internet access or only from external attackers?

The vulnerability is network-accessible (CVSS vector AV:N), meaning an attacker anywhere with network connectivity to your system can exploit it. If the registration endpoint is exposed to the internet or accessible from untrusted internal networks, the risk is severe. Even if the application is behind a firewall, internal malicious actors or compromised devices on your network could exploit it.

If we disable the registration feature, are we safe from this vulnerability?

Yes, if you can operationally afford to disable student registration and use alternative sign-up processes, this eliminates the attack surface for this particular vulnerability. However, confirm that disabling the registration feature actually removes or blocks all access to the vulnerable endpoint—do not rely solely on front-end UI removal. Test that direct HTTP requests to /service/RegisterService.php are rejected or inaccessible.

The vendor has not responded to the disclosure. What should we do?

Do not wait indefinitely for a patch. Implement immediate mitigations: restrict network access to the registration endpoint via firewall rules or WAF policies, apply file upload filters, and monitor logs for suspicious activity. In parallel, evaluate alternative student management systems. Set a deadline (e.g., 30 days) for the vendor to provide a security update; if none is forthcoming, begin a migration plan.

This analysis is based on publicly disclosed vulnerability data current as of the publication date. SEC.co does not maintain a formal relationship with Kushan2k and cannot guarantee the accuracy or completeness of vendor statements or patch timelines. Organizations must verify patch applicability and test thoroughly in non-production environments before deployment. This explainer does not constitute a recommendation to use or avoid any particular product. Consult your vendor, security team, and legal counsel for decisions regarding remediation, migration, or workaround implementation. Source: NVD (public-domain), retrieved 2026-07-15. Analysis generated by SEC.co (claude-haiku-4-5).