Devel is in the Details: Why Golang Versioning Gaps Cause Scanners to Miss IngressNightmare

When it comes to vulnerability management, the devil (or devel) is in the details. Golang has a long-standing issue that causes version information to be missing from the main module associated with binaries depending on how they are built and deployed. This seemingly small problem can result in vulnerability scanners missing critical issues, leading to false negatives in vulnerability scanning, one of the most dangerous failure modes in modern Kubernetes environments.

In this post, we will:

• Explain the Golang build issue
• Connect it to the recent IngressNightmare vulnerability (CVE-2025-1974)
• Show real-world scanner misses
• Recommend actions you should take
• Show how Averlon helps identify such blind spots

TL;DR

• The main module associated with Go binaries may be missing version info due the deployment using ‘go build’ without the ldflags.
• This can cause critical vulnerabilities like IngressNightmare to go undetected by many vulnerability scanners.
• Until the industry fully adopts Go 1.24.1+ and rebuilds affected images, these blind spots will persist.
• Averlon helps detect vulnerable images even when scanners fail due to missing version metadata.

Golang’s Build Limitation: Missing Main Module Versions

When you run ‘go build’, the resulting binary often lacks main module version information, leaving it marked as (devel).

Compare the two methods below:

go build Output

go build
go version -m ./hello | grep mod.*
mod     mgk.ro/hello   (devel)

go install Output (Version Recorded)

go install robpike.io/ivy@latest
go version -m $(which ivy) | grep mod.*
mod     robpike.io/ivy   v0.1.124

This is the root cause:

• go build → version info missing
• go install → version info present

This issue has been raised in the official Golang issue tracker and, while some progress is planned in Go 1.24.1+, the problem persists for older builds.

Why This Matters in Practice: IngressNightmare Case Study

About CVE-2025-1974 (Part of IngressNightmare)

CVE-2025-1974 is one of several critical vulnerabilities associated with what is now referred to as the IngressNightmare class of issues affecting the Kubernetes ingress-nginx controller.

One of its most severe impacts:

An unauthenticated attacker with access to the pod network can achieve arbitrary code execution inside the ingress-nginx controller, potentially exposing all cluster-wide secrets.

For full details, see: 

• The official Kubernetes GitHub advisory 
• The NVD entry for CVE-2025-1974

Affected Versions:

• < v1.11.0
• v1.11.0 - v1.11.4
• v1.12.0

Fixed Versions:

• V1.11.5
• V1.12.1
• v1.13.x and above

What Do Scanners Actually Use?

Most vulnerability scanners correlate vulnerabilities by pulling version data from registries like:

• Kubernetes Vulnerability Feed
• OSV.dev Kubernetes Advisory Database

For example, the JSON entry for IngressNightmare looks like:

CVSS Rating: ([CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)) (Score: 9.8, Critical)

A security issue was discovered in Kubernetes where under certain conditions, an unauthenticated attacker with access to the pod network can achieve arbitrary code execution in the context of the ingress-nginx controller. This can lead to disclosure of Secrets accessible to the controller.

(Note that in the default installation, the controller can access all Secrets cluster-wide.)

### Am I vulnerable?

This issue affects ingress-nginx. If you do not have ingress-nginx installed on your cluster, you are not affected.

You can check this by running:
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

### Affected Versions
- v1.11.0  
- v1.11.0 – v1.11.4  
- v1.12.0

Scanners match this against the version info inside the binary. But if the version is missing ((devel)), they cannot confirm the vulnerability.

Real-World Example — Missing Detection for IngressNightmare

Suppose you run:

registry.k8s.io/ingress-nginx/controller:v1.10.0

Inspecting the binary shows:

go version -m nginx-ingress-controller
path    k8s.io/ingress-nginx/cmd/nginx
mod     k8s.io/ingress-nginx   (devel)

Without version info, vulnerability scanners will likely miss CVE-2025-1974 entirely.

Scanner Behavior Comparison

OSV-Scanner

osv-scanner scan image --serve registry.k8s.io/ingress-nginx/controller:v1.10.0@sha256:42b3f0e5d0846876b1791cd3afeb5f1cbbe4259d6f35651dcc1b5c980925379c

Trivy

trivy image --scanners=vuln --format json registry.k8s.io/ingress-nginx/controller:v1.10.0@sha256:42b3f0e5d0846876b1791cd3afeb5f1cbbe4259d6f35651dcc1b5c980925379c | jq '.Results[].Vulnerabilities[] | select(.VulnerabilityID=="CVE-2025-1974")'

Docker Scout

docker scout cves --only-cve-id CVE-2025-1974 registry.k8s.io/ingress-nginx/controller:v1.10.0

The Risk of False Negatives in Vulnerability Scanners

Unlike common false positives, this creates a dangerous false negative.

You might believe you’re safe, but you’re running a vulnerable version without knowing it.

This problem affects:

• Any Golang binary built and deployed via go build
• All Kubernetes components packaged this way (e.g., ingress controllers, custom controllers)

Go 1.24.1+ may help if and when everyone upgrades their build pipelines — but older images (and old scanner assumptions) will continue to cause problems.

What Should You Do?

Go-based tools and services with improperly built binaries can create a class of blind spots — where vulnerabilities may be missed entirely by scanners. IngressNightmare (CVE-2025-1974) is just one such example.

Here’s how you can evaluate your exposure — whether you’re using third-party software or building your own.

For Users of Vulnerability Scanners and Container Security Tools

• Cross-check scanner results: Don’t rely solely on binary scanners. Validate actual versions through deployment manifests, Helm charts, or other configuration sources.
• Check SBOMs for missing metadata: If your SBOM shows main module: (devel) or lacks version info, it’s a signal the binary was built without proper provenance — and that scanners might miss associated CVEs.
• Evaluate your scanner’s behavior: Try scanning known vulnerable images (e.g., older versions of ingress-nginx). If your scanner doesn’t flag them, it may be affected by this broader metadata gap. Talk to your vendor.

For Developers Building Go-Based Container Images

• Audit your container images: Use go version -m <binary> to inspect what version metadata is present — and whether the main module appears as (devel).
• Build and deploy with version metadata:

go install <module>@<version>

or

go build -ldflags="-X main.version=<version>"

• Track Golang toolchain improvements: Golang 1.24.1+ includes efforts to improve metadata tracking in builds. Future versions may address this natively — but you’ll still need to align your build process.

How Averlon Helps

Averlon detects vulnerable versions — even if the scanner misses them — by:

• Tracking image tags, digests, and image metadata directly from the runtime.
• Not relying solely on binary introspection.
• Giving you full visibility into system pods and application workloads.
• Alerting you when you’re running known vulnerable images.

Related Resources

• IngressNightmare Explained
• Kubernetes Resource Exhaustion: How to Secure Your Clusters
• Averlon Platform Overview

_{Credits: Hayk Baluyan (co-author), Matthias Luft (research), Rajeev Raghunarayan (editor).}