I am still playing catch-up. When I was sick with COVID, I was down and not up to writing or reading a lot. Don’t get me wrong – I was fortunately vaccinated, which helped me recover very quickly, but it still felt like a really bad flu. 

So, when my inbox and news feed started blowing up the day after I got my positive COVID test result, I wasn’t too interested in digging into it. However, the IT world waits for no one, and not even four days after the CVE was announced, I got an interesting email from my VPS Host.  

Apparently, someone had made a script to search the open Internet for Confluence instances that no one had updated yet, and automatically send an email to the hosting company’s abuse email line. My hosting company took this seriously and thus sent me an email saying, “Please see the abuse report below and reply with your solution at your earliest availability. Failure to respond in a timely manner may result in service suspension and/or termination.” Thankfully, I have a reasonably robust configuration management setup, so I didn’t need to do too much other than changing the version number variable to what I wanted to be installed, and hit “go.” I wouldn’t be able to test the upgrade, which would end up biting me, but that will have to be another blog post. 😉

So, now that I’m feeling much better, let us take a look today at this vulnerability, what it means, and what you should do to keep your Confluence instance safe.

Refresher – what is a CVE?

CVE is an acronym for Common Vulnerabilities and Exposures. If someone gives you a CVE number, the company that makes the vulnerable product has responsibly documented the vulnerability with the MITRE Corporation – which maintains the list of vulnerabilities with funding from the Cybersecurity and Infrastructure Security Agency (CISA), which is part of the US. Dept. of Homeland Security. 

Why would they do this? Well, for one thing, it helps get the word out – especially for the nasty bugs, such as the one we are discussing today. Many security agencies pay close attention to the additions to this list, so when something big like this shows up, they are ready to take action. 

Likewise, it helps security researchers who perform audits. Most exploited vulnerabilities are publically known when the criminals use them. Having an organized, well-documented list of these exploits lets the good hackers be thorough in their analysis, thus helping companies close what would otherwise be easy ways in. This logic also motivates software companies to put their issues on the list, as no one wants the bad PR of being the method a bad actor used to break into a computer system.

So what’s the deal with this CVE

Alright, this is the point I should note I am neither a Programmer nor a Hacker – especially when it comes to Java. So, I will give you this explanation as best I understand it, but some of the details might be off. Please have mercy, Internet!

Anyways, CVE-2022-26134 specifically exploits the OGNL module. This module is responsible for taking user-supplied input and processing it to determine what the user wants to do. If this sounds familiar, it’s the same module responsible for CVE-2021-26084, published last year by Atlassian. 

Essentially, any time you take arbitrary user input, you should always treat it as suspect. In this case, the module is invoked in such a way that it doesn’t sanitize the input first, allowing a hacker to use a special web request to allow them to execute commands on your system. This command could, for example, download and execute a script they’ve made – which is instant game over for your system.

By doing so, they could:

• Start a ransomware attack
• Install a cryptominer
• Create credentials to log into your server to gain access to your network
• Deface or otherwise break your Confluence instance
• Steal Corporate secrets (this is Confluence, after all.) 

So, as I’ve stated previously, as far as vulnerabilities, remote code execution is about as bad as it gets. 

So what can we do?

Thankfully, in publishing this vulnerability, Atlassian provided two possible solutions.  

The first and most obvious is to make sure you update your Confluence instance. The announcement explicitly calls these fixed versions, so you want to be at or above these releases. 

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

I should note that the current Long-Term Support version of Confluence is 7.13. LTS Versions get bug fixes and support for longer than non-LTS versions, a full two years from the initial release. So it is generally preferred you stay on an LTS when possible. 

However, just upgrading your instance without thorough testing is not recommended – even more so if you run a large Confluence instance. For those unable to update quickly, Atlassian has also provided Mitigation steps that will make this exploit no longer work on your instance.

These instructions are different depending on which version of Confluence you run, so please pay attention. 

For Confluence 7.15.0-7.18.0

1. Shut Down Confluence

systemctl stop confluence

2. Download this file from Atlassian: xwork-1.0.3-atlassian-10.jar

wget https://packages.atlassian.com/maven-internal/opensymphony/xwork/1.0.3-atlassian-10/xwork-1.0.3-atlassian-10.jar

3. Change your directory to /confluence/WEB-INF/lib/ – Note: this is the same directory your install your MySQL JDBC driver into if you run on a MySQL database.

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

4. Look at and record the permissions on the xwork-1.0.3-atlassian-8.jar file – you will need this later.

ls -lah xwork-1.0.3-atlassian-8.jar

5. Move the file xwork-1.0.3-atlassian-8.jar to another directory.

mv ./xwork-1.0.3-atlassian-8.jar ~/

6. Copy the xwork-1.0.3-atlassian-10.jar file you downloaded back into the <confluence-install>/confluence/WEB-INF/lib/ directory

