Post cover image

October 31, 2026

NGINX Has Three Critical Vulnerabilities: CVE-2026–15176, CVE-2026-97205 and CVE-2026-93479…

Three critical security vulnerabilities affecting NGINX could allow remote attackers to crash worker processes and potentially execute…

By White Arrow Cybersecurity

7 min read

Three critical security vulnerabilities affecting NGINX could allow remote attackers to crash worker processes and potentially execute arbitrary code under specific conditions. Here's what system administrators and security engineers need to know.

If you manage web infrastructure, there's a good chance NGINX is running somewhere in your environment.

It could be serving your website, acting as a reverse proxy, balancing application traffic, handling API requests or managing traffic inside your Kubernetes cluster.

Now imagine an attacker sending a specially crafted HTTP request to your web server and triggering a memory corruption vulnerability.

The result could be more than an application error. Depending on the vulnerability and system configuration, it could cause NGINX worker processes to crash, disrupt application availability or potentially allow arbitrary code execution.

On 14 October 2026, F5 published security advisories covering three particularly serious vulnerabilities affecting NGINX Open Source and NGINX Plus.

All three received a CVSS v4.0 score of 9.2 out of 10, classified as Critical by F5.

The vulnerabilities are:

  • CVE-2026–15176
  • CVE-2026–97205
  • CVE-2026–93479

India's CERT-In subsequently published vulnerability note CIVN-2026–0517 on 22 October 2026, classifying the issue as Critical and recommending security updates.

Let's examine what these vulnerabilities actually do, which configurations are affected and how administrators can protect their infrastructure.

What Are the Three NGINX Vulnerabilities?

The three vulnerabilities involve different memory management problems within NGINX.

Although their technical causes differ, they share an important characteristic: an unauthenticated remote attacker may be able to trigger the vulnerable behaviour by sending specially crafted HTTP requests, provided the required configuration conditions exist.

1. CVE-2026–15176: Heap-Based Buffer Overflow in Alias and Rewrite

CVSS v4.0: 9.2 | CVSS v3.1: 8.1

This vulnerability involves the interaction between the NGINX alias directive, rewrite processing and the $request_filename variable.

The issue occurs under specific configurations where a location uses alias together with rewrite, and a set or return directive references $request_filename.

A similar condition can occur when $request_filename is referenced in an access-log log_format directive.

A specially crafted HTTP request can trigger a heap-based buffer overflow in the NGINX worker process.

Potential consequences include:

  • Worker process crashes or restarts.
  • Denial of service.
  • Potential arbitrary code execution under certain conditions.

F5 notes that code execution may be possible when Address Space Layout Randomization (ASLR) is disabled or when an attacker can bypass ASLR.

What should administrators investigate?

Review configurations involving:

  • location blocks using alias.
  • Rewrite rules.
  • set and return directives.
  • References to $request_filename.
  • Custom access-log formats.

The important point is that using alias alone does not automatically establish vulnerability. The specific combination of configuration directives matters.

Official advisory: https://my.f5.com/manage/s/article/K000162416

2. CVE-2026–97205: Use-After-Free in Asynchronous File I/O

CVSS v4.0: 9.2 | CVSS v3.1: 8.1

This vulnerability involves asynchronous file I/O (AIO) and Server Side Includes (SSI).

A use-after-free vulnerability occurs when software attempts to access memory after that memory has already been released.

This can lead to memory corruption, unexpected application behaviour or process crashes.

In this particular case, the vulnerable behaviour involves asynchronous file operations and SSI pages using the include virtual functionality.

Under the affected conditions, specially crafted HTTP requests could trigger the memory management issue.

Potential consequences include:

  • NGINX worker process crashes.
  • Memory corruption.
  • Denial of service.
  • Potential code execution under certain conditions.

What should administrators investigate?

Check whether your NGINX configuration uses:

  • Asynchronous file I/O.
  • Server Side Includes.
  • SSI pages containing include virtual.
  • Related request-processing configurations.

One important detail: enabling AIO alone does not establish that your server is exploitable. The affected interaction between AIO and SSI must be considered.

If immediate patching is not possible, F5 recommends disabling either AIO or SSI as a temporary mitigation, where appropriate.

Official advisory: https://my.f5.com/manage/s/article/K000162608

3. CVE-2026–93479: Heap-Based Buffer Overflow in Script Evaluation

CVSS v4.0: 9.2 | CVSS v3.1: 8.1

