CVE-2022-26133

What it actually does

CVE-2022-26133 is a critical unauthenticated remote code execution flaw in Atlassian Bitbucket Data Center caused by unsafe Java deserialization in the SharedSecretClusterAuthenticator component. A remote attacker who can reach the affected Bitbucket Data Center service can submit a crafted serialized Java object that is deserialized by the application and can trigger arbitrary code execution in the Bitbucket application process. Successful exploitation provides confidentiality, integrity, and availability impact: the attacker may run operating-system commands with the privileges of the Bitbucket service account, read or alter repositories and configuration, steal secrets, deploy persistence, or disrupt the service.

Why it matters to the business

A compromised Bitbucket Data Center instance can expose source code, credentials, deployment keys, build or release secrets, and intellectual property, and can allow attackers to tamper with code that flows into software delivery pipelines. Because Bitbucket commonly sits at the center of development and release operations, exploitation can lead to source-code theft, supply-chain compromise, service outage, and downstream compromise of connected CI/CD systems. The CVSS score is 9.8 and EPSS is high at approximately 71%, indicating meaningful likelihood of exploitation in the wild even though it is not currently listed in CISA KEV for known exploitation.

How an attack unfolds

An attacker first identifies an internet- or network-accessible Atlassian Bitbucket Data Center deployment running an affected version. The attacker then sends a specially crafted request or cluster-authentication interaction containing a malicious serialized Java payload to the vulnerable SharedSecretClusterAuthenticator code path. When the Bitbucket application deserializes the attacker-controlled object, gadget-chain execution can occur inside the Java process. The attacker’s payload may execute shell commands, write web-accessible files, create reverse shells, modify application configuration, or access repository data using the permissions of the Bitbucket service account. After initial code execution, a typical attacker will enumerate the host, dump configuration files and secrets, access repositories, search for deployment credentials, pivot to CI/CD tooling, and establish persistence before covering traces.

How to fix it

Upgrade Bitbucket Data Center to a fixed version immediately. Affected ranges are Bitbucket Data Center 5.14.0 and later before 7.6.14; 7.7.0 and later before 7.17.6; 7.18.0 and later before 7.18.4; 7.19.0 and later before 7.19.4; and 7.20.0. Upgrade to 7.6.14, 7.17.6, 7.18.4, 7.19.4, 7.20.1 or later, preferably the latest supported Long Term Support or current release. If immediate upgrade is not possible, restrict network access to Bitbucket and any clustering interfaces to trusted hosts only, block direct internet access, require access through a VPN or reverse proxy with strict allowlists, and ensure cluster communication ports are not exposed beyond cluster members. Treat mitigation as temporary; unsafe deserialization RCE flaws should be remediated by patching rather than configuration alone. After patching, rotate credentials and secrets accessible to Bitbucket if exploitation is suspected.

How to confirm the fix worked

Confirm the deployed Bitbucket Data Center version is no longer in an affected range by checking the application administration UI, startup logs, package metadata, or the version reported by the Bitbucket installation. Validate that all nodes in a Data Center cluster are upgraded, not just one node, and verify that shared home and application nodes were restarted successfully after upgrade. Confirm externally and internally that Bitbucket HTTP endpoints and cluster communication interfaces are not reachable from untrusted networks. Review vulnerability scanner results and software inventory for residual affected versions. Where safe and authorized, perform a non-destructive exposure check that verifies version and network reachability rather than sending exploit payloads. If compromise is suspected, validate integrity of repositories, installed plugins, application configuration, service account files, scheduled tasks, and startup scripts.

Typical attack path

1. Identify externally reachable or internally reachable Atlassian Bitbucket Data Center instances.
2. Fingerprint the Bitbucket version or infer vulnerability from exposed metadata, response behavior, or asset inventory.
3. Send a crafted Java deserialization payload to the vulnerable SharedSecretClusterAuthenticator path or associated cluster-authentication interface.
4. Achieve code execution inside the Bitbucket Java application process under the Bitbucket service account.
5. Run reconnaissance commands to identify the operating system, user context, network access, installed tools, and repository locations.
6. Read Bitbucket configuration, shared home directories, repository data, SSH keys, application passwords, tokens, and CI/CD integration secrets.
7. Use stolen credentials or repository access to pivot into build systems, deployment platforms, cloud environments, or developer infrastructure.
8. Deploy persistence, modify code or configuration, exfiltrate data, or disrupt Bitbucket availability.

How to detect it

Investigate both application-layer evidence and host-level behavior. Review Bitbucket access logs, application logs, Catalina/Tomcat logs if present, reverse proxy logs, and load balancer logs for unusual unauthenticated requests around the time of suspicious activity, especially requests followed by 500 errors, serialization exceptions, abrupt connection resets, or unusual response sizes. Review Bitbucket logs for Java deserialization errors, class-loading errors, SharedSecretClusterAuthenticator messages, and unexpected stack traces involving ObjectInputStream. On hosts, examine EDR, syslog, auditd, Windows Event Logs, process accounting, and command-line telemetry for the Bitbucket Java process spawning shells or utilities such as bash, sh, cmd.exe, powershell.exe, curl, wget, nc, ncat, perl, python, or openssl. Look for outbound connections from the Bitbucket host to unfamiliar IPs, especially shortly after suspicious HTTP or cluster-authentication traffic. Inspect the Bitbucket installation and shared home directories for newly written plugins, modified startup scripts, cron jobs, systemd units, SSH authorized_keys changes, web shells, or unexpected executable files. Review repository audit logs for unusual clone, archive, branch, tag, hook, or permission changes. If exploitation is plausible, preserve volatile evidence and logs before restarting or rebuilding nodes.

• SharedSecretClusterAuthenticator
• java.io.ObjectInputStream
• java.io.InvalidClassException
• java.io.StreamCorruptedException
• java.io.OptionalDataException
• java.lang.ClassNotFoundException
• ysoserial
• Runtime.getRuntime().exec
• ProcessBuilder
• /bin/sh -c
• /bin/bash -c
• cmd.exe /c
• powershell.exe -enc
• powershell.exe -EncodedCommand
• curl http://
• wget http://
• nc -e
• ncat -e
• bash -i >& /dev/tcp/
• /var/atlassian/application-data/bitbucket/shared/plugins/installed-plugins/
• /var/atlassian/application-data/bitbucket/shared/bitbucket.properties
• /var/atlassian/application-data/bitbucket/log/atlassian-bitbucket.log
• /opt/atlassian/bitbucket/logs/catalina.out
• authorized_keys

What your security team should do

• Prioritize immediate upgrade of all Bitbucket Data Center nodes to a fixed release: 7.6.14, 7.17.6, 7.18.4, 7.19.4, 7.20.1, or later supported versions.
• Inventory all Bitbucket Data Center deployments, including single-node Data Center installations, development instances, disaster-recovery nodes, and non-production systems.
• Restrict inbound access to Bitbucket and clustering interfaces to trusted networks and cluster members; remove direct internet exposure where possible.
• Search historical logs and endpoint telemetry for evidence of Java deserialization exploitation, suspicious Bitbucket child processes, reverse shells, unusual outbound connections, and unauthorized repository access.
• If suspicious activity is found, isolate the affected node, preserve logs and disk evidence, rotate Bitbucket secrets, SSH keys, access tokens, webhooks, and CI/CD credentials, and review repository integrity.
• Monitor Bitbucket service-account behavior for abnormal command execution, file writes outside expected directories, new plugins, modified startup scripts, and anomalous outbound network traffic.
• Review connected CI/CD systems, deployment platforms, and cloud credentials for downstream compromise if the Bitbucket instance may have been exploited.
• Add detection content for Java application processes spawning shell utilities or network tools from the Bitbucket service context.