CVE-2024-21683

What it actually does

CVE-2024-21683 is an authenticated remote code execution vulnerability in Atlassian Confluence Data Center and Confluence Server, introduced in version 5.2. A network-accessible attacker with valid Confluence credentials and low privileges can send crafted requests that cause the Confluence application to execute attacker-controlled code in the context of the Confluence server process. Because Confluence commonly has access to sensitive page content, attachments, user directories, application links, plugins, and integration secrets, successful exploitation can compromise confidentiality, integrity, and availability of the instance and may provide a foothold for broader infrastructure compromise.

Why it matters to the business

A compromised Confluence instance can expose internal documentation, credentials, project plans, customer data, and operational runbooks; attackers may also modify or delete content, deploy persistence, interrupt collaboration services, or pivot into connected systems. The risk is elevated because the vulnerability is remotely exploitable after authentication, has high EPSS likelihood, is reported as weaponized, and affects widely deployed Confluence Data Center and Server installations. Even though it is not currently listed in CISA KEV and is not specifically flagged for ransomware use, externally reachable or broadly accessible Confluence instances should be treated as high-priority remediation targets.

How an attack unfolds

An attacker first obtains valid Confluence credentials through phishing, credential stuffing, password reuse, compromised SSO/session material, or abuse of an existing low-privilege account. The attacker then identifies a vulnerable Confluence Data Center or Server instance running an affected version and submits a crafted request to the vulnerable functionality. Because the flaw requires no user interaction and has low attack complexity, the request can trigger execution of attacker-supplied commands or code under the Confluence application account. After code execution, the attacker may enumerate local files, read Confluence configuration and database connection settings, extract secrets, deploy web shells or malicious plugins, create persistence, tamper with pages or attachments, and use the server as a pivot point to reach internal systems or connected Atlassian integrations.

How to fix it

Upgrade Confluence Data Center or Confluence Server to the latest supported release recommended by Atlassian. If an immediate upgrade to the latest release is not possible, upgrade to a supported fixed version identified in Atlassian’s official release notes and security advisory for this vulnerability. Because no fixed versions were provided in the input, do not assume an arbitrary target version; verify the exact fixed branch for the deployed release line against Atlassian documentation before change implementation. If upgrade must be delayed, reduce exposure by restricting Confluence access to trusted networks or VPN, enforcing strong MFA/SSO controls, disabling or removing unused accounts, reviewing privileged users, limiting outbound network access from Confluence servers, and increasing monitoring. Mitigations should be considered temporary because the vulnerability enables server-side code execution once an attacker is authenticated.

How to confirm the fix worked

Confirm remediation by checking the running Confluence version from the administrative interface, application startup logs, package inventory, or deployment metadata and comparing it with Atlassian’s fixed-version guidance. Verify all cluster nodes in Confluence Data Center are upgraded, not only the primary node. Confirm that old application directories, rollback images, containers, and standby nodes are not still running vulnerable builds. Validate that access controls limiting external reachability are in place if used as interim mitigation. After upgrade, run an authenticated vulnerability scan or configuration assessment that can identify Confluence build versions, and review logs for failed upgrade attempts, plugin incompatibilities, or unexpected post-upgrade restarts.

Typical attack path

1. Acquire valid Confluence credentials or a reusable authenticated session.
2. Identify the Confluence version and confirm it is within the affected Confluence Data Center or Server range.
3. Send a crafted authenticated request to the vulnerable Confluence functionality.
4. Execute commands or code as the Confluence application process.
5. Read Confluence configuration files, database credentials, attachment stores, plugin directories, and application-link secrets.
6. Establish persistence through web shells, malicious plugins, scheduled jobs, modified startup scripts, or new administrative accounts.
7. Exfiltrate Confluence content and secrets, alter or destroy data, or pivot to connected internal systems.

How to detect it

Look for signs of authenticated exploitation and post-exploitation rather than relying on a single definitive request signature. Review Confluence access logs, reverse proxy logs, WAF logs, atlassian-confluence.log, atlassian-confluence-security.log, catalina.out, audit logs, SSO/IdP authentication logs, operating system process telemetry, EDR alerts, filesystem changes, and outbound network telemetry. Focus on low-privilege users making unusual requests followed by server errors, abnormal latency, unexpected file writes, or Confluence spawning shell and scripting interpreters. Investigate new or modified files under Confluence install, home, plugin, attachment, and temporary directories; unexpected plugin installations; new administrative users; unusual personal access tokens or sessions; changes to application links; and outbound connections from the Confluence server to unfamiliar IPs or domains. If threat intelligence identifies a specific campaign or actor using this vulnerability, correlate the relevant infrastructure, user agents, command patterns, and payload hashes with these same log sources. Because no authoritative CVE-specific public IOC is provided here, treat generic command-execution artifacts as leads requiring triage rather than proof of exploitation.

• java.lang.ProcessBuilder
• java.lang.Runtime.getRuntime
• /bin/sh -c
• bash -c
• cmd.exe /c
• powershell.exe
• curl http://
• curl https://
• wget http://
• wget https://
• nc -e
• ncat -e
• /confluence/WEB-INF/classes/
• /confluence/WEB-INF/lib/
• <confluence-home>/plugins-cache/
• <confluence-home>/bundled-plugins/
• <confluence-home>/temp/
• <confluence-home>/logs/atlassian-confluence-security.log
• <confluence-home>/logs/atlassian-confluence.log
• catalina.out

What your security team should do

• Prioritize upgrade of all internet-facing or broadly accessible Confluence Data Center and Server instances because exploitation is reported as weaponized and EPSS is high.
• Inventory every Confluence node, including Data Center cluster members, disaster-recovery systems, test systems, containers, and archived VM images.
• Require MFA for all Confluence users, with urgent review of administrator accounts, stale accounts, local accounts outside SSO, and recently created users.
• Hunt for evidence of post-exploitation, especially unusual child processes spawned by the Java/Confluence process, suspicious plugin uploads, web shells, unexpected outbound connections, and newly created administrator accounts.
• Restrict Confluence network exposure to trusted users and systems until patching and hunting are complete.
• Rotate credentials and secrets stored in Confluence configuration files, application links, automation pages, and integration documentation if exploitation is suspected.
• Review Confluence Marketplace and custom plugins for unexpected additions or modifications.
• Preserve relevant logs before upgrade or cleanup, including access logs, application logs, audit logs, proxy/WAF logs, authentication logs, and endpoint telemetry from Confluence hosts.