CVE-2022-43781

What it actually does

CVE-2022-43781 is a command injection vulnerability in Atlassian Bitbucket Server and Data Center caused by unsafe handling of attacker-controlled username data when constructing environment variables used by server-side operations. If an attacker can choose or modify a username, they can craft input that is interpreted as operating-system command syntax and execute arbitrary commands on the Bitbucket host. Successful exploitation provides code execution in the security context of the Bitbucket application service account and can lead to repository disclosure, credential theft, persistence, lateral movement, or full host compromise. The CVSS 9.8 rating and EPSS score of 0.98076 indicate high practical exploitability; exploit maturity is reported as weaponized.

Why it matters to the business

A compromised Bitbucket Server or Data Center instance can expose source code, secrets embedded in repositories, CI/CD credentials, signing keys, deployment tokens, and internal development history. Attackers may also alter code, implant backdoors, disrupt development workflows, or use the server as a foothold into build pipelines and production environments. The risk is especially high for internet-facing Bitbucket instances and any deployment with public signup enabled, because exploitation may not require a pre-existing account. Although this CVE is not listed in CISA KEV and is not specifically marked as ransomware-associated, the combination of remote exploitability, weaponized exploit availability, and very high EPSS warrants urgent treatment.

How an attack unfolds

An attacker first determines that the target is running a vulnerable Bitbucket Server or Data Center version. If public signup is enabled, the attacker can create an account without authentication; otherwise, they need any path that lets them control or influence their username, such as an existing low-privileged account. The attacker sets the username to a value containing shell metacharacters or command-substitution syntax intended to break out of the expected environment-variable context. When Bitbucket later performs an affected server-side operation that uses that username in an unsafe environment-variable construction path, the payload is interpreted by the operating system or shell. The injected command then runs as the Bitbucket service user. After initial command execution, the attacker commonly validates execution, retrieves host and application context, reads repository and application configuration data, harvests secrets or credentials, deploys a web shell or reverse shell, and pivots toward CI/CD systems, databases, or internal services reachable from the Bitbucket host.

How to fix it

Upgrade Atlassian Bitbucket Server or Data Center to a vendor-supported fixed release or the latest available version. Because no fixed-version list was provided in the input, validate the exact safe target version against the Atlassian advisory and current release notes before deployment. Treat internet-facing instances and instances with public signup enabled as highest priority. If immediate upgrade is not possible, disable public signup, restrict Bitbucket access to trusted networks or VPN, enforce strong authentication, remove the ability for untrusted users to create or modify usernames, and monitor for suspicious account names or child processes spawned by the Bitbucket Java process. These mitigations reduce exposure but should not be considered a substitute for patching.

How to confirm the fix worked

Confirm the installed Bitbucket Server or Data Center version is at or above a vendor-fixed release. Review administrative settings to ensure public signup is disabled unless explicitly required. Enumerate user accounts and recent account changes for usernames containing shell metacharacters, command-substitution syntax, URL-encoded command characters, or references to common command-line tools. Verify that the Bitbucket service process has not spawned unexpected shells, download utilities, scripting interpreters, or outbound network connections. After patching, perform a controlled validation in a non-production environment using a harmless username payload that should be stored but never executed, and confirm no shell process or command execution occurs. Also confirm reverse proxies, load balancers, and access controls limit Bitbucket exposure as intended.

Typical attack path

1. Identify an exposed Atlassian Bitbucket Server or Data Center instance and infer its version or patch level.
2. Determine whether public signup is enabled or obtain a low-privileged account that can control its username.
3. Set or register a username containing command-injection syntax designed to execute on the Bitbucket host.
4. Trigger a vulnerable Bitbucket operation that processes the crafted username through unsafe environment-variable handling.
5. Execute arbitrary commands as the Bitbucket application service account.
6. Collect repository data, application configuration, tokens, SSH keys, database credentials, or CI/CD secrets.
7. Establish persistence or remote access, such as a dropped script, web shell, scheduled task, SSH key, or reverse shell.
8. Use the Bitbucket server’s network position and stored credentials to move laterally into build, deployment, or production systems.

How to detect it

Investigate whether the Bitbucket instance allowed public signup or permitted users to control usernames during the vulnerable period. Review Bitbucket audit logs and application logs for account creation, username changes, authentication activity, or user-management requests containing shell metacharacters or encoded command syntax. Examine access logs for bursts of signup, profile, or user-management requests from unfamiliar IP addresses. Correlate suspicious account activity with endpoint telemetry showing the Bitbucket Java process spawning unexpected child processes such as sh, bash, cmd, powershell, curl, wget, nc, python, perl, or chmod. Review system authentication logs, cron directories, service definitions, SSH authorized_keys files, temporary directories, plugin directories, and Bitbucket home/shared directories for new or modified files near the time of suspicious requests. Inspect outbound network telemetry for connections from the Bitbucket host to unfamiliar external IPs or domains shortly after account creation or username modification. If threat hunting identifies suspicious execution, assume repository contents and stored integration secrets may have been accessed and proceed with incident response and credential rotation.

• $BITBUCKET_HOME/log/atlassian-bitbucket.log
• $BITBUCKET_HOME/log/audit/atlassian-bitbucket-audit.log
• $BITBUCKET_HOME/log/access_log*
• /var/atlassian/application-data/bitbucket/log/atlassian-bitbucket.log
• /var/atlassian/application-data/bitbucket/log/audit/atlassian-bitbucket-audit.log
• /var/atlassian/application-data/bitbucket/log/access_log*
• java -> sh
• java -> /bin/sh
• java -> bash
• java -> /bin/bash
• java -> curl
• java -> wget
• java -> nc
• java -> netcat
• java -> python
• java -> python3
• java -> perl
• java -> chmod
• java -> chattr
• java -> crontab
• $(
• `
• ;
• |
• ||
• &&
• > /tmp/
• /bin/sh -c
• bash -c
• curl http
• curl -fsSL
• wget http
• wget -qO
• nc -e
• netcat -e
• /dev/tcp/
• python -c
• perl -e
• chmod +x
• authorized_keys
• /tmp/.
• /var/tmp/.
• /etc/cron.d/
• /etc/systemd/system/

What your security team should do

• Immediately inventory all Atlassian Bitbucket Server and Data Center instances, prioritizing internet-facing systems and deployments with public signup enabled.
• Upgrade to a vendor-supported fixed version or the latest supported release after confirming the applicable Atlassian advisory for CVE-2022-43781.
• Disable public signup unless there is a documented business requirement, and restrict self-service account creation to trusted identity-provider workflows.
• Search current and historical usernames for command-injection characters and suspicious substrings such as command substitution, shell separators, curl, wget, bash, sh, nc, python, or perl.
• Hunt for unexpected child processes spawned by the Bitbucket Java process, especially shells, download tools, scripting interpreters, and reverse-shell utilities.
• Review Bitbucket application logs, access logs, audit logs, system logs, EDR telemetry, and network egress for activity around account creation or username changes followed by command execution or outbound connections.
• Rotate credentials that may be accessible to the Bitbucket service account, including repository tokens, SSH keys, database credentials, CI/CD integration secrets, and deployment credentials, if compromise is suspected.
• Check repositories and recent commits for unauthorized changes, malicious hooks, altered build scripts, credential theft tooling, or backdoored source code.
• Apply host hardening controls: run Bitbucket with least privilege, restrict outbound network access, monitor child process creation, and ensure EDR coverage on Bitbucket nodes.
• Preserve forensic evidence before remediation when exploitation is suspected, including logs, process telemetry, user account history, filesystem timelines, and memory or disk images where feasible.