CVE-2025-48373 is a critical authorization flaw (CVSS 9.1) in Schule, an open-source school management system. Before version 1.0.1 it relied on client-side JavaScript to send users to role-based panels, trusting a role value the user can change. Upgrade to version 1.0.1 and enforce roles on the server.
What's affected
Per the CVE record and the GitHub advisory, Schule versions before 1.0.1 are affected, and 1.0.1 contains the fix.
The advisory points at the login script index.js, which reads a role value (admin, owner, teacher or student) and redirects the browser to the matching panel. The application treats that value as trustworthy. A user can change it in the browser, using developer tools or by altering a response, and then land in a panel for another role.
The record files this under CWE-863 (Incorrect Authorization), incorrect authorization. The base vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N: reachable over the network, no privileges and no interaction, with high confidentiality and integrity impact.
A school system holds records about children and staff, so the data behind these panels is sensitive, and that is context worth keeping in mind when you judge urgency.
How to check if you're exposed
Check which release you run. If you installed from a Git checkout, look at the tag or commit:
git describe --tags
If you installed from a download, compare the release number against 1.0.1. Anything older is in scope.
Then test your own deployment the right way: ask whether the server itself checks the role on every request to the admin, owner and teacher pages. You can check this with a low-privilege test account on a staging copy, by requesting a restricted page directly and confirming the server refuses. Do not test systems you do not own.
Also review your reverse proxy or web server rules. Restricting the panel folders to trusted networks is a useful second layer for an application like this.
What to do now
- Upgrade Schule to version 1.0.1 or later.
- Confirm after the upgrade that every protected page checks the user role on the server, using a test account for each role.
- Restrict admin and owner panels to trusted networks or a VPN where you can.
- Review accounts and access logs for panel pages visited by users who should not have had access.
- Treat the data in the system as possibly exposed if it was reachable from the internet, and follow your local rules for notification where they apply.
- Check any customizations you made, since a fork may repeat the same pattern.
Why it matters
Anything that runs in the browser is under the control of the person using it. A redirect that depends on a value in a script, or in a response the browser can alter, is a convenience for the user and not a security control. The server has to decide, on every request, who the user is and what they may do.
The class is incorrect authorization. This is an old lesson with a plain fix: keep the role in a server-side session and check it before returning any protected page or data.
It is not listed in the CISA Known Exploited Vulnerabilities catalog, and the record does not report exploitation in the wild. The score is critical because the check is missing for the whole application, not for one function, and it needs neither an account nor a click.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is hiding a menu item or redirecting a page enough?
No. The browser can be changed by its user. The server must check the role before it returns protected pages or data.
Which version fixes CVE-2025-48373?
Version 1.0.1, according to the record and the GitHub advisory.
Sources
- NVD record for CVE-2025-48373
- Schule GitHub security advisory GHSA-37h9-qq7c-6mc9
- Schule fix commit (listed in the record)
Last reviewed: 18 October 2026.
