Vulnerability in mysql-connector-j should be reported but is not

[DominicTulley]

I have a project which uses mysql-connector-j at version 9.1.0.
I recently discovered that this has a vulnerability CVE-2025-30706 but my dependency track instance did not flag it.

I've done a bit of digging and can confirm

• The vulnerability is present in the list presented in the DT ui - fetched from NVD
• The mysql-connector-j component is correctly detected, reported as version 9.1.0 and forms part of the dependency tree from the root of the project.
• The vulnerability is not suppressed (I started a clean DT instance using the latest version 4.14.3 and did not add any suppressions)

The CPE for the vulnerability is cpe:2.3:a:oracle:mysql_connectors:*:*:*:*:*:*:*:* (>=9.0.0|<=9.2.0) which appears to correctly correlate with the component pkg:maven/com.mysql/mysql-connector-j@9.1.0?type=jar.

I've had plenty of other vulnerabilities reported since starting to use DT, so it's not that the whole system is wrongly configured (although I accept there may be something that's not right about the configuration).

Any suggestions on remedying this (if it's likely to be an issue my end) would be appreciated.

[dev-rehaann]

9.1.0 is in the affected 9.0.0–9.2.0 range, but the two identifiers do not automatically correlate in Dependency-Track.

The important detail is that the NVD record identifies the product with a CPE (oracle:mysql_connectors), while your component is identified with a Maven PURL. Dependency-Track's NVD matching requires the component itself to have a valid CPE; it does not infer an arbitrary CPE from a PURL. The project FAQ explicitly calls out that there is no PURL-to-CPE/CVE mapping in the local NVD mirror.

I would check the component's CPE field, not only its PURL. If it is empty, a reproducible remedy is to have the SBOM generator emit a CPE for this component (for example the Oracle mysql_connectors product at version 9.1.0, after confirming that identity is appropriate), upload the updated BOM, and trigger project analysis again. PURL-based sources such as OSS Index/OSV can also match Maven coordinates, but only if that source publishes this advisory with the corresponding PURL.

This appears to be an identifier-domain mismatch rather than suppression or dependency-tree configuration. NVD confirms that 9.0.0 through 9.2.0 are affected: CVE-2025-30706. Dependency-Track documents the matching behavior here: Known Vulnerability Analysis and FAQ.

[DominicTulley]

Thank you for the detailed response. I think you've hit the nail on the head here. The component only has a PURL and not a CPE, exactly as you guessed, so there is no way to correlate it with the vulnerability.
I was quite unclear on the relationship between PURL and CPE but it makes more sense now, although it seems like a tricky issue to resolve well. I'm using cdxgen for bom generation and my initial reading says they deliberately don't generate CPEs.
Either way, I know what the problem is and can move forward with some sort of solution.

[dev-rehaann]

You’re welcome, and thank you for confirming the missing CPE. That explains the behavior.

cdxgen’s decision not to generate CPEs is understandable because PURL-to-CPE mapping is often ambiguous. For this component, the practical options are to enrich the SBOM with the verified Oracle CPE before uploading it, or use a PURL-aware vulnerability source that publishes this advisory against the Maven coordinates.

I would avoid generating CPEs automatically for every component, since an incorrect CPE can create false matches. A small, reviewed override for known components such as mysql-connector-j is safer.

Glad we were able to isolate the cause.