Critical Confluence vulnerability: IT admins should act quickly

Atlassian reported a critical Confluence vulnerability via email to all customers tonight. IT admins of the Atlassian software Confluence should act urgently. Appropriate patches to secure the systems are now available. We have summarized the steps that are now necessary.

Besides Vulnerabilities in Exchange Servers, there are always gaps in other popular software tools. This is how Atlassian reports for Confluence Server and Confluence Data Center "CVE-2022-26134 - Critical severity unauthenticated remote code execution vulnerability". A critical vulnerability that allows unauthenticated users to remotely execute code on the server. Ouch.

Update at 22:25 p.m.: We updated the article with the latest information from Atlassian.

Confluence CVE-2022-26134: Who is affected?

All, yes, really all. Atlassian speaks of all supported instances, later - then more precisely - of version 1.3.0 and higher. So really all Confluence instances should be vulnerable. The variant, i.e. whether Confluence Server or Confluence Data Center, is irrelevant. Only customers of the Atlassian Cloud can breathe a sigh of relief: the Confluence servers used there are not vulnerable and are secure. Confluence instances that end in .atlassian.com in the URL are hosted in the cloud. The security company Volexity was able to identify and recreate this gap, then reported it to Atlassian.

• All actively supported Confluence versions (7.4 - 7.18) affected
• All versions from 1.3.0 and higher are affected
• Both Confluence variants, Confluence Server and Confluence Data Center, are affected

Atlassian is said to already be aware of cases in which this vulnerability has been exploited. So it's only a matter of time before the attacks - like the last Confluence vulnerability im September 2021 - start on a large scale.

What should Confluence admins do now?

Depending on the initial situation of your own infrastructure, there are several options and solutions on how to proceed. Attacks are already in progress, so it should as soon as possible traded.

If the instance is publicly accessible to everyone from outside via the Internet and both the security patch and the workaround cannot be installed immediately, access to Confluence should be restricted immediately. It is best to make the Confluence instance accessible exclusively via the VPN or internal network in the company. If there are no options, Atlassian recommends that the Confluence Server or Confluence Data Center be switched off.

• Immediately restrict access to Confluence Server or Confluence Data Center from outside (VPN, only make it accessible internally)
• Alternatively switch off Confluence Server or Data Center

Confluence version (7.4, 7.13 – 7.18) is used: Apply security patch

Admins of the actively supported versions have been able to import a security patch since Friday evening. A fix is ​​available for each version level from 7.4 (LTS) and from 7.13 to 7.18, which are for the following versions:

• 7.4.17
• 7.13.7
• 7.14.3
• 7.15.2
• 7.16.4
• 7.17.4
• 7.18.1

The updates can be directly from Atlassian downloaded, with the respective LTS and Latest releases at the top. Depending on the version level, you will find the update you are looking for a little further down.

No update possible: Use workaround

If it is currently not possible to carry out an update, a temporary workaround is also available depending on the Confluence version. This closes the gap, as does the security patch, but is only recommended by Atlassian temporarily.

Confluence 7.15.0 – 7.18.0

If Confluence is operated in a cluster, the following steps must be carried out separately on each node.

1. Shut down Confluence
2. Download the following file to the server: xwork-1.0.3-atlassian-10.jar
3. Delete or move away an already existing (vulnerable) JAR file from the installation directory (Attention – should a JAR file remain in the installation directory, the instance remains vulnerable!):

   <confluence-install>/confluence/WEB-INF/lib/xwork-1.0.3-atlassian-8.jar

   Note: matches by default /opt/atlassian/confluence

4. Copy the downloaded file to the directory instead:

   <confluence-install>/confluence/WEB-INF/lib/

5. Check the file's permissions and owner attributes to make sure it matches other files in the same directory
6. Start Confluence

Confluence 7.0.0 - Confluence 7.14.2

If Confluence is operated in a cluster, the following steps must be carried out separately on each node.

1. Shut down Confluence
2. Download the following three files to the server:
   1. xwork-1.0.3-atlassian-10.jar
   2. webwork-2.1.5-atlassian-4.jar
   3. CachedConfigurationProvider.class
3. Delete existing (vulnerable) JAR files from the installation directory or move them away (Attention – should a JAR file remain in the installation directory, the instance remains vulnerable!):

   <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

   Note: matches by default /opt/atlassian/confluence

4. Copy both downloaded files to the following directory:

   <confluence-install>/confluence/WEB-INF/lib/

5. Check permissions and owner attributes of files to ensure they match other files in the same directory
6. Change to the following directory:

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

7. Create a new folder called "webwork" in this directory
8. The file CachedConfigurationProvider.class copy to the following directory:

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

9. Permissions and owner attributes of the file and folder verify that they match the other files in the same directory
10. Start Confluence

We will keep you informed and update this article regularly.

Recommendations for you

• Confluence with critical security gap: attackers can take over servers [+ demo]