Nginx CVE Fix - Source-Built Drop-in for nginx:1.25-bookworm

A source-built nginx 1.25.5 container image that remediates two CVEs present in the official nginx:1.25-bookworm image while preserving upstream runtime behavior.

These represent two distinct remediation models:

1. Version bump (CVE-2024-6119) - the fixed library version is directly visible to scanners via the dpkg database. No additional attestation needed.
2. Source backport (CVE-2026-42945) - the package version remains 1.25.5, so scanners cannot distinguish the patched binary from an unpatched one. Remediation is demonstrated through source provenance, build-time verification, and regression testing. VEX provides the scanner-layer signal.

Parity status

The nginx -V configure arguments of this image match those of nginx:1.25-bookworm (compared character-by-character after normalizing the -ffile-prefix-map build path; verified in test/compat.py::test_nginx_version). The test suite (make test) validates 89 assertions covering image metadata, dynamic modules, filesystem layout, entrypoint behavior, dpkg packaging, and HTTP request handling against the live upstream image.

Known differences from upstream (not validated as identical):

• The built with OpenSSL X.X.X line in nginx -V reflects the builder's libssl-dev version, which may differ from upstream's compile-time OpenSSL.
• Binary content is not byte-for-byte identical (different compilation environment, different toolchain invocation timestamps).
• The image package set differs - debian:bookworm-slim base rather than the official image's inherited package tree.
• Runtime libssl3 version is whatever bookworm currently provides (3.0.20 at time of writing), not the pinned version in the upstream image.

Quick Start

# Build everything (builder → .deb → final image)
make image

# Run automated compatibility tests
make test

# Run CVE-2026-42945 regression test
make test-cve

# Verify patch provenance (re-derives from upstream tarballs)
make verify-patch

# Scan and demonstrate VEX
make scan

One command to build, test, and scan:

make all

Repository Structure

build/
  Dockerfile.build          Builder image (debian:bookworm-slim + compilation deps)
  build.sh                  Fetch → verify → patch → compile → package nginx
  generate-vex.sh           Generate OpenVEX document for backported CVE
  verify-patch.sh           Re-derive patch from upstream tarballs (audit tool)
  patches/
    CVE-2026-42945.patch           Backported one-line fix from nginx 1.30.1
    CVE-2026-42945.provenance.json Machine-readable patch provenance and derivation metadata

test/
  compat.py                 89-assertion compatibility test suite (runs against live upstream)
  test_cve_2026_42945.py    CVE-specific regression test (exercises vulnerable code path)

artifacts/
  patch-attestation.json    Build-time patch attestation (tracked)
  nginx_*.deb               Compiled package (gitignored - rebuilt via `make build-source`)
  nginx                     Compiled binary (gitignored)
Containerfile               Final runtime image definition
Makefile                    Orchestrates build → test → scan pipeline
vex.json                    Generated OpenVEX v0.2.0 document
baseline-trivy.txt          Point-in-time Trivy scan of nginx:1.25-bookworm
baseline-grype.txt          Point-in-time Grype scan of nginx:1.25-bookworm
fixed-trivy.txt             Trivy scan of the fixed image
fixed-grype.txt             Grype scan of the fixed image (without VEX)
fixed-grype-vex.txt         Grype scan of the fixed image (with VEX applied)

Build Process

Architecture

debian:bookworm-slim (builder)
  └─ build.sh
       ├─ curl nginx-1.25.5.tar.gz (SHA256-verified)
       ├─ curl njs-0.8.4 from github.com/nginx/njs
       ├─ patch -p1 < CVE-2026-42945.patch
       ├─ ./configure (flags identical to upstream nginx -V)
       ├─ make: release binary, debug binary, 4 dynamic module families (×2 release/debug)
       ├─ make: NJS modules (×2 release/debug) + njs CLI binary
       └─ dpkg-deb → nginx_1.25.5-1~bookworm+echo1_<arch>.deb

debian:bookworm-slim (runtime)
  ├─ apt-get install runtime deps (libssl3 ≥ 3.0.14 enforced)
  ├─ dpkg -i nginx_*.deb
  └─ COPY --from=upstream /docker-entrypoint.sh + /docker-entrypoint.d/

The Containerfile does NOT copy /etc/nginx from upstream. All configuration files are shipped inside the .deb and tracked by dpkg's conffile mechanism. This is required for the 10-listen-on-ipv6-by-default.sh entrypoint script, which uses dpkg-query to detect whether default.conf has been user-modified.

