Securing F5 NGINX in the age of AI

Jay BhalodSenior Director, Engineering | F5

In a recent blog, our Chief Product Officer shared how F5 is applying frontier AI to harden our software. The blog outlined an AI-driven approach to scanning, triage, fixing, testing, and release—not as a one-time exercise, but as a repeatable operating model for finding and addressing issues more quickly and rigorously.

That approach has important implications for F5 NGINX.

NGINX sits in the critical path for a significant part of the modern Internet. NGINX powers nearly a third of all websites. As one of the most widely used web servers, reverse proxies, API gateways, and Kubernetes ingress technologies, that reach comes with a serious responsibility—especially when it comes to security.

Security has always been central to how we build and maintain NGINX. But the environment around software security is changing quickly. Frontier AI models make it easier to analyze complex codebases, reason across modules, and identify potential vulnerabilities faster than traditional approaches alone. That creates opportunities for defenders, but it also creates urgency. If AI can help engineering teams find and fix issues more quickly, it can also help attackers look for weaknesses more efficiently.

That is why F5 is investing in an AI-driven approach to securing NGINX. The goal is simple: find issues earlier, validate them rigorously, fix them carefully, and make hardened releases available to users as quickly and consistently as we can.

Securing the full F5 NGINX portfolio

NGINX is not a single code path. It is a broad ecosystem that includes open source software, commercial products, Kubernetes-focused components, security modules, and developer-facing extensibility projects. Securing NGINX means looking across that full surface area.

Our testing and validation work spans F5 NGINX Open Source, F5 NGINX Plus, F5 NGINX Ingress Controller, F5 NGINX Gateway Fabric, F5 NGINX Instance Manager, F5 NGINX One Console, F5 WAF for NGINX, related application security modules, and nginx JavaScript modules, known as njs.

That breadth matters because users run NGINX in many ways. Some use it as a web server or reverse proxy. Others use it as a load balancer, API gateway, ingress controller, or part of a broader application delivery architecture. Some rely on open source components. Others use commercial support and enterprise features. Many use a mix.

For users, the value is consistency. Security work should reflect how software is actually deployed, not just how one component is packaged. Testing across the NGINX portfolio helps us evaluate issues in context, reduce uncertainty, and give users clearer guidance when updates are needed.

Community makes NGINX stronger

NGINX has always benefited from the expertise of its community. Researchers, maintainers, contributors, operators, customers, and open source users all help make the software better.

We want to acknowledge the people who have identified issues, reported bugs, submitted fixes, and helped improve NGINX over time. Their work strengthens the project and helps protect the broader internet.

Examples of community contributions include recently identified issues such as CVE-2026-42530, CVE-2026-42055, CVE-2026-9256, and CVE-2026-42945. These findings, reported through the broader community, helped us quickly investigate, validate, fix, and release updates. They are practical examples of how researchers, contributors, and maintainers work together to reduce risk and improve security for everyone relying on NGINX.

This collaboration matters even more in the AI era. As scanning tools improve, more people will be able to find more issues across more projects. That can be a very good thing for software security when maintainers, researchers, and users work together with a shared goal: reducing risk for everyone who depends on the software.

The best outcomes happen when potential security issues are investigated, validated, fixed, tested, and communicated in a way that gives users a clear path to protection. We appreciate the community’s role in helping make that possible.

Scan, triage, fix, test, release, repeat

NGINX has had rigorous engineering, testing, and security practices for years. What is changing is the pace and scale at which security work can happen.

AI-driven security analysis gives us a faster way to inspect code, identify suspicious patterns, and reason about possible vulnerability chains. But the value does not come from simply asking a model to find bugs. The value comes from the full cycle around the model: scan, triage, fix, test, release, repeat.

F5’s scanning infrastructure follows a vigorous, multistep process.

Scanning helps surface potential issues across large and complex codebases. Triage helps separate real findings from false positives. Engineering review turns validated findings into fixes. Testing helps to confirm that fixes work and do not introduce regressions. Release planning helps users obtain hardened software in a timely and understandable way.

AI helps accelerate parts of that cycle, but engineering judgment remains essential. Models can propose findings, support analysis, and help reason about exploitability. People still validate, prioritize, fix, test, and decide how to release with care.

For mature infrastructure software like NGINX, that balance matters. NGINX is widely deployed, highly configurable, and used in performance-sensitive environments. A fix cannot be evaluated only in isolation. It has to be tested against realistic usage patterns, product combinations, and deployment models.

The user benefit is straightforward: a more systematic way to find and fix issues, backed by engineering review and testing across the environments where NGINX is used.

Sustained investment matters

This level of work requires sustained investment. It requires access to advanced AI models, dedicated security and engineering capacity, test infrastructure, release discipline, and coordination across open source and commercial software.

That investment is one of the ways F5 supports NGINX. Open source communities are powerful, and NGINX continues to benefit from that model. At the same time, applying AI-driven security analysis across a broad portfolio, validating findings, testing fixes across multiple products, and preparing clear releases takes people, tooling, process, and time.

For users, that matters because security is not a one-time event. It is a continuous practice. The value is not only in finding a defect, but also in building a system that keeps finding, fixing, testing, and releasing improvements over time.

We also know that updates create work for users. More hardened releases mean more updates to evaluate, test, and deploy. We are mindful of that. Our goal is to improve security while making the process as clear and predictable as possible.

Help us make the Internet safer

The Internet depends on shared infrastructure. NGINX is part of that infrastructure, and its security is a shared commitment.

F5 will continue investing in AI-driven security practices, coordinated release processes, and testing across the NGINX portfolio. We will also continue learning as AI changes what is possible in software security.

We are asking the community to help in two important ways.

First, if you believe you have found a security issue in NGINX, work with us before making details public. Share enough detail for us to reproduce and understand the issue. Give maintainers time to validate, fix, test, and release updates that help protect users. You can report a vulnerability through our security reporting process here or here.

Second, keep your infrastructure current. Finding and fixing issues is only part of the security lifecycle. Those fixes protect users only when they are deployed. We know patching critical infrastructure can be difficult, especially in complex environments with many dependencies, change windows, and validation requirements. That is why organizations should look for ways to make patching a normal part of their operating lifecycle, including automation wherever possible.

The AI era changes the pace of software security, but it does not change the goal. We all want safer software, more resilient infrastructure, and a more secure Internet.

The best way to get there is together.

To learn more, read our previous blog post, “Securing our code with frontier AI: What F5 built and learned.”

About the Author

Jay BhalodSenior Director, Engineering | F5

More blogs by Jay Bhalod