CVE-2026-40977
Local File Corruption via PID File Write in Spring Boot
Publication date: 2026-04-28
Last updated on: 2026-04-30
Assigner: VMware
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| vmware | spring_boot | From 4.0.0 (inc) to 4.0.6 (exc) |
| vmware | spring_boot | From 3.3.0 (inc) to 3.3.19 (exc) |
| vmware | spring_boot | From 3.4.0 (inc) to 3.4.16 (exc) |
| vmware | spring_boot | From 3.5.0 (inc) to 3.5.14 (exc) |
| vmware | spring_boot | to 2.7.33 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-59 | The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows a local attacker with write access to corrupt files on the host system each time the affected application starts, potentially leading to denial of service or availability issues.
However, the vulnerability does not impact confidentiality or allow privilege escalation, which means it does not directly expose sensitive data.
Given that common standards and regulations like GDPR and HIPAA emphasize the protection of data confidentiality, integrity, and availability, this vulnerability primarily affects the availability and integrity aspects.
Organizations relying on affected Spring Boot versions should consider the risk of service disruption and potential data integrity issues, which could indirectly impact compliance if availability or integrity of regulated data or services is compromised.
Mitigation by upgrading to fixed versions is necessary to maintain compliance and reduce risk.
Can you explain this vulnerability to me?
CVE-2026-40977 is a medium-severity vulnerability in Spring Boot versions 2.7.0 through 4.0.5 that occurs when an application uses the ApplicationPidFileWriter component.
This component writes the process ID (PID) to a file at a predictable default location. A local attacker who has write access to the directory where this PID file is created can exploit the vulnerability by placing a symbolic link (symlink) at the expected PID file location.
When the application starts, it follows the symlink and writes the PID to the linked file, allowing the attacker to overwrite or corrupt an arbitrary file on the host system each time the application starts.
How can this vulnerability impact me? :
This vulnerability can lead to denial of service or other impacts due to file corruption on the host system.
It does not allow for confidentiality breaches or privilege escalation.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves the ApplicationPidFileWriter component writing the PID file to a predictable location. Detection involves checking if the application is using ApplicationPidFileWriter and verifying the presence and integrity of the PID file or any symbolic links at the expected PID file location.
You can inspect the PID file location for suspicious symbolic links or unexpected file modifications. For example, on a Unix-like system, you might use commands like:
- ls -l /path/to/pidfile # to check if the PID file is a symlink
- stat /path/to/pidfile # to check file metadata and modification times
- find /path/to/pidfile_directory -type l # to find any symbolic links in the PID file directory
Additionally, monitoring application startup logs for errors related to PID file writing or unexpected file corruption may help detect exploitation attempts.
What immediate steps should I take to mitigate this vulnerability?
The primary and recommended mitigation is to upgrade Spring Boot to a fixed version that addresses this vulnerability.
- Upgrade to Spring Boot 4.0.6 if using the 4.0.x line.
- Upgrade to Spring Boot 3.5.14 if using the 3.5.x line.
- Upgrade to Spring Boot 3.4.16 if using the 3.4.x line (Enterprise Support only).
- Upgrade to Spring Boot 3.3.19 if using the 3.3.x line (Enterprise Support only).
- Upgrade to Spring Boot 2.7.33 if using the 2.7.x line (Enterprise Support only).
No additional mitigation steps are necessary beyond upgrading.