Yes. CISA added CVE-2022-36804 to its Known Exploited Vulnerabilities catalogue on 30 September 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Any organisation running the affected product should treat remediation as urgent. Check exposure first, then patch or mitigate, then review logs for signs of earlier compromise.
What “exploited in the wild” means for this CVE
For a CVE like this, the practical question is not whether the flaw exists, but whether attackers are already using it against real systems. CISA’s KEV listing is the strongest public signal that exploitation has moved beyond theory and proof-of-concept testing. That makes the issue operational, not academic, because defenders must assume the vulnerability is already part of active attack paths.
When a command injection flaw reaches that stage, exposure can translate quickly into remote code execution, data access, or foothold creation. The immediate task is to identify whether the product is present, whether it is internet-facing or otherwise reachable by an attacker, and whether compensating controls are actually limiting exploitation.
How to confirm exposure and prioritise response
Start with a simple asset check: do you run the affected Atlassian Bitbucket Server or Data Center product anywhere, including test, lab, or overlooked internal instances? If yes, treat every reachable deployment as a candidate for urgent action until version and patch status are verified through the vendor advisory and the KEV catalogue.
Prioritisation should be driven by exposure, not by convenience. An authenticated internal-only instance is still worth immediate attention, but an externally reachable system, a system with privileged integrations, or a system with broad repository access deserves faster escalation because command injection on a collaboration platform can have wide blast radius.
For a deeper triage workflow, use a Zero-Day and Exploited Vulnerabilities Guide to frame KEV-driven prioritisation, emergency mitigation, and post-patch hunting. If you want a broader operational process for scoring and tracking exposures, the Vulnerability Management Guide covers asset scoping, KEV triage, SLAs, and verification.
Containment, patching, and compromise review
If the product is exposed, patching or vendor-recommended mitigation should be the first response, not a later maintenance task. If patching must wait, reduce attack surface immediately by removing unnecessary network exposure, tightening access paths, and monitoring the application and host for suspicious execution behaviour.
Because this is a command injection issue, you should also look backward, not only forward. Review application, system, and authentication logs for unusual process launches, web request anomalies, unexpected child processes, and any signs that an attacker used the Bitbucket host as an initial foothold or staging point. If there are signs of compromise, treat credential rotation and session review as part of the incident response, especially for any accounts, tokens, or service integrations that had access to repositories or administrative functions.
Where Atlassian environments are already in scope, the Atlassian Cloud Security Guide is useful for understanding the broader control surface around permissions, admin access, and API tokens. For real-world context on how adjacent Atlassian compromise often cascades through service tokens and accounts, Cloudflare Thanksgiving breach 2023 is a useful reminder that one exposed control plane can create wider identity and access exposure.
Risk and Threat Considerations
Command injection on an exposed collaboration or source-control platform is especially dangerous because attackers can often turn one request into server-side execution, then pivot into code, secrets, or internal systems. The main risk is not just service disruption, but trust-boundary collapse: a platform that stores or brokers repository access can become a stepping stone to broader compromise.
Failure mechanism: An attacker sends a crafted request that the vulnerable server interprets as an operating-system command, then uses that execution to enumerate the host, steal credentials or tokens, or implant persistence.
Impact: The outcome can include repository theft, malicious code changes, lateral movement, and further compromise of connected systems, especially where the Bitbucket instance has privileged integrations or reused credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Active exploitation makes rapid vuln triage and remediation central to this CVE. |
| Recommendation — Prioritise KEV-listed exposure and verify remediation with continuous vulnerability management. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerabilities Are Identified and Documented | The answer depends on confirming where Bitbucket is deployed and exposed. |
| PR.IP-12 — Vulnerability Management | Urgent patching and mitigation are the core defensive actions for an exploited CVE. | |
| Recommendation — Identify affected Bitbucket assets and document their exposure before remediation. Apply vulnerability management to patch or mitigate the exposed Bitbucket deployment quickly. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | KEV status requires continuous monitoring and verification of exposure and fix state. |
| Recommendation — Scan for the vulnerable product and confirm remediation with vulnerability monitoring. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Command injection is a code-execution flaw that maps to secure design and validation failure. |
| Recommendation — Review server-side input handling and command execution paths to prevent injection. | ||
Practitioner Guidance
What to verify: Confirm whether every Bitbucket Server or Data Center instance is inventoried, internet exposure is known, and patch or mitigation status is validated from the vendor advisory rather than assumed from change records.
Decision rule: If the system is reachable and unpatched, treat it as urgent remediation. If patching is delayed, assume the system may already be targeted and move immediately to containment, log review, and blast-radius reduction.
What practitioners underestimate: The biggest mistake is focusing only on the CVE itself and overlooking the surrounding access paths. On a source-control platform, one exploited server can expose code, secrets, deployment credentials, and downstream systems in a single incident.
Practitioner takeaway: For KEV-listed flaws, the right question is not whether exploitation is theoretically possible, but whether your instance is still exposed and whether you have already checked for signs that someone else was first.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2022-36804 (Atlassian Bitbucket Server and Data Center Command Injection)?
- CVE-2022-36804 (Atlassian Bitbucket Server and Data Center Command Injection)
- Is CVE-2019-3396 (Atlassian Confluence Server and Data Center Server-Side Template Injection) being exploited in the wild?
- Is CVE-2023-22527 (Atlassian Confluence Data Center and Server Template Injection) being exploited in the wild?