The Dot That Killed the Host: Litestar AllowedHosts Bypass

In the chaotic world of web security, the Host header is often the only thing tethering an application to reality. It tells the backend, 'Hey, I'm serving traffic for this domain.' When frameworks blindly trust this header, we get Host Header Injection—a vulnerability that serves as the gateway drug to cache poisoning, password reset hijacking, and illicit redirects.

To combat this, responsible frameworks like Litestar implement an AllowedHostsMiddleware. It’s essentially a bouncer at the club door, checking the ID of every incoming request against a VIP list. If your name isn't on the list, you don't get in. Simple, right?

Well, it turns out the bouncer had a bit of a reading comprehension problem. In Litestar versions prior to 2.20.0, the logic used to verify these hosts contained a subtle but devastating flaw in how it handled regular expressions. It’s a textbook example of why 'string' and 'regex pattern' are not synonyms, and why assuming they are is a great way to get your application pwned.

The vulnerability stems from a fundamental misunderstanding of how Python's re module consumes strings. When a developer configures allowed_hosts=["api.example.com"], they intend for that string to be a literal match. They want the middleware to say, 'If the host is exactly api.example.com, allow it.'

However, Litestar took these configuration strings and fed them directly into a regular expression compiler without escaping them first. In the regex world, the dot character (.) is a diva. It doesn't just sit there being a period; it acts as a wildcard that matches any single character (except a newline).

So, to the Litestar middleware, the configuration api.example.com wasn't a strict domain name. It was interpreted as the regex pattern api.example.com. This means it would happily match api.example.com, but it would also match api-example.com, apiXexample.com, or api/example.com. The bouncer wasn't checking for your specific ID; he was checking if your name had roughly the right number of letters.

Let's look at the code that caused the headache. The issue resided in litestar/middleware/allowed_hosts.py. The middleware took the list of allowed hosts and compiled them directly. Here is a reconstruction of the logic flaw:

# THE VULNERABLE LOGIC
import re
 
allowed_hosts = ["api.example.com"]
# The framework compiled the string directly as a regex pattern
regex_pattern = re.compile(f"^({'|'.join(allowed_hosts)})$", flags=re.IGNORECASE)
 
# This matches the legitimate host...
print(bool(regex_pattern.match("api.example.com")))  # True
 
# ...but also matches this malicious one:
print(bool(regex_pattern.match("api-example.com")))  # True (OOPS)

The fix was painfully simple but critical. The developers needed to ensure that the configuration strings were treated as literals, not patterns. Python's standard library provides re.escape() for exactly this purpose.

# THE FIX (v2.20.0)
import re
 
allowed_hosts = ["api.example.com"]
 
# Escape the strings first! 
# "api.example.com" becomes "api\.example\.com"
escaped_hosts = [re.escape(h) for h in allowed_hosts]
 
regex_pattern = re.compile(f"^({'|'.join(escaped_hosts)})$", flags=re.IGNORECASE)
 
# Now the malicious host is rejected
print(bool(regex_pattern.match("api-example.com")))  # False

How do we weaponize a stray dot? The goal here is Host Header Injection. Since the middleware validates the Host header before the application processes it, bypassing this check allows us to trick the application into thinking it resides at a domain controlled by the attacker.

Scenario: You are targeting a password reset flow on sso.corp.com. The application generates reset links using the incoming Host header because the developers were too lazy to hardcode the canonical URL.

1. Reconnaissance: You determine the target is running an older version of Litestar.
2. Registration: You register the domain sso-corp.com (note the hyphen).
3. The Attack: You send a password reset request for a victim user, but you manipulate the Host header:

POST /reset-password HTTP/1.1
Host: sso-corp.com
Content-Type: application/json
 
{"email": "admin@corp.com"}

4. The Bypass: The regex sso.corp.com matches sso-corp.com. The middleware says "Pass."
5. The Impact: The application generates a reset email containing: https://sso-corp.com/reset-token?user=admin

When the admin clicks that link, they aren't going to the corporate SSO. They are landing on your server, where you harvest the token and take over the account.

For developers using Litestar, the path forward is straightforward: Upgrade to version 2.20.0 immediately. This version includes the patch that applies re.escape() to all host entries.

If you are stuck on an older version and cannot upgrade (why?), you have a manual workaround: escape the dots in your configuration yourself.

Instead of: allowed_hosts=["api.example.com"]

Use: allowed_hosts=["api\\.example\\.com"]

However, relies on you remembering to double-escape backslashes in your config files, which is error-prone. The real lesson here is about defensive coding. Never assume a string is just a string when passing it to a regex engine. If you aren't writing a regex pattern, escape it. Always.