# Grype doesnt match CVE-2025-24813

**URL:** <https://anchorecommunity.discourse.group/t/grype-doesnt-match-cve-2025-24813/363>\
**Category:** Grype\
**Created:** [March 17, 2025, 2:08pm UTC](https://anchorecommunity.discourse.group/t/grype-doesnt-match-cve-2025-24813/363 "2025-03-17T14:08:38Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![henrysachs](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/henrysachs/32/63_2.png) [@henrysachs](https://anchorecommunity.discourse.group/u/henrysachs)\
**Post date:** [March 17, 2025, 2:08pm UTC](https://anchorecommunity.discourse.group/t/grype-doesnt-match-cve-2025-24813/363/1 "2025-03-17T14:08:38Z")

</div>

Hey There,

i have the following sbom: [GitHub - henrysachs/grype-issues](https://github.com/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

---

<div class="post-metadata">

**Author:** ![westonsteimel](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/westonsteimel/32/470_2.png) [@westonsteimel](https://anchorecommunity.discourse.group/u/westonsteimel)\
**Post date:** [March 17, 2025, 3:48pm UTC](https://anchorecommunity.discourse.group/t/grype-doesnt-match-cve-2025-24813/363/2 "2025-03-17T15:48:44Z")

</div>

[Apache Tomcat: Potential RCE and/or information disclosure and/or information corruption with partial PUT · CVE-2025-24813 · GitHub Advisory Database · GitHub](https://github.com/advisories/GHSA-83qj-6fr2-vhqg) 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

---

<div class="post-metadata">

**Author:** ![westonsteimel](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/westonsteimel/32/470_2.png) [@westonsteimel](https://anchorecommunity.discourse.group/u/westonsteimel)\
**Post date:** [March 17, 2025, 3:51pm UTC](https://anchorecommunity.discourse.group/t/grype-doesnt-match-cve-2025-24813/363/3 "2025-03-17T15:51:38Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![westonsteimel](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/westonsteimel/32/470_2.png) [@westonsteimel](https://anchorecommunity.discourse.group/u/westonsteimel)\
**Post date:** [March 17, 2025, 3:55pm UTC](https://anchorecommunity.discourse.group/t/grype-doesnt-match-cve-2025-24813/363/4 "2025-03-17T15:55:19Z")

</div>

> <https://github.com/github/advisory-database/pull/5373>
>
> \*\*Updates\*\*
> \- Affected products
> 
> \*\*Comments\*\*
> add tomcat-embed-core

---

<div class="post-metadata">

**Author:** ![henrysachs](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/henrysachs/32/63_2.png) [@henrysachs](https://anchorecommunity.discourse.group/u/henrysachs)\
**Post date:** [March 17, 2025, 8:02pm UTC](https://anchorecommunity.discourse.group/t/grype-doesnt-match-cve-2025-24813/363/5 "2025-03-17T20:02:58Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![westonsteimel](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/westonsteimel/32/470_2.png) [@westonsteimel](https://anchorecommunity.discourse.group/u/westonsteimel)\
**Post date:** [March 18, 2025, 11:14am UTC](https://anchorecommunity.discourse.group/t/grype-doesnt-match-cve-2025-24813/363/6 "2025-03-18T11:14:45Z")

</div>

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](https://github.com/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](https://github.com/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](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

---

<div class="post-metadata">

**Author:** ![westonsteimel](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/westonsteimel/32/470_2.png) [@westonsteimel](https://anchorecommunity.discourse.group/u/westonsteimel)\
**Post date:** [March 18, 2025, 11:20am UTC](https://anchorecommunity.discourse.group/t/grype-doesnt-match-cve-2025-24813/363/7 "2025-03-18T11:20:38Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![henrysachs](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/henrysachs/32/63_2.png) [@henrysachs](https://anchorecommunity.discourse.group/u/henrysachs)\
**Post date:** [March 18, 2025, 12:12pm UTC](https://anchorecommunity.discourse.group/t/grype-doesnt-match-cve-2025-24813/363/8 "2025-03-18T12:12:22Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![henrysachs](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/henrysachs/32/63_2.png) [@henrysachs](https://anchorecommunity.discourse.group/u/henrysachs)\
**Post date:** [March 18, 2025, 12:12pm UTC](https://anchorecommunity.discourse.group/t/grype-doesnt-match-cve-2025-24813/363/9 "2025-03-18T12:12:56Z")

</div>

thanks for the insight and the slight hit in the direction of the GHSA database. I had a good laugh

---

<div class="post-metadata">

**Author:** ![westonsteimel](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/westonsteimel/32/470_2.png) [@westonsteimel](https://anchorecommunity.discourse.group/u/westonsteimel)\
**Post date:** [March 18, 2025, 12:32pm UTC](https://anchorecommunity.discourse.group/t/grype-doesnt-match-cve-2025-24813/363/10 "2025-03-18T12:32:58Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![westonsteimel](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/westonsteimel/32/470_2.png) [@westonsteimel](https://anchorecommunity.discourse.group/u/westonsteimel)\
**Post date:** [March 18, 2025, 12:36pm UTC](https://anchorecommunity.discourse.group/t/grype-doesnt-match-cve-2025-24813/363/11 "2025-03-18T12:36:47Z")

</div>

Have you seen that it is already possible to pass a purl directly into grype and get match results? For instance, something like

```auto
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

```

---

<div class="post-metadata">

**Author:** ![henrysachs](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/henrysachs/32/63_2.png) [@henrysachs](https://anchorecommunity.discourse.group/u/henrysachs)\
**Post date:** [March 18, 2025, 12:50pm UTC](https://anchorecommunity.discourse.group/t/grype-doesnt-match-cve-2025-24813/363/12 "2025-03-18T12:50:20Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![westonsteimel](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/westonsteimel/32/470_2.png) [@westonsteimel](https://anchorecommunity.discourse.group/u/westonsteimel)\
**Post date:** [March 18, 2025, 1:27pm UTC](https://anchorecommunity.discourse.group/t/grype-doesnt-match-cve-2025-24813/363/13 "2025-03-18T13:27:37Z")

</div>

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