What Happened
On February 17, 2026, an attacker exploited a compromised npm publish token to release Cline CLI version 2.3.0, an unauthorized update that installed OpenClaw on developer systems. This malicious package was downloaded approximately 4,000 times in an eight-hour window before detection. The root cause was a misconfigured GitHub Actions workflow that exposed publication secrets and enabled arbitrary code execution.
This was not a zero-day exploit or a sophisticated social engineering campaign. It was a configuration error in a CI/CD pipeline that gave an attacker access to a trusted package.
Timeline
February 17, 2026 - Morning: The attacker exploited a misconfigured GitHub Actions workflow to access the npm publish token.
February 17, 2026 - Shortly after token compromise: Cline CLI version 2.3.0 was published to the npm registry containing the OpenClaw payload.
February 17, 2026 - Eight-hour window: The malicious package was downloaded approximately 4,000 times by developers running routine updates.
February 17, 2026 - Evening: The unauthorized package was detected and removed from the npm registry.
The speed of propagation shows why supply chain attacks are effective: developers trust their package managers, and automated dependency updates can spread compromised code across entire organizations before anyone notices.
Which Controls Failed or Were Missing
Secrets Management in CI/CD
The GitHub Actions workflow allowed access to the npm publish token through a configuration that didn't properly restrict permissions. The workflow likely used a long-lived token with write access to the npm registry, stored as a repository secret without additional protection layers.
Your CI/CD pipeline should never grant workflow runs blanket access to publication credentials. The attacker didn't need to break encryption or bypass authentication—the workflow configuration did that for them.
Workflow Execution Controls
The misconfiguration enabled arbitrary code execution within the GitHub Actions environment. This suggests the workflow accepted external input without validation or ran untrusted code before credential access was restricted.
Package Verification
The npm registry accepted the publication because the token was valid. There was no secondary verification step—no human approval, no signature verification from a separate key, no anomaly detection on publication patterns.
Runtime Monitoring
Four thousand downloads occurred before detection. This indicates missing or inadequate monitoring of package behavior post-publication. No automated system flagged the sudden appearance of OpenClaw installation routines in a CLI tool update.
What the Relevant Standards Require
NIST 800-53 Rev 5: Supply Chain Risk Management
Control SR-3 (Supply Chain Controls and Processes) requires organizations to establish controls throughout the system development life cycle to identify and mitigate supply chain risks. This includes validating that external system services and components meet security requirements.
Your GitHub Actions workflow is part of your supply chain. The token management failure violates SR-3's requirement to implement security safeguards for supply chain elements.
Control SR-11 (Component Authenticity) mandates anti-counterfeit measures and provenance verification. Publishing packages without multi-factor authentication or code signing fails this control entirely.
PCI DSS v4.0.1: Secure Development
Requirement 6.3.2 states that changes to system components in production must be managed through change control procedures. Automated publication without human verification or rollback capability doesn't meet this bar.
Requirement 6.5.5 requires protection against common coding vulnerabilities, including injection flaws. A workflow that accepts arbitrary code execution through misconfiguration is a code injection vulnerability in your deployment pipeline.
SOC 2 Type II: Logical Access Controls
CC6.1 requires implementation of logical access controls to prevent unauthorized access to information and systems. A misconfigured workflow that exposes publication tokens fails to restrict access to authorized users and programs.
CC7.2 requires monitoring of system components to detect anomalies. The eight-hour window before detection indicates insufficient monitoring of package publication events and post-release behavior.
ISO/IEC 27001:2022: Access Control
Control 5.15 (Access Control) requires rules to control physical and logical access to information and assets. Your npm publish token is a critical asset. Storing it where a misconfigured workflow can expose it violates this control.
Control 5.23 (Information Security for Use of Cloud Services) requires security measures for cloud service usage. GitHub Actions is a cloud service. Your configuration must ensure secrets remain protected even if workflow definitions change.
Lessons and Action Items for Your Team
Immediate Actions
Rotate all publication tokens now. If you're using GitHub Actions to publish packages, assume your current tokens could be exposed through similar misconfigurations. Generate new tokens with minimum required permissions.
Audit workflow permissions. Review every GitHub Actions workflow that accesses secrets. Search your .github/workflows directory for secrets. references and verify each workflow uses permissions: blocks to restrict token scope.
Enable package provenance. npm now supports package provenance using Sigstore. Configure your workflows to publish with the --provenance flag. This creates a verifiable link between your source code, build process, and published package.
Configuration Changes
Implement environment protection rules. GitHub allows you to require manual approval before workflows can access secrets in specific environments. Create a production environment for your npm token and require approval from two maintainers before any workflow can publish.
Use OIDC instead of long-lived tokens. GitHub Actions supports OpenID Connect, allowing workflows to request short-lived tokens from npm without storing credentials. This eliminates the risk of token exposure entirely.
Restrict workflow triggers. If your workflow runs on workflow_dispatch or pull_request, add explicit conditions that prevent secret access during untrusted runs. Use if: github.event_name == 'push' && github.ref == 'refs/heads/main' to limit when publication can occur.
Monitoring
Monitor package downloads post-publication. Set up alerts for unusual download patterns in the first hour after publishing. A spike to 4,000 downloads in eight hours should trigger investigation.
Implement post-release scanning. Configure automated scanning of your own packages after publication. Tools like Socket or Snyk can detect when your package suddenly includes unexpected dependencies or behaviors.
Track workflow execution. Enable GitHub Actions audit logging and send workflow execution events to your SIEM. Alert on workflow runs that access publication secrets, especially if they occur outside normal release schedules.
The Cline CLI attack succeeded because configuration errors in automation are invisible until exploited. Your CI/CD pipeline is now part of your attack surface. Treat it accordingly.
