Spring Boot temp-dir takeover opens session hijack path
TL;DR - org.springframework.boot.system.ApplicationTemp uses a predictable temp directory and never verifies ownership. If server.servlet.session.persistent=true, a local attacker on the same host can read persisted session data, hijack authenticated users, or - worst case - feed persisted state into a gadget chain and execute code as the application's OS user.
What happened
Spring Boot wires the production defaults for most Java services: embedded servlet containers, config, actuator, the works. It is the de-facto starting point for new Spring applications.
CVE-2026-40973 sits in org.springframework.boot.system.ApplicationTemp. The class resolves a temp directory using a predictable path and never checks whether it already exists or who owns it. A local attacker who can pre-create that path - another OS user, a compromised sidecar, another workload on the same Kubernetes node - wins control of the directory before the application claims it.
On its own that is a nuisance. Add server.servlet.session.persistent=true and it becomes a session-hijack primitive. Servlet sessions serialised to disk land in that attacker-controlled path, readable and writable. In the worst case, a crafted serialised object in that directory gets deserialised by the application - gadget chain, code execution, game over for the service account.
The Spring advisory was posted on 2026-04-23. The CNA record followed on 2026-04-27. The vulnerability only activates when two things coincide: ApplicationTemp in the framework and session persistence in your config. Neither is unusual in long-running, stateful Java services.
Who is impacted
- Spring Boot applications on any host where a local attacker can obtain a foothold: shared OS users, multi-tenant Kubernetes nodes, compromised sidecars, or any workload co-located with an untrusted process.
- Deployments with
server.servlet.session.persistent=trueset anywhere in config files, Helm values, or environment variables. - Affected versions:
| Spring Boot line | Affected versions | Fixed version |
|---|---|---|
4.0.x | 4.0.0 to 4.0.5 | 4.0.6 |
3.5.x | 3.5.0 to 3.5.13 | 3.5.14 |
3.4.x | 3.4.0 to 3.4.15 | 3.4.16 |
3.3.x | 3.3.0 to 3.3.18 | 3.3.19 |
2.7.x | 2.7.0 to 2.7.32 | 2.7.33 |
What to do now
- Upgrade to the fixed version for your Spring Boot line. The vendor is unambiguous:
"Users of affected versions should upgrade to the corresponding fixed version." "No further mitigation steps are necessary."
- Grep your config files, Helm charts, and environment variables for
server.servlet.session.persistent=true. Those services are your highest priority for patch rollout. - Use this as a prompt to audit temp-path assumptions broadly: confirm your application's runtime user cannot have predictable paths under the system temp directory pre-created or overwritten by other users, especially on shared nodes.
- If you suspect compromise: treat session confidentiality and integrity as lost. Invalidate all active sessions for affected services, rotate credentials the sessions could have exposed, and review your session invalidation runbook.
Additional Information
- Spring advisory (scope and fix table): https://spring.io/security/cve-2026-40973/
Related
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.