Achieving NGINX Remote Code Execution via an 18-Year-Old Vulnerability

| The is_args flag is set on the main engine when a rewrite replacement contains ?, ...

That also limits the impact a bit. I've always preferred the error_page / return trick for redirection, much more predictable and less surprising on config changes.

For example:

    location /dev {
        set $backend_port 3000;
        error_page 418 = $access_dev_location;
        return 418;
    }

Where the destination is given by the map directive:

map $ssl_client_i_dn $access_dev_location {
    default "@denied_access";
    "~^OU=XYZ$" "@trusted_access";
}

1. Open an initial connection and send partial headers. NGINX allocates a request pool for this connection.
2. Open a second victim connection, which allocates a victim pool exactly adjacent to the first pool.

Am I misunderstanding something, or does this assume that these two connections will happen exactly after each other? If so, wouldn't the entire chain become unpredictable if there's any other connection made between these two?

Because the likelyhood of two requests arriving at my nginx predictably right after each other is... slim. The higher req/sec I have, the less likely two requests would be handled right after each other. And if this is required for exploiting, and has to be repeated potentially many times to bypass ASLR, then exploiting this in the wild would be very tricky.