Vulnerability Overview

I was able to achieve Remote Code Execution (RCE) via the file upload functionality on Academico.

TL;DR: Academico's profile picture upload lacks server-side file type validation and serves uploaded files from a public directory. I uploaded an executable file, accessed it directly, and achieved full RCE. Technical proof-of-concept details and direct payloads have been redacted for safety.

Disclosure note: CVE-2025–10763 is referenced here. This post intentionally omits raw exploit code and certain command payloads while disclosure status with the vendor and databases is confirmed.

Technical Background

When a person thinks of a file upload endpoint for profile pictures, they assume it will only accept .png, .jpg, .jpeg, or .gif. Even if someone tries uploading a non-image file, most web apps block the request and notify the user about the invalid format. Even if an attacker bypasses such restrictions and uploads a .php or an executable file, server configurations usually prevent execution from public upload directories.

But what happens when there is no validation to ensure the file is actually an image? Or when a misconfiguration allows execution of uploaded files in public storage? That is where remote code execution happens.

Discovery Process and Exploitation Steps

I start by mapping endpoints and available functionality; then I interact and tinker. While auditing academico I followed the same process - upload a benign image, try an SVG with embedded JS (to test for XSS), and finally, out of curiosity, upload an executable file.

  • Uploading a valid image (for example .webp) shows the app converts it to .jpg and serves it by appending -thumb.jpg to the filename. The original uploaded image is retained but not served directly:
storage/app/public/3/:
total 52
drwxr-xr-x 3 kali kali  4096 Sep  3 05:40 .
drwxrwxr-x 7 kali kali  4096 Sep  3 07:09 ..
drwxr-xr-x 2 kali kali  4096 Sep  3 05:40 conversions
-rw-r--r-- 1 kali kali 39264 Sep  3 05:40 what-is-ai-artificial-intelligence.webp

storage/app/public/3/conversions:
total 100
drwxr-xr-x 2 kali kali  4096 Sep  3 05:40 .
drwxr-xr-x 3 kali kali  4096 Sep  3 05:40 ..
-rw-r--r-- 1 kali kali 90163 Sep  3 05:40 what-is-ai-artificial-intelligence-thumb.jpg
  • I then uploaded an SVG to see what happens when conversion to jpg fails:
storage/app/public/4/
total 12
drwxr-xr-x 2 kali kali 4096 Sep  3 06:33 .
drwxrwxr-x 6 kali kali 4096 Sep  3 06:33 ..
-rw-r--r-- 1 kali kali  362 Sep  3 06:33 xss.svg
  • There is no conversions directory for this upload, yet the application tries to serve the converted file at http://localhost:8000/storage/4/conversions/xss-thumb.jpg, which returns 404.
  • Accessing the original file at http://localhost:8000/storage/4/xss.svg is allowed; this SVG triggered client-side script execution in my test environment.

At this point I concluded that arbitrary files can be uploaded — no validation; even if conversion fails, the original file is accessible due to insecure file storage exposure. Next step was to upload an executable file and inspect server behavior.

  • I uploaded an executable file that would normally be interpreted by the server; the conversion to .jpg failed and the app attempted to serve the converted file.
  • I accessed the original uploaded file via the public storage URL and confirmed it was served by the web server.
  • I verified server-side execution by requesting a benign command parameter and observing the command output returned in the HTTP response; the server executed the supplied parameter and returned the output.

Proof-of-concept details and direct payloads removed for safety.

  • I also demonstrated practical exploitation that resulted in an interactive session on the host — the reverse-shell payload and full curl invocation are redacted.

Listener output screenshot redacted for safety.

This confirms remote code execution via the file upload vector.

Impact Analysis

  • Severity - Critical; RCE allows complete compromise of the application server and potentially lateral movement to other systems.
  • Confidentiality impact - High; attacker can read files accessible to the application user, database credentials, source code, user data, backups.
  • Integrity impact - High; attacker can modify application files, replace binaries, install backdoors, and tamper with logs or stored data.
  • Availability impact - High; attacker can disrupt services, delete data, or deploy ransomware.
  • Exploitability - Moderate; in my test it required only the ability to upload a profile picture as an authenticated user.
  • Scope - Potential full server compromise and data exfiltration; depending on hosting/configuration, attacker could pivot to internal networks or persist via scheduled tasks.
  • Additional note - SVG upload led to XSS; combined vulnerabilities increase the attack surface and may allow client-side attacks against other users.

Remediation

Prioritize fixes and add layered defenses - do not rely on a single control.

Immediate / high-priority fixes

  1. Disable execution in upload directories — Ensure the storage (or equivalent) directory is not executable by the web server; configure Nginx/Apache to never pass PHP (or other interpreters) from the uploads directory to the PHP engine.
  2. Store uploads outside the webroot or use object storage — Avoid serving raw uploaded files directly from a public directory. Store uploads outside public and serve them through a controller that enforces access controls; or use S3-like storage with signed URLs.
  3. Enforce strict file-type validation — Use a whitelist of allowed extensions and verify the actual file type server-side using finfo or image libraries; do not rely solely on client-side checks or filename extensions.
  4. Reject or sanitize SVGs — Either disallow SVG uploads entirely or sanitize them using a trusted sanitizer that strips scripts and event attributes; treat SVGs as untrusted XML.
  5. Perform server-side image processing and serve only processed images — Convert uploaded images to safe raster formats (PNG/JPG) server-side and only serve those derived files; do not serve original uploads.
  6. Sanitize and normalize filenames — Avoid using user-supplied filenames; generate randomized filenames and ensure there is no path traversal in the storage path. Validate and normalize paths before saving or serving.
  7. Set restrictive file permissions — Uploaded files should have the minimum permissions required (for example 0644) and be owned by a non-privileged user; ensure no execute bit is set.
  8. Content Security Policy (CSP) — Add a strong CSP to mitigate impact of any client-side XSS via uploaded assets.

Timeline

  • Disclosed this vulnerability to VulDB on: 09/03/2025 02:12 PM
  • Moderated on: 09/20/2025 09:26 AM

#cybersecurity #web-security #rce #file-upload