WelcomeUser Guide
ToSPrivacyCanary
DonateBugsLicense

©2026 Poal.co

1.3K

Archive: https://archive.today/jBWvB

From the post:

>TLDR: We used depthfirst’s system to analyze the NGINX source code, and it autonomously discovered 4 remote memory corruption issues, including a critical heap buffer overflow introduced in 2008. We further investigated the exploitability of the issues, and developed a working proof of concept demonstrating RCE with ASLR off. If you use rewrite and set directives in your NGINX configuration, you’re at risk.

Archive: https://archive.today/jBWvB From the post: >>TLDR: We used depthfirst’s system to analyze the NGINX source code, and it autonomously discovered 4 remote memory corruption issues, including a critical heap buffer overflow introduced in 2008. We further investigated the exploitability of the issues, and developed a working proof of concept demonstrating RCE with ASLR off. If you use rewrite and set directives in your NGINX configuration, you’re at risk.
[–] 1 pt

This is the part I don’t understand:

For each finding, we provided a detailed vulnerability description, root cause analysis, and a proof of concept generated directly by our system.

They submitted 5 findings. Only 4 of them were confirmed by Nginx.

If the findings had everything, including a proof of concept, why was one of them not accepted?

Did they manually test these proof of concepts?

I’m guessing they found something that is not actually exploitable from outside the software, but they were too excited to consider that and submitted it anyway. They made the Nginx team do the work of verifying it properly.