Announcing NES for Ingress NGINX, resolving CVE-2026-32282

Kubernetes users now have a new option for staying secure after the end of life of Ingress NGINX: Never-Ending Support (NES) for Ingress NGINX from HeroDevs. NES for Ingress NGINX resolves CVE-2026-32282 plus four additional dependency vulnerabilities across gomarkdown and Helm, giving teams a drop-in path to keep Kubernetes ingress infrastructure secure and operational while migration plans move on a realistic timeline.

For organizations that still depend on Ingress NGINX, that matters immediately. Once upstream support ends, every unresolved CVE becomes a security, compliance, and operational problem. HeroDevs exists to solve those exact problems: keeping end of life open source software secure, compliant, and fully operational while engineering teams build what comes next.

‍

Why NES for Ingress NGINX matters now

Ingress controllers sit directly in the request path for production traffic. When an ingress stack reaches end of life, unsupported components can turn into a standing exposure across authentication boundaries, edge routing, and cluster entry points.

NES for Ingress NGINX is designed to be a drop-in replacement for Ingress NGINX 1.5.1. That means enterprise users can continue operating on the same Ingress NGINX while HeroDevs delivers ongoing vulnerability remediation and maintenance coverage.

‍

CVE-2026-32282 and the current CVEs resolved in NES for Ingress NGINX

The current tracked vulnerabilities resolved in NES for Ingress NGINX are:

‍

Technical detail: CVE-2026-32282 in NES for Ingress NGINX

The headline issue in this release line is CVE-2026-32282, a Medium severity vulnerability in the Go standard library with a CVSS score of 6.4. The flaw affects Linux path handling through internal/syscall/unix, where Root.Chmod can be tricked into following a symlink outside the intended root under a time-of-check, time-of-use race condition.

From a defender's perspective, this is the kind of issue that matters because ingress infrastructure often operates in tightly permissioned, automation-heavy environments. Even when the exploit path is narrow, platform teams do not want unsupported ingress components carrying filesystem safety flaws in production.

‍

Additional dependency vulnerabilities resolved

NES for Ingress NGINX resolves four additional dependency vulnerabilities, including two issues in Helm and two in gomarkdown. The Helm issues, both rated High severity, are a path traversal flaw (CVE-2026-35204, CVSS 8.4) that allows arbitrary file writing during plugin version handling, and missing provenance file validation (CVE-2026-35205, CVSS 8.4) which weakens plugin signature verification. The gomarkdown dependency resolutions address a denial of service vulnerability (CVE-2024-4433, Medium, CVSS 5.1) caused by an infinite loop in the paragraph parser, and a separate High severity issue (CVE-2026-40890) where malformed input to the SmartypantsRenderer can trigger an out-of-bounds read and panic.

‍

Who is affected

Teams are affected if they still operate workloads that depend on Ingress NGINX 1.15.1 and cannot immediately complete an ingress migration to a Gateway API-based solution. That includes organizations with:

• Regulated environments that cannot tolerate unsupported edge software
• Kubernetes platforms with long validation cycles
• Production ingress tiers where replacement testing takes weeks or months
• Security programs that need documented remediation, not just best-effort upgrades

If that sounds familiar, NES is the security bridge. HeroDevs provides ongoing support coverage for end of life open source software so teams can stay secure without forcing a rushed platform migration.

‍

Remediation options

For NES customers

NES for Ingress NGINX is the straightforward path. The maintained release line preserves the upstream 1.15 base while delivering vulnerability remediation and continued maintenance coverage. That means customers can adopt a drop-in supported build instead of carrying unsupported ingress exposure in production.

‍

For non-NES users

If you are not using NES, the long-term answer is still migration to a supported ingress path based on Gateway API, such Envoy or Calico. For some teams, that means moving to a newer ingress stack, validating controller behavior in staging, updating deployment and Helm automation, and then rolling out on a controlled schedule. The problem is not that migration is the wrong answer. The problem is that many organizations cannot finish it before risk and compliance deadlines arrive.

That is exactly where NES fits. It buys time without accepting unsupported security exposure.

‍

The HeroDevs mission

HeroDevs does not just ship patched artifacts. The mission is broader: keep critical open source systems secure, compliant, and operational after upstream support ends. That is why NES exists across frameworks, runtimes, and infrastructure components that enterprises still depend on long after community support windows close.

If you want a parallel example of how HeroDevs approaches EOL security events, see Beyond the Patch: Securing Your .NET Ecosystem After CVE-2025-55315.

‍

Taking action

If your organization still depends on Ingress NGINX and the migration path is not immediate, now is the time to put a support bridge in place. NES for Ingress NGINX gives teams a path to stay secure on the 1.15.1 line while they plan the next platform move deliberately, not reactively.