student-management-system CVE-2026-11476

The attacker must possess a valid, authenticated low-privileged account within the student-management-system application (CVSS PR:L confirms authentication is required). The Profile Update Endpoint serviced by the edit-admin function in controllers/AdminController.php must be reachable - this is standard functionality in a default deployment, not a non-default configuration. No special server configuration or additional feature enablement is required beyond the presence of user accounts. Exploitation is strictly limited to users who can authenticate; unauthenticated external attackers are excluded from this attack path. The system must be running code at or before commit f16a4ceaddd6729c4b306ed4641cda3176c1ef2a. The primary limiting factor is the authentication prerequisite, making external threat actors reliant on credential theft or social engineering before exploiting this flaw.

The CVSS 4.0 base score of 2.1 is intentionally low, driven by the requirement for prior authentication (PR:L) and a limited impact scope - confidentiality, integrity, and availability are each rated Low with no downstream scope change (SC:N/SI:N/SA:N). The E:P exploit maturity modifier confirms a publicly available proof-of-concept, elevating practical urgency beyond the raw score suggests. The vulnerability is not listed in CISA KEV, and no EPSS data was provided in the available intelligence, so widespread automated exploitation has not been confirmed. Real-world risk is primarily an insider threat or post-initial-access privilege escalation vector: an external unauthenticated attacker cannot exploit this directly without first obtaining credentials. However, the combination of a public exploit, an unresponsive vendor, and no available patch on a rolling-release project represents a meaningful gap for any self-hosted deployment. The CVSS score may understate operational risk in multi-tenant academic environments where student accounts are widely distributed.

An authenticated student or staff user with a standard low-privileged account sends a crafted HTTP POST request to the Profile Update Endpoint, appending or modifying the isadmin field to a truthy value (e.g., isadmin=1). Because edit-admin in AdminController.php applies the supplied value directly without an authorization check, the application persists the elevated role to the user's account. A publicly available exploit demonstrating this technique is referenced in GitHub issue #3 of the project repository.