What is the CVSS score of CVE-2026-40977?

CVE-2026-40977 has a CVSS 3.1 base score of 4.7 (Medium). CVSS vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-40977?

Yes, a patch is available for CVE-2026-40977. Update the affected software to the latest version immediately.

Spring Boot CVE-2026-40977

MEDIUM

Improper Link Resolution Before File Access (CWE-59)

2026-04-28 security@vmware.com

Information Disclosure Java Red Hat

4.7

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

4.7 MEDIUM

AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H

Red Hat

5.3 MEDIUM

qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H

Attack Vector

Local

Attack Complexity

High

Privileges Required

High

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

Low

Availability

High

Lifecycle Timeline

Analysis Generated

Apr 28, 2026 - 00:32 vuln.today

Analysis Generated

Apr 28, 2026 - 00:22 vuln.today

CVE Published

Apr 28, 2026 - 00:16 nvd

MEDIUM 4.7

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

16 maven packages depend on org.springframework.boot:spring-boot-cassandra (5 direct, 11 indirect)

Ecosystem-wide dependent count for version 4.0.0.

DescriptionCVE.org

When an application is configured to use ApplicationPidFileWriter, a local attacker with write access to the PID file's location can corrupt one file on the host each time the application is started.

Affected: Spring Boot 4.0.0-4.0.5 (fix 4.0.6), 3.5.0-3.5.13 (fix 3.5.14), 3.4.0-3.4.15 (fix 3.4.16), 3.3.0-3.3.18 (fix 3.3.19), 2.7.0-2.7.32 (fix 2.7.33); PID file / symlink behavior (ApplicationPidFileWriter). Versions that are no longer supported are also affected per vendor advisory.

AnalysisAI

Spring Boot applications configured with ApplicationPidFileWriter are vulnerable to local file corruption when a high-privilege user can write to the PID file directory. An attacker with high privileges and write access to the PID file location can corrupt arbitrary files each time the application restarts, achieving denial of service or data integrity violations. Exploitation requires local access and elevated privileges, limiting real-world impact to co-resident or insider threat scenarios. No active exploitation has been publicly reported.

Technical ContextAI

ApplicationPidFileWriter is a Spring Boot component that writes the application process ID to a file for process management and monitoring. The vulnerability stems from unsafe handling of PID files and potential symlink attacks (CWE-59: Improper Link Resolution Before File Access). When an application starts, if an attacker with write access to the PID file directory has created a symlink pointing to a critical system or application file, the PID write operation will overwrite that target file instead of the intended PID file. This symlink-following behavior is the root cause. The affected component operates during application initialization when it attempts to write the PID, making it a startup-phase vulnerability.

RemediationAI

Spring released patched versions addressing ApplicationPidFileWriter symlink handling: upgrade to Spring Boot 4.0.6 or later for 4.x branches, 3.5.14 or later for 3.5.x, 3.4.16 or later for 3.4.x, 3.3.19 or later for 3.3.x, and 2.7.33 or later for 2.7.x. Consult https://spring.io/security/cve-2026-40977 and https://www.herodevs.com/vulnerability-directory/cve-2026-40977 for guidance on your specific branch. As an interim compensating control, restrict write access to the directory where PID files are stored (typically /var/run or /tmp) using filesystem permissions so that only the application owner or root can create files in that location; this prevents unprivileged users from creating symlinks, though it does not fully mitigate attacks from high-privilege users already having directory write access. Additionally, disable ApplicationPidFileWriter if process management can be handled through alternative means (systemd, container orchestration, or external process monitors), though this removes the functionality for applications that depend on PID file based health checks.