Integrity Guarantees

• Source tarballs: All source archives (nginx, NJS) are SHA256-verified against hardcoded hashes before extraction. Build aborts on mismatch.
• Build from source: ./configure && make inside a clean Debian container. No upstream binaries, no apt install nginx.
• No network access during compilation: dependencies are installed in the builder Docker image layer; build.sh only fetches pinned source archives.

Reproducibility

The build is mostly reproducible but not hermetic:

• nginx source version and SHA256 are pinned and verified before extraction.
• NJS version and SHA256 are pinned and verified before extraction.
• Builder dependencies are enumerated in Dockerfile.build but not version-pinned.
• Debian runtime packages are resolved from live bookworm repositories at build time, so minor versions can drift between builds.

To improve reproducibility, pin the base image digest:

docker pull debian:bookworm-slim
docker inspect debian:bookworm-slim --format='{{index .RepoDigests 0}}'
# Then use: FROM debian:bookworm-slim@sha256:<digest>

CVE Remediation Details

CVE-2024-6119 - OpenSSL Version Bump

How the fix works:

The .deb package declares Depends: libssl3 (>= 3.0.14), which forces apt-get install to pull an OpenSSL version that includes the fix. The current Debian bookworm repositories provide 3.0.20, which fixes CVE-2024-6119 and dozens of other OpenSSL CVEs from the baseline (CVE-2024-2511, CVE-2024-5535, CVE-2024-4741, CVE-2023-5678, CVE-2023-6129, CVE-2023-6237, CVE-2024-9143, CVE-2025-15467, CVE-2025-69420).

Scanner behavior: Grype and Trivy see libssl3 3.0.20 in the dpkg database and recognise that 3.0.20 ≥ 3.0.14, so CVE-2024-6119 is no longer reported. No VEX needed - the version bump is self-evident.

Verification:

grep "CVE-2024-6119" baseline-grype.txt  # present
grep "CVE-2024-6119" fixed-grype.txt     # absent

CVE-2026-42945 - Backported Patch

Vulnerability:

ngx_http_script_regex_end_code() in src/http/ngx_http_script.c failed to reset e->is_args when processing a rewrite regex result. If is_args was set by a preceding script engine operation, subsequent buffer length calculations in the redirect/rewrite path would be incorrect, causing a heap buffer overflow of attacker-controlled size via crafted request URIs.

The fix (one line):

// Added before the existing e->quote = 0; at line 1205
e->is_args = 0;

Patch provenance:

How the patch was created:

1. Downloaded nginx-1.25.5.tar.gz (SHA256 verified against pinned hash)
2. Downloaded nginx-1.30.1.tar.gz (SHA256 verified: 99765000d974896b31ca5882d8c279ce3fe7ef6f5c6f9f0a967ed7fd3407f9cc)
3. Ran diff src/http/ngx_http_script.c between the two trees
4. The diff produced exactly one line - the e->is_args = 0; addition
5. Extracted as a unified diff patch with context lines
6. Verified the patch applies cleanly to nginx 1.25.5
7. Both source trees are retained in research/ for independent verification

Regression testing:

The test suite test/test_cve_2026_42945.py exercises the vulnerable code path by sending requests through rewrite rules that manipulate query string state (is_args). It validates:

• Rewrite redirects with trailing ? (query strip) produce well-formed responses
• Chained rewrites that toggle is_args state don't crash the worker
• Long query strings (4KB+) don't cause buffer overflow artifacts (null bytes, overlong Location headers)
• 100 rapid mixed requests don't cause worker crashes
• The worker process survives all test cases without SIGSEGV or heap corruption

Run: make test-cve

Scanner behavior:

Because the package version remains 1.25.5, scanners will flag CVE-2026-42945 when the advisory is present in their database. This is expected - scanners match by (package-name, upstream-version) and cannot inspect whether source has been patched. The VEX document suppresses this finding with machine-readable justification. The scanner suppression is a communication mechanism, not the primary evidence of remediation. The primary evidence is the patch provenance chain and regression test above.

VEX (Vulnerability Exploitability eXchange)

Why VEX is needed

Scanners identify packages by (name, version) from the dpkg database. Our package is nginx 1.25.5-1~bookworm+echo1 - scanners parse this as upstream version 1.25.5 and flag all CVEs affecting nginx ≤ 1.25.5.

