Vulnerability Instance

Rack::Request accepts invalid Host characters, enabling host allowlist bypass
## Summary

`Rack::Request` parses the `Host` header using an `AUTHORITY` regular
expression that accepts characters not permitted in RFC-compliant
hostnames, including `/`, `?`, `#`, and `@`. Because `req.host`
returns the full parsed value, applications that validate hosts
using naive prefix or suffix checks can be bypassed.

For example, a check such as `req.host.start_with?("myapp.com")` can
be bypassed with `Host: myapp.com@evil.com`, and a check such as
`req.host.end_with?("myapp.com")` can be bypassed with
`Host: evil.com/myapp.com`.

This can lead to host header poisoning in applications that use
`req.host`, `req.url`, or `req.base_url` for link generation,
redirects, or origin validation.

## Details

`Rack::Request` parses the authority component using logic equivalent to:

```ruby
AUTHORITY = /
  \A
  (?<host>
    \[(?<address>#{ipv6})\]
    |
    (?<address>[[[:graph:]&&[^\[\]]]]*?)
  )
  (:(?<port>\d+))?
  \z
/x
```

The character class used for non-IPv6 hosts accepts nearly all
printable characters except `[` and `]`. This includes reserved
URI delimiters such as `@`, `/`, `?`, and `#`, which are not
valid hostname characters under RFC 3986 host syntax.

As a result, values such as the following are accepted and returned
through `req.host`:

```text
myapp.com@evil.com
evil.com/myapp.com
evil.com#myapp.com
```

Applications that attempt to allowlist hosts using string prefix or
suffix checks may therefore treat attacker-controlled hosts as
trusted. For example:

```ruby
req.host.start_with?("myapp.com")
```

accepts:

```text
myapp.com@evil.com
```

and:

```ruby
req.host.end_with?("myapp.com")
```

accepts:

```text
evil.com/myapp.com
```

When those values are later used to build absolute URLs or enforce
origin restrictions, the application may produce attacker-controlled
results.

## Impact

Applications that rely on `req.host`, `req.url`, or `req.base_url`
may be affected if they perform naive host validation or assume
Rack only returns RFC-valid hostnames.

In affected deployments, an attacker may be able to bypass host
allowlists and poison generated links, redirects, or origin-dependent
security decisions. This can enable attacks such as password reset
link poisoning or other host header injection issues.

The practical impact depends on application behavior. If the
application or reverse proxy already enforces strict host validation,
exploitability may be reduced or eliminated.

## Mitigation

* Update to a patched version of Rack that rejects invalid
  authority characters in `Host`.
* Enforce strict `Host` header validation at the reverse proxy
  or load balancer.
* Do not rely on prefix or suffix string checks such as
  `start_with?` or `end_with?` for host allowlisting.
* Use exact host allowlists, or exact subdomain boundary checks,
  after validating that the host is syntactically valid.