CVE-2026-40973

What it actually does

This vulnerability allows a low-privileged local user on the same host as a Spring Boot application to take control of, pre-create, or manipulate the predictable temporary directory used by ApplicationTemp. The risk becomes significant when `server.servlet.session.persistent=true` and the attack survives an application restart. Under those conditions, the attacker may read persisted session data, tamper with session state, hijack authenticated users, or place malicious serialized data that is later processed by the application, potentially resulting in code execution as the application’s operating-system user. The issue is local-only, high-complexity, and requires existing access to the host, but successful exploitation can compromise confidentiality, integrity, and availability of the application process.

Why it matters to the business

An attacker who already has limited access to a server could escalate their impact from a local foothold to control over application sessions or the application process itself. This can lead to account takeover, exposure of sensitive user session data, unauthorized actions as authenticated users, service disruption, or further lateral movement using the application’s privileges. Because Spring Boot is widely used across Java services and older unsupported versions are also affected, organizations should treat this as a priority for systems that use persistent sessions or run applications on shared hosts, even though there is no known KEV listing, ransomware association, or mature public exploit activity at this time.

How an attack unfolds

An attacker first obtains low-privileged local access to the same host where a vulnerable Spring Boot application runs. They identify that the application uses an affected Spring Boot version and that persistent servlet sessions are enabled. The attacker then abuses the predictable ApplicationTemp directory behavior by creating, replacing, changing ownership of, or otherwise controlling the relevant temporary directory before or across an application restart. After the application restarts, it may trust or reuse attacker-controlled content in that directory. If persisted session data is present, the attacker can read it to recover session information and hijack authenticated users. In a more severe scenario, the attacker plants a malicious serialized payload or gadget chain in the session persistence location so that the application processes it during startup or session restoration, causing code execution under the application user account.

How to fix it

Upgrade Spring Boot to a fixed version for the active release line in use: 4.0.6 or later, 3.5.14 or later, 3.4.16 or later, 3.3.19 or later, or 2.7.33 or later. If running an unsupported Spring Boot version, upgrade to a supported fixed release because unsupported versions are also affected. If persistent sessions are not required, disable them by setting `server.servlet.session.persistent=false`. Ensure each application runs under a dedicated least-privileged operating-system account. Use a private, application-specific temporary directory owned by the application user with restrictive permissions such as 0700, and avoid shared writable locations where other local users can create or replace directories. Consider service isolation controls such as systemd `PrivateTmp`, containers with isolated filesystems, hardened mount options, and file integrity monitoring on application temporary and session persistence directories. Remove stale temporary/session files after patching if they may have been created or modified by untrusted users.

How to confirm the fix worked

Confirm the effective Spring Boot version from build metadata, dependency manifests, runtime actuator/build information where available, or package/dependency tooling such as Maven or Gradle. Verify that the application is running one of the fixed versions: 4.0.6+, 3.5.14+, 3.4.16+, 3.3.19+, or 2.7.33+. Review configuration files, environment variables, and runtime configuration to determine whether `server.servlet.session.persistent` is enabled. Inspect the application temporary directory and session persistence location after restart to confirm they are owned by the intended application user and are not writable by other local users or groups. Validate that temporary directories are not predictable shared locations controlled by another user. Restart the application after upgrading and confirm normal session handling. Where possible, test in a non-production environment that a non-privileged local user cannot pre-create, replace, or write to the application’s temporary directory.

Typical attack path

1. Gain low-privileged local access to the same operating system host as the Spring Boot application.
2. Determine that the application runs an affected Spring Boot version and has persistent servlet sessions enabled.
3. Identify or predict the ApplicationTemp directory used by the application.
4. Create, replace, or take ownership of the relevant temporary directory or its contents before the application starts or restarts.
5. Wait for or trigger an application restart so the application reuses the attacker-controlled directory.
6. Read persisted session artifacts to hijack authenticated sessions, or place malicious serialized content intended to be processed during session restoration.
7. Abuse the resulting session access or code execution as the application user to access data, modify application behavior, or expand control on the host.

How to detect it

Look for evidence that a local user manipulated the application temporary directory or persistent session files before an application restart. Useful log sources include Linux auditd, process accounting, shell history where available, system authentication logs, sudo logs, EDR telemetry, file integrity monitoring, application startup logs, container runtime logs, and filesystem metadata. Investigate mkdir, chmod, chown, ln, mv, rm, or file-write activity affecting ApplicationTemp or application-specific temporary/session directories by users other than the application service account. Check for directories or files owned by unexpected users, world-writable permissions, symlinks in place of expected directories, or session files modified shortly before application startup. Review application logs around restarts for session restoration, deserialization failures, class loading errors, unexplained exceptions, or abnormal startup behavior. If exploitation may have progressed to code execution, hunt for child processes spawned by the Java application process, unusual outbound network connections, dropped files in temporary directories, and post-exploitation commands executed under the application user. For session hijacking, correlate suspicious session reuse, sudden changes in source IP or user agent, anomalous authenticated actions, and session activity immediately after application restarts.

• server.servlet.session.persistent=true
• ApplicationTemp
• SESSIONS.ser
• java.io.tmpdir
• chmod 777
• chmod -R 777
• chown -R
• ln -s
• AC ED 00 05
• java.lang.ClassNotFoundException
• java.io.InvalidClassException
• java.io.StreamCorruptedException
• java.io.ObjectInputStream
• org.apache.catalina.session.StandardManager
• org.apache.catalina.session.PersistentManager

What your security team should do

• Inventory Spring Boot applications and prioritize hosts where multiple local users, build agents, scheduled jobs, or shared service accounts coexist.
• Upgrade affected applications to the fixed Spring Boot release for their supported branch: 4.0.6+, 3.5.14+, 3.4.16+, 3.3.19+, or 2.7.33+.
• Immediately disable persistent servlet sessions where they are not operationally required.
• Harden application temporary directory handling by assigning a private per-application temp path with restrictive ownership and permissions.
• Review servers for local user accounts, shared accounts, CI/CD runners, or other services that could act as the required local attacker.
• Audit existing ApplicationTemp and session persistence directories for unexpected ownership, permissions, symlinks, recently modified serialized session files, or files created by non-application users.
• Add file integrity monitoring or audit rules for application temp/session directories on high-value systems.
• Rotate active user sessions or invalidate persisted sessions if suspicious session files or directory ownership anomalies are found.
• Treat any evidence of malicious serialized session content as potential application-user code execution and initiate incident response.