Dependency-Check reports 15 CVEs in spring-core 6.2.19 and spring-security-core 6.5.11, with no fixed release available

[tcheeric]

Found once Dependency-Check could actually complete a scan (see the reactor fix in the PR that references this issue). Recording it rather than acting on it, because there is nothing to upgrade to.

What it reports

spring-core 6.2.19 — 12 CVEs, four at 9.8:

CVE-2026-47884 (9.8)  CVE-2026-47890 (9.8)  CVE-2026-47891 (9.8)  CVE-2026-47892 (9.8)
CVE-2026-59313 (9.8)  CVE-2026-59283 (9.1)  CVE-2026-47885 (7.5)  CVE-2026-47886 (7.5)
CVE-2026-47888 (7.5)  CVE-2026-47889 (7.5)  CVE-2026-47893 (7.5)  CVE-2026-59282 (7.5)

spring-security-core 6.5.11 — 3 CVEs:

CVE-2026-59270 (9.4)  CVE-2026-47841 (7.4)  CVE-2026-41707 (7.4)

Confirmed real against the NVD API directly, not taken on the scanner's word. Three spot-checked:

• CVE-2026-47884 (9.8): XsltView in Spring MVC, SSRF and RCE where the application maps /**
• CVE-2026-59313 (9.8): functional web framework, stream corruption
• CVE-2026-59270 (9.4): Spring Security's embedded UnboundID LDAP server registers an administrative account unconditionally

Nothing to upgrade to

spring-core 6.2.19 and spring-security-core 6.5.11 are the newest published releases in their lines. This cannot be closed with a version bump today.

This is the finding I previously retracted

Issue #34 claimed 14 Spring CVEs and I closed it as not reproducible, because re-running the scanner gave BUILD SUCCESS at -DfailBuildOnCVSS=7 and at 0. That retraction was wrong, and the reason is worth writing down: the scan was failing before it reached nap-spring, and a build that dies on module 2 of 7 reports success for the modules it never analysed. I read a green result as evidence of a clean tree when it was evidence of an incomplete run.

The original report was right. It was the verification that was broken.

Not reachable here, as far as the source shows

• XsltView and the functional web framework: not used, no match in nap-spring/src/main
• Embedded LDAP / UnboundIdContainer: not used, and spring-security-core is pulled for its primitives rather than its LDAP support
• The /** mapping that CVE-2026-47884 needs is an application concern, and this is a library

So the realistic exposure is low for nap-java itself, and higher for any consumer that does use Spring MVC with those features. A library cannot make that judgement for its consumers.

OSV does not see these

Worth flagging, because the OSV job gates merges and would not have caught this:

OSV spring-core 6.2.19:              0 advisories
OSV spring-security-core 6.5.11:     0 advisories

Both scanners have blind spots in opposite directions. OSV found the bcprov critical that Dependency-Check missed by never running; Dependency-Check finds these, which OSV does not carry. That is an argument for keeping both rather than picking one.

Options

1. Accept and document, with a suppression file naming each CVE and why it is not reachable. Keeps the scan green and honest, but suppressions rot silently.
2. Leave the nightly scan red until Spring publishes fixes. Honest, and loud, and exactly the "permanently red check people learn to ignore" the workflow comments argue against.
3. Raise failBuildOnCVSS above 9.8 so nothing fires. Dishonest; not recommended.

I would take 1, with an expiry date on each suppression so it has to be revisited rather than forgotten. Happy to implement it, but it is a call about risk acceptance rather than a mechanical fix, so it should be yours.

In the meantime the job is non-blocking and runs nightly, so this reports without stopping anyone.

[tcheeric]

The scan is now reliable, so this finding is confirmed rather than provisional

Four separate defects were hiding this, each only visible once the one before it was fixed:

1. No NVD API key — failed on module 1 with "Invalid API Key"
2. 80 minute cold download — too slow for a pull request, so it moved to a nightly schedule
3. Standalone goal invocation (ci: build the reactor before scanning it in Dependency-Check #52) — could not resolve sibling modules at an unpublished 0.9.0, so it died on module 2 of 7 and reported nothing for the other five
4. Cache discarded on failure (ci: actually persist the NVD database between runs #53), then poisoned by a cached lock file (ci: never cache the dependency-check update lock #54)

Every green result along the way was a scan that had not run. That is also why I wrongly retracted #34 as not reproducible: BUILD SUCCESS meant "died before reaching nap-spring", and I read it as "clean".

Current state, measured

Cache restored from key: nvd-Linux-36073314929
download lines: 0        lock waits: 0
duration: 54 seconds     (was 80 minutes)
all 7 modules built
fails on findings only

So the nightly job now produces a trustworthy answer in under a minute, and the answer is the CVE list in this issue.

Still needs a decision

Nothing in the tooling changes the substance here. spring-core 6.2.19 and spring-security-core 6.5.11 remain the newest published releases, so there is no version to move to, and the reachability analysis above still holds: no XsltView, no functional web framework, no embedded LDAP in this source.

The options are unchanged, and the choice is a risk acceptance rather than a fix. My preference is still a suppression file with an expiry on each entry, so it has to be revisited rather than quietly outlive the CVEs it covers.

[tcheeric]

Triage: leaving open. Nothing to close it with, and the decision it needs has not been made.

The scan reliability half is done, which is what the 2026-09-24 comment was about rather than the CVEs themselves. ci.yml has a dependency-check job with NVD caching (lines 214, 278-284), and the last three CI runs on master report success.

The substance is unchanged. nap-java still resolves Spring through imani-bom 0.1.81, which pins spring-boot.version to 3.5.16. That is the line the reported spring-core 6.2.19 and spring-security-core 6.5.11 come from, and the issue's finding is that those are the newest published releases in their lines, so there is no version to move to.

No suppression file exists in this repository, so the author's own stated preference (a suppression file with an expiry on each entry, so it has to be revisited rather than quietly outlive the CVEs) has not been acted on either.

This is the shape of issue the brief for this pass says not to close: it is a risk acceptance decision, not a fix. The reachability analysis in the body (no XsltView, no functional web framework, no embedded LDAP in this source) is the argument for accepting, and a library cannot make that judgement for its consumers, which the issue says explicitly.

Worth noting the issue also records that it is the finding previously retracted as #34 and then re-confirmed once the scan could complete. Closing it without a decision would be the third time this finding disappears.