CrowdSec、2026年5月のソースコード流出を認める——原因はTanstack侵害か
CrowdSec Source Code Leak
CrowdSecは2026年5月に発生したGitHubリポジトリからのソースコード流出を確認した。流出したのは非公開のSaaSコンソールやAWS関連コード、コネクタなどで、公開のSecurity Engineは対象外。クライアントデータやPII、認証情報の漏洩はなく影響はCrowdSec内に限定されると説明。侵入経路としてTanstackの侵害が濃厚で、同社はトークンを即時ローテーションし監視を続ける。
流出したコードには価値があるが、CrowdSecを本当に傷つけることはできない。我々の効率性はネットワーク効果と規模に依存しており、コードだけではそれを再現できないからだ。
HNでの議論
40- mewse-hn
今朝、Debian 13のVPSでcrowdsecのインストールをトラブルシューティングして直すのに時間を費やした後でこれを見るのは面白い。どうやら彼らは、直接彼らからではなく古いDebianパッケージ版を動かしているという理由で、私のマシンへのコミュニティブロックリストの提供を止めたらしい（http 500）。私は彼らのSaaSプラットフォームにより強く縛られるよりも、公開されているソースからLLMにブロックリストを作らせた。
- 6thbit
> the Tanstack compromise is very likely to have been the leak vector
....appears to have been backdoored to extract an API key with authorization to read the private codebase.
...
> immediately rotated all required tokens & credentials to prevent further incidents.
APIキーをローテーションしただけでは、彼らが「さらなるインシデントを防ぐ」立場に立ったとは言い難いのではないだろうか？次のPyPI/npmのサプライチェーン問題で、新しいキーがただ手に入るだけでは？
そのキーが何に使われているにせよ、見直して可能ならスコープを絞り直すべきなのでは？
GitHubでは、特定のAPIキーを使ってリクエストを発信できる場所を制限できるのだろうか？それとも、まだそこまでには至っていないのだろうか？
- sandeepkd
面白いことに、ウェブサイトのタグラインを読むと、どうやら彼らは誰があなたを攻撃しているかは分かると主張しているが、自分たちを攻撃した誰かについてはちょうど見落としているようだ。
結局のところ、彼らは本当のセキュリティ企業ではなく、悪いIPのアグリゲーターにすぎない。理想的には、この種のアグリゲーター問題は、データを提供するのに一定の信頼性が求められ、データを照会するのにセットアップを維持するための名目上の料金がかかる、信頼された非営利企業に最も適している。
- itintheory
我々はボット/スクレイピング対策としてCrowdSecを導入した。アーキテクチャは堅牢だが、結果として我々にとって許容できないほどの誤検知率となった。これはどんな種類のIPレピュテーションアプローチにもある問題かもしれない。導入準備に2ヶ月ほどかけた後、数日でオフにしなければならなかった。
- giancarlostoro
コードを抽出するために必要な認証情報をエクスプロイトが奪ったように聞こえる。Ubikey + gitアクセス用のSSL証明書があれば、この漏洩全体を防げたのではないかと思わされる。