Introduction
In Part 1, I described how an image upload functionality allowed Stored XSS via SVG upload, which was later assigned CVE-2026–27147.
After confirming the Stored XSS, I continued testing the same upload functionality to understand whether the vulnerability could be triggered without direct user interaction. This led to the discovery of a second issue: a Cross-Site Request Forgery (CSRF) vulnerability in the file upload endpoint.
By chaining these two flaws together, the overall impact increased significantly. This CSRF vulnerability was later assigned CVE-2026–27146.
Understanding the Attack Surface
The file upload feature allowed authenticated users to upload image files that were later stored and rendered by the application.
Key observations:
- The upload endpoint required authentication
- No additional user confirmation was required for uploads
- The endpoint accepted
POSTrequests with multipart form data
This made the upload functionality a strong candidate for CSRF testing.
Testing for CSRF Protection
To check for CSRF protections, I examined the upload request closely and looked for common defensive mechanisms such as:
- Anti-CSRF tokens
- Origin or Referer header validation
- SameSite cookie enforcement
The request contained no CSRF token, and the server did not enforce any meaningful origin checks.
This indicated that the endpoint was vulnerable to CSRF.
Crafting the CSRF Payload
To validate the issue, I created a simple HTML proof-of-concept that automatically submitted a file upload request when opened in a victim's browser.
When this CSRF payload was opened in the browser of an authenticated user:
- The request was sent using the victim's active session
- The file upload succeeded without any warning or confirmation
- The server accepted and stored the uploaded file
This confirmed the presence of a CSRF vulnerability in the file upload functionality.
Escalation: CSRF → Stored XSS
The real impact became clear when this CSRF vulnerability was combined with the Stored XSS described in Part 1. You can check it here ↓
Instead of uploading a harmless image, the CSRF payload was used to upload a malicious SVG file containing a stored XSS payload.
This resulted in:
- A malicious file being uploaded without the victim's knowledge
- Persistent JavaScript execution when the uploaded file was accessed
- A Stored XSS triggered through CSRF
At this point, an attacker could force an authenticated user to unknowingly upload a persistent XSS payload, escalating the severity of both issues.
Impact
The chained attack significantly increased the risk to users and the application:
- Persistent XSS uploaded silently via CSRF
- No user interaction beyond visiting a malicious page
- Potential session hijacking and account compromise
- Abuse of trusted authenticated users to plant malicious content
What initially appeared as two moderate issues became a high-impact vulnerability when combined.
Responsible Disclosure
The vulnerability was tested ethically and within scope. The proof of concept demonstrated impact without abusing real user data or production systems. Full details were shared privately with the maintainers to allow proper remediation.
CVE Assignment
After responsible disclosure and validation by the maintainers, this CSRF vulnerability in the file upload functionality was officially assigned CVE-2026–27146.
The CVE acknowledges the lack of CSRF protection and its role in enabling the escalation of Stored XSS attacks.
Read The Report Here: https://github.com/GetSimpleCMS-CE/GetSimpleCMS-CE/security/advisories/GHSA-26rv-8wpp-q84r
Key Takeaway
CSRF vulnerabilities should never be evaluated in isolation.
When combined with other flaws such as Stored XSS, CSRF can:
- Enable silent exploitation
- Amplify impact
- Turn medium-severity issues into critical risks
File upload endpoints must implement robust CSRF protections, especially when user-generated content is stored and rendered.
Until next time — Stay curious. Hack ethically.
Cyber Tamarin out. 🍌