Executive Summary

Our software supply chain security feed detected a compromised release of the popular AI assistant Cline. It was first reported by Adnan Khan and is tracked as GHSA-9ppg-jx86-fqw7. 

Version 2.3.0 of the Cline CLI npm package uses a post-install hook to automatically install OpenClaw on the same machine. The malicious version has been flagged in the meantime, but the tarball and metadata are still available at the time of writing.

As visible from the metadata, the attacker supposedly got hold of a long-lived token to publish the malicious version, thereby bypassing the trusted publication process established by the Cline maintainers.

Overall impact is considered low, despite high download counts: OpenClaw itself is not malicious, and the installation does not include the installation/start of the Gateway daemon.

Still, this event emphasizes the need for package maintainers to not only enable trusted publishing, but also disable publication through traditional tokens – and for package users to pay attention to the presence (and sudden absence) of corresponding attestations.

Impacted Versions

‍

The compromised version installs the popular open source package OpenClaw using npm install -g openclaw@latest. Because the package is benign, the impact of this attack is considered low. In particular, the compromised version does not install/start the Gateway daemon (launchd/systemd user service).

The monthly download count for the timeframe from Jan 19 to Feb 17 is 418,545, which means that the malicious version has probably been installed on many machines -- supposedly developer or end-user machines.

Technical Analysis

Overall, considering the simplistic trigger through an installation hook and the (unwanted) installation of an otherwise benign package, this attack has more the character of a prank than a serious attack.

Still, the detection of this malware by our AI-based analysis pipeline confirms our belief that differential analyses are one key ingredient of effective malware detection: Several signals collected for every package version under analysis put specific focus on the comparison of code and metadata to its preceding version.

In this particular case, our engine noticed the following differences:

1. The addition of a post-install hook in version 2.3.0

‍

2. The lack of provenance information and a change of the publisher account

‍

Rightfully, the final verdict for this package version picks this information up, providing a concise summary of the malicious characteristics:

Mitigations

Check whether you run the infected version of Cline using cline –version. If yes, update to the latest version (2.4.0) and remove OpenClaw using npm uninstall -g openclaw.

At this point, the rotation of credentials or other secrets is NOT needed. 

Takeaways

There are several important takeaways for package maintainers and consumers.

The Cline maintainers enabled trusted publishing, which is considered a best practice: It allows publishing packages from trusted platforms like GitHub or GitLab using short-lived OICD tokens, as opposed to using traditional tokens, which have been compromised again and again to publish malicious versions.

Once configured, package versions published are labelled correspondingly on npmjs.org:

However, the Cline maintainers – as far as we can tell from the metadata – did not disable token-based publication, which is also promoted on the npm documentation:

“Once you've configured trusted publishers for your package, we strongly recommend restricting traditional token-based publishing access for enhanced security.”

This becomes visible from the metadata of the malicious version, which differs between versions 2.2.3-nightly.1771330659 and 2.3.0, and suggests that the long-lived token of npm account clinebotorg got compromised by the attacker to publish this malicious version.

     "dist": {
        "shasum": "a746385d45c949afd1d40e577cfb49da71efcd44",
        "tarball": "https://registry.npmjs.org/cline/-/cline-2.3.0.tgz",
        "fileCount": 20,
        "integrity": "sha512-ZYoMvFhYaxzCM2PzDAYkz6oDNCPjMwDBqY/2euFUxFxb3SCE1VnXJvj6iC50NdtgECY195zIXK2s2Wbx+quDHg==",
        "signatures": [
          {
            "sig": "MEQCIE4emS01dFF03ZWfe3ssawCLoofgwrBBzSNk6FHDGvyrAiBULPYEnr3sOE3rFAb5ycqrhjS6rYL52ggdq8mAzYNfhg==",
            "keyid": "SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"
          }
        ],
        "unpackedSize": 53932164
      },
<snip>
      "_npmUser": {
        "name": "clinebotorg",
        "email": "engineering@cline.bot"
      },

Version 2.3.0

‍

 "dist": {
        "shasum": "bcbac640b0e842d46c921f6a3a318741c24a4d6a",
        "tarball": "https://registry.npmjs.org/cline/-/cline-2.2.3-nightly.1771330659.tgz",
        "fileCount": 18,
        "integrity": "sha512-hE8uoHvTzKIcH1pFZ88YV09bGcNFxGv8Z3yaIjF+uxnFV4iAXN2xnZ35zNDudCC4OIS5ub6DT7y56xnxjljk5Q==",
        "signatures": [
          {
            "sig": "MEYCIQDR3ldlRWfELDH831KUlUqNOLjz6P0gex4ldVoxXqX73wIhAKaF0Jv8co9XwtJZDyYPr+K+KxnZT0y46X8s3UVqvpbh",
            "keyid": "SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"
          }
        ],
        "attestations": {
          "url": "https://registry.npmjs.org/-/npm/v1/attestations/cline@2.2.3-nightly.1771330659",
          "provenance": {
            "predicateType": "https://slsa.dev/provenance/v1"
          }
        },
        "unpackedSize": 53932150
      },
<snip>
      "_npmUser": {
        "name": "GitHub Actions",
        "email": "npm-oidc-no-reply@github.com",
        "trustedPublisher": {
          "id": "github",
          "oidcConfigId": "oidc:a70d39d6-604d-4920-9966-e3317287dca7"
        }

Version 2.2.3-nightly.1771330659

‍

For package users, with more and more packages using trusted publishing, it makes sense to inspect new versions for the presence (or absence) of attestations before installation.

However, this seems viable only for direct dependencies, which is just a small fraction of dependencies being downloaded and installed on developer and CI/CD machines.

With hundreds or thousands of transitive dependencies, developers need tool support from npm and other package managers to better control dependencies, e.g., to disable the installation of (or update to) versions that do not have any attestations – or not any longer, as in the case of cline@2.3.0.

Acknowledgments

Kudos to Adnan Khan for detecting and reporting the incident through GitHub.