For backported fixes, the scanner cannot determine that the vulnerable code has been patched. The version intentionally remains 1.25.5 to preserve package compatibility. VEX provides a machine-readable attestation that the CVE has been addressed, linked to verifiable evidence.

VEX credibility chain

The VEX statement for CVE-2026-42945 is NOT mere paperwork. It is backed by:

1. Patch provenance - build/patches/CVE-2026-42945.provenance.json documents the exact upstream source, derivation method, and file hashes
2. Build-time verification - build.sh asserts the fix marker is present in the compiled source, aborting the build on failure
3. Build attestation - artifacts/patch-attestation.json records pre/post-patch file hashes generated during the build
4. Regression test - test/test_cve_2026_42945.py exercises the vulnerable code path without crash or corruption
5. Independent re-derivation - make verify-patch downloads both upstream tarballs and demonstrates the committed patch is the minimal security diff

What the VEX covers

The VEX scope is intentionally narrow: only CVEs that this project actively remediated with verifiable evidence are covered. Findings that are merely "expected to be mitigated" by the shipped version are not suppressed - this avoids using VEX as a blanket suppression tool.

How it works

The build/generate-vex.sh script produces an OpenVEX v0.2.0 document. The scanner command to apply it:

# Without VEX - CVE is reported (version-based match):
grype nginx-fixed > fixed-grype.txt

# With VEX - CVE is suppressed with justification:
grype nginx-fixed --vex vex.json > fixed-grype-vex.txt

Scanner evidence

The VEX suppression is observable in saved scan artifacts. Note that scanner databases are rebuilt periodically and CVE presence may vary between runs. The saved baseline-grype.txt and fixed-grype.txt files are point-in-time evidence. The VEX document's validity does NOT depend on scanner DB state - it is independently verifiable via the provenance chain above.

Scanner Integrity

Package naming decision

The package is named nginx (not nginx-custom). This is critical because:

1. Honest reporting: If the package were renamed, scanners would not recognise it as nginx and ALL nginx CVEs would silently vanish - including unfixed ones. That's a false sense of security.
2. VEX demonstration: VEX can only suppress a CVE that the scanner actually reports. Renamed packages make VEX unnecessary (and untestable).
3. Package management: Naming it nginx allows it to satisfy dependencies and be managed by standard Debian tooling.

Scanner database volatility

Scanner advisory databases are rebuilt periodically. A CVE present one week may be absent the next. This project does NOT rely on scanner output as the primary proof of remediation. The evidence chain is:

1. Patch provenance (verifiable independently of any scanner)
2. Build-time attestation (generated during compilation)
3. Regression test (exercises the vulnerable code path)
4. VEX suppression (scanner-layer acknowledgment)

Saved scan files are point-in-time evidence only.

What scanners see (fixed image)

With --vex vex.json, the CVE-2026-42945 finding (if present in the scanner DB) is suppressed. The VEX document's validity is established by the provenance chain (patch derivation, build attestation, regression test), not by scanner output alone.

Compatibility Test

The test suite (test/compat.py) boots both nginx:1.25-bookworm and nginx-fixed as Docker containers and compares behavior. Each assertion directly tests the live fixed image against the live upstream image.

89 assertions. All passing.

Additionally, test/test_cve_2026_42945.py provides ~20 assertions specifically targeting the backported CVE fix (see "Regression testing" above).

What is NOT tested

• HTTP/3 QUIC protocol behavior (only the --with-http_v3_module flag presence is verified; no UDP/QUIC traffic is sent)
• Performance or latency characteristics under load
• All possible nginx configuration directives
• Behavior of seldom-used dynamic modules (GeoIP, image_filter, XSLT) beyond verifying the .so files are present on disk

Run:

make test

Image Size

The fixed image is larger than upstream. This is expected: the official image uses pre-compiled binaries in optimized layers, while ours installs build artifacts and full runtime dependencies (including libraries for all 12 dynamic modules) into a debian:bookworm-slim base. The size difference is a tradeoff for source-level build control, not a regression in functionality.

Residual Risk Assessment

CVEs remaining in the fixed image

The fixed image still contains vulnerabilities in system libraries not addressed by this project (point-in-time; run make scan for current state):

These are inherited from debian:bookworm-slim and are outside the scope of this project's nginx-focused CVE remediation.

Limitations of this approach

1. Not hermetic. Base image and apt packages are resolved at build time from live Debian repositories. Pinning the base image SHA and using apt snapshots would improve reproducibility.
2. No behavioral QUIC testing. HTTP/3 support is compiled in (verified by flag) but no QUIC traffic is exercised in the test suite.
3. No performance validation. The 50-concurrent-request test proves correctness, not throughput or latency equivalence.
4. Module loading only. Dynamic modules (GeoIP, image_filter, XSLT) are verified to be present and loadable, but their feature behavior is not exercised beyond basic load.
5. Single-architecture evidence. Tests run on the build host architecture only (arm64 in development; would need CI for multi-arch).

Future improvements (not implemented)

1. Pin base image digest and use apt snapshot URLs for hermetic builds.
2. Strip unnecessary packages (ncurses, util-linux) pulled as transitive deps.
3. Generate SBOM (make sbom target exists, uses syft) and link to VEX via SBOM purl.
4. Sign the image with cosign and attach VEX + SBOM + patch-attestation as OCI attestations.
5. Add CI pipeline (GitHub Actions) for automated build → test → scan → push.
6. Add HTTP/3 protocol test (QUIC client, certificate setup, UDP port).
7. Consider distroless base to eliminate OS-level CVE noise entirely.
8. Add ASan (AddressSanitizer) build variant to prove no heap corruption under test load.

Build Flags vs. Upstream

The ./configure flags in build.sh are identical to those reported by nginx -V in the official nginx:1.25-bookworm image. This is verified by test/compat.py::test_nginx_version, which normalizes the -ffile-prefix-map=<path> difference and compares the remaining flags character-by-character.

Noteworthy flags (all present in both images):

Debian Package

The .deb package metadata:

Package: nginx
Version: 1.25.5-1~bookworm+echo1
Depends: libc6 (>= 2.34), libcrypt1 (>= 1:4.1.0), libpcre2-8-0 (>= 10.22),
         libssl3 (>= 3.0.14), zlib1g (>= 1:1.2.11), libgeoip1 (>= 1.6.12),
         libgd3 (>= 2.1.0~alpha~), libxml2 (>= 2.7.4), libxslt1.1 (>= 1.1.25),
         lsb-base (>= 3.0-6), adduser
Provides: httpd, nginx, nginx-r1.25.5
Conflicts: nginx-common, nginx-core
Replaces: nginx-common, nginx-core

Key packaging decisions:

• libssl3 (>= 3.0.14) - explicitly requires patched OpenSSL (upstream declares >= 3.0.0). This is the mechanism that enforces CVE-2024-6119 fix.
• Provides: nginx-r1.25.5 - satisfies dynamic module packages that depend on this virtual package.
• Conffiles registered with dpkg: /etc/nginx/nginx.conf and /etc/nginx/conf.d/default.conf. This is required for the IPv6 entrypoint script's dpkg-query --showformat check.
• postinst creates nginx user/group with uid/gid 101 and shell /bin/false (matching upstream - verified in test suite).
• Ships: nginx binary, nginx-debug binary, all 12 .so modules, full /etc/nginx config tree, init.d/systemd/logrotate files, man page, HTML defaults, and /etc/nginx/modules → /usr/lib/nginx/modules symlink.

Design Decisions and Tradeoffs

1. Package named nginx, not nginx-custom. If renamed, scanners would not match it against nginx advisories - all nginx CVEs would silently disappear from reports, including unfixed ones. Keeping the name nginx ensures honest scanner reporting and makes VEX meaningful.

2. VEX requires CVE visibility. The purpose of VEX is to suppress a CVE that is already reported. If the scanner doesn't find the CVE (due to package renaming or DB timing), VEX has nothing to suppress.

3. libssl3 (>= 3.0.14) as package dependency. Rather than hoping the runtime base happens to have a patched OpenSSL, the .deb hard-requires a version that contains the fix for CVE-2024-6119.

4. Scanner database volatility. Advisory databases rebuild periodically. A CVE present one week may be absent the next. The saved scan files in this repo are point-in-time evidence; current scans may differ.

5. AI tools used. GitHub Copilot assisted with patch analysis (comparing nginx 1.25.5 and 1.30.1 source trees), test suite structure, identifying the package-rename scanner evasion issue, and VEX document authoring. Debian packaging details and Grype version-matching heuristics required manual verification.