• 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/!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