#npm

この症状は、少なくとも報告されている範囲では Termux / Android と、macOS 上での npm グローバルインストールまわりの2系統に分かれていました。どちらも、`claude` を起動したときに 「native binary が見つからない」 形で止まります。ただし、解決済みの共通パターンはまだ見えていません。 Android 側の報告は [#50270](https://github.com/anthropics/claude-code/issues/50270) です。ここでは、v2.1.113 以降で Claude Code が JavaScript のエントリポイントから glibc のネイティブ Linux バイナリに切り替わり、Termux では動かなくなったと書かれています。報告者は、v2.1.112 は動くが v2.1.113 と v2.1.114 は壊れると述べています。 macOS 側の報告は [#84224](https://github.com/anthropics/claude-code/issues/84224) です。こちらは別の

この記事を読んでまず思ったのは、「パッケージを入れるだけでここまでやられるのか」という、かなり素朴で、それでいて重い怖さでした。npm の malware というだけなら珍しくないのですが、今回は単に credential を抜くだけで終わらず、感染した package からさらに別の package へ広がっていく“worm”になっている。しかも開発者の手元だけでなく CI 環境まで狙っているので、被害の入口がかなり広い。ライブラリを `install` した瞬間の lifecycle script がこんなに危ないのだと、あらためて突きつけられます。 特に引っかかったのは、「署名や provenance があるから安心、とはならない」点です。GitHub Actions の正規の release workflow を通っていて、OpenID Connect や SLSA の provenance まで付いていたとある。でも、それでも中身が安全だとは言えなかった。ここはかなり厄介で、いまの開発現場が頼っている“信頼の見え方”が、攻撃者の動き方と相性が悪いのだと思います。証明書や ba

GitHub issue #492 では、`@redhat-cloud-services/` 配下の多数の npm package で悪意あるリリースが見つかったと報告されています。 影響を受けたのは、`frontend-components` や `insights-client`、`rbac-client` など、かなり広い範囲です。 ここでいう「npm package」は、JavaScript/TypeScript開発で使う部品の配布物のこと。これが汚染されると、使う側のアプリにも被害が波及する可能性があります。 こういう事件の怖さは、自分のコードに何も悪くなくても巻き込まれるところだと思います。 依存パッケージの version 固定、lockfile の確認、セキュリティフィードの監視がかなり重要です。 GitHub の issue #492 では、`@redhat-cloud-services/` スコープに属する複数の npm package で、malicious npm releases（悪意ある npm リリース）が検出されたと報告さ

npm に staged publishing が追加され、公開前に人間による 2FA承認 が必要になった これにより、CI/CD からの自動公開でも「本当に人が関与したか」を確認しやすくなる `npm stage publish` は npm CLI 11.15.0 以降 が必要 既存の `-allow-git` に加えて、非 registry 由来の install 元を制御する3つのフラグが追加された いまソフトウェアサプライチェーン攻撃が増えているので、こうした防御はかなり重要 npm と GitHub が、ソフトウェア供給網のセキュリティを強化する新しい仕組みを出しました。 ざっくり言うと、「npm パッケージを公開するときに、勝手に世に出ていかないようにする」ための対策です。 これ、地味に見えてかなり重要です。というのも、近年の攻撃者は「アプリ本体」よりも、開発者が日常的に使うライブラリやパッケージ管理の流れを狙うことが増えているからです。つまり、1つの悪意ある更新が入るだけで、多くの開発現場に一気に広がってしまうわけです。い

TeamPCP と呼ばれる攻撃グループが、ソフトウェア供給網攻撃（開発者が使う正規の配布経路を悪用する攻撃）を複数のエコシステムで同時進行させた。 2026年5月の1週間で、GitHubの内部リポジトリ侵害、Microsoft公式Python SDKの改ざん、npmエコシステムへの大量混入が立て続けに起きた。 特に厄介なのは、verified-publisher badge や Sigstore verification badge のような「見た目の信頼材料」が、今回あまり当てにならなかったこと。 攻撃は単なる情報窃取にとどまらず、worm（自己増殖型） や wiper（消去型） の要素まで含み、破壊性が一段上がっている。 防御側は、install時の見た目を信用しすぎず、lockfileのハッシュ確認 や 実際の振る舞い監視 に寄せる必要がある。 SANS Internet Storm Center の記事は、2026年5月24日時点での TeamPCP 系キャンペーンを総まとめしたもの

露出したばかりのShai-Hulud wormのsource codeを使った初期のクローン攻撃が確認された 攻撃者はNPM（JavaScriptのパッケージ配布基盤）に悪意あるパッケージを公開していた その中にはShai-Huludをほぼそのまま写したものもあれば、typosquatting（似た名前で誤クリックを狙う手口）やDDoS botnetを使うものもあった つまり、1人の攻撃者が複数の手口を使い分けており、今後さらに供給網攻撃が増える前触れかもしれない SecurityWeekによると、Shai-Hulud wormのsource codeがGitHubで公開されてから、わずか数日で“クローン”が出てきたそうです。調べたのはOx Securityです。 ここでいう worm は、いわゆる自己増殖するマルウェアです。感染した端末からさらに広がるので、普通のマルウェアよりもずっと厄介。しかも今回のShai-Huludは、感染した開発者のcredentials（認証情報）、API keys、tokens、その

この記事は、npmのサプライチェーン攻撃をネタにした風刺記事 「防ぎようがない」と言う開発者たちを、かなり痛烈に皮肉っている npmは便利な一方で、大量の第三者パッケージに依存しやすいのが弱点 Go、Rust、Web APIs のように、標準機能が強い環境との対比が面白い ただのジョーク記事ではあるけれど、依存関係の管理と安全設計の重要さはかなり本質的 Kevin Patel の記事は、「npmで起きるサプライチェーン攻撃は、もうどうしようもない」という空気を、これでもかというほど皮肉った風刺です。 元記事では、npmレジストリで壊滅的な攻撃が起きて、企業アプリが大量に巻き込まれ、ユーザーデータも漏れた、という設定で話が進みます。 そのうえで、開発者たちが「仕方ないよね」「現代のWeb開発の代償だよ」と、まるで天災みたいに受け止めている様子が描かれます。 これがかなり痛烈です。 というのも、実際のセキュリティ事故では、後から「予防は難しかった」と言われがちですが、この記事はそこに真正面からツッコミを入れているわけです。 **本当に防げなかったのか

npmのメンテナーアカウント `atool` が侵害され、317個のパッケージに637個の悪性バージョンが公開された 影響を受けた中には `size-sensor`、`echarts-for-react`、`timeago.js`、そして多数の `@antv` 系パッケージが含まれる 月間ダウンロード数は合計で1500万超とされ、被害範囲がかなり広い ペイロードは認証情報の収集、GitHubへの漏えい、CI/CDへの永続化、AI開発ツールの乗っ取りまでやる しかも、単純な1回きりの攻撃ではなく、複数の経路で再感染しやすい設計になっているのが厄介 semver範囲（`^3.0.6` のような指定）を使っていると、`latest` タグを見ていなくても悪性版を自動で拾う可能性がある SafeDepの記事によると、2026年5月19日、npm のメンテナーアカウント `atool` が侵害されました。 その結果、22分という短時間に、317個のパッケージへ637個の悪性バージョンが一気に公開されたそうです。 ここで地味に