Join our Newsletter — 33% off our NHI Course
Home› Glossary› Cyber Security› CVE-2022-36804 (Atlassian Bitbucket Server and Data…
Cyber Security

CVE-2022-36804 (Atlassian Bitbucket Server and Data Center Command Injection)

← Back to Glossary
By NHI Mgmt Group Updated October 17, 2026 Domain: Cyber Security

CVE-2022-36804 is a command injection vulnerability in Atlassian Bitbucket Server and Data Center. CISA added it to the Known Exploited Vulnerabilities catalogue on 30 September 2022, which means attackers have used it in real attacks. Organisations running the affected product should apply the vendor fix or mitigation as a priority.

What makes this vulnerability dangerous in Bitbucket Server and Data Center

Command injection means an attacker can supply input that the server interprets as operating-system commands, turning a web-facing product weakness into code execution on the host. In a source-code platform such as Bitbucket Server and Data Center, that can expose repositories, service credentials, build integrations, and the broader environment the application can reach.

The practical danger is not just that a request succeeds, but that the attacker may move from application control to server-level actions. That shift can create access to source code, configuration data, internal endpoints, and secrets that were never meant to be exposed through the product interface.

How organisations should assess exposure

Exposure checks start with a complete inventory of Bitbucket Server and Data Center instances, including development, staging, and internet-facing deployments. Organisations should confirm which systems are reachable from untrusted networks, which integrations depend on the product, and whether vendor guidance has already been applied to each instance.

Because this CVE was added to the CISA KEV catalogue, it should be treated as an actively exploited issue rather than a theoretical one. For version and remediation details, readers should rely on the vendor advisory and the CVE Program record alongside the NIST National Vulnerability Database entry.

Remediation and compensating controls

The primary response is to apply Atlassian’s fix or mitigation as soon as operationally possible. When immediate patching is blocked, organisations should reduce exposure by restricting network access, tightening administrative reach, and limiting who can interact with the Bitbucket interface while the risk remains open.

Compensating controls should also assume that the application may already have been probed or abused. That means reducing lateral movement opportunities, reviewing adjacent service permissions, and removing any unnecessary trust paths from the Bitbucket host to internal systems, backup locations, or other management services.

Detection and compromise review

After remediation, teams should review logs and host telemetry for signs that command execution occurred before the fix was applied. Useful indicators include unexpected process launches, unusual child processes from the Bitbucket service, suspicious outbound connections, and new or modified files that do not align with normal repository activity.

Because command injection can be used to steal or plant identity material, post-incident review should also include credential and session hygiene where Bitbucket integrations depend on tokens, keys, or service accounts. If there is any evidence of exploitation, rotate the relevant secrets and verify whether adjacent systems were accessed using those trust relationships.

Risk and Threat Considerations

This vulnerability is materially dangerous because it is in a source-control platform that often holds sensitive code, automation tokens, and integration trust. Once command injection is achieved, the attacker may pivot from application access to host compromise and then to internal systems that Bitbucket can reach.

Failure mechanism: Unsanitised input reaches an operating-system command path, allowing the attacker to execute arbitrary commands with the privileges of the Bitbucket process or its surrounding service context.

Impact: The attacker can steal source code, harvest credentials or tokens, tamper with repositories, and use the compromised server as a foothold for broader internal access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST SP 800-53 Rev 5SI-10 — Information Input ValidationCommand injection stems from unsafe input handling in a software command path.
SI-2 — Flaw RemediationThe CVE requires timely remediation after vendor and KEV notice.
AU-6 — Audit Record Review, Analysis, and ReportingDetecting exploitation depends on reviewing process and host telemetry.
Recommendation — Validate all external input before it reaches command execution logic. Prioritise remediation of actively exploited flaws in internet-reachable systems. Review logs for abnormal process execution and post-exploitation activity.
CIS Controls v8CIS-7 — Continuous Vulnerability ManagementKEV-listed exploitation makes prioritised vulnerability handling essential.
CIS-4 — Secure Configuration of Enterprise Assets and SoftwareExposure is reduced by tightening configuration and limiting unnecessary reachability.
Recommendation — Track exposed Bitbucket instances and expedite remediation for known exploited flaws. Harden Bitbucket deployments and remove unnecessary network exposure.

Practitioner Guidance

Why practitioners should care: Treat this as a high-priority vulnerability management issue, not a routine application bug. If Bitbucket is exposed to users or reachable through shared infrastructure, the blast radius can extend well beyond the product itself.

What to watch for: Look for any sign that the instance was contacted before patching, then validate whether repository integrity, automation secrets, and nearby administrative accounts remain trustworthy. A clean patch does not by itself prove the host was never used for post-exploitation activity.

Practitioner takeaway: For exploited repository platforms, remediation and compromise review should move together, because the security question is not only whether the flaw is fixed, but whether trust in the server and its connected secrets still holds.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org