Vulnerabilities in ingress-nginx controller v1.12.2

Question

I was tasked with using ingress-nginx controller v1.12.2 on a Kubernetes Cluster for my org. I scanned it for vulnerabilities with Trivy (github action), and got this report -

 ┌──────────────────────────────────────────────────┬──────────┬─────────────────┬─────────┐ │ Target │ Type │ Vulnerabilities │ Secrets │ ├──────────────────────────────────────────────────┼──────────┼─────────────────┼─────────┤ │ ingress-nginx/controller:v1.12.2 (alpine 3.21.3) │ alpine │ 2 │ - │ ├──────────────────────────────────────────────────┼──────────┼─────────────────┼─────────┤ │ dbg │ gobinary │ 3 │ - │ ├──────────────────────────────────────────────────┼──────────┼─────────────────┼─────────┤ │ nginx-ingress-controller │ gobinary │ 3 │ - │ ├──────────────────────────────────────────────────┼──────────┼─────────────────┼─────────┤ │ wait-shutdown │ gobinary │ 3 │ - │ └──────────────────────────────────────────────────┴──────────┴─────────────────┴─────────┘ Legend: - '-': Not scanned - '0': Clean (no security findings detected) For OSS Maintainers: VEX Notice -------------------------------- If you're an OSS maintainer and Trivy has detected vulnerabilities in your project that you believe are not actually exploitable, consider issuing a VEX (Vulnerability Exploitability eXchange) statement. VEX allows you to communicate the actual status of vulnerabilities in your project, improving security transparency and reducing false positives for your users. Learn more and start using VEX: https://trivy.dev/v0.63/docs/supply-chain/vex/repo#publishing-vex-documents To disable this notice, set the TRIVY_DISABLE_VEX_NOTICE environment variable. ingress-nginx/controller:v1.12.2 (alpine 3.21.3) ================================================ Total: 2 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 2, CRITICAL: 0) ┌─────────┬────────────────┬──────────┬────────┬───────────────────┬───────────────┬───────────────────────────────────────────────────────────┐ │ Library │ Vulnerability │ Severity │ Status │ Installed Version │ Fixed Version │ Title │ ├─────────┼────────────────┼──────────┼────────┼───────────────────┼───────────────┼───────────────────────────────────────────────────────────┤ │ libxml2 │ CVE-2025-32414 │ HIGH │ fixed │ 2.13.4-r5 │ 2.13.4-r6 │ libxml2: Out-of-Bounds Read in libxml2 │ │ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2025-32414 │ │ ├────────────────┤ │ │ │ ├───────────────────────────────────────────────────────────┤ │ │ CVE-2025-32415 │ │ │ │ │ libxml2: Out-of-bounds Read in xmlSchemaIDCFillNodeTables │ │ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2025-32415 │ └─────────┴────────────────┴──────────┴────────┴───────────────────┴───────────────┴───────────────────────────────────────────────────────────┘ dbg (gobinary) ============== Total: 3 (UNKNOWN: 0, LOW: 0, MEDIUM: 2, HIGH: 1, CRITICAL: 0) ┌─────────┬────────────────┬──────────┬────────┬───────────────────┬─────────────────┬──────────────────────────────────────────────────────────────┐ │ Library │ Vulnerability │ Severity │ Status │ Installed Version │ Fixed Version │ Title │ ├─────────┼────────────────┼──────────┼────────┼───────────────────┼─────────────────┼──────────────────────────────────────────────────────────────┤ │ stdlib │ CVE-2025-22874 │ HIGH │ fixed │ v1.24.2 │ 1.24.4 │ crypto/x509: Usage of ExtKeyUsageAny disables policy │ │ │ │ │ │ │ │ validation in crypto/x509 │ │ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2025-22874 │ │ ├────────────────┼──────────┤ │ ├─────────────────┼──────────────────────────────────────────────────────────────┤ │ │ CVE-2025-0913 │ MEDIUM │ │ │ 1.23.10, 1.24.4 │ Inconsistent handling of O_CREATE|O_EXCL on Unix and Windows │ │ │ │ │ │ │ │ in os in syscall... │ │ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2025-0913 │ │ ├────────────────┤ │ │ │ ├──────────────────────────────────────────────────────────────┤ │ │ CVE-2025-4673 │ │ │ │ │ net/http: Sensitive headers not cleared on cross-origin │ │ │ │ │ │ │ │ redirect in net/http │ │ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2025-4673 │ └─────────┴────────────────┴──────────┴────────┴───────────────────┴─────────────────┴──────────────────────────────────────────────────────────────┘ nginx-ingress-controller (gobinary) =================================== Total: 3 (UNKNOWN: 0, LOW: 0, MEDIUM: 2, HIGH: 1, CRITICAL: 0) ┌─────────┬────────────────┬──────────┬────────┬───────────────────┬─────────────────┬──────────────────────────────────────────────────────────────┐ │ Library │ Vulnerability │ Severity │ Status │ Installed Version │ Fixed Version │ Title │ ├─────────┼────────────────┼──────────┼────────┼───────────────────┼─────────────────┼──────────────────────────────────────────────────────────────┤ │ stdlib │ CVE-2025-22874 │ HIGH │ fixed │ v1.24.2 │ 1.24.4 │ crypto/x509: Usage of ExtKeyUsageAny disables policy │ │ │ │ │ │ │ │ validation in crypto/x509 │ │ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2025-22874 │ │ ├────────────────┼──────────┤ │ ├─────────────────┼──────────────────────────────────────────────────────────────┤ │ │ CVE-2025-0913 │ MEDIUM │ │ │ 1.23.10, 1.24.4 │ Inconsistent handling of O_CREATE|O_EXCL on Unix and Windows │ │ │ │ │ │ │ │ in os in syscall... │ │ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2025-0913 │ │ ├────────────────┤ │ │ │ ├──────────────────────────────────────────────────────────────┤ │ │ CVE-2025-4673 │ │ │ │ │ net/http: Sensitive headers not cleared on cross-origin │ │ │ │ │ │ │ │ redirect in net/http │ │ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2025-4673 │ └─────────┴────────────────┴──────────┴────────┴───────────────────┴─────────────────┴──────────────────────────────────────────────────────────────┘ wait-shutdown (gobinary) ======================== Total: 3 (UNKNOWN: 0, LOW: 0, MEDIUM: 2, HIGH: 1, CRITICAL: 0) ┌─────────┬────────────────┬──────────┬────────┬───────────────────┬─────────────────┬──────────────────────────────────────────────────────────────┐ │ Library │ Vulnerability │ Severity │ Status │ Installed Version │ Fixed Version │ Title │ ├─────────┼────────────────┼──────────┼────────┼───────────────────┼─────────────────┼──────────────────────────────────────────────────────────────┤ │ stdlib │ CVE-2025-22874 │ HIGH │ fixed │ v1.24.2 │ 1.24.4 │ crypto/x509: Usage of ExtKeyUsageAny disables policy │ │ │ │ │ │ │ │ validation in crypto/x509 │ │ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2025-22874 │ │ ├────────────────┼──────────┤ │ ├─────────────────┼──────────────────────────────────────────────────────────────┤ │ │ CVE-2025-0913 │ MEDIUM │ │ │ 1.23.10, 1.24.4 │ Inconsistent handling of O_CREATE|O_EXCL on Unix and Windows │ │ │ │ │ │ │ │ in os in syscall... │ │ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2025-0913 │ │ ├────────────────┤ │ │ │ ├──────────────────────────────────────────────────────────────┤ │ │ CVE-2025-4673 │ │ │ │ │ net/http: Sensitive headers not cleared on cross-origin │ │ │ │ │ │ │ │ redirect in net/http │ │ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2025-4673 │ └─────────┴────────────────┴──────────┴────────┴───────────────────┴─────────────────┴──────────────────────────────────────────────────────────────┘ 

Afterwards, I tried updating the libxml2 package in the image, but it seems like I am working with an immutable image.

I have tried using a Dockerfile (copying a patched-up version of the package from a 'patcher' image.)

Anybody has any suggestions on how I may be able to mitigate this issue? Thanks in Advance!

Answer 1

Upgrade your ingress to the latest in a test environment, and see what the vulnerability scanner thinks of that. Later upgrade production.

The image in the deployment template needs to be changed to take effect. If not, the old v1.12.2 will keep getting used for new containers. Also, vulnerability scanners may be checking version numbers; upgrading the apk package may silence it but copying in fixed library files might not. apk because this is based on alpine distro.

Impact of the vulnerabilities to your use varies a lot and can be difficult to determine. Even though your choice of scanner is capable of filtering using vulnerability exploitability metadata, someone has to do the analysis and write it.

For example from your list, CVE-2025-32414 is in libxml2 but only the Python bindings. I doubt there is a python installed in this image. And a container nobody has a shell to is a restrictive environment, would be difficult to add one to a running pod.

Regarding the reports about gobinary programs, CVE-2025-22874 is a cryptography thing given the crypto/x509 subsystem. I doubt all 3 of those binaries are using cryptography at all, let alone this specific thing.

Consider your organization's tolerance for risk and how severely the issues could impact this application. If a known exploit in a feature you use (kubernetes ingress) is in the wild, that justifies faster, more aggressive action than some little used code. The categories of intervention as I see it go like this, easiest first:

• Upgrade software via the usual repositories. Regularly in batches, and be able to rush in select patches for urgent fixes.
• Do your own rebuilds to pick up fixed versions of subcomponents. In the libxml2 case, the latest version in alpine 3.21 is fixed, as long as the version is not locked rebuilding the container image would pick up a fix.
• Implement any mitigations to avoid the problem.
• Write your own security patches, such as backporting fix code and rebuilding. In this report, all have released upstream fixes, so this would be unnecessary duplication of effort.