I started working on a bash script called exploit-check.sh some time ago. The script does a bunch of odd jobs, but one specific task is to query a known vulnerability (CVE ID) to get a description of the vulnerability and more importantly tie it back to a bunch of vulnerability intelligence sources.
We want to be able to understand:
- The CVSS score from NVD, which tells us on a scale of 1-10 how bad the vulnerability is.
- The EPSS score from FIRST, which tells us on a scale of 0-100% the likelihood of exploitation.
- CISA's KEV database lets us know if the specific CVE ID is known to be exploited in the wild.
- The OSV API lets us know is the CVE ID is mapped to a specific software dependency sourced from public, open-source registries like npm, PyPI and Maven Central.
- Finally, we'll see if there's a weaponised exploited script crafted for the specific CVE ID. This is achieved via the ExploitDB database.
A simple one-line command looks like this:
./exploit-check.sh query CVE-2016-5195 --package-info
Connecting the dots with EU CRA
The European Union's Cyber Resilience Act (CRA) mandates that products with digital elements are designed securely and prohibits selling products with known, unpatched vulnerabilities. Manufacturers must report actively exploited vulnerabilities (where malicious actors use these known flaws without permission) to ENISA and national authorities, ensuring prompt patching and transparency throughout the product lifecycle.
Key aspects of "known exploits" under the CRA can be seen under Article 3(42). This sub-section defines an actively exploited vulnerability as one with reliable evidence of unauthorised malicious exploitation. Examples include weak authentication/identification and malware introduced into release channels. So, from a reporting obligation perspective, software developers (manufacturers) must report these exploited vulnerabilities, or known malicious software dependencies, immediately, along with providing security updates for the expected lifetime of the product. If a product is sold with known, unpatched vulnerabilities, manufacturers and distributors face significant liability.
The act will be fully in force by December 11, 2027, with specific reporting requirements beginning by September this year.
Investigating Malware
By this point I haven't really explored malicious packages (malware in known software dependencies). As we mentioned in the CRA section, we cannot ship exploited vulnerabilities, but also we cannot ship malicious code to our customers. The malicious packages goes beyond CVE IDs. In this scenario we map MAL IDs with the CVEs. A perfect example is the below lookup of a npm package called backslash using the exploit-check.sh script:
./exploit-check.sh pkg npm backslash --follow-cves
./exploit-check.sh query MAL-2025-46968
Continuous Monitoring for EU CRA
As of September 11th this year, Article 14 of the CRA (the reporting requirements) goes live. In this scenario, you must report actively exploited vulnerabilities in your product. And the only way to know if a software dependency is actively exploited, or even exploitable, is through these threat intelligence sources. Article 13(7) specifically calls for systematic documentation of vulnerabilities using third-party intelligence. In a few months, you'll need to actively answer the questions:
- Is this vulnerable?
- Is it exploitable in your product?
- Is it being actively exploited right now?
The EPSS data source can answer the realistic exploitation under practical operational conditions, or at least prioritise the likelihood of a CVE being exploited, regardless of the point-in-time CVSS score. CISA's KEV database will tell us that a CVE is definitely known to have been exploited in the real world, increasing the likelihood of an CVE getting exploited in your environment. ExploitDB raises the stakes as it shows you the weaponised exploit scripts used to exploit a known vulnerability. While all of this threat-informed intelligence is certainly valuable for CRA reporting requirements, only Vulnerability Exploitability eXchange (VEX) will truly convey the exploitability of vulnerable components in the context of the specific product in which they're used. As in, the CVE can be exploited, but not in this product.
ExploitPwned
As some of your may already know, I love writing my own tools for specific tasks. One of these simple tools is shell script called ExploitPwned. The purpose of this script was simple - to first of all see if a CVE is correctly mapped to a known exploitation script in in ExploitDB - and if not - can I find a PoC of the exploit in Github (which is also a credible example of weaponised exploits, even if a lot of these PoCs don't actually work as intended).
Ingress-NGINX Exploits
To prioritise the safety and security of the ecosystem, the Kubernetes SIG Network and the Security Response Committee announcement the retirement of Ingress NGINX in Kubernetes. Best-effort maintenance continued until March 2026. After that, there were no further releases, no bugfixes, and no updates to resolve any security vulnerabilities that may be discovered. Existing deployments of Ingress NGINX will obviously continue to function up to a point (can't install in Kubernetes 1.36 and higher), so the installation artifacts still remain available in Github, but ultimately we won't be seeing patches to those vulnerabilities.
In that time, a bunch of CVEs were discovered, and naturally, adversaries found creative ways to exploit those vulnerabilities knowing that Ingress Nginx will remain in a large percentage of global Kubernetes clusters, with no fix coming to the project.
./exploitPwned.sh CVE-2025-24514 --details
./exploitPwned.sh CVE-2025-1974 --details
./exploitPwned.sh CVE-2025-1098 --details
./exploitPwned.sh CVE-2025-1097 --details
You'll probably notice a few things from that screenshot that should be alarming. We can see that there is an existing weaponised exploit script (52475), but the CVE is not added to the CISA KEV database - proof that we cannot solely rely on what is in the KEV database to understand the impact of exploited vulnerabilities in software dependencies and open-source projects. While Beatriz did the correct/ethical thing to publish the exploit on ExploitDB, we could find at least 5 PoCs of that exact CVE ID, and in one case the repository had 249 stars (which means its quite popular amongst hackers).
Chainguard saves the day
In the case of the exploitable Ingress-Nginx flaws that we know to be unpatched, the issue can be solved through Chainguard Images. But what the heck is Chainguard? Chainguard provides commercial ingress-nginx container images for users who require low CVE images with SLAs or FIPS versions.
According to a blog post from Adrian Mouat, Chainguard will keep the project moving forward and up-to-date with fresh versions of libraries. If CVEs are identified, they will address them on a best-efforts basis. This does not address the issue of Ingress-Nginx being retired, but it allows organisations to continue using the project safely during this transition period.
We need to be clear that we are not continuing the development of
ingress-nginx. We are maintaining a working version based on the
latest release. This support is intended to help buy users time to
move to a different solution. We’re giving users time to evaluate
options and develop migration strategies without risking the security
of their clusters.
Closing Statement
This blog was really just a way of showing how we can think about these different open-source data sources, how they are necessary for meeting upcoming regulatory requirement hurdles, but also how they apply to real-life vulnerabilities such as Ingress-Nginx. Organisations need to seriously understand what is running within their software supply chain, traditionally achieved via SBOM generation, but then need to enrich this data with threat intelligence. Is it likely to be exploited, do we know if it's "actually" being exploited in the wild, and more importantly, are these open-source libraries, dependencies and projects being maintained from a security standpoint? In the case of Ingress-Nginx, if you cannot adopt hardened images, you need to migrate away from this project as soon as possible. This is a baseline requirement under the EU CRA.
