Vulnerability Directory | CVE-2026-40977 | Spring

Overview

Spring Boot is the most widely used Java framework for building production-grade applications with minimal configuration. It ships an optional ApplicationPidFileWriter listener that records the JVM process ID to a file on startup so that orchestration scripts, init systems, and operators can locate and signal the running application. By default the listener writes to application.pid in the process's current working directory, and the filename is customizable via constructor argument or the spring.pid.file property.

A medium-severity vulnerability (CVE-2026-40977) has been identified in that listener's underlying write helper. The ApplicationPid.write(File) method opens the target file with java.io.FileWriter, which follows symbolic links. A local attacker who has write access to the directory that holds the PID file, but no other privileges on the Spring Boot process, can plant application.pid as a symlink to an arbitrary file that the Spring Boot UID can write. When the application is next started, Spring Boot opens through the symlink, truncates the target file, and writes the JVM's PID digits into it. The previous contents of the target file are destroyed.

Per OWASP: "A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the intended directory. By manipulating files with 'dot-dot-slash (../)' sequences and their variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on the file system, including application source code, configuration files, and critical system files." This vulnerability is the link-following variant of that class: instead of ../ traversal, the attacker uses a symbolic link that the application blindly follows when opening a predictably-named file for write.

The CVSS v3.1 base score for this vulnerability is 4.4 (Medium) with vector AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H. Exploitation requires local write access to the PID file's directory and the ability to pick a target file that the Spring Boot JVM can open for writing. The attacker cannot control the contents written (only the JVM's PID digits are appended after truncation), which bounds the integrity impact, but choosing a critical file as the symlink target can corrupt it to the point of denying service to the host or another application component.

The vulnerable FileWriter-based write path has been present in every tagged Spring Boot release since 1.0.2 (April 2014), when ApplicationPidFileWriter's predecessor first began creating a PID file on startup. Later class reorganizations (moving ApplicationPid into org.springframework.boot.system and ApplicationPidFileWriter into org.springframework.boot.context in 2018) did not change the underlying open semantics. This issue affects Spring Boot 1.0.2 through 2.7.32, 3.3.0 through 3.3.18, 3.4.0 through 3.4.15, 3.5.0 through 3.5.13, and 4.0.0 through 4.0.5.

‍

Details

Module Info

Product: Spring Boot
Affected packages: spring-boot
Affected versions: >=1.0.2 <=2.7.32, >=3.3.0 <=3.3.18, >=3.4.0 <=3.4.15, >=3.5.0 <=3.5.13, >=4.0.0 <=4.0.5
GitHub repository: https://github.com/spring-projects/spring-boot
Published packages: https://central.sonatype.com/artifact/org.springframework.boot/spring-boot
Package manager: Maven
Fixed in:
NES for Spring Boot 1.5.x, 2.5.x, 2.7.x, 3.2.x, 3.3.x, 3.4.x
OSS Spring Boot 3.5.14, 4.0.6

‍

Vulnerability Info

The vulnerability is in org.springframework.boot.system.ApplicationPid, specifically the write(File) method used by org.springframework.boot.context.ApplicationPidFileWriter to record the JVM process ID on application startup.

An application is vulnerable when all of the following conditions are true:

The application registers ApplicationPidFileWriter (directly, via SpringApplication#addListeners, or via the META-INF/spring.factories entries commonly enabled in production deployments).
A local attacker has write access to the directory that holds the PID file. By default this is the process's current working directory and the filename is application.pid, so the predictable path is whatever working directory the service runs from (for example /opt/myapp/application.pid or the directory configured in a systemd unit's WorkingDirectory=).
The attacker can choose a target file that the Spring Boot JVM's own UID is able to open for writing. Examples include application-owned log files, application-managed lock or state files, or any file under a group-writable directory that the JVM's group membership covers.

When those conditions are met, the attacker creates a symbolic link at the expected PID file path that points at the file they want to destroy. On the next application start, ApplicationPidFileWriter fires and calls new ApplicationPid().write(this.file). In the pre-fix code, write opens the file with new FileWriter(file) and appends the PID:

public void write(File file) throws IOException {
    Assert.state(this.pid != null, "No PID available");
    createParentDirectory(file);
    if (file.exists()) {
        assertCanOverwrite(file);
    }
    try (FileWriter writer = new FileWriter(file)) {
        writer.append(String.valueOf(this.pid));
    }
}

‍

FileWriter is backed by FileOutputStream, whose default open semantics on every mainstream operating system follow symbolic links. The existence and permission pre-checks (file.exists(), file.canWrite(), Files.getPosixFilePermissions(file.toPath())) all operate on file.toPath() without LinkOption.NOFOLLOW_LINKS, so they see the symlink's target rather than the link itself. The writer therefore opens the link target, truncates it with CREATE + TRUNCATE_EXISTING semantics, and writes only the PID digits (for example 12345). Whatever data the target previously contained is gone. Because the attacker can re-plant the symlink between restarts, they can corrupt one arbitrary writable file per application start.

Although the CVSS vector marks integrity impact as Low (the attacker cannot choose the bytes written beyond the JVM's PID digits), availability impact is High: a well-chosen target file, such as a dependency artifact, an application-managed license or keystore file, a log file consumed by a monitoring daemon, or a write-ahead log segment, can be rendered invalid by the truncation-and-overwrite, causing the next restart to fail or causing another system component to malfunction.

‍

Mitigation

Only recent versions of Spring Boot receive community support and updates. Older versions have no publicly available fixes for this vulnerability.

Users of the affected components should apply one of the following mitigations:

Upgrade to a currently supported version of Spring Boot.
Leverage a commercial support partner like HeroDevs for post-EOL security support through Never-Ending Support NES for Spring Boot.