CVE-2022-36804

What it actually does

CVE-2022-36804 is a command injection vulnerability in Atlassian Bitbucket Server and Bitbucket Data Center affecting multiple REST API endpoints. A remote attacker who can read a public repository, or who has read permission to a private repository, can send a crafted HTTP request that causes Bitbucket to pass attacker-controlled input into operating-system command execution paths. Successful exploitation allows arbitrary code execution with the privileges of the Bitbucket application process, enabling repository data theft, application tampering, credential access, and potential lateral movement from the Bitbucket host.

Why it matters to the business

A compromised Bitbucket server can expose source code, secrets embedded in repositories, CI/CD credentials, deployment keys, and intellectual property. Because Bitbucket often sits in the software delivery pipeline, exploitation can also enable supply-chain compromise, malicious code insertion, build system access, and service disruption. This issue is high urgency: it is listed in CISA KEV, has active exploitation in the wild, and has an EPSS score of 0.99077, indicating a very high likelihood of exploitation against exposed vulnerable systems.

How an attack unfolds

An attacker first identifies an internet-facing or internally reachable Bitbucket Server or Data Center instance running an affected version. The attacker then obtains repository read access, which may be as simple as using a public repository or a low-privileged authenticated account with read rights. They send a malicious HTTP request to one of the vulnerable Bitbucket REST API endpoints, commonly involving repository operations, with crafted parameters designed to break out of intended command arguments and inject shell commands. If the instance is vulnerable, Bitbucket executes the injected command as the Bitbucket service account. The attacker may then run reconnaissance commands, download additional tooling, create persistence, access repository contents and application configuration, extract credentials or SSH keys, and pivot toward build systems, source-code management integrations, or internal network services.

How to fix it

Upgrade Bitbucket Server or Bitbucket Data Center to a fixed version immediately. Fixed versions are: 7.6.17 or later in the 7.6 line, 7.17.10 or later in the 7.17 line, 7.21.4 or later in the 7.21 line, 8.0.3 or later in the 8.0 line, 8.1.3 or later in the 8.1 line, 8.2.2 or later in the 8.2 line, and 8.3.1 or later in the 8.3 line. If possible, upgrade to the latest supported Bitbucket Long Term Support or current release rather than only the minimum fixed version. If immediate upgrade is not possible, restrict network access to Bitbucket, remove public repository exposure where feasible, limit repository read permissions to trusted users, enforce strong authentication, monitor vulnerable endpoints closely, and consider temporarily disabling or isolating affected instances until patched. After patching, rotate credentials and secrets accessible to the Bitbucket process if exploitation is suspected.

How to confirm the fix worked

Confirm the installed Bitbucket version is not in an affected range: 7.0.0 through earlier than 7.6.17, 7.7.0 through earlier than 7.17.10, 7.18.0 through earlier than 7.21.4, 8.0.0 through earlier than 8.0.3, 8.1.0 through earlier than 8.1.3, 8.2.0 through earlier than 8.2.2, or 8.3.0 through earlier than 8.3.1. Validate the version through the Bitbucket administration interface, package manager, container image tag, deployment manifest, or application startup logs. Confirm internet-facing exposure is removed or restricted where required. Review access logs to verify that vulnerable API endpoints are no longer accepting suspicious payloads. In a non-production test environment only, use a safe vendor-approved or internally controlled validation method to confirm crafted injection payloads are rejected and do not result in command execution.

Typical attack path

1. Identify a reachable Atlassian Bitbucket Server or Data Center instance.
2. Determine or infer that the instance is running a vulnerable version.
3. Use a public repository or obtain low-privileged credentials with repository read permission.
4. Send a crafted HTTP request to a vulnerable Bitbucket API endpoint with command-injection payloads in request parameters.
5. Execute operating-system commands under the Bitbucket application account.
6. Run discovery commands such as whoami, id, uname, env, ipconfig, or hostname to confirm execution context.
7. Download or stage follow-on tooling using curl, wget, PowerShell, Python, or similar utilities.
8. Search Bitbucket configuration, repositories, hooks, plugins, and home directories for credentials, tokens, SSH keys, and secrets.
9. Use stolen credentials or source-code access to move into CI/CD systems, cloud environments, or internal services.
10. Optionally establish persistence, modify repositories, exfiltrate data, or disrupt Bitbucket availability.

