Remote Code Execution via Profile Picture Upload on Academico (CVE-2025-10763) - PoC Redacted
TL;DR: Academico's profile picture upload lacked server-side file-type validation and served uploaded files from a public directory. I uploaded an executable file, accessed it directly, and confirmed remote code execution. Technical PoC details and direct payloads have been redacted for safety.
Disclosure note: CVE-2025-10763 is referenced below. This post intentionally omits raw exploit code and certain command payloads while vendor coordination and disclosure status are confirmed.
Vulnerability overview
I achieved Remote Code Execution (RCE) via the profile-picture file upload on Academico. The root causes were:
- unrestricted upload of arbitrary file types server-side, and
- publicly served storage that allowed uploaded files to be accessed and executed.
This combination enabled an attacker to place executable content on the server and have it interpreted, resulting in full RCE in my test environment.
Technical background
Clients assume profile-picture endpoints accept only image types - .png, .jpg, .jpeg, .gif, etc. Servers sometimes rely on client-side checks or simple extension checks; attackers can bypass these. Normally, even if a bad file is uploaded, server configuration or storage policies should prevent execution from upload directories.
In this case the application accepted non-image files, retained the original upload, and the storage location was served by the web server in a way that allowed interpreter handling. That allowed an uploaded executable to be requested and executed by the server.
Discovery and exploitation (sanitized)
My methodology is simple - map endpoints, interact with feature flows, and iterate.
Upload a benign image - observe conversion pipeline and storage layout.
- Example: uploading a
.webpresulted in a converted-thumb.jpginside aconversionsfolder; the original upload remained understorage/app/public/<id>/.
Upload an SVG to test conversion failure handling.
- The conversion failed and no
conversionsoutput existed; the app still attempted to serve the converted URL. The original.svgwas accessible at the public storage URL and triggered client-side script execution in my test lab.
Upload an executable file intended to be interpreted by the server.
- Conversion failed as with the SVG; the original upload was directly accessible via the storage URL.
- I confirmed server-side execution by requesting a benign command parameter and observing the command output returned in the HTTP response. Proof-of-concept payloads are redacted.
- Practical exploitation led to an interactive session on the host; reverse-shell payload and full invocation details have been redacted.
Screenshots and raw payloads have been redacted for safety.
Impact analysis
- Severity - Critical; RCE enables complete compromise of the host and potential lateral movement.
- Confidentiality - High; attacker can read files accessible to the application user - credentials, source, backups.
- Integrity - High; attacker can modify application files, implant backdoors, and tamper with logs.
- Availability - High; attacker can disrupt or destroy service, or deploy disruptive malware.
- Exploitability - Low to moderate; exploit only requires the ability to upload a profile picture. If uploads are allowed for unauthenticated users, exploitability is trivial; if limited to authenticated users, any allowed account can exploit.
- Scope - Potential full server compromise and data exfiltration; possible lateral pivot depending on environment.
- Related issue - SVG upload yielded XSS; combined with the file-execution issue, the attack surface is larger.
Remediation - immediate and medium-term
Prioritize layered defenses; do not rely on a single control.
Immediate / high-priority fixes
- Disable execution in upload directories - ensure storage is not executable and webserver configs deny interpreter handling for upload paths.
- Store uploads outside the webroot or use object storage - serve via controller or signed URLs instead of direct public files.
- Enforce strict file-type validation - server-side checks using
finfoor robust image libraries; whitelist extensions and MIME types. - Reject or sanitize SVGs - either disallow SVGs or sanitize them to remove scripts and event attributes.
- Perform server-side image processing and serve only processed images - convert to safe raster formats and never serve originals.
- Sanitize and normalize filenames - use randomized names; avoid user-supplied filenames; validate and normalize paths.
- Set restrictive file permissions - minimum needed permissions; ensure no execute bit is set.
- Add a strong Content Security Policy (CSP) - reduce impact of client-side XSS.
Timeline
- Disclosed to VulDB:
2025-09-03 02:12 PM - Moderated on VulDB:
2025-09-20 09:26 AM - CVE assigned: CVE-2025-10763
Note: the CVE identifier is public; PoC payloads and some exploit details are intentionally redacted here pending clear vendor- or CNA-level confirmation that full technical disclosure is allowed.
References and credits
- Academico project - https://github.com/academico-sis/academico/tree/oss
- CVE-2025-10763 - assigned for this issue
Final notes
I intentionally redacted direct exploit payloads and command strings. If you maintain Academico or run a service with user-uploaded content, prioritize the immediate fixes above. If you want a follow-up post with full PoC after vendor confirmation, I will publish it as an update and link it here.
Top comments (0)