cp ~/xwork-1.0.3-atlassian-10.jar ./

7. Set the correct permissions and ownership of this file to match those you recorded in step 4.

chmod 644 xwork-1.0.3-atlassian-10.jar
chown <confluence-user>:<confluence-user> xwork-1.0.3-atlassian-10.jar

8. Start Confluence

systemctl start confluence

A note here is that you need to update every node in your Data Center cluster. Doing it on just one or a few will leave you only partially protected. 

For Confluence 6.0.0-7.14.2

1. Shut down Confluence

systemctl stop confluence

2. Download these files from Atlassian: xwork-1.0.3-atlassian-10.jar, webwork-2.1.5-atlassian-4.jar, CachedConfigurationProvider.class

wget https://packages.atlassian.com/maven-internal/opensymphony/xwork/1.0.3-atlassian-10/xwork-1.0.3-atlassian-10.jar
wget https://packages.atlassian.com/maven-internal/opensymphony/webwork/2.1.5-atlassian-4/webwork-2.1.5-atlassian-4.jar
wget https://confluence.atlassian.com/doc/files/1130377146/1137639562/3/1654274890463/CachedConfigurationProvider.class

3. Change your directory to /confluence/WEB-INF/lib/

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

4. Look at and record the permissions on the xwork-1.0.3.6.jar and webwork-2.1.5-atlassian-3.jar files – you will need this later.

ls -lah xwork-1.0.3.6.jar
ls -lah webwork-2.1.5-atlassian-3.jar

5. Move the webwork-2.1.5-atlassian-3.jar and xwork-1.0.3.6.jar files out of the directory.

mv ./webwork-2.1.5-atlassian-3.jar ~/
mv ./xwork-1.0.3.6.jar

6. Copy the xwork-1.0.3-atlassian-10.jar and webwork-2.1.5-atlassian-4.jar into the <confluence-install>/confluence/WEB-INF/lib/ directory

cp ~/xwork-1.0.3-atlassian-10.jar ./
cp ~/webwork-2.1.5-atlassian-4.jar ./

7. Make sure both files permissions and ownership match those observed in Step 4

chmod 644 xwork-1.0.3-atlassian-10.jar
chmod 644 webwork-2.1.5-atlassian-4.jar
chown <confluence-user>:<confluence-user> xwork-1.0.3-atlassian-10.jar
chown <confluence-user>:<confluence-user> webwork-2.1.5-atlassian-4.jar

8. Change to directory <confluence-install>/confluence/WEB-INF/classes/com/atlassian/confluence/setup

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

9. Create a new directory called webwork

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

10. Copy the CachedConfigurationProvider.class file into <confluence-install>/confluence/WEB-INF/classes/com/atlassian/confluence/setup/webwork

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

11. Set Permissions and ownership for both files

chmod -R 644 <confluence-install>/confluence/WEB-INF/classes/com/atlassian/confluence/setup/webwork
chown -R <confluence-user>:<confluence-user> <confluence-install>/confluence/WEB-INF/classes/com/atlassian/confluence/setup/webwork

12. Start Confluence

systemctl start confluence

I should note that any version before 6.0.0 is considered “End of Life” and should be upgraded immediately or otherwise decommissioned. These steps have not been tested on these old versions and are not guaranteed to work.  

What do you think?

Honestly, I think this is far from the last CVE we’ll see from Atlassian. When I started as an Atlassian Admin, Jira and Confluence were obscure things. Now I’m more surprised when an organization doesn’t have at least one Confluence or Jira instance running. That makes it a juicy target for both security researchers and bad actors. Given that, I fully expect more bugs to be discovered.

As Atlassian Admins, we are keepers of our organization’s knowledge repositories and project management tools, which means it’s on us to respond to these threats promptly. Having configuration management or orchestration that can quickly upgrade test and production can go a long way. But – as always, due diligence. Always test an upgrade on your non-prod test system before deploying to production. In my case, I upgraded my public Confluence test instance to 7.18.1 directly, which had different memory requirements, causing Confluence to crash shortly after launch due to the OS being out of memory. However, being a VPS, I can’t easily install more RAM, so I had to tweak both the Synchrony and Confluence max Heap settings to get something to run stably. I don’t want to go too much into this – as I think the investigation and resolution would make an interesting blog article, so watch out for that.   

You can always find me on social media via my Linktree page. Be sure to follow, like, and comment on posts, as it helps the various Platforms know this is content to share with more people. I’m not joking; the “who’s seen this” stat on LinkedIn can vary by 1000 people 24 hrs after publishing, depending on how many comments it’s gotten! So it does help!

You can also subscribe to the blog to get updates via the form below. Signing up will get all new posts sent directly to your inbox – and it’s the fastest way to be notified of new articles.  

But until next time, my name is Rodney, asking, “Have you updated your Confluence Instance today?”

---