Spring Boot DevTools timing side-channel can hand attackers RCE
TL;DR - The remote secret comparison in spring-boot-devtools leaks information through timing differences. An adjacent attacker who recovers the secret can upload changed classes to the remote application - that's RCE. CVSS 7.5 (High). Patch to the fixed release for your Spring Boot line.
What happened
spring-boot-devtools is Spring Boot's developer productivity module - hot reload, remote restart, that sort of thing. It's supposed to stay out of production, but it ends up there more often than teams realise.
CVE-2026-40972 is a timing side-channel (CWE-208) in the module's remote secret comparison. The attack is two steps: an attacker on the same network uses timing differences to recover the remote secret, then uses that secret to upload changed classes. Changed classes mean arbitrary code execution inside the running application.
| Item | Detail |
|---|---|
| Affected component | spring-boot-devtools |
| Vulnerability class | Timing side-channel in secret comparison (CWE-208) |
| Worst-case impact | Upload changed classes, leading to remote code execution |
| Severity | CVSS 3.1 7.5 (High) |
| CVSS vector | CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H |
This is the familiar failure mode for shared-secret control planes. Once the secret can be inferred, the remote-management surface stops being an admin feature and becomes an execution path.
Who is impacted
- Any Spring Boot application that includes
spring-boot-devtoolsin an affected version. - The attack requires adjacent network position, so risk is highest in shared or cloud environments where network adjacency is easier to achieve.
- Unsupported Spring Boot lines are also affected.
| 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
The vendor is direct: upgrade to the fixed release for your line. No additional mitigations are required once you're on a fixed version.
"Users of affected versions should upgrade to the corresponding fixed version." "No further mitigation steps are necessary."
- Upgrade to the fixed release matching your Spring Boot line (see table above).
- Inventory production artifacts - build manifests, lockfiles, SBOMs, container images - and identify every service that bundles
spring-boot-devtools. It should never ship to production; this is a good moment to confirm it isn't. - Prioritise services using remote DevTools workflows. Those are the ones where the class-upload path is actually reachable.
- If you suspect prior exposure: treat credentials accessible to the affected application as potentially compromised. Review deployment history for unexpected class changes or restarts.
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.