CVE-2020-7040: High severity StoreBackup StoreBackup vulnerability
Last updated 25 August 2025
Other sources
storeBackup.pl in storeBackup through 3.5 relies on the /tmp/storeBackup.lock pathname, which allows symlink attacks that possibly lead to privilege escalation. (Local users can also create a plain file named /tmp/storeBackup.lock to block use of storeBackup until an admin manually deletes that file.)
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/storebackupto a version that resolves this vulnerability.Fixed in 3.2.1-2Fixed in 3.5.2-2 - Compensating control
Prevent symlink/path attacks on /tmp/storeBackup.lock by using an anti-symlink/secure file creation approach for the lock file path used by storeBackup.pl (stored in /tmp/storeBackup.lock), so local users cannot influence it via symlinks.
- Operational
If you created /tmp/storeBackup.lock to block storeBackup, manually delete /tmp/storeBackup.lock after applying the secure lock-file handling fix so storeBackup.pl can run again.
Event History
Frequently Asked Questions
What is the severity of CVE-2020-7040?
CVE-2020-7040 is categorized as a high severity vulnerability due to its potential for privilege escalation via symlink attacks.
How do I fix CVE-2020-7040?
To fix CVE-2020-7040, upgrade the storeBackup package to version 3.5 or higher.
Which versions of storeBackup are affected by CVE-2020-7040?
Versions of storeBackup up to and including 3.5 are affected by CVE-2020-7040.
Can local users exploit CVE-2020-7040?
Yes, local users can exploit CVE-2020-7040 by creating a symlink to the /tmp/storeBackup.lock pathname.
What impact does CVE-2020-7040 have on system security?
CVE-2020-7040 can lead to privilege escalation, allowing attackers to gain unauthorized access to system resources.