What We Know About the Zero-Day Vulnerability Affecting Zimbra Collaboration and cpio

Default Author Image
October 7, 2022

On September 10, an attack was reported in the Zimbra forums where a malicious actor was able to upload a JSP web shell into the /public directory to execute a command, generating a pre-authentication key to login to an existing account. The attack vector was a specially crafted TAR archive, which was sent with a .jpg extension as an email attachment.

RCE bug in Zimbra Collaboration Suite (CVE-2022-41352, VulnDB 302181)

The content of the TAR archive shows that it includes a symlink to the jetty/webapps/zimbra/public/ directory to which the JSP web shell is extracted.

Based on the provided information, the amavis email content filter identifies the ‘pax’ package as missing, and issues a warning message as it uses ‘cpio’ as a replacement, which Zimbra states “can be a security risk.”

News publications report that the zero-day vulnerability RCE in Zimbra Collaboration Suite is being actively exploited by threat actors. But instead of releasing a security advisory, Zimbra has responded by publishing a blog post advising users to ensure that the ‘pax’ package is installed in order to avoid using cpio. However, does doing so actually address the vulnerability?

Investigating the root cause of the vulnerability

This raises the question: Which component actually causes the vulnerability? At first sight, there are several components in play that are obvious suspects.

  1. Zimbra for using an insecure setup
  2. amavis for using cpio despite being insecure
  3. cpio for insecurely extracting an archive

Without having access to a Zimbra Collaboration installation, we checked the amavis source code to look for known vulnerabilities in cpio. And according to known details, CVE-2015-1197 sounds exactly like the issue that was exploited. However, according to VulnDB, the issue is fixed in version 2.13 which was released November 2019. Notably, the issue affects ‘cpio’, even when using the –no-absolute-filenames command-line option, which was introduced to create all files relative to the current directory.

Next, we checked whether amavis actually uses this option, and in lib/Amavis/, it invokes ‘cpio’ with the –no-absolute-filenames option.

At this point, we needed to put cpio to the test. Based on the initial report and similar symlink attacks, we generated a tar file that would extract a JSP file to an arbitrary directory on the system.

$ mkdir -p /tmp/jetty/webapps/zimbra/public/
$ ln -s /tmp/jetty/webapps/zimbra/public/
$ echo "test" > public/ws.jsp
$ tar cf public.tar public public/ws.jsp

Then, we passed this to the ‘cpio’ utility on an Ubuntu 20.04.4 LTS to test this with a temporary directory.

$ ls /tmp/jetty/webapps/zimbra/public/
$ $ cpio -i < public.tar 
4 blocks
$ ls /tmp/jetty/webapps/zimbra/public/

According to the documentation, the file should not be written to the /tmp/jetty/webapps/zimbra/public/ directory when the –no-absolute-filenames option is used.

$ ls /tmp/jetty/webapps/zimbra/public/
$ cpio -i --no-absolute-filenames < public.tar 
4 blocks
$ ls /tmp/jetty/webapps/zimbra/public/

This is strange. Searching for information on the mailing list shows at least one post claiming that the issue is still not fixed. It also revealed that after a bug report, the developer suggested reverting the patch that fixes the vulnerability

We downloaded the source code and built ‘cpio’ version 2.13 to see if the issue was fixed or not. Surprisingly, everything worked as expected:

$ ls /tmp/jetty/webapps/zimbra/public/
$ ./cpio-2.13/src/cpio -i --no-absolute-filenames < public.tar 
./cpio-2.13/src/cpio: Removing leading `/' from hard link targets
./cpio-2.13/src/cpio: public/ws.jsp: Cannot open: No such file or directory
4 blocks

We didn’t see that coming. Since our Ubuntu release comes with cpio version 2.13, something was wrong with the Ubuntu cpio package.
We checked the Ubuntu package files downloaded from and indeed, the patch for CVE-2015-1197 was reverted.

$ ls -1 debian/patches/

$ cat debian/patches/revert-CVE-2015-1197-handling.patch 
From: Chris Lamb <[email protected]>
Date: Sat, 1 Feb 2020 13:36:37 +0100
Subject: Fix a regression in handling of CVE-2015-1197 &



This reverts (most of):
 src/copyin.c    | 2 --
 tests/testsuite | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/copyin.c b/src/copyin.c
index e1350af..e0a092a 100644
--- a/src/copyin.c
+++ b/src/copyin.c
@@ -646,8 +646,6 @@ copyin_link (struct cpio_file_stat *file_hdr, int in_file_des)
       link_name = xstrdup (file_hdr->c_tar_linkname);
-  cpio_safer_name_suffix (link_name, true, !no_abs_paths_flag, false);
   res = UMASKED_SYMLINK (link_name, file_hdr->c_name,
   if (res < 0 && create_dir_flag)

And since Ubuntu is a Debian-based distribution, we checked the stable Debian packages, which also includes the reverted patch.

Solving the case

Our research involving the RCE in Zimbra Collaboration Suite has been like a good crime novel. A series of events that need investigation, interesting characters, with a twist at the end revealing that an unsuspected character was the killer. Reverting vulnerability-related fixes based on suggestions on a mailing list is bad practice. For Zimbra Collaboration instances, only servers where the ‘pax’ package was not installed were affected. But other applications may use cpio on Ubuntu as well. However, we are currently unaware of other attack vectors. Since the vendor has clearly marked CVE-2015-1197 in version 2.13 as fixed, Linux distributions should carefully handle those vulnerability patches—and not just revert them. 

Uncover the truth with Flashpoint

New vulnerabilities are disclosed everyday and sometimes, the details you need to remediate them simply aren’t available. That is why it is important to have an experienced vulnerability research team in your corner. Sign up for a free VulnDB trial to get actionable details on over 300,000 vulnerabilities affecting all manners of IT, OT, IoT, and third party libraries and dependencies.

Begin your free trial today.