← Back to Cybersecurity News Center
Severity
CRITICAL
CVSS
9.5
Priority
0.938
×
Tip
Pick your view
Analyst for full detail, Executive for the short version.
Analyst
Executive
Executive Summary
On April 22, 2026, attackers compromised the Bitwarden command-line interface package on npm by hijacking its automated publishing workflow, inserting credential-harvesting code that ran silently in any environment that installed the affected version during a 90-minute window. Developers and CI/CD pipelines that pulled @bitwarden/cli@2026.4.0 during that window are at risk of cascading compromise across cloud infrastructure, source code repositories, and AI coding tool configurations. This is not a breach of Bitwarden vaults or end-user password data; the risk is concentrated in engineering and DevSecOps environments where the CLI is used programmatically.
Impact Assessment
CISA KEV Status
Not listed
Threat Severity
CRITICAL
Critical severity — immediate action required
Actor Attribution
HIGH
Unknown — unattributed at time of reporting
TTP Sophistication
HIGH
11 MITRE ATT&CK techniques identified
Detection Difficulty
HIGH
Multiple evasion techniques observed
Target Scope
INFO
@bitwarden/cli v2026.4.0 (npm); GitHub Actions trusted publishing pipeline; secondary exposure: Claude, Kiro, Cursor, Codex CLI, Aider AI coding tool configurations; CI/CD pipelines using affected npm token scope
Are You Exposed?
⚠
Your industry is targeted by Unknown — unattributed at time of reporting → Heightened risk
⚠
You use products/services from @bitwarden/cli v2026.4.0 (npm); GitHub Actions trusted publishing pipeline; secondary exposure: Claude → Assess exposure
⚠
11 attack techniques identified — review your detection coverage for these TTPs
✓
Your EDR/XDR detects the listed IOCs and TTPs → Reduced risk
✓
You have incident response procedures for this threat type → Prepared
Business Context
If any development pipeline installed the compromised package during the exposure window, attackers may hold valid credentials to your cloud infrastructure, source code repositories, and software build systems — enabling unauthorized code commits, infrastructure changes, or lateral movement that could persist long after the initial compromise. A cascading credential compromise in a CI/CD environment can halt software delivery operations and, depending on what was reachable from those pipelines, expose customer data or production systems. Organizations in regulated industries whose engineering pipelines accessed regulated environments through affected credentials face potential breach notification obligations even if vault or customer data was not directly targeted.
You Are Affected If
Your environment installed @bitwarden/cli@2026.4.0 from npm during approximately the 90-minute exposure window on April 22, 2026
Your CI/CD pipelines use the Bitwarden CLI to retrieve secrets and those pipelines ran during the exposure window
Developers on your team use AI coding tools (Claude, Kiro, Cursor, Codex CLI, Aider) on machines where the affected package was installed
Your GitHub Actions workflows or npm publish tokens were accessible from a runner environment that executed the compromised package
You mirror or cache npm packages internally and have not yet verified whether v2026.4.0 was pulled into your internal registry
Board Talking Points
Attackers inserted credential-stealing code into a widely used developer tool distributed through an automated publishing system, giving them potential access to any cloud or code infrastructure reachable from affected build pipelines.
Engineering teams should immediately audit whether any pipeline or developer machine installed the affected version during a 90-minute window on April 22 and rotate all associated credentials within 24 hours.
Organizations that do not act risk persistent attacker access to source code, cloud infrastructure, and software build systems — access that could remain active through reused or unrotated credentials.
Technical Analysis
Affected package: @bitwarden/cli@2026.4.0 (npm).
Removed from registry approximately 90 minutes after publication on April 22, 2026.
Attack vector: threat actors hijacked a GitHub Actions workflow within Bitwarden's CI/CD pipeline and exploited npm's trusted publishing mechanism, assessed as a rare or notable abuse of npm trusted publishing in a supply chain attack context.
The malicious package contained embedded malicious code (CWE-506) that harvested GitHub tokens, npm tokens, cloud provider credentials, and shell history. Exfiltration occurred over encrypted channels to a domain impersonating Checkmarx and to attacker-controlled public GitHub repositories (CWE-829, CWE-312, CWE-522). Relevant MITRE techniques: T1195.001 (Supply Chain Compromise: Compromise Software Dependencies), T1528 (Steal Application Access Token), T1552.001 (Credentials In Files), T1552.004 (Private Keys), T1567.001 (Exfiltration to Code Repository), T1027 (Obfuscated Files or Information), T1078.004 (Valid Accounts: Cloud Accounts). No CVE assigned as of this writing. No vendor CVSS vector provided. Attribution unconfirmed. Organizations should treat any install of v2026.4.0 as a full credential compromise event and initiate immediate credential rotation.
Action Checklist IR ENRICHED
Triage Priority:
IMMEDIATE
Escalate to CISO and legal counsel immediately if forensic review confirms that secrets accessible from affected runners included credentials to systems storing PII, PHI, or PCI-scoped data, or if evidence shows the attacker executed secondary publishes from your npm tokens — either condition triggers breach notification obligations under GDPR Article 33, HIPAA §164.410, or applicable state breach notification laws, and exceeds the response capability of the IR team alone.
1
Step 1: Containment — Identify every system, pipeline, and developer workstation that executed npm install or npm ci referencing @bitwarden/cli@2026.4.0 between approximately 00:00–02:00 UTC on April 22, 2026 (confirm exact window against Bitwarden's advisory). Isolate affected CI/CD runners immediately. Begin rotating all credentials accessible from those environments — GitHub PATs, npm tokens, cloud provider keys — without waiting for confirmed exfiltration. Use your account inventory to scope the rotation. (Cite: NIST AC-2 — Account Management / NIST AC-6 — Least Privilege / CIS 5.1 — Establish and Maintain an Inventory of Accounts / D3-CRO — Credential Rotation)
IR Detail
Containment
NIST 800-61r3 §3.3 — Containment Strategy
NIST IR-4 (Incident Handling)
NIST AC-2 (Account Management)
NIST AC-17 (Remote Access)
CIS 5.4 (Restrict Administrator Privileges to Dedicated Administrator Accounts)
CIS 6.2 (Establish an Access Revoking Process)
Compensating Control
For teams without a centralized SIEM: run `grep -r '@bitwarden/cli' /path/to/repos --include='package-lock.json'` across all developer machines and CI runner file systems to locate version 2026.4.0 references. On GitHub Actions runners, query workflow run logs via GitHub CLI: `gh run list --json startedAt,name,conclusion | jq '.[] | select(.startedAt >= "2026-04-22T00:00:00Z" and .startedAt <= "2026-04-22T02:00:00Z")'`. Immediately revoke GitHub PATs via the GitHub API (`DELETE /applications/{client_id}/token`) and rotate npm tokens via `npm token revoke <token-id>` for every token scoped to the affected pipeline. Isolate CI runners by disabling the runner in GitHub Actions settings (Settings → Actions → Runners → set to Offline) or by blocking outbound network access with a host-based firewall rule (`ufw deny out` on Linux runners).
Preserve Evidence
Before isolating runners, capture: (1) a full snapshot of the runner's npm cache directory (`~/.npm/_cacache/` on Linux, `%AppData%\npm-cache` on Windows) to preserve the v2026.4.0 package tarball and its embedded malicious postinstall script; (2) the process tree at time of discovery using `ps auxf` (Linux) or `Get-WmiObject Win32_Process` (Windows) to identify any child processes spawned by the npm postinstall hook from @bitwarden/cli@2026.4.0; (3) `/proc/net/tcp` or `netstat -antp` output to capture any live outbound connections to attacker-controlled domains at moment of isolation; (4) environment variable dumps (`/proc/<pid>/environ` on Linux) from the npm install process to document which secrets (GITHUB_TOKEN, AWS credentials, npm tokens) were accessible in the runner's environment at time of compromise.
2
Step 2: Detection — Query npm audit logs, package-lock.json files, and CI/CD pipeline logs for installs of @bitwarden/cli version 2026.4.0. Per AU-2 and AU-6, review audit records for the exposure window: search outbound network logs for connections to any domain impersonating 'Checkmarx' (not the legitimate checkmarx.com) and for unexpected HTTPS POSTs from CI runner IPs. Pull GitHub Organization Security logs and filter for oauth_access.create, personal_access_token.create, or unexpected repo.create events during the April 22 window. Review npm access logs for token usage outside normal pipeline hours. Examine shell history files on affected systems for unexpected commands. (Cite: NIST AU-2 — Event Logging / NIST AU-6 — Audit Record Review, Analysis, and Reporting / NIST AU-3 — Content of Audit Records / CIS 8.2 — Collect Audit Logs / D3-LAM — Local Account Monitoring / D3-SFA — System File Analysis)
IR Detail
Detection & Analysis
NIST 800-61r3 §3.2 — Detection and Analysis
NIST AU-2 (Event Logging)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
NIST SI-4 (System Monitoring)
NIST IR-5 (Incident Monitoring)
CIS 8.2 (Collect Audit Logs)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
Compensating Control
Without SIEM: (1) Search all package-lock.json files recursively: `find / -name 'package-lock.json' 2>/dev/null | xargs grep -l '"@bitwarden/cli"' | xargs grep '2026.4.0'`. (2) Query npm access log at `~/.npm/_logs/` for install timestamps matching the 00:00–02:00 UTC window. (3) Search DNS query logs or use `journalctl -u systemd-resolved` (Linux) for queries to Checkmarx-impersonating domains — look for typosquatted variants such as `checkmarx[.]io`, `chekmarx[.]com`, `checkmar[.]xyz`. (4) Run `git log --all --oneline --since='2026-04-22T00:00:00' --until='2026-04-22T02:00:00'` on all local repos to detect unauthorized commits. (5) Query GitHub audit log via API: `GET /orgs/{org}/audit-log?phrase=action:git.push&after=2026-04-22T00:00:00Z` and `GET /orgs/{org}/audit-log?phrase=action:npm.publish`. (6) Use osquery to search shell history: `SELECT * FROM shell_history WHERE command LIKE '%bitwarden%' OR command LIKE '%2026.4.0%'`.
Preserve Evidence
Capture before pivoting on detections: (1) the malicious postinstall script embedded in the v2026.4.0 package (extract from npm cache at `~/.npm/_cacache/content-v2/` by locating the tarball for `@bitwarden/cli@2026.4.0` and inspecting `package/scripts/postinstall.js` or equivalent); (2) outbound HTTP/DNS logs filtered for the 00:00–02:00 UTC window showing any beacon or exfiltration to non-Bitwarden infrastructure — specifically look for base64-encoded POST bodies or multipart uploads to unknown endpoints that would carry harvested environment variables; (3) GitHub Actions workflow run logs (downloadable via `gh run download <run-id>`) for the affected window, preserving the raw log before GitHub's 90-day retention purges them; (4) npm token last-used timestamps from `npm token list` or the npm registry API to identify tokens that authenticated after the install window from unexpected IP ranges; (5) `.bash_history` / `.zsh_history` and PowerShell `ConsoleHost_history.txt` (`%APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\`) from all affected developer workstations.
3
Step 3: Eradication — Rotate all credentials accessible from any affected environment: GitHub PATs and Actions secrets, npm tokens, and cloud provider keys (AWS, GCP, Azure). Apply D3-CRO (Credential Rotation) and D3-CH (Credential Hardening) to ensure rotated credentials meet hardened configuration standards. Remove v2026.4.0 from any internal artifact mirrors or caches. Upgrade to the next clean release of @bitwarden/cli verified against Bitwarden's official advisory. Audit GitHub Actions workflow permissions and restrict GITHUB_TOKEN scopes to the minimum required per AC-6. Verify software inventory reflects only the clean, supported version per CIS 2.2. (Cite: NIST AC-6 — Least Privilege / NIST AC-2 — Account Management / CIS 2.2 — Ensure Authorized Software is Currently Supported / CIS 2.3 — Address Unauthorized Software / D3-CRO — Credential Rotation / D3-CH — Credential Hardening)
IR Detail
Eradication
NIST 800-61r3 §3.4 — Eradication
NIST IR-4 (Incident Handling)
NIST SI-2 (Flaw Remediation)
NIST AC-2 (Account Management)
NIST CM-7 (Least Functionality)
CIS 5.1 (Establish and Maintain an Inventory of Accounts)
CIS 7.2 (Establish and Maintain a Remediation Process)
CIS 7.4 (Perform Automated Application Patch Management)
Compensating Control
Credential rotation without enterprise PAM: (1) AWS — `aws iam delete-access-key --access-key-id <key>` then `aws iam create-access-key`; audit CloudTrail for API calls made by the compromised key using `aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=<compromised-key-id>`. (2) GCP — `gcloud iam service-accounts keys delete <key-id> --iam-account=<sa>`. (3) Azure — revoke via `az ad app credential delete`. (4) For AI tool API keys (Claude/Anthropic, OpenAI Codex): log into each provider console and revoke keys associated with affected developer accounts — document each revocation with timestamp for audit trail. (5) Remove v2026.4.0 from internal mirrors: `npm unpublish @bitwarden/cli@2026.4.0 --registry <internal-registry>` or delete from Artifactory/Nexus via their REST APIs. (6) Restrict GITHUB_TOKEN: add `permissions: read-all` at workflow top level and explicitly grant `contents: write` only to the specific job that requires it, using GitHub Actions workflow YAML `permissions` key.
Preserve Evidence
Before rotating credentials, preserve: (1) AWS CloudTrail events for the compromised access key covering 2026-04-22T00:00:00Z through time of rotation — export via `aws cloudtrail lookup-events` filtered by the key ID, preserving evidence of any S3 exfiltration, IAM privilege escalation, or Lambda/EC2 modifications; (2) GitHub audit log entries for each PAT being rotated, specifically capturing any `git.push`, `repository.create`, `org.invite_member`, or `workflow.created` events post-compromise window; (3) npm registry access logs for the compromised npm token showing any `npm publish` calls, which would indicate the attacker attempted secondary supply chain propagation through packages your pipeline publishes; (4) AI tool API usage logs (Anthropic Console, OpenAI usage dashboard) for the affected key covering the exposure window — an attacker with a Claude/Codex API key could have exfiltrated code context or used the key for unauthorized inference.
4
Step 4: Recovery — After credential rotation, validate CI/CD pipeline integrity by re-running builds from a known-clean state. Per AU-6, confirm no unauthorized commits, package publishes, or infrastructure changes occurred during or after the exposure window. Monitor cloud provider billing and API usage for anomalies indicating ongoing unauthorized access. Re-scan all environments that touched v2026.4.0 using a dependency integrity tool before restoring to production. Verify the software inventory under CIS 2.1 reflects only authorized, verified packages. (Cite: NIST AU-6 — Audit Record Review, Analysis, and Reporting / NIST AU-11 — Audit Record Retention / CIS 2.1 — Establish and Maintain a Software Inventory / CIS 7.2 — Establish and Maintain a Remediation Process / D3-SFA — System File Analysis)
IR Detail
Recovery
NIST 800-61r3 §3.5 — Recovery
NIST SI-7 (Software, Firmware, and Information Integrity)
NIST CP-10 (System Recovery and Reconstitution)
NIST IR-4 (Incident Handling)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
CIS 2.2 (Ensure Authorized Software is Currently Supported)
CIS 7.3 (Perform Automated Operating System Patch Management)
Compensating Control
For teams without enterprise integrity monitoring: (1) Verify clean build state by running `npm ci --ignore-scripts` on a freshly provisioned runner (disable postinstall hooks to prevent re-execution of any cached malicious scripts) and then run `npm audit signatures` to verify package registry signatures for all installed packages. (2) Validate pipeline output integrity: compare SHA-256 hashes of build artifacts produced pre- and post-compromise using `sha256sum` (Linux) or `Get-FileHash` (PowerShell). (3) Audit all git repositories touched by the affected pipeline for unauthorized commits: `git log --all --format='%H %ae %ai %s' --since='2026-04-22T00:00:00' --until=<rotation-timestamp>` — any commit author email not matching your team roster warrants investigation. (4) Check cloud billing anomalies: enable AWS Cost Explorer anomaly detection alerts or GCP Billing Budget alerts; for immediate review, use `aws ce get-cost-and-usage` for the 2026-04-22 period. (5) Re-scan with `npm audit` and `node_modules/.bin/better-npm-audit` after upgrading to the verified clean @bitwarden/cli release confirmed in Bitwarden's official advisory.
Preserve Evidence
Capture for recovery validation: (1) signed provenance attestation for the replacement @bitwarden/cli package, obtainable via `npm audit signatures` — verify the attestation chain traces to Bitwarden's official npm trusted publisher configuration, not the compromised GitHub Actions workflow; (2) diff of all infrastructure-as-code (Terraform state files, CloudFormation stacks, GitHub Actions workflow YAML) between pre-compromise baseline and post-recovery state to detect any backdoor persistence mechanisms the attacker may have inserted during the exposure window; (3) cloud provider API call history for the 24 hours following the exposure window — specifically look for IAM role modifications, new access key creation, Lambda function updates, or S3 bucket policy changes that would indicate attacker persistence beyond the initial token theft.
5
Step 5: Post-Incident — Implement npm package version pinning with integrity hash verification (package-lock.json integrity fields) across all pipelines. Evaluate adoption of npm provenance attestation to detect future trusted publishing abuse. Audit GitHub Actions workflow permissions organization-wide: apply AC-6 least privilege to GITHUB_TOKEN and restrict which workflows can trigger package publishes. Require manual approval gates for any workflow that publishes to npm or cloud artifact registries, enforcing AC-5 separation of duties between build and publish steps. Update the vulnerability management process under CIS 7.1 to include supply chain integrity checks for third-party CI/CD dependencies. Conduct operational dependency mapping to identify all pipelines consuming external npm packages. (Cite: NIST AC-6 — Least Privilege / NIST AC-5 — Separation of Duties / CIS 7.1 — Establish and Maintain a Vulnerability Management Process / CIS 4.6 — Securely Manage Enterprise Assets and Software / D3-ODM — Operational Dependency Mapping / D3-CH — Credential Hardening)
IR Detail
Post-Incident
NIST 800-61r3 §4 — Post-Incident Activity
NIST IR-4 (Incident Handling)
NIST IR-8 (Incident Response Plan)
NIST SI-2 (Flaw Remediation)
NIST SI-7 (Software, Firmware, and Information Integrity)
NIST CM-7 (Least Functionality)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
CIS 7.2 (Establish and Maintain a Remediation Process)
CIS 4.6 (Securely Manage Enterprise Assets and Software)
Compensating Control
Free controls to implement immediately: (1) Enforce package-lock.json integrity — add `npm ci` (not `npm install`) to all pipeline definitions; `npm ci` validates the `integrity` field (SHA-512 hash) in package-lock.json against the downloaded tarball, which would have flagged the tampered v2026.4.0. (2) Enable npm provenance attestation verification: add `npm audit signatures` as a mandatory pipeline step; this verifies each package was built and published by a trusted CI system using OIDC, detecting the kind of GitHub Actions workflow hijack used in this campaign. (3) Add a Sigma rule to your log pipeline (or run as a cron-based grep): detect any npm install of packages with `postinstall` scripts that make outbound network connections — use `sysmon` Event ID 3 (Network Connection) with parent process `node.exe` or `npm.cmd` as the detection anchor. (4) Implement GitHub Actions environment protection rules (free on all GitHub plans): require manual reviewer approval for any job that has `contents: write` permission or publishes to npm, enforced via `environment: production` with required reviewers set. (5) Pin all GitHub Actions to commit SHA rather than mutable tags (e.g., `uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af68` instead of `@v4`) to prevent tag-hijacking attacks analogous to this trusted publishing compromise.
Preserve Evidence
Document for lessons-learned report and future detection: (1) the exact package-lock.json integrity hash discrepancy between the signed clean release and v2026.4.0 — this becomes the baseline IOC for YARA rules targeting future npm supply chain attacks against your package set; (2) the GitHub Actions workflow diff showing the injected malicious publishing step, preserved as evidence for the incident record and as a template for detection rules monitoring workflow YAML changes via `git diff` in a pre-commit hook or GitHub's `workflow_dispatch` audit events; (3) a complete inventory of all pipelines, repositories, and developer workstations confirmed exposed, mapped to the credential types accessible from each — this scoping document satisfies NIST IR-6 (Incident Reporting) requirements and supports any regulatory breach notification assessment if PII or PHI was accessible from the compromised environments.
Recovery Guidance
Do not restore any CI/CD runner or developer environment to production until `npm audit signatures` passes clean against the replacement @bitwarden/cli version confirmed by Bitwarden's official advisory, and until all credentials accessible from those environments have completed rotation with confirmed invalidation of the prior credentials verified via each provider's token audit log. Monitor GitHub organization audit logs, AWS CloudTrail, and GCP Audit Logs continuously for a minimum of 30 days post-recovery for signs of persistence — specifically watch for new OAuth app authorizations, unexpected IAM role assumption patterns, and any npm publish events from your organization's packages, as attackers who obtained npm tokens during the exposure window may have staged a delayed secondary supply chain attack. Treat any AI coding tool configuration file (`.cursor/`, `.aider.conf`, Kiro settings) on affected developer workstations as potentially modified and restore from a pre-compromise backup or clean re-installation before those tools are used against production codebases.
Key Forensic Artifacts
npm cache tarball for @bitwarden/cli@2026.4.0 at ~/.npm/_cacache/content-v2/ (Linux) or %AppData%\npm-cache (Windows) — contains the malicious postinstall script that executed credential harvesting; extract and hash (SHA-256) before any cache-clearing operations
GitHub Actions workflow run logs for all runs between 2026-04-22T00:00:00Z and 2026-04-22T02:00:00Z — downloadable via `gh run download <run-id>` — preserves evidence of which secrets (GITHUB_TOKEN, repository secrets) were injected into the runner environment where the malicious npm postinstall hook executed
Outbound network connection logs (DNS queries and TCP session records) from CI runners and developer workstations during the exposure window — specifically DNS lookups and HTTPS POST requests to Checkmarx-impersonating domains, which is the identified exfiltration channel for harvested environment variable contents including credential strings
Environment variable state at time of npm install — recoverable from /proc/<pid>/environ (Linux) snapshots if the runner was captured live, or from CI/CD platform secret audit logs (GitHub Actions: Settings → Secrets → usage log) — documents precisely which API keys, cloud credentials, and tokens were in scope for exfiltration by the postinstall hook
Git reflog and commit history across all repositories accessible to the compromised GitHub PATs or GITHUB_TOKEN — run `git reflog --all` and `git log --all --format='%H %ae %ai %s' --since=2026-04-22` to detect unauthorized commits, branch creations, or tag modifications that could indicate attacker persistence or secondary supply chain staging using your own repositories
Detection Guidance
Detection for this campaign focuses on four log source categories, each grounded in specific KB controls.
1.
Package Install Records (CIS 8.2 — Collect Audit Logs / NIST AU-2 — Event Logging): Search package-lock.json, yarn.lock, and CI/CD build logs across all pipelines for '@bitwarden/cli' pinned to version '2026.4.0'.
This is the highest-confidence initial indicator.
Automated log collection per CIS 8.2 is a prerequisite — environments without centralized build log retention cannot perform this query retroactively.
2. Network Egress Anomalies (NIST AU-6 — Audit Record Review, Analysis, and Reporting / NIST AU-3 — Content of Audit Records / D3-PBWSAM — Proxy-based Web Server Access Mediation): Query firewall and proxy logs for outbound connections to any domain containing 'checkmarx' that is not the legitimate checkmarx.com. Search for unexpected HTTPS POSTs to github.com/repos originating from CI runner IPs during the 00:00–02:00 UTC April 22, 2026 window. Proxy-based access mediation (D3-PBWSAM) provides the enforcement point for egress filtering and the log source for this query. AU-3 requires that audit records capture source, destination, and timestamp — confirm your proxy logs meet this standard before relying on absence of results as a negative finding.
3. Token and Account Usage Anomalies (NIST AU-6 / NIST AU-12 — Audit Record Generation / D3-LAM — Local Account Monitoring): Pull GitHub Organization Security logs and filter for oauth_access.create, personal_access_token.create, and unexpected repo.create events during the exposure window. Check npm access logs for token usage outside normal pipeline operating hours. D3-LAM applies here: analyze local and service account activity on affected runners for commands or processes inconsistent with normal pipeline behavior. Cross-reference against the account inventory required by CIS 5.1 to identify any accounts whose tokens were exposed but not yet rotated.
4. File System and Configuration Indicators (D3-SFA — System File Analysis / D3-SICA — System Init Config Analysis / NIST AU-2): Review shell history files on affected CI/CD runners and developer workstations for unexpected commands executed post-install. Apply D3-SICA to examine system process startup configurations on affected hosts for persistence mechanisms inserted during the 90-minute exposure window. D3-SFA covers inspection of configuration files and system executables for modification or tampering consistent with the embedded malicious code (CWE-506) described in the technical summary.
Note on IOCs: Specific indicators (Checkmarx-impersonating domain, exfiltration server IPs) were not publicly released as of the article publication date. Detection must rely on behavioral and package version indicators until Bitwarden or a threat intelligence provider publishes confirmed IOCs. Apply NIST AU-13 (Monitoring for Information Disclosure) to monitor open-source intelligence sources for IOC publication. Once IOCs are available, push them to proxy blocklists and SIEM detection rules immediately.
Audit log retention (NIST AU-11 — Audit Record Retention) is a hard dependency: if CI/CD build logs and network egress logs from April 22, 2026 were not retained, retroactive detection for this window is not possible. Confirm retention coverage before concluding no exposure occurred.
Indicators of Compromise (3)
Export as
Splunk SPL
KQL
Elastic
Copy All (3)
1 domain
1 url
1 hash
Type Value Enrichment Context Conf.
⌘ DOMAIN
Checkmarx-impersonating exfiltration domain — specific domain not yet publicly confirmed
VT
US
Threat actors used a domain impersonating Checkmarx (checkmarx.com) to receive encrypted stolen credentials. Specific domain pending publication by Bitwarden or threat intelligence sources.
LOW
🔗 URL
Public GitHub repository used for credential exfiltration — specific repository not yet publicly identified
VT
US
Stolen data was exfiltrated to one or more attacker-controlled public GitHub repositories. Specific URL pending disclosure.
LOW
# HASH
@bitwarden/cli@2026.4.0 npm package — integrity hash pending vendor publication
VT
MB
The malicious npm package version 2026.4.0. Compare package-lock.json integrity field against Bitwarden's official advisory once published.
HIGH
Platform Playbooks
Microsoft Sentinel / Defender
CrowdStrike Falcon
AWS Security
🔒
Microsoft 365 E3
3 log sources
Basic identity + audit. No endpoint advanced hunting. Defender for Endpoint requires separate P1/P2 license.
🛡
Microsoft 365 E5
18 log sources
Full Defender suite: Endpoint P2, Identity, Office 365 P2, Cloud App Security. Advanced hunting across all workloads.
🔍
E5 + Sentinel
27 log sources
All E5 tables + SIEM data (CEF, Syslog, Windows Security Events, Threat Intelligence). Analytics rules, playbooks, workbooks.
IOC Detection Queries (1)
1 URL indicator(s).
KQL Query Preview
Read-only — detection query only
// Threat: Bitwarden CLI Supply Chain Compromise: GitHub Actions Abuse Turns Developer Tool
let malicious_urls = dynamic(["Public GitHub repository used for credential exfiltration — specific repository not yet publicly identified"]);
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has_any (malicious_urls)
| project Timestamp, DeviceName, RemoteUrl, RemoteIP,
InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
MITRE ATT&CK Hunting Queries (4)
Sentinel rule: Sign-ins from unusual locations
KQL Query Preview
Read-only — detection query only
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| summarize Locations = make_set(Location), LoginCount = count(), DistinctIPs = dcount(IPAddress) by UserPrincipalName
| where array_length(Locations) > 3 or DistinctIPs > 5
| sort by DistinctIPs desc
Sentinel rule: Encoded command execution
KQL Query Preview
Read-only — detection query only
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine matches regex @"[A-Za-z0-9+/]{50,}={0,2}"
or ProcessCommandLine has_any ("-enc ", "-encodedcommand", "frombase64string", "certutil -decode")
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "certutil.exe")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, AccountName
| sort by Timestamp desc
Sentinel rule: Suspicious scheduled task creation
KQL Query Preview
Read-only — detection query only
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "schtasks.exe"
| where ProcessCommandLine has "/create"
| where ProcessCommandLine has_any ("/sc minute", "/sc hourly", "powershell", "cmd /c", "http", "\\\\", "frombase64")
| project Timestamp, DeviceName, ProcessCommandLine, AccountName, InitiatingProcessFileName
| sort by Timestamp desc
Sentinel rule: Suspicious PowerShell command line
KQL Query Preview
Read-only — detection query only
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe")
| where ProcessCommandLine has_any ("-enc", "-nop", "bypass", "hidden", "downloadstring", "invoke-expression", "iex", "frombase64", "new-object net.webclient")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, AccountName, InitiatingProcessFileName
| sort by Timestamp desc
Falcon API IOC Import Payload (1 indicators)
POST to /indicators/entities/iocs/v1 — Weak/benign indicators pre-filtered. Expiration set to 90 days.
Copy JSON
[
{
"type": "domain",
"value": "Checkmarx-impersonating exfiltration domain \u2014 specific domain not yet publicly confirmed",
"source": "SCC Threat Intel",
"description": "Threat actors used a domain impersonating Checkmarx (checkmarx.com) to receive encrypted stolen credentials. Specific domain pending publication by Bitwarden or threat intelligence sources.",
"severity": "medium",
"action": "no_action",
"platforms": [
"windows",
"mac",
"linux"
],
"applied_globally": true,
"expiration": "2026-08-19T00:00:00Z"
}
]
No hard IOCs available for AWS detection queries (contextual/benign indicators excluded).
Compliance Framework Mappings
T1567.001
T1078.004
T1027
T1053.003
T1195.001
T1078.001
+5
SI-3
SI-4
CM-7
IA-5
SR-2
SC-13
164.308(a)(5)(ii)(D)
164.312(d)
164.312(e)(1)
MITRE ATT&CK Mapping
T1567.001
Exfiltration to Code Repository
exfiltration
T1027
Obfuscated Files or Information
defense-evasion
T1195.001
Compromise Software Dependencies and Development Tools
initial-access
T1528
Steal Application Access Token
credential-access
T1608.001
Upload Malware
resource-development
T1552.001
Credentials In Files
credential-access
Guidance Disclaimer