This vulnerability concerns string-expression evaluation involving variables and regular-expression captures.

One affected configuration involves the map directive using regular-expression matching, with capture variables referenced in a root directive or access-log format before the map output variable is referenced.

Under certain conditions, a specially crafted HTTP request can trigger a heap-based buffer overflow in the NGINX worker process.

Potential consequences include:

  • Worker process crashes or restarts.
  • Denial of service.
  • Potential arbitrary code execution under certain conditions.

F5 also describes another affected scenario involving non-cacheable variables used in string expressions.

What should administrators investigate?

Review:

  • map directives using regular expressions.
  • Named and unnamed capture variables.
  • References to regex capture variables.
  • Dynamic root configurations.
  • Custom access-log formats.
  • Variable evaluation order.

F5 recommends using named captures instead of unnamed captures and restricting their use to the configuration block containing the regular-expression match as a mitigation.

Official advisory: https://my.f5.com/manage/s/article/K000162607

Why Are the Severity Ratings Different?

There is an interesting detail in the vulnerability assessments.

F5 assigned the three vulnerabilities:

Scoring systemSeverityScoreCVSS v3.1High8.1CVSS v4.0Critical9.2

However, the NGINX security advisory page classifies these vulnerabilities as Medium.

Why does this happen?

Different security organisations can use different assessment methodologies and severity classifications.

CVSS versions also use different metrics and scoring approaches.

For administrators, the important thing is not to rely on a single severity label.

Consider the actual technical conditions:

  • Is the affected NGINX version running?
  • Are the vulnerable directives configured?
  • Can an unauthenticated attacker reach the service?
  • Could the vulnerability affect availability?
  • Are there conditions that could make code execution possible?

These questions provide a more useful understanding of actual exposure.

Which NGINX Versions Are Affected?

According to the official NGINX security advisories, the affected version ranges differ between the three vulnerabilities.

CVEAffected NGINX Open Source versionsCVE-2026–151760.1.29 through 1.31.6CVE-2026–972050.8.11 through 1.31.6CVE-2026–934791.31.2–1.31.6 and 1.30.0–1.30.5

The fixed NGINX Open Source releases are:

  • 1.30.6 for the stable branch.
  • 1.31.7 for the mainline branch.

NGINX subsequently released 1.31.8 on 21 October 2026.

For NGINX Plus and other F5 products, administrators should consult the corresponding F5 product-specific advisory and upgrade matrix.

Affected products can include:

  • NGINX Plus.
  • NGINX Instance Manager.
  • F5 WAF for NGINX.
  • NGINX App Protect WAF.
  • F5 DoS for NGINX.
  • NGINX Gateway Fabric.
  • NGINX Ingress Controller.

Do not assume that updating the host operating system automatically updates every NGINX instance running inside containers or appliances.

Source: NGINX Security Advisories and CERT-In CIVN-2026–0517.

Is There Evidence of Active Exploitation?

As of the reporting reviewed for this article, these three vulnerabilities had not been established as actively exploited in the wild.

They were also not listed in CISA's Known Exploited Vulnerabilities catalogue in the initial reporting period.

However, the absence of confirmed exploitation does not mean that internet-facing systems should remain unpatched.

Memory corruption vulnerabilities can attract significant attention from vulnerability researchers and attackers, particularly when technical details and proof-of-concept material become available.

Organisations should prioritise remediation based on exposure, configuration and business impact.

Practical Security Assessment: How to Check Your NGINX Infrastructure

This is where system administrators and security engineers should focus their attention.

Instead of immediately assuming that every NGINX installation is vulnerable, begin with asset discovery and configuration analysis.

Step 1: Identify Your NGINX Version

Run:

nginx -v

For detailed build information:

nginx -V

The second command also provides information about compilation options and enabled modules.

Remember that vendor-packaged versions may include security backports without using the upstream version number. Check your distribution's security advisory as well.

Step 2: Review the Active Configuration

Dump the configuration:

sudo nginx -T

This displays the loaded configuration, including included files.

Review the output for:

alias
rewrite
$request_filename
aio
ssi
include virtual
map
log_format

These searches are useful for initial triage, but finding a directive does not automatically establish that the relevant vulnerability conditions are present.

Review the surrounding configuration and directive relationships.

Also protect the output of nginx -T, because configuration files may contain sensitive information.

Step 3: Review NGINX Logs

Check the error log:

sudo tail -n 200 /var/log/nginx/error.log

Review access logs:

sudo tail -n 200 /var/log/nginx/access.log

