Exploit about School Management System 7.1 (Authenticated RCE)# CVE-2025-60500 — Insecure file upload / logic flaw in QDocs Smart School (Smart School 7.1)
**Publication date:** 2025-10-17
**Author / Discoverer:** Lebas Vivien
**Status:** Reserved
**CVE:** CVE-2025-60500 (reserved)
---
## Summary
An insecure file upload / logic flaw in **QDocs Smart School — School Management System 7.1** allows authenticated users with roles such as **accountant**, **admin**, or **superadmin** to bypass file-type restrictions in the media upload feature by abusing the alternative **YouTube URL** option. This flaw permits an attacker to cause arbitrary PHP files to be stored in a web-accessible directory, enabling remote code execution when the uploaded file is accessed.
**Affected product:** Smart School : School Management System 7.1 (QDocs)
**Vendor confirmed:** Yes
---
## Impact
- **Remote code execution (RCE)** via uploaded PHP files placed in a web-accessible directory.
- An authenticated user with the specified roles can upload an arbitrary PHP file that will be stored under a predictable web-accessible path.
- Attackers could execute system commands or pivot further into the environment by invoking the uploaded file.
---
## Affected component
- File Upload feature — **Download Center > Upload Share Content** (media upload / share content flow)
---
## Attack type / Vector
- **Attack type:** Remote (requires authenticated account with role: accountant/admin/superadmin)
- **Attack vectors:** Upload flow combined with the alternate YouTube URL option; by submitting both an uploaded file and the YouTube link field, the server stores the uploaded file with a `.php` extension in a web-accessible directory.
---
## Reproduction (conceptual PoC — no executable payload included)
1. Log in to Smart School as a user with role `accountant`, `admin` or `superadmin`.
2. Navigate to **Download Center → Upload Share Content**.
3. Intercept the HTTP request (e.g., with a proxy such as Burp) during the upload/share workflow.
4. Upload a file whose filename ends with `.php` (the server-side checks/filters attempt to block PHP uploads through the regular file-type validation).
5. In the same upload/submit request, also populate the alternate **YouTube URL** field (the logic path that handles the YouTube option incorrectly allows the uploaded file to be accepted and stored).
6. Complete the share/upload flow; note the server response or observe the stored file path returned (the application reveals the storage path). Example observed storage path pattern: /uploads/school_content/material/media/<unique-id>!file.php
7. Access the stored `.php` file via the returned URL to trigger code execution (if the file contains executable PHP code).
---
## Proof-of-concept (high level)
- A PHP file uploaded via the vulnerable flow is written to a web-accessible directory and can be called directly by HTTP.
- The vulnerability is a **logic/validation bypass** (the alternate YouTube URL code path fails to enforce the same strict file-type restrictions as the normal upload flow).
---
## Mitigation / Recommended fixes
Vendor-side fixes (recommended):
1. **Fix the logic flaw** so that the alternate YouTube URL path and any other special-case upload paths enforce the *same* file type validation and filtering as the normal upload flow. Also verify if the YouTube URL is valid/existing.
2. **Block execution of uploaded files** by storing uploaded content outside the webroot or ensuring uploads are served through a safe handler that never executes server-side code.
3. **Enforce server-side MIME type and extension checks**, and validate against a whitelist of allowed file types rather than a blacklist.
4. **Rename stored files** to safe extensions and/or randomize names without preserving the original extension.
5. **Set correct server permissions** so uploaded files are not executable (e.g., `chmod` to remove execute permission; configure web server not to execute PHP from upload directories).
6. **Add logging and monitoring** for suspicious uploads and access attempts to uploaded files.
7. **Apply role-based restrictions** — tighten which roles are allowed to upload content, and require additional validation for privileged roles.
Workarounds for administrators:
- Temporarily disable the problematic upload/share feature if feasible.
- Restrict upload access to fewer trusted accounts.
- Configure the webserver to disallow execution of `.php` in the `/uploads/...` directory.
---
## References
- Demo instance reported: `https://smart-school.in/demo`
- MITRE CVE ID reserved: **CVE-2025-60500**
登录后查看神龙缓存的 POC 文件快照
登录查看