ingress-nginx Security Update

The Forkline-maintained ingress-nginx fork is moving from NGINX 1.27.1 to NGINX 1.30.1.

This is a security maintenance release. It is not a feature release, and it is not a new direction for ingress-nginx. The purpose is narrower and more practical: keep the retired Kubernetes ingress-nginx controller usable for existing operators while covering current CVEs in the NGINX layer it embeds.

The release version is 2026.5.14.

Why this release matters

The immediate reason is CVE-2026-42945, a heap buffer overflow in ngx_http_rewrite_module.

NGINX lists affected open source versions as 0.6.27-1.30.0, with 1.30.1+ and 1.31.0+ marked as not vulnerable in the NGINX security advisories. The NVD entry reports an F5 CNA CVSS 3.1 score of 8.1 HIGH.

For ingress controllers, the rewrite module deserves attention. ingress-nginx commonly generates rewrite-related NGINX configuration from paths, annotations, redirects, snippets, and internal routing glue. Even when exploitability depends on exact configuration and request shape, this is not a module most ingress-nginx users can confidently dismiss as unused.

That is why we are treating this as upgrade-worthy now.

What changed

This release updates the embedded NGINX baseline:

• Previous NGINX version: 1.27.1
• New NGINX version: 1.30.1
• Forkline ingress-nginx version: 2026.5.14

The NGINX bump also moves the fork past the fixed-version boundary for the current advisory batch listed by NGINX, including the rewrite-module issue and other module-gated vulnerabilities such as SCGI/uWSGI overreads, charset overreads, HTTP/3 address spoofing, and OCSP resolver handling.

Not every advisory is equally relevant to a normal Kubernetes ingress controller. Some depend on modules or configuration that are uncommon in ingress-nginx deployments. The rewrite-module issue is different: rewrite behavior is close enough to the normal ingress path that we do not want to leave operators on 1.27.1.

What this fork is

Forkline ingress-nginx is a maintained fork of the retired Kubernetes ingress-nginx controller.

It is intentionally boring.

Our maintenance policy is:

• no new features
• no behavior changes unless required for security or compatibility
• dependency updates
• CVE fixes
• snapshot tests to make generated configuration changes visible
• review before release, even when automation prepares the update

That last point matters. We use automation heavily, but the fork is not an unattended bot mirror. The goal is to make repeated maintenance work safer and faster while keeping release decisions reviewable.

Why date-based versions

The fork uses date-based versions such as 2026.5.14 instead of semantic versions.

Semantic versioning is useful when a project is adding features, changing APIs, and making compatibility promises across minor and major releases. That is not the model here.

For this fork, every release should answer a simpler operator question:

How recently was this ingress-nginx replica maintained?

Date-based versions make that visible. A release named 2026.5.14 tells you this is the May 14, 2026 maintenance state of the fork. It does not imply a new feature surface. It does not imply a breaking change. It means dependencies, images, generated manifests, and security fixes have been carried forward to that date.

That fits the maintenance-mode contract better than pretending each CVE or dependency bump is a new product version.

Switching from Kubernetes ingress-nginx

If you already consume ingress-nginx from the Kubernetes Helm chart repository, switch to the Forkline chart repository and use the maintained date-based release:

• Repository: oci://ghcr.io/forkline/helm-charts
• Version: 2026.5.14

Treat the migration like an ingress-controller upgrade, not like a brand-new ingress product. Review your generated manifests, run it first in a non-production cluster, and pay attention to custom annotations, snippets, admission webhooks, and any controller flags you override.

The fork is designed to preserve the ingress-nginx operating model, but ingress controllers sit on the request path. Test the path your users actually hit.

The bottom line

Upstream ingress-nginx is retired. Existing clusters still need maintenance.

Forkline ingress-nginx exists for teams that are not ready to migrate every ingress workload today but also do not want to keep shipping an unmaintained controller image. This release moves the fork to NGINX 1.30.1, addresses the CVE-2026-42945 exposure window, and keeps the project inside a strict maintenance boundary.

If you run public ingress-nginx today, do not stay on a controller image built with NGINX 1.27.1. Upgrade, test, and keep planning your longer-term Gateway API path.