Look for:

  • Repeated worker process crashes.
  • Unexpected worker restarts.
  • Abnormal request patterns.
  • Unusual HTTP request lengths.
  • Repeated requests to specific endpoints.
  • Unexpected upstream failures.

These indicators are not proof of exploitation, but they can help identify abnormal behaviour.

Step 4: Validate the Patch

After upgrading, verify the running version:

nginx -v

Test the configuration before reloading:

sudo nginx -t

If the configuration test succeeds, reload NGINX:

sudo systemctl reload nginx

For containerised deployments, rebuild and redeploy the relevant image rather than assuming that updating the host package is sufficient.

Step 5: Validate the Environment Again

After patching:

  • Confirm the intended binary is running.
  • Check the active service version.
  • Verify container image versions.
  • Review application availability.
  • Confirm that no old vulnerable instances remain.
  • Reassess the affected configuration patterns.

A successful package installation is not the same as a completed security remediation.

What About Kubernetes and NGINX Ingress?

Kubernetes administrators should pay particular attention to this incident.

NGINX can run in several different forms inside a Kubernetes environment:

  • NGINX-based ingress controllers.
  • NGINX reverse proxies.
  • NGINX containers deployed as application components.
  • Custom NGINX images.
  • F5 NGINX Gateway Fabric.

Start by identifying the deployed images:

kubectl get pods -A -o wide

Review container image references:

kubectl get pods -A \
-o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}'

Then inspect the relevant image versions and vendor security notices.

Do not assume that every NGINX-based controller is affected in exactly the same way. Build options, enabled modules, configuration and product versions can change exposure.

For production Kubernetes environments, review the security guidance for the exact controller and release you operate.

What Should Organisations Do Immediately?

My recommendation is to approach this as an infrastructure vulnerability management exercise.

PriorityActionCriticalIdentify all internet-facing NGINX deploymentsCriticalUpgrade affected NGINX versionsHighReview vulnerable configuration patternsHighCheck NGINX Plus and F5 product advisoriesHighInspect container and Kubernetes deploymentsHighReview logs for unexpected worker crashesMediumValidate WAF and monitoring coverageMediumDocument remediation and retest

If immediate patching is not possible, apply the vendor-recommended temporary mitigations after assessing their operational impact.

For example:

  • CVE-2026–15176: Avoid the vulnerable alias and $request_filename configuration combination.
  • CVE-2026–97205: Disable either AIO or SSI where appropriate.
  • CVE-2026–93479: Use named regex captures and restrict their scope as recommended.

Temporary mitigations should not replace installing the security updates.

The Bigger Picture: Why Memory Corruption in Web Infrastructure Matters

NGINX is frequently deployed at the edge of an organisation's infrastructure.

It can process traffic from thousands or millions of clients and act as a gateway to internal application services.

That makes memory corruption vulnerabilities particularly important.

A worker process crash can affect availability even when the operating system and underlying server remain operational.

Potential code execution under the required conditions introduces a much more serious risk.

For security teams, this incident highlights the importance of:

  • Secure memory management.
  • Configuration hardening.
  • Timely vulnerability management.
  • Continuous infrastructure monitoring.
  • Regular security assessments.
  • Testing patch effectiveness.

A web server should not be considered secure simply because it has been running without problems for several months.

Configuration changes, new modules, software updates and application integrations can introduce security risks that were not present during the original deployment.

Final Thoughts

The three NGINX vulnerabilities are a reminder that even widely deployed and mature infrastructure software can contain serious security weaknesses.

What makes these issues particularly relevant is that they involve components commonly used in production environments.

A reverse proxy, web server or ingress controller may be exposed to untrusted HTTP requests every day.

Administrators should therefore focus on identifying affected versions, understanding the configuration requirements and applying the available security updates.

Do not wait for a public exploitation campaign before reviewing your infrastructure.

From a practical security engineering perspective, the goal is not simply to know that a CVE exists. It is to establish whether your infrastructure is exposed, validate the relevant controls and confirm that remediation has actually worked.

That is the difference between reading a vulnerability advisory and performing effective vulnerability management.

Accuracy note: This article reflects publicly available NGINX, F5 and CERT-In security information reviewed as of 31 October 2026. The three vulnerabilities discussed are CVE-2026–15176, CVE-2026–97205 and CVE-2026–93479. Severity classifications and affected version ranges are attributed to their respective sources. Check vendor advisories before making production changes.

Credits: Salil Sardesai