fix(security): address the three actionable CVEs from the full dependency pass

[kathrynalpert]

Description

Three follow-ups from a full reachability pass over all 28 Spring-ecosystem jars in WEB-INF/lib. Of 43 CVEs across those jars, 35 are not applicable, two were fixed in #53, and these are the remaining ones that can be addressed without waiting for the Spring Framework 6 migration.

Grouped into one PR because they share a cause and a review context. Each is a separate commit and can be reviewed or dropped independently.

Commit	CVE	Severity	Fix
fix(security) headers	CVE-2026-22732	Critical	Vendor workaround in SecurityConfig — no upgrade available
fix(security) password	CVE-2025-22228	High	72-byte password cap in XNAT — no upgrade available
fix(deps) spring-ldap	CVE-2024-38829	Medium	Bump 2.4.2 → 2.4.4, public on Central

Risks and impact

Security, authentication, and authorization

All three reduce exposure and grant nothing. No roles, permissions or authorization logic change.

CVE-2026-22732 (Critical). When an application configures response headers through Spring Security and HeaderWriterFilter.shouldWriteHeadersEagerly is left at its default of false, those headers can go unwritten on responses that commit early. XNAT meets the precondition — SecurityConfig sets frame options, cache control, a content security policy and a referrer policy — so requests can be served without protections the site believes are in place. No public 5.7.x release has the fix (5.7.22 is commercial), so this applies the vendor's documented workaround via an ObjectPostProcessor.

The vendor notes a behavioural trade-off: with eager writing, application-specific headers override individual Spring Security headers rather than suppressing them wholesale. Checked, and the two sets are disjoint, so nothing changes hands. Spring Security writes X-Frame-Options, Content-Security-Policy, Referrer-Policy, X-Content-Type-Options and X-XSS-Protection, and XNAT sets none of them. XNAT sets Cache-Control (26 sites), Pragma and Expires — and Spring Security's cacheControl() and HSTS writers are both .disable()d in SecurityConfig. So the headers XNAT controls are exactly the ones Spring Security was told not to write.

That grep covered XNAT core only. A plugin setting its own CSP or frame options would see its value win after this change — arguably more correct, but a change.

CVE-2025-22228 (High). bcrypt hashes only the first 72 bytes of a password, and this CVE means matches() ignores everything past that on comparison too — any two passwords sharing a 72-byte prefix both authenticate. XNAT is exposed: PasswordEncoderFactories.createDelegatingPasswordEncoder() makes bcrypt the active encoder, it is wired into XnatDatabaseAuthenticationProvider, and no maximum length was enforced — primary_password is xs:string with no maxLength, the default passwordComplexity is ^.*$, and no password input carries a maxlength.

CVE-2024-38829 (Medium). The same locale-dependent case-conversion defect as CVE-2024-38827, in Spring LDAP query handling. 2.4.4 is the vendor's fix for the 2.4.x branch and is on Central.

Input data

N/A

Upgrade and compatibility

No schema, data model, REST API or signature changes.

One user-visible change: a password over 72 bytes can no longer be set.

Testing

Unit tests

Added RegExpValidatorTest (4 tests): 72 bytes accepted, 73 rejected, 25 three-byte characters rejected, ordinary passphrase unaffected. Two of them fail without the change. Suites: xnat-web 423 and xdat 167, 0 failures.

REST integration tests

None added.

Manual verification

1. Deploy and confirm Content-Security-Policy, X-Frame-Options and Referrer-Policy are present across response types — a normal page, an error page, a static resource, a streamed download — and compare against the same set before the change.
2. Diff that header set against the same requests before the change — the overlap analysis above is static, and only a live response shows whether headers are actually written everywhere they should be.
3. Set a >72-byte password through the UI and through the REST user API, and confirm the rejection message reaches the user rather than surfacing as a generic error.
4. An LDAP login against a real directory, for the spring-ldap bump.