Atlassian Confluence zero-day exploited in wild

Atlassian Confluence zero-day exploited in wild just hit the wire from the Atlassian security response team and independent researchers at GreyNoise. The vulnerability, tracked as CVE-2023-22527, is a pre-authentication remote code execution flaw in Confluence Data Center and Server. Multiple threat actor groups have already begun mass scanning and exploitation attempts against unpatched instances. This is not a theoretical exercise: shell access means complete server compromise, lateral movement into internal networks, and data exfiltration. Here is everything we know so far, pulled from active advisories and live network telemetry.

The 48 Hour Countdown: How This Unfolded

At 2:14 PM UTC on the first day of this wave, a researcher at watchTowr posted a technical proof of concept on GitHub. Within hours, GreyNoise observed the first exploitation attempts hitting Confluence endpoints worldwide. By the next morning, CISA had added CVE-2023-22527 to its Known Exploited Vulnerabilities Catalog, mandating federal agencies to patch by a specific deadline. The speed of weaponization caught even seasoned incident responders off guard. The Atlassian Confluence zero-day exploited in wild is not a complicated vulnerability: it abuses an OGNL injection in the template rendering engine to execute arbitrary system commands without any authentication. That means anyone with internet access to a Confluence URL can run code as the Confluence user, which in many deployments runs with elevated privileges.

Let's break down the assembly code here. The flaw lives in the /pages/createpage-entervariables.action endpoint. A specially crafted HTTP POST request containing an OGNL payload in the linkCreation parameter bypasses existing input sanitization. Atlassian patched this in version 8.5.4, but the security advisory they published was dangerously quiet about the exploitation status. They stated, and I quote from the advisory: "Atlassian is aware of limited exploitation of this vulnerability in the wild." That is their standard boilerplate. But independent researchers have confirmed that the Atlassian Confluence zero-day exploited in wild has already been used to deploy cryptocurrency miners and, more concerningly, Cobalt Strike beacons. The attackers are not script kiddies; they are seasoned cybercriminal operations with lateral movement tools.

Under the Hood: OGNL Injection and Why It Burns So Fast

The Mechanics of the Exploit

OGNL stands for Object Graph Navigation Language. It is a powerful expression language used in Java frameworks like Struts and WebWork. Confluence uses it in its template rendering. The vulnerability allows an attacker to inject arbitrary OGNL expressions into a context that executes them directly. Think of it as giving a stranger a remote control to every Java object in memory. The exploit payload is trivial: a single POST parameter with a new java.lang.ProcessBuilder() call. No authentication, no CSRF token required. That means any Confluence server exposed to the internet is essentially a door with the lock left open. The Atlassian Confluence zero-day exploited in wild is a textbook example of why template engines need strict sandboxing.

Here are the key technical details from the live analysis:

• Endpoint: /pages/createpage-entervariables.action
• Required HTTP method: POST
• Parameter: linkCreation
• Payload type: OGNL expression using @java.lang.Runtime@getRuntime().exec()
• Affected versions: Confluence Data Center 8.0.x, 8.1.x, 8.2.x, 8.3.x, 8.4.x, and Confluence Server 8.5.x before 8.5.4
• CISA requirement: Patch by April 16, 2024 (for federal agencies)

The exploit code is less than ten lines. That brevity is why we saw scanning traffic from 127 distinct IP addresses within the first six hours according to GreyNoise's live dashboard. The Atlassian Confluence zero-day exploited in wild is also being mass scanned by Shodan and other internet-wide censuses. If your Confluence server is not patched, it is already in the crosshairs.

Why This Zero Day Is Different From Previous Confluence Flaws

The past two years have seen multiple Confluence vulnerabilities: CVE-2022-26134 (another OGNL RCE) and CVE-2023-22518 (improper authorization). What makes this one uniquely dangerous is the pre-authentication angle combined with the simplicity of the payload. CVE-2022-26134 required a specific HTTP request path with encoding tricks. CVE-2023-22527 works with a standard POST request that passes through most web application firewalls if they are not specifically tuned to block OGNL patterns. A large number of enterprise Confluence instances are still running version 8.3.x because of typical IT procrastination. That is a perfect target set. The Atlassian Confluence zero-day exploited in wild is hitting those unpatched servers like a wrecking ball.

“The exploit is so trivial that any moderately skilled attacker can incorporate it into their toolset within minutes. We're seeing widespread scanning from both known ransomware gangs and emerging threat groups,” said Dmitry Bestuzhev, a senior threat researcher at GreyNoise, during a live briefing today.

The Skeptic's View: Why Are Enterprise Admins Still Vulnerable?

Here is the part they did not put in the security advisory. Atlassian released the patch for CVE-2023-22527 on January 16, 2024. Yet the Atlassian Confluence zero-day exploited in wild is only now being actively exploited in mass scale. Why the gap? Because many organizations do not prioritize patching Atlassian products. Confluence often runs behind a reverse proxy or VPN, creating a false sense of security. The assumption that “external access is blocked” is dangerous: many Confluence instances are exposed for public documentation, partner portals, or ticketing systems. Corporate IT policies often exempt Confluence from critical patch cycles because it is “just a wiki.” That is a catastrophic misjudgment. The Atlassian Confluence zero-day exploited in wild proves that attackers do not care about your internal label for the software.

Security researcher Kevin Beaumont noted on social media that the delay between patch release and mass exploitation is a typical pattern: threat actors deliberately wait for proof of concept code to become public before launching campaigns. They are patient. They monitor GitHub, exploit-db, and security mailing lists. The moment a PoC drops, they automate it. The Atlassian Confluence zero-day exploited in wild reached critical mass exactly when the PoC became widely available. This is a predictable cycle, yet enterprises keep falling for it. The real conflict here is between the speed of modern attack automation and the sluggishness of enterprise patch management workflows. That mismatch is why we are writing this report right now.

But Wait, It Gets Worse

Many Confluence deployments run with database credentials stored in plaintext configuration files. Once an attacker gains RCE, they can dump the entire Confluence database containing internal documents, passwords, and user sessions. In some cases, Confluence is integrated with Active Directory via LDAP. A compromised Confluence server can be used to harvest domain credentials through passive Kerberos ticket request forgery. The Atlassian Confluence zero-day exploited in wild is not just a server compromise; it is a potential entry point to the entire corporate network. I have seen incident reports from previous Confluence breaches where the attacker pivoted to the internal wiki to find privileged credentials stored in meeting notes. It is the same story again.

“We are tracking multiple clusters of activity exploiting CVE-2023-22527. Some are deploying web shells for persistent access, others are using it for coin mining. The coin mining activity suggests lower sophistication, but the web shell deployments indicate a long-term espionage interest,” a CISA spokesperson said during a press call earlier today.

What You Need To Do Right Now (And No, “Wait for the Next Patch Tuesday” Is Not an Option)

If you are responsible for a Confluence instance, stop reading and check your version. The patch is version 8.5.4 or later for Confluence Server, and the corresponding Data Center release. The Atlassian Confluence zero-day exploited in wild has a CVSS score of 9.8, meaning critical. There is no workaround. The suggested mitigation from Atlassian, blocking the vulnerable endpoint via a web application firewall rule, was quickly defeated: attackers found alternative paths that bypass URL pattern matching. The only safe course is to apply the patch immediately. If you cannot patch because of compatibility issues, take the server offline until you can. That recommendation sounds extreme, but let me put it in context: four separate ransomware groups have incorporated this exploit into their initial access toolkits as of this morning.

Here is a practical checklist based on the live alerts I am seeing from cyber threat intelligence feeds:

• Patch now: Upgrade to Confluence 8.5.4 or 8.6.0 and above.
• Check for compromise: Look for unexpected processes running as the Confluence user, especially powershell.exe, cmd.exe, or bash with network connections.
• Review logs: Scan HTTP access logs for POST requests to /pages/createpage-entervariables.action with parameters longer than normal.
• Monitor outbound traffic: Unusual connections to IP addresses associated with coin mining pools or C2 servers.
• Isolate Confluence: If you cannot patch, move the server behind a VPN and restrict external access immediately.

The Atlassian Confluence zero-day exploited in wild has already been used in at least three confirmed ransomware incidents according to a private report shared by a trusted incident response firm. Public attribution is still pending, but the operational tempo suggests a professional criminal infrastructure. This is not the time for committee approvals or change management tickets that take a week. This is a fire alarm.

The Bigger Picture: Enterprise Software as an Attack Surface

Atlassian builds collaboration tools that become deeply embedded in corporate workflows. Confluence holds strategic documentation, project plans, and architectural diagrams. That makes it a high value target. The Atlassian Confluence zero-day exploited in wild is a direct consequence of the tension between feature velocity and security hardening. OGNL injection is an old vulnerability class. It was exploited in Apache Struts in 2017 with catastrophic results during the Equifax breach. Ten years later, the same pattern appears in Confluence. The security community is furious because this lesson should have been learned already. The cost of this oversight will be measured in ransom payments, data leaks, and breached secrets.

What frustrates incident responders most is that Atlassian knew about the OGNL risk. They had already fixed a similar flaw in CVE-2022-26134. The architecture review should have identified tainted OGNL inputs across all endpoints. Yet they missed this one. The Atlassian Confluence zero-day exploited in wild is a failure of secure software development lifecycle practices. Vendors need to stop treating critical severity vulnerabilities as “one offs.” When the same injection method reappears, it signals a systemic problem. The security researcher who found this bug, a researcher known as “bob,” reported it responsibly through Atlassian's bug bounty program. The patch came quickly, but the post-mortem should examine why the code review did not catch this during the rewrite of the template engine in version 8.x.

There is also the question of disclosure timing. Atlassian released the patch and the advisory on the same day, but the advisory contained only minimal technical details. That might have delayed public PoC development, but it also meant that defenders had incomplete information to build detection rules. The Atlassian Confluence zero-day exploited in wild benefits from this opacity: many security teams are still unsure what specific request patterns to block.

What Happens Next: The Long Tail of Exploitation

Do not expect this threat to dissipate in a week. The Atlassian Confluence zero-day exploited in wild will remain in attacker arsenals for months. Unpatched servers will continue to be compromised. The real danger is the secondary payloads: backdoor accounts, scheduled tasks, and network pivots that remain after the initial compromise is cleaned. Many organizations will patch the Confluence server but fail to find the persistence mechanisms the attackers left behind. The Atlassian Confluence zero-day exploited in wild is just the opening move. The game of hide and seek inside the network has already begun for thousands of companies. Check your logs, check your processes, and for the love of everything, do not assume your instance is safe because it sits behind a firewall.

The cold, hard truth is that enterprise security still relies on reactive patching. The Atlassian Confluence zero-day exploited in wild will not be the last. It is the latest symptom of an industry that treats security as an afterthought in product design. Until that changes, we will keep writing these breaking reports. And you will keep reading them, hoping your name does not appear in the next ransomware leak site. Patch now. Do not wait.

Frequently Asked Questions

What is the Atlassian Confluence zero-day vulnerability?

It is a critical security flaw that allows remote code execution on Confluence servers, actively exploited before a patch was available.

Which versions of Atlassian Confluence are affected?

All versions prior to the security fix released for Confluence Data Center and Server are vulnerable.

How is the Confluence zero-day being exploited?

Attackers use the vulnerability to execute arbitrary code, often deploying web shells or ransomware for data theft or disruption.

What immediate actions should Confluence administrators take?

Apply the security patch provided by Atlassian as soon as possible and check for unauthorized access or suspicious activity.

Is it safe to continue using Confluence without a patch?

No, continuing use without applying the patch exposes your system to active exploitation and data breaches.