How to detect it

Investigate whether exploitation already occurred by reviewing Bitbucket HTTP access logs, Bitbucket application logs, reverse proxy logs, WAF logs, authentication logs, operating-system process telemetry, EDR events, and network egress records. Key log sources include atlassian-bitbucket-access.log, atlassian-bitbucket.log, audit logs, catalina logs, systemd journals, syslog, Windows Event Logs where applicable, and proxy/load-balancer logs in front of Bitbucket. Search for requests to Bitbucket REST repository endpoints, especially archive or repository browsing operations, containing URL-encoded shell metacharacters, command separators, command substitution patterns, or references to utilities such as bash, sh, cmd.exe, powershell, curl, wget, nc, ncat, python, perl, chmod, chattr, crontab, and mkfifo. Correlate suspicious HTTP requests with child processes spawned by the Bitbucket Java process or service account; normal Bitbucket activity should not cause Java to spawn interactive shells or external download utilities. Review outbound connections from the Bitbucket host to unfamiliar IP addresses or domains shortly after suspicious requests. Examine temporary directories, Bitbucket home directories, repository hooks, plugin directories, scheduled tasks, cron entries, and startup scripts for recently created or modified files. If threat activity is confirmed or strongly suspected, assume credentials accessible to the Bitbucket process or stored in repositories may be compromised and perform incident response, containment, eradication, and credential rotation.

• /rest/api/latest/projects/
• /repos/
• /archive
• /browse
• %3b
• %3B
• %7c
• %7C
• %26
• %60
• %24%28
• ;id
• ;whoami
• ;uname
• ;hostname
• /bin/sh
• /bin/bash
• cmd.exe
• powershell
• curl
• wget
• nc
• ncat
• mkfifo
• chmod +x
• python -c
• perl -e
• bash -c
• sh -c
• atlassian-bitbucket-access.log
• atlassian-bitbucket.log
• catalina.out
• java -> sh
• java -> bash
• java -> curl
• java -> wget
• java -> powershell
• /var/atlassian/application-data/bitbucket/log/atlassian-bitbucket.log
• /var/atlassian/application-data/bitbucket/log/atlassian-bitbucket-access.log
• /opt/atlassian/bitbucket/logs/catalina.out

What your security team should do

• Patch or upgrade all affected Bitbucket Server and Data Center instances immediately; treat this as emergency remediation because it is in CISA KEV and actively exploited.
• Prioritize internet-facing instances, instances hosting public repositories, and instances integrated with CI/CD, deployment, cloud, or secret-management systems.
• Restrict Bitbucket access to trusted networks or VPNs and remove unnecessary public repository access until remediation is complete.
• Audit all repository read permissions, especially anonymous access, public projects, stale accounts, and service accounts.
• Hunt for exploitation in Bitbucket access logs, application logs, system logs, EDR telemetry, proxy logs, and web application firewall logs.
• Look for shell execution, download utilities, scripting interpreters, reverse-shell behavior, and unusual child processes spawned by the Bitbucket Java process.
• If compromise is suspected, preserve forensic evidence before rebuilding or upgrading, including Bitbucket logs, web access logs, process history, file system timestamps, repository hook changes, and authentication logs.
• Rotate Bitbucket administrator credentials, repository access tokens, SSH keys, CI/CD tokens, deployment keys, and secrets stored in repositories or accessible to the Bitbucket service account.
• Review repository history and recent commits, branches, tags, hooks, plugins, and pull-request activity for unauthorized changes.
• Add SIEM detections for suspicious Bitbucket REST requests containing encoded command separators, shell metacharacters, and operating-system command strings.