Hey There,
i have the following sbom: GitHub - henrysachs/grype-issues and it should match the CVE stated above, but it doesnt. So I searched the grype db via:
grype db search --vuln CVE-2025-24813
and it returned the packages that i thought would match
VULNERABILITY PACKAGE ECOSYSTEM NAMESPACE VERSION CONSTRAINT
CVE-2025-24813 cpe:2.3:a:apache:tomcat-catalina:::::maven:* maven nvd:cpe >= 11.0.0-M1, < 11.0.3 || >= 10.1.0-M1, < 10.1.35 || >= 9.0.0.M1, < 9.0.99
CVE-2025-24813 cpe:2.3:a:apache:tomcat-embed-core:::::maven:* maven nvd:cpe >= 11.0.0-M1, < 11.0.3 || >= 10.1.0-M1, < 10.1.35 || >= 9.0.0.M1, < 9.0.99
CVE-2025-24813 cpe:2.3:a:apache:tomcat:::::maven:* maven nvd:cpe >= 11.0.0-M1, < 11.0.3 || >= 10.1.0-M1, < 10.1.35 || >= 9.0.0.M1, < 9.0.99
CVE-2025-24813 cpe:2.3:a:org.apache.tomcat.embed:tomcat-embed-core:::::maven:* maven nvd:cpe >= 11.0.0-M1, < 11.0.3 || >= 10.1.0-M1, < 10.1.35 || >= 9.0.0.M1, < 9.0.99
CVE-2025-24813 cpe:2.3:a:org.apache.tomcat:tomcat-catalina:::::maven:* maven nvd:cpe >= 11.0.0-M1, < 11.0.3 || >= 10.1.0-M1, < 10.1.35 || >= 9.0.0.M1, < 9.0.99
CVE-2025-24813 pki-servlet-engine rpm redhat:distro:redhat:8
CVE-2025-24813 pki-servlet-engine rpm redhat:distro:redhat:9
CVE-2025-24813 tomcat rpm redhat:distro:redhat:8
CVE-2025-24813 tomcat rpm redhat:distro:redhat:9
CVE-2025-24813 tomcat10 deb debian:distro:debian:12
CVE-2025-24813 tomcat10 deb debian:distro:debian:13 < 10.1.35-1
CVE-2025-24813 tomcat10 deb debian:distro:debian:unstable < 10.1.35-1
CVE-2025-24813 tomcat10 deb ubuntu:distro:ubuntu:24.04
CVE-2025-24813 tomcat10 deb ubuntu:distro:ubuntu:24.10
CVE-2025-24813 tomcat6 rpm redhat:distro:redhat:6
CVE-2025-24813 tomcat9 deb debian:distro:debian:11
CVE-2025-24813 tomcat9 deb debian:distro:debian:12 < 9.0.70-2
CVE-2025-24813 tomcat9 deb debian:distro:debian:13 < 9.0.70-2
CVE-2025-24813 tomcat9 deb debian:distro:debian:unstable < 9.0.70-2
CVE-2025-24813 tomcat9 deb ubuntu:distro:ubuntu:20.04
CVE-2025-24813 tomcat9 deb ubuntu:distro:ubuntu:22.04
CVE-2025-24813 tomcat9 deb ubuntu:distro:ubuntu:24.04
CVE-2025-24813 tomcat9 deb ubuntu:distro:ubuntu:24.10
So why doesnt grype match this? I also checked with trace logging but grype isnt matching this cve for this package.
I had to obfuscate the sbom a bit but hope its still usable for you guys
Apache Tomcat: Potential RCE and/or information disclosure and/or information corruption with partial PUT ¡ CVE-2025-24813 ¡ GitHub Advisory Database ¡ GitHub tomcat-embed-core needs to be added to this GHSA, then it will. We have discussed this with GitHub several times in the past that they need to include tomcat-embed-core when they add other tomcat components, but I think one of their longtime advisory database maintainers recently left so may be a gap
1 Like
What you are seeing from grype db search are the cpe-based matches from NVD and those will currently never match by default since weâve disabled CPE matching for ecosystems covered by github due to the horrible quality of data and immense numbers of FPs. In future weâll be able to make use of our enriched dataset for package matches (based on essentially purl), but that will likely be a few months still before we have the resources to work on that
1 Like
Hey thanks for updating the data and claryfying why this doesnt match. Can you tell me more about this new data source youâre talking about or if I can read something more about this?
Also how did you manage to get your PR merged without a review? Or am I missing something? 
So if Iâm interested in getting these findings would it be possible to have like a âfake sbomâ with the real tomcat in it? How could something look like?
After NVD collapsed for a bit last year, we began maintaining some of our own enriched data records to fill the gap at GitHub - anchore/cve-data-enrichment. I donât love the format of these yet, but it was the best I could do in the short window of time available. Currently, we are only able to make use of these in vunnel and grype via the old NVD provider which expects as input NVD json format, so from the enriched dataset we generate NVD override data off of the Anchore enriched records at GitHub - anchore/nvd-data-overrides, which vunnel eventually consumes. The issue with that is that we are currently limited to only CPEs as the identifier, but we have been adding more precise identifiers (packageType and packageName) to our records which would be preferable to use over the CPEs. We plan to replace the old nvd provider in vunnel with a new provider that pulls from a combination of NVD, our enriched dataset, and the upstream CVE5 data and creates the most precise entries it can based on the available information. This would allow for instance https://raw.githubusercontent.com/anchore/cve-data-enrichment/a8e0d1fa958dae7382cf342b2ca88516ce1e8173/data/anchore/2024/CVE-2024-21690.json which would allow us to better match against java packages with maven compatible metadata but that arenât in maven central and GitHub currently wonât accept enhancements for. Getting the grype db v6 schema released was a prerequisite for being able to do this work, so now that it has been completed I should (hopefully) get some time in the upcoming months to start looking into this again
1 Like
As for the PR, it was merged by the GitHub Advisory data team. They donât follow a normal contribution process where PRs are approved and then merged because I think the true source of their database is not the github repo but rather some private database that they then reconcile the repo with, but I donât know the specifics of that. I assume the approval happens via an external process after which the advisory-bot âmergesâ it into whatever abomination it is they have created
1 Like
this sounds quite promising and the goal would be to match on PURLs instead of CPEs am i right? How would you construct a purl from this data?
thanks for the insight and the slight hit in the direction of the GHSA database. I had a good laugh
To be very clear, I also refer to our processes as an abomination, and I am very happy that Micosoft continue to fund the work the GitHub Advisory database folks are doing and hope it continues well into the future.
The hope would be to move to package-based matching in future for as many things as possible yes. Not purl specifically, but compatible with purl. With grype db v6 we have a concept of aliases which can allow consistent lookups to occur even if different datasources use different names for referring to a particular package type for instance. So for the grype db storage itself, we align around the syft package types that we have defined, but we can still lookup by the purl type where those differ from our names, and can be expanded with future mappings as well.
The reason we donât specifically align around purl internally is because we are wanting to identify things outside of the purl spec (and that is a very, very slow moving specification). Things like java vm flavours, etc. And weâll probably get some of them wrong and have to refine and define more alias mappings later down the line, but that is okay
1 Like
Have you seen that it is already possible to pass a purl directly into grype and get match results? For instance, something like
grype 'pkg:maven/org.apache.tomcat.embed/tomcat-embed-core@1.2.3'
â Scanned for vulnerabilities [3 vulnerability matches]
âââ by severity: 0 critical, 2 high, 1 medium, 0 low, 0 negligible
âââ by status: 3 fixed, 0 not-fixed, 0 ignored
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
tomcat-embed-core 1.2.3 7.0.99 java-archive GHSA-9xcj-c8cr-8c3c High
tomcat-embed-core 1.2.3 7.0.99 java-archive GHSA-hh3j-x4mc-g48r High
tomcat-embed-core 1.2.3 7.0.100 java-archive GHSA-qxf4-chvg-4r8r Medium
sound great! I didnt knew about the feature, but if thats possible why isnt grype doing this internally already? as my sbom had a purl
It is, there wasnât a package-based vulnerability record to match to until the GitHub record was updated with the additional package name
pkg:maven/org.apache.tomcat.embed/tomcat-embed-core@10.1.34 didnât match anything previously because org.apache.tomcat.embed:tomcat-embed-core wasnât on the GitHub Advisory record, so there was no match available for that purl