CVE-2026-25701
Received Received - Intake
Insecure Temporary File Vulnerability in openSUSE sdbootutil Risks Data Integrity

Publication date: 2026-02-25

Last updated on: 2026-02-25

Assigner: SUSE

Description
An Insecure Temporary File vulnerability in openSUSE sdbootutil allows local users toΒ pre-create a directory to achieve various effects like: * gain access to possible private information found in /var/lib/pcrlock.d * manipulate the data backed up in /tmp/pcrlock.d.bak, therefore violating the integrity of the data should it be restored. * Β overwrite protected system files with data from /var/lib/pcrlock.d by placing symlinks to existing files in the directory tree in /tmp/pcrlock.d.bak. This issue affects sdbootutil: from ? before 5880246d3a02642dc68f5c8cb474bf63cdb56bca.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-25
Last Modified
2026-02-25
Generated
2026-05-07
AI Q&A
2026-02-25
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
suse sdbootutil From 5880246d3a02642dc68f5c8cb474bf63cdb56bca (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-377 Creating and using insecure temporary files can leave application and system data vulnerable to attack.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-25701 is an Insecure Temporary File vulnerability in the openSUSE sdbootutil package, specifically in the sdbootutil-update-predictions.service systemd service.

The service uses a fixed and predictable backup directory at /tmp/pcrlock.d.bak without enabling PrivateTmp=yes, and it runs as root.

Before running its main command, the service copies data from /var/lib/pcrlock.d to /tmp/pcrlock.d.bak, then executes sdbootutil -v update-predictions. If the command fails, it restores the original data from the backup and deletes the backup directory.

Because the backup directory is predictable and located in /tmp, local unprivileged users can pre-create or manipulate it, leading to unauthorized access to sensitive data, tampering with backup data, or symlink attacks that overwrite protected system files.


How can this vulnerability impact me? :

This vulnerability can impact you by allowing local unprivileged users to:

  • Gain unauthorized access to potentially sensitive information stored in /var/lib/pcrlock.d.
  • Manipulate or corrupt backup data in /tmp/pcrlock.d.bak, compromising the integrity of data if it is restored.
  • Perform symlink attacks to overwrite protected system files by placing symbolic links in the backup directory.

Overall, this can lead to confidentiality breaches, data integrity violations, and potential system compromise.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves the predictable and insecure use of the backup directory /tmp/pcrlock.d.bak by the sdbootutil-update-predictions.service running as root.

To detect if your system is vulnerable, you can check for the existence and permissions of the /tmp/pcrlock.d.bak directory and whether it can be pre-created or manipulated by unprivileged users.

  • Check if the backup directory exists and its permissions: ls -ld /tmp/pcrlock.d.bak
  • Attempt to pre-create the directory as an unprivileged user: mkdir /tmp/pcrlock.d.bak
  • Check the systemd service file for sdbootutil-update-predictions.service to see if PrivateTmp=yes is enabled: systemctl cat sdbootutil-update-predictions.service

If the directory can be created or manipulated by a non-root user, or if PrivateTmp is not enabled, the system is likely vulnerable.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include preventing local unprivileged users from pre-creating or manipulating the /tmp/pcrlock.d.bak directory used by the sdbootutil-update-predictions.service.

  • Modify the service to use a secure backup location such as /var/backups instead of a fixed directory in /tmp.
  • Use a uniquely named temporary directory created with mktemp -d to avoid predictable directory names.
  • Configure the service to attempt to create /tmp/pcrlock.d and fail if it already exists, preventing pre-creation attacks.
  • Enable PrivateTmp=yes in the systemd service file to isolate the temporary directory, although this alone does not fully mitigate the issue.

Applying available patches or updates that address this vulnerability is also recommended.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart