Security Advisory - Published 2026-06-08 - File upload RCE

Student Management System CVE-2026-11474: Unrestricted Upload Self-Check

CVE-2026-11474 affects Kushan2k student-management-system. The public report points to the registration image field stimg: server-side code saves uploaded files into public/profiles/ after checking size, but without enough file type validation. If PHP runs in that public folder, an uploaded "image" can become code execution.

Scope: This guide does not include an upload payload or exploit request. It is for checking whether your installation has dangerous files, whether uploads can execute as PHP, and what to change before reopening registration.

What is affected

  • Product: Kushan2k student-management-system
  • CVE: CVE-2026-11474
  • Component: registration endpoint / student image upload
  • Reported files: service/RegisterService.php and controllers/RegisterController.php
  • Argument: stimg
  • Weakness: unrestricted upload of a dangerous file type, mapped to CWE-434 / CWE-284 in public metadata
  • Public exploit signal: yes
  • Known exploited in CISA KEV: no, as of this publication

The dangerous condition is simple: an upload field accepts a file, stores it under a public directory, and the web server is willing to execute that file as PHP. That turns a profile image feature into a backdoor path.

10-minute self-check

Step 1: Confirm the project and registration route

Search the application folder for the reported files. If the project is no longer used, shut down the public vhost and archive the code offline. 

find /var/www /home /www -path "*student-management-system*" -type d 2>/dev/null
find /var/www /home /www \( -path "*RegisterService.php" -o -path "*RegisterController.php" \) -type f 2>/dev/null

Step 2: Inspect upload handling

From the project root, search the upload path and field name:

grep -R "stimg\|move_uploaded_file\|public/profiles" service controllers -n 2>/dev/null

Risk signs: only checking file size, reusing the original filename, saving directly below public/profiles/, no extension allowlist, no MIME/content check, and no randomized server-side filename.

Step 3: Hunt existing PHP files in the profile directory

Check for executable extensions under the public profile folder:

find /path/to/student-management-system/public/profiles -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" -o -name "*.php5" \) -ls

Any match is suspicious. Preserve the file path, timestamp, owner, and web logs before deleting it. If you find a web shell, this is already an incident.

Step 4: Check web logs for profile execution

Search web-server logs for requests to uploaded PHP-like files:

grep -R "public/profiles/.*\.php\|public/profiles/.*\.phtml\|public/profiles/.*\.phar" /var/log/nginx /var/log/apache2 /usr/local/apache/logs 2>/dev/null | tail -50

Requests returning 200 from upload paths are the strongest signal. Also check for POST requests to the registration controller followed by a GET request to a new file in public/profiles.

Safe fix path

  1. Disable public registration temporarily. Stop new uploads while you inspect existing files.
  2. Block PHP execution in upload folders. Upload directories should serve static files only.
  3. Use an allowlist. Accept only expected image extensions and validate content with a server-side image library.
  4. Rename files on the server. Use random names, not user-supplied names.
  5. Store uploads outside the web root if possible. Serve them through a controlled download/image route.
  6. Scan and preserve evidence. If any executable upload exists, keep logs and rotate secrets before cleanup.

Temporary server hardening

For Nginx, deny PHP execution under the profile directory:

location ~ ^/public/profiles/.*\.(php|phtml|phar|php5)$ {
    return 403;
}

For Apache, put a deny rule inside the upload directory or the vhost:

<Directory "/path/to/student-management-system/public/profiles">
    <FilesMatch "\.(php|phtml|phar|php5)$">
        Require all denied
    </FilesMatch>
</Directory>

Test the rule with a harmless text file and a known static image. Existing profile photos should still load; PHP-like uploads should not execute.

When to treat it as an incident

  • You find .php, .phtml, .phar, or similar files in public/profiles.
  • Logs show requests to executable files under the profile upload path.
  • The database has new admins, changed student records, or suspicious exports.
  • Other sites on the same hosting account share writable directories or database credentials.
  • You cannot prove whether uploaded files were only stored or actually executed.

Ping7 repair path

Ping7 can review the upload route, check for web shells, add upload-directory execution blocks, and write a small cleanup plan. Start from CVE Repair and include the domain, hosting type, and whether public/profiles contains any PHP-like files.

References

Author: Ping7 security team - Published: 2026-06-08 - CVE-2026-11474 - Defensive self-check only.