CVE-2024-21683: Atlassian Confluence authenticated remote code execution
The short version: CVE-2024-21683 lets an authenticated user who can add a new macro language execute arbitrary code on Atlassian Confluence Data Center and Server. It's not unauthenticated, which caps how bad it is — but it's a real path to code execution with public proof-of-concept and a Metasploit module. If you self-host Confluence, patch. Steady hands.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — authenticated, but a clean path to code execution |
| CVSS v3.1 (NVD) | 8.8 — High · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
| CVSS (Atlassian, CNA) | 7.2 — High |
| EPSS | 88.27% · 99.75th percentile (2026-07-17) |
| In CISA KEV? | No |
| Known exploited? | Not confirmed in the wild; public PoC and Metasploit module exist |
| Vulnerability type | CWE-94 code injection → authenticated remote code execution |
| Requires authenticated session? | Yes — an account with privilege to add a new language |
| Affected | Confluence Data Center & Server: 5.2 through 8.9.0 (see advisory for the full range) |
| Fixed in | 7.19.22 (LTS) · 8.5.9 (LTS) · 8.9.1 (and later) |
What you need to know
The "Add a new language" function in the Configure Code Macro section didn't properly validate input, so a user with that privilege can upload a malicious Java file that the server executes — code execution on the Confluence host.
- It requires an account. The attacker must be authenticated and hold the privilege to add a macro language, which is what separates this from the unauthenticated Confluence RCEs.
- It's well-understood and tooled. Public technical write-ups, proof-of-concept code, and a Metasploit module are available, so exploitation is low-effort for anyone who has (or gains) a suitable account.
- The range is broad. A wide span of self-hosted versions is affected; Confluence Cloud is not in scope.
How serious we see it
High — not Critical, because it's authenticated, but not to be shrugged off.
The authentication requirement genuinely lowers the risk versus an unauthenticated RCE — an attacker needs valid, sufficiently privileged access first. But "authenticated" is a smaller barrier than it sounds on a widely used internal platform: credentials get phished, reused, and over-granted. Combined with public tooling, a foothold account turns into server code execution quickly. The reassuring part is that it's bounded and fixable — specific versions, a published patch, and quick to confirm.
Recommendations
Straight from Atlassian's security bulletin:
- Patch. Upgrade to 7.19.22 (LTS) / 8.5.9 (LTS) / 8.9.1 or later.
- Tighten who can add macro languages. Review which accounts hold that privilege and reduce it to the minimum.
- Enforce MFA and strong credentials. Raise the bar on getting the authenticated foothold this needs.
- Confirm your exposure first. Verify whether you run an affected self-hosted Confluence build.
How BreachRisk sees it
BreachRisk discovers internet-facing Confluence from little more than your domain, fingerprints the product and version, and flags version-based exposures like this one. We identify and flag the affected version; because exploitation here requires a privileged account, our external view focuses on surfacing the exposed, affected instance so you can prioritize the patch — not on exploiting it.
The continuous outside-in view keeps your exposed Confluence mapped and version-tracked, so an authenticated RCE like this is a known, ranked item rather than a surprise.