Atlassian Confluence OGNL Injection Vulnerability Protection | Fastly

What you need to know:

- The recent Atlassian Confluence vulnerability (CVE-2021-26084) is reportedly being exploited in the wild.
- We’ve released a new WAF rule that blocks exploitation of this vulnerability; we recommend our next-gen WAF (formerly Signal Sciences) customers enable it immediately (see below)
- There is a patch available from Atlassian that should be applied immediately to any Confluence Server or Data Center instances.


Our Security Research Team has built and deployed a rule to help protect customers of our next-gen WAF against the recently announced CVE-2021-26084, an Atlassian Confluence OGNL injection vulnerability that allows for the execution of arbitrary code on a Confluence Server or Data Center instance. Mass exploitation of the vulnerability is ongoing and expected to accelerate, so it’s worth your attention if you’re a self-managed Confluence customer. 

What’s the impact?

Only self-managed Confluence instances are vulnerable; cloud-hosted (“Confluence Cloud”) instances are not affected. A non-administrator user or unauthenticated user can gain full access to self-managed Confluence instances if the “Allow people to sign up to create their account” function is enabled. 

Attackers do not need local access before exploiting this vulnerability, making it a compelling option in attack campaigns. By gaining remote control over the Confluence instance, attackers can do whatever they want on the system — such as migrating to other production servers that process customer data, installing a cryptominer, or implanting a backdoor to guarantee future access. 

Digging deeper

This issue is an Object-Graph Navigation Language (OGNL) injection vulnerability. OGNL is an expression language for getting and setting properties of Java objects and therefore is able to create or change executable code by design (which is why OGNL injection attacks are infamous, especially in the context of Apache Struts).

The intent of OGNL was to offer limiting formatting capability that could do conditional formatting of text based on a template — but what they actually got was the ability to run arbitrary code because they accidentally exposed part of the Java runtime for loading executable code. 

The goal of any injection attack is to inject code into expected user input that would be evaluated and executed by the application out of context. In this case, the vulnerability is specifically triggered through a template injection attack in Velocity (a Java template engine by the Apache Foundation). Attackers can include command line (bash) commands in their input that are then executed on the operating system.

Exploitation involves a clever bypass of the isSafeExpression method, which checks if anything malicious is being called inside an OGNL expression. By using unicode characters, attackers can craft input that bypasses validation; so, rather than input like #{3*33}, an attacker can instead craft the input as the string \u0027%2b#{3*33}%2b\u0027 to end up with the result of 99. To dig even deeper, read the exploit writeup.

What should you do now?

This is definitely worth addressing immediately. Proof-of-concept exploit code has been publicly available since Aug. 31, 2021, and our Security Research Team has observed active exploitation.

We strongly suggest that customers using our next-gen WAF in front of their self-managed Confluence instances enable this rule as soon as possible and configure it to block requests if the signal is observed. Customers can navigate to Site Rules →  Templated Rules →  then under "Category" select "CVE" and the rule will appear in the list of CVE rules released for customers.

Rule for CVE-2021-26084Templated rules

Additionally, we recommend that you follow all guidance from Atlassian to patch affected Confluence instances. The vulnerability in question is being actively exploited globally and can have severe impact if attackers use it to remotely execute code on vulnerable servers.

Further reading

If you would like to dig deeper into the technical details of this chain of attacks, please see this post by CSO Online. Please refer to our documentation for details on how to enable templated rules.

Fastly Security Research Team
Fastly Security Research Team
Xavier Stevens
Staff Security Researcher
Simran Khalsa
Staff Security Researcher
Published

3 min read

Want to continue the conversation?
Schedule time with an expert
Share this post
Fastly Security Research Team
Fastly Security Research Team

The Fastly Security Research Team focuses on ensuring our customers have the tools and data available to them to keep their systems secure. They analyze and ultimately help prevent attacks at Fastly scale. The team is a group of behind-the-scenes security experts who are here to help you stay on the cutting edge of the ever-evolving security landscape.

Xavier Stevens
Staff Security Researcher

Xavier Stevens is a Staff Security Researcher at Fastly, with a focus on threat research, detection engineering, and product innovation.

Simran Khalsa
Staff Security Researcher

Simran is a Staff Security Researcher at Fastly where he focuses on threat intelligence, vulnerability research, and product innovation. He enjoys researching novel attack techniques and fortifying technology to prevent real-world web attacks. He has spent his career on both the offensive and defensive sides of the industry in both public and private sectors with an emphasis on building modern security solutions.

Ready to get started?

Get in touch or create an account.