Take Action Now: Critical Zero Day Discovered in Atlassian Confluence

Editor’s note: This post has been modified with an updated security advisory and mitigation tips from Atlassian following a critical vulnerability first reported on June 3, 2022. 

Security researchers say a new critical zero-day vulnerability in all supported versions of Atlassian Confluence is being actively exploited to deploy webshells, and admins are being urged to apply workarounds until a patch is released.

The vulnerability, tracked as CVE-2022-26134, is a remote code execution bug that affects Confluence, Confluence Server and Confluence Data Center, according to the company’s security advisory.

Atlassian says all supported versions of those products are affected, and select fixed versions are  available. See a list of fixed versions of Atlassian’s Confluence here.

Atlassian recommends upgrading to the latest long term support release. The latest version is available from Atlassian’s download centre.

If your organization is unable to upgrade Confluence immediately, there is a temporary workaround by updating the following files for the specific version of the product:

For Confluence 7.0.0 – Confluence 7.14.2

If you run Confluence in a cluster, you will need to repeat this process on each node. You don’t need to shut down the whole cluster to apply this mitigation.

1. Shut down Confluence.
2. Download the following 3 files to the Confluence server:
   • xwork-1.0.3-atlassian-10.jar
   • webwork-2.1.5-atlassian-4.jar
   • CachedConfigurationProvider.class
3. Delete (or move the following JARs outside of the Confluence install directory):

   <confluence-install>/confluence/WEB-INF/lib/xwork-1.0.3.6.jar
   <confluence-install>/confluence/WEB-INF/lib/webwork-2.1.5-atlassian-3.jar

    Do not leave a copy of the old JARs in the directory.

4. Copy the downloaded xwork-1.0.3-atlassian-10.jar into <confluence-install>/confluence/WEB-INF/lib/

5. Copy the downloaded webwork-2.1.5-atlassian-4.jar into <confluence-install>/confluence/WEB-INF/lib/

6. Check the permissions and ownership on both new files matches the existing files in the same directory.
7. Change to directory <confluence-install>/confluence/WEB-INF/classes/com/atlassian/confluence/setup

   1. Create a new directory called webwork
   2. Copy CachedConfigurationProvider.class into <confluence-install>/confluence/WEB-INF/classes/com/atlassian/confluence/setup/webwork
   3. Ensure the permissions and ownership are correct for:

      <confluence-install>/confluence/WEB-INF/classes/com/atlassian/confluence/setup/webwork

      <confluence-install>/confluence/WEB-INF/classes/com/atlassian/confluence/setup/webwork/CachedConfigurationProvider.class

8. Start Confluence.

Remember, If you run Confluence in a cluster, make sure you apply the above update on all of your nodes.

Note: Confluence End Of Life versions are not fully tested with the workaround.

We strongly recommend upgrading to a fixed version of Confluence as there are several other security fixes included in the fixed versions of Confluence.

The company recommends restricting access to Confluence Sever and Data Center instances from the internet or disabling those instances altogether.

Admins can also implement a web application firewall rule to block URLs containing ${ to reduce risk.

The security advisory comes as cybersecurity firm Volexity published a detailed blog of the exploit it discovered over Memorial Day weekend involving two internet-facing web servers running Confluence Server software.

Suspicious activity included JSP webshells being written to disk after an attacker exploited CVE-2022-26134 to achieve remote code execution. Volexity recreated the exploit and identified the zero-day bug impacting fully up-to-date Confluence Server versions.

According to Volexity, the JSP file written into a publicly accessible web directory was a “well-known copy of the JSP variant of the China Chopper webshell … which appears to have been written as a means of secondary access.”

The firm also discovered bash shells being launched by the Confluence web application process.  “This stood out because it had spawned a bash process which spawned a Python process that in turn spawned a bash shell,” the firm’s security researchers write.

Successful exploitation of CVE-2022-26134 essentially gives attackers the ability to execute commands as if they were directly logged into the system, and attackers with access to the shell would have full control over the Confluence Sever, Volexity researchers say.

The exploit is similar to other RCE bugs, as it is a command injection vulnerability that allows for full control of a vulnerable system without credentials as long as web request can be made to the Confluence Server system.

“Volexity believes the attacker launched a single exploit attempt at each of the Confluence Server systems, which in turn loaded a malicious class file in memory. This allowed the attacker to effectively have a webshell they could interact with through subsequent requests,” researchers say. “The benefit of such an attack allowed the attacker to not have to continuously re-exploit the server and to execute commands without writing a backdoor file to disk.”

After successful exploitation of CVE-2022-26134, attackers deploy an in-memory copy of the BEHINDER implant, a popular web server implant with source code available eon GitHub that provides “very powerful capabilities to attackers, including memory-only webshells and built-in support for interaction with Meterpreter and Cobalt Strike,” Volexity researchers say.

“Once BEHINDER was deployed, the attacker used the in-memory webshell to deploy two additional webshells to disk: CHINA CHOPPER and a custom file upload shell,” according to researchers.

For more information, including indicators of compromise, read Volexity’s blog and Atlassian’s advisory.