Finding six NGINX vulnerabilities with open models — winfunc<br>LoginBook a Demo
Contentsv
We used open models to test whether they could find new vulnerabilities in mature systems code. We selected NGINX because it is widely deployed, written in C, and has received extensive security review.
NGINX uses two-pass encoders, compact binary protocols, shared request state, and configuration-dependent control flow. These features require analysis across functions and modules. A local code fragment is often not enough to confirm a vulnerability.
We ran Winfunc with GLM-5.1 and GLM-5.2 from Z.AI. The scan produced six public NGINX findings:
two heap overflows in HTTP/2 upstream request builders;
one heap overflow in the rewrite engine;
one heap overflow in the stream scripting engine;
one HTTP/2 frame-injection bug; and
one mTLS authorization bypass where a revoked certificate was accepted.
CVEs: CVE-2026-28755 CVE-2026-42926 CVE-2026-9256 CVE-2026-42055 (gRPC) CVE-2026-42055 (proxy) CVE-2026-42533.
All F5/NGINX advisories for the six vulnerabilities credit "Mufeed VH of Winfunc Research".
A note on the traces
We reconstructed the analysis below from stored traces from several NGINX scans. We rerun targets when the agent or model changes. These scans therefore used more than one model provider. The traces show how the agent inspected the code and rejected invalid hypotheses. They do not identify which model first found each CVE. This experiment used GLM-5.1 and GLM-5.2.
The source-analysis agents used read-only repository tools. They produced evidence and test plans. Separate build and reproduction environments produced the AddressSanitizer and live-service results on the Hacktivity pages.
Why NGINX
We did not use a known-vulnerability corpus. In those corpora, the affected function is usually known before the scan starts. We wanted the agent to select relevant code, verify reachability, and produce evidence that a maintainer could review.
NGINX also has several code patterns that require cross-file analysis. A field named len can refer to an allocation size, a serialized size, or a 24-bit wire value. Script modules can evaluate the same expression once for sizing and again for copying. Header validation depends on configuration. HTTP, stream, gRPC, and upstream HTTP/2 use some shared helpers but have separate enforcement paths.
Each finding in this post involved a mismatch between two related operations.
How the scan worked
The following description omits prompts, target-specific mission plans, ranking rules, and model-routing settings.
An initialization pass maps the repository. It records exposed entry points, authentication, trust boundaries, configuration surfaces, and attacker-controlled inputs. A planner uses this information to create bounded scan tasks. For NGINX, a task can focus on data that crosses a wire-format limit, expands during encoding, or passes through separate size and copy operations.
Discovery runs in two paths. A low-cost gate selects files for file-level analysis. At the same time, mission agents follow hypotheses across files and modules. The harness groups and deduplicates the resulting candidates.
The judge checks the attacker-controlled source, trigger path, failed condition, sink, prerequisites, and failure mode. A reporter then reads the relevant code again. The reporter can confirm the finding, reject it, or retain it as a non-standalone gadget. A later pass can combine confirmed findings and gadgets.
Select a stage in the diagram to see its input, output, and validation rule.
winfunc-agent / public system view<br>GLM-5.1GLM-5.2
01Map target02Plan analysis03Analyze code04Cluster05Validate06Store results<br>Map target: Record repository modules, entry points, configuration, and trust boundaries before source analysis.Init<br>Map target
InputSource tree + scan scope<br>OutputRepository map + security context
Record repository modules, entry points, configuration, and trust boundaries before source analysis.<br>File paths are restricted to the target repository.
Stage 1 / 6Select any stage
The first two stages decide where to look and what condition to test . The remaining stages manage concurrent work, retries, deduplication, validation, and stored evidence.
Six findings, five CVE numbers
The gRPC and HTTP/2 proxy reports share CVE-2026-42055. They are separate findings because they affect different modules and have separate trigger paths. The view below summarizes all six findings.
Six paths / five CVE identifiers<br>Select a finding<br>Finding 01CVE-2026-28755Finding 02CVE-2026-42926Finding 03CVE-2026-9256Finding 04CVE-2026-42055Finding 05CVE-2026-42055Finding 06CVE-2026-42533<br>CVE-2026-28755: Stream TLS did not enforce the OCSP resultCVE-2026-28755Medium · 5.4<br>Stream TLS did not enforce the OCSP result<br>ngx_stream_ssl_module
Full report<br>Attacker control<br>A revoked client certificate and its private key
Failed condition<br>Stream TLS did not check the stored OCSP...