Student Management System CVE-2026-97647

Exploitation targets the user/editLog.php endpoint of ningzichun student-management-system (up to commit 98760f5711cf6dc8b4adca53a9e207ca49b02ebf) by manipulating the sid/addtime/type/reason/detail/logdate request arguments to bypass the intended authorization/ownership check on log records. VulDB rates the vector PR:N (no authentication), but as a CWE-639 IDOR on an internal log-management function, realistic exploitation likely requires an active session/logged-in account, so authentication requirements are not firmly confirmed from available data. Limiting factors: impact is integrity-only (log tampering, no read or DoS), the affected software is a rare hobby project, and no patched release exists so only deployments running this unmaintained code are exposed.

This is a low-real-world-risk issue despite a moderate 6.9 CVSS 4.0 base score. The signals are mostly weak: the impact is confined to VI:L (low integrity, C:N/A:N) - an attacker can modify log records in user/editLog.php but cannot read data or deny service, and there is no chained escalation described. EPSS is not provided and there is no CISA KEV listing, so there is no evidence of active or automatable exploitation; the only elevated signal is E:P (Proof-of-Concept) plus a publicly disclosed exploit in the vendor's own GitHub issue tracker, which raises opportunistic-scripting risk but not to KEV levels. A notable conflict: VulDB's vector asserts PR:N (unauthenticated), yet the flaw is a CWE-639 authorization-bypass on a log-editing function that in a student-management panel would normally sit behind a login - this suggests PR:L is more honest, and the PR:N rating should be verified against the actual code path. Combined with the product being an obscure hobby/student PHP project with negligible production footprint, this is a low-priority finding: real but marginal, worth patching if the software is in use, not worth emergency response.

A remote attacker sends a crafted HTTP request to user/editLog.php manipulating the sid/addtime/type/reason/detail/logdate parameters to alter or forge log entries belonging to records they should not control. A public proof-of-concept exists (disclosed in the project's GitHub issue #10), lowering the skill barrier, though the payoff is limited to log-integrity tampering (e.g., covering tracks or falsifying entries).