CVE-2026-42945 — NGINX Wazuh SCA Defensive Lab

Overview

This repository documents a defensive lab for CVE-2026-42945, affecting the NGINX ngx_http_rewrite_module.

The goal of this project was to approach the CVE from a blue-team perspective by using Wazuh Security Configuration Assessment (SCA) to centrally assess NGINX exposure.

The lab checks for two exposure conditions:

1. An unpatched Ubuntu NGINX package version
2. A risky NGINX rewrite configuration pattern related to CVE-2026-42945

The final result is a centralized Wazuh SCA policy that can be deployed to monitored NGINX servers through Wazuh centralized agent configuration.

Lab Architecture

The lab was built using a segmented network architecture.

Internet / WAN
     |
     |
  pfSense Firewall
     |
     |-----------------------------
     |                             |
    LAN                           DMZ
     |                             |
Wazuh Manager                Ubuntu NGINX Server
Wazuh Dashboard              Wazuh Agent
                             NGINX

Components

Objective

The objective was to build a safe and repeatable defensive workflow:

Wazuh Manager
     |
     | Centralized SCA policy
     v
Wazuh Agent on DMZ NGINX Server
     |
     | Checks package version and NGINX configuration
     v
Wazuh Dashboard
     |
     | Shows passed / failed checks
     v
Remediation validation

This approach allows CVE exposure assessment without running exploit code.

Detection Strategy

The custom Wazuh SCA policy performs two checks.

Check 1 — NGINX Package Version

The policy checks whether the installed Ubuntu NGINX package matches the unpatched version observed in the lab.

Initial vulnerable package version:

nginx         1.28.3-2ubuntu1
nginx-common  1.28.3-2ubuntu1

Fixed package version after remediation:

nginx         1.28.3-2ubuntu1.1
nginx-common  1.28.3-2ubuntu1.1

Policy file:

sca-policy/nginx-cve-2026-42945.yml

Check 2 — Risky NGINX Rewrite Configuration

The policy also checks for a risky rewrite pattern related to CVE-2026-42945.

The risky test configuration is stored here:

nginx-config/vulnerable-example.conf

The remediated configuration is stored here:

nginx-config/remediated-example.conf

The risky condition tested in the lab includes:

rewrite directive
unnamed capture such as $1
replacement containing ?
follow-up directive such as set

Repository Structure

wazuh-nginx-cve-2026-42945-sca-lab/
├── README.md
├── sca-policy/
│   └── nginx-cve-2026-42945.yml
├── wazuh-config/
│   └── agent.conf
├── nginx-config/
│   ├── vulnerable-example.conf
│   └── remediated-example.conf
├── commands/
│   ├── 01-agent-validation.md
│   ├── 02-nginx-version-check.md
│   ├── 03-sca-policy-deployment.md
│   └── 04-remediation.md
├── screenshots/
│   ├── 01-lab-architecture.png
│   ├── 02-agent-active.png
│   ├── 03-sca-policy-failed.png
│   ├── 04-nginx-package-before.png
│   ├── 05-risky-rewrite-config.png
│   ├── 06-sca-partial-remediation.png
│   ├── 07-nginx-package-after.png
│   └── 08-sca-policy-passed.png
└── docs/
    └── lab-notes.md

How the Lab Was Built

Step 1 — Network Segmentation

The lab used pfSense to separate the environment into:

LAN:
- Wazuh Manager
- Wazuh Dashboard

DMZ:
- Ubuntu NGINX server
- Wazuh Agent

The Ubuntu NGINX server was placed in the DMZ.
The Wazuh Manager was placed in the LAN.

Only the required Wazuh communication was allowed from the DMZ server to the Wazuh Manager.

Step 2 — Wazuh Agent Deployment

The Ubuntu DMZ server was registered as a Wazuh agent.

The agent was verified from the Wazuh Manager and confirmed as active.

Validation commands are documented in:

commands/01-agent-validation.md

Expected state:

Agent: ubuntu-dmz-nginx2
Status: Active

Step 3 — NGINX Version Assessment

The installed NGINX package version was checked on the Ubuntu DMZ server.

Version-check commands are documented in:

commands/02-nginx-version-check.md

Initial state:

nginx         1.28.3-2ubuntu1
nginx-common  1.28.3-2ubuntu1

After package index update, the fixed candidate version became available:

1.28.3-2ubuntu1.1

Step 4 — Risky NGINX Configuration

A test NGINX configuration was created to simulate the risky rewrite pattern.

The vulnerable example is stored in:

nginx-config/vulnerable-example.conf

The remediated version is stored in:

nginx-config/remediated-example.conf

The purpose was not to exploit the service, but to validate whether Wazuh SCA can identify risky local configuration exposure.

Step 5 — Custom Wazuh SCA Policy

A custom SCA policy was created on the Wazuh Manager.

Policy file:

sca-policy/nginx-cve-2026-42945.yml

In the lab, this policy was deployed from the Wazuh Manager shared directory:

/var/ossec/etc/shared/default/nginx-cve-2026-42945.yml

The policy contains two checks:

Step 6 — Centralized Agent Configuration

The custom SCA policy was deployed using Wazuh centralized agent configuration.

The centralized configuration file is stored in this repository as:

wazuh-config/agent.conf

In the lab, it was deployed under:

/var/ossec/etc/shared/default/agent.conf

The Wazuh Manager was running in Docker:

single-node-wazuh.manager-1

Deployment commands are documented in:

commands/03-sca-policy-deployment.md

Step 7 — Policy Validation on the Agent

After restarting the Wazuh agent, the custom SCA policy was received by the Ubuntu DMZ server.

The received policy appeared under:

/var/ossec/etc/shared/nginx-cve-2026-42945.yml

The Wazuh agent logs confirmed that the policy was loaded and evaluated.

Expected log indicators:

Loaded policy
Starting evaluation of policy
Evaluation finished for policy

Initial Result

With both exposure conditions present, the Wazuh Dashboard showed:

Passed: 0
Failed: 2
Score: 0%

This means both checks failed:

Screenshot:

screenshots/03-sca-policy-failed.png

Remediation

Remediation Step 1 — Fix Risky Rewrite Configuration

The risky NGINX rewrite configuration was replaced with a safer configuration.

Reference file:

nginx-config/remediated-example.conf

After the configuration was fixed and the Wazuh SCA scan ran again, the expected result was:

Passed: 1
Failed: 1
Score: 50%

At this stage:

Screenshot:

screenshots/06-sca-partial-remediation.png

Remediation Step 2 — Upgrade NGINX Packages

The NGINX packages were upgraded using a targeted package upgrade.

Remediation commands are documented in:

commands/04-remediation.md

Before upgrade:

Installed: 1.28.3-2ubuntu1
Candidate: 1.28.3-2ubuntu1.1

After upgrade:

nginx         1.28.3-2ubuntu1.1
nginx-common  1.28.3-2ubuntu1.1

Screenshot:

screenshots/07-nginx-package-after.png

Final Result

After both remediation steps were completed, the Wazuh SCA result changed to:

Passed: 2
Failed: 0
Score: 100%

This confirmed that:

1. The risky rewrite configuration was fixed
2. The NGINX packages were upgraded to the fixed version

Screenshot:

screenshots/08-sca-policy-passed.png

Results Summary

Screenshots

Recommended screenshots:

Production Considerations

For the lab, the policy was deployed through the Wazuh default group.

In production, it is better to create a dedicated Wazuh agent group, for example:

nginx-servers

Only servers running NGINX should be assigned to that group.

Recommended production-style deployment:

Wazuh Manager
     |
     | Centralized SCA policy
     v
nginx-servers agent group
     |
     | Applied only to NGINX systems
     v
Wazuh Dashboard

This avoids applying NGINX-specific checks to unrelated systems.

Why No Exploit Code Was Used

This project intentionally avoids exploit code.

The purpose of the lab was to demonstrate defensive security engineering, not exploitation.

The assessment was based on:

package version exposure
configuration exposure
centralized Wazuh SCA validation
remediation verification

Key Takeaways

• Wazuh SCA can be used to centrally assess CVE exposure.
• CVE validation does not always require exploit execution.
• pfSense DMZ segmentation makes the lab more realistic.
• Custom SCA policies can check both package versions and risky configurations.
• Remediation should be validated with measurable before-and-after results.
• A dedicated Wazuh agent group should be used for production deployment.

Disclaimer

This repository is for educational and defensive security purposes only.

No exploit code is included.

The checks are designed for a controlled lab environment and should be reviewed before use in production.