Grafana Labs GitHub環境への不正アクセス：コードベース流出インシデントの全容と防御策

2026年5月17日、Grafana Labsの公式Xアカウントが6連投の重大スレッドを公開した。「不正な第三者がGrafana LabsのGitHub環境にアクセスできるトークンを入手し、コードベースをダウンロードした」という内容に加え、顧客データへのアクセス痕跡なし・身代金要求あり・FBI公式見解に従って支払い拒否という重要な続報も同時公表された。

監視ツールの雄が、監視される側になった。GitHubトークン1本が奪われ、数千本のリポジトリを抱えるGrafana Labsのコードベースが外部者の手に渡ったとされる。一方でGrafana Labsはオープンソース企業として身代金要求を即座に拒否し、その判断を公然と表明した。本記事では公式スレッド全文と外部脅威インテリジェンスから確認された事実と推測を明確に区別しながら、この事案の技術的・組織的な意味と、企業が今すぐ実施すべき防御策を整理する。

本インシデントはGitHub CI/CDを狙ったサプライチェーン攻撃の新たな事例です。攻撃手法・防御の全体像は サプライチェーンセキュリティ完全ガイド2026｜攻撃手法・防御ツール・実践チェックリスト で解説しています。

インシデントの概要：公式声明スレッド（6連投）の全文要点

Grafana Labsは2026年5月17日、公式Xアカウントで6連投のスレッドを公開した。当初の第1投で「不正な第三者がトークンを入手し、コードベースをダウンロードした」と発表した後、続く2〜6投目で被害評価・対応状況・身代金要求への対応方針まで踏み込んで開示している。

このスレッドにより、当初不明だった被害範囲と組織の対応方針が大きく明らかになった。重要なポイントは3つだ。

第一に、顧客データや個人情報への不正アクセスは確認されていない。Grafana Cloud利用者・OSS利用者の本番システムには現時点で影響なしと公式に明言された。

第二に、攻撃者はコードベース公開を防ぐ対価として身代金を要求した。これは典型的なデータ窃取型ランサムウェアの恐喝モデル（後述するcoinbasecartelの手口と一致）であり、データ暗号化は伴わないことが裏付けられた。

第三に、Grafana LabsはFBIの公式見解に従って身代金支払いを明確に拒否した。これはオープンソース企業として身代金市場への資金供給を断つ責任ある姿勢であり、業界全体にとって重要な前例となる。

一方で、以下の点はこの記事の執筆時点（2026年5月17日）で公式の詳細レビュー（PIR）を待つ必要がある。

• トークンがどのような手口で窃取されたか（フィッシング・IAB・コミット履歴漏れなど）
• どのリポジトリが対象になったか（全リポジトリか特定のリポジトリか）
• ダウンロードされたコードベースの容量・内容範囲
• 攻撃者の特定・帰属（Attribution）の正式確認（後述するcoinbasecartel関与の公式認定）
• 今後の追加防御策の詳細

Grafana Labsは2025年4月のGitHub Actionsインシデントにおいても迅速で透明性の高い情報開示を行った実績があり、今回も同様に詳細なPost-Incident Review（PIR）が公開される見込みだ。

攻撃の連鎖構造：トークン窃取からコードベース流出まで

現時点で判明している情報をもとに、攻撃の一般的な経路を図示する。以下の図には推定的な部分が含まれることを明記する。

初期侵入の手口は現時点で未公表だが、脅威インテリジェンスの観点から複数の仮説が考えられる。一つはフィッシング・ソーシャルエンジニアリングによる認証情報の直接窃取、もう一つはInitial Access Broker（IAB）経由で購入した認証情報の利用だ。

なぜGitHubトークン1本でコードベースが取れるのか

GitHubのPersonal Access Token（PAT）やGitHub App tokenは、適切にスコープ設定されていない場合、組織内の複数リポジトリへの読み取り権限を一括で持つ。古典的な「Classic PAT」は特定のリポジトリではなくスコープ（repo、read:orgなど）単位で権限が付与されるため、1本のトークンで組織全リポジトリへのアクセスが可能になる。

# トークンのスコープを確認するコマンド（漏洩したトークンの調査に使用）
curl -H "Authorization: token YOUR_TOKEN" \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/user | jq '{login: .login, scopes: .X-OAuth-Scopes}'

# レート制限情報でトークンの有効性を確認
curl -I -H "Authorization: token YOUR_TOKEN" \
  https://api.github.com/rate_limit

Fine-grained PATを使えばリポジトリ単位・権限種別単位でのスコープ制限が可能だが、多くの組織でまだ移行が完了していないのが現実だ。

公開情報から見るインシデントタイムライン

公式スレッドと外部脅威インテリジェンス情報を時系列で整理すると、次のような流れになる。

攻撃者の犯行声明文には「We can cause you more damage then you would ever imagine, contact us.（想像以上のダメージを与えられる、連絡せよ）」というcoinbasecartelの定型文が記されている。Grafana Labs側がこの恐喝を一切公開せず、内部のフォレンジック分析と認証情報の無効化を先行させた上で、48時間以内に公式声明を出したことになる。

coinbasecartelとの関連：脅威アクターの正体

ランサムウェア追跡サイト「ransomware.live」の記録によると、coinbasecartelというグループが2026年5月15日20:57 UTCにGrafanaを被害者としてリストアップしている。Grafana Labsの公式発表（5月17日）における「攻撃者はGrafanaを脅迫しコードベースの公開を防ぐために支払いを要求した（4/6）」という記述と犯行声明の文言・手口が一致しており、このグループが今回のインシデントに関与している可能性が極めて高いと推定される。ただし公式からの帰属（Attribution）確認は現時点で行われていない。

外部脅威インテリジェンスが示す追加データ

侵害認証情報の流通データを追跡しているHudson Rockの調査では、Grafana Labs関連で以下が確認されている。

注目すべき点は3つある。

第一に、Grafana Labs従業員端末からのinfostealer感染履歴は0件である点。これは「従業員PCがinfostealer感染→社内認証情報が直接漏洩」という古典的な初期侵入ベクトルの可能性が低いことを示唆する。

第二に、第三者経由のクレデンシャル漏洩が9件確認されている点。これはGrafana Labsと業務上接続する外部パートナー・ベンダー・コントラクター端末で発生した感染を意味する。サプライチェーン上のサードパーティ経由の認証情報漏洩は近年急増しており、今回のインシデントにおける有力な仮説の一つとなる。

第三に、ユーザー側ではRedLineとLummaという2大infostealerファミリーが圧倒的なシェアを占めている点。これらは2024〜2026年にかけて最も活発に流通しているスティーラーで、ダークウェブのIAB（Initial Access Broker）市場で日常的に売買されている。

これらはあくまで外部脅威インテリの観測データであり、今回の侵入経路を断定するものではない。Grafana公式の調査結果待ちとなる。

coinbasecartelとはどのような脅威アクターか

coinbasecartelは2025年9月に活動を開始した比較的新しい脅威グループで、登場から半年あまりで急速に被害規模を拡大している。Bitdefender Business Insightsの分析とInfoStealers.comの追跡調査をもとに、その全体像を整理する。

暗号化なしの純粋なデータ窃取型：一般的なランサムウェアがファイルを暗号化して業務を停止させるのに対し、coinbasecartelはデータを暗号化せず、窃取したデータの公開を脅しに身代金を要求するモデルを採る。被害組織の業務継続性は保たれるが、機密データの流出リスクが焦点になる。Grafana Labsへの恐喝（「コードベース公開を防ぐための支払い要求」）はこのモデルに完全に一致する。

主要な標的セクター：技術・医療・輸送・エネルギー分野で被害報告が多く、Grafana Labsはその「技術」セクターに該当する。

初期侵入の主要手口（Bitdefender分析より）：

• 古いinfostealerログの認証情報を購入 — RedLine、Lumma、Vidar、StealCなどのスティーラーがダークウェブのIABマーケットで日常的に売買されており、coinbasecartelはこれら過去ログから対象企業の正規アカウント情報を入手
• 購入した認証情報で正規のログインフローを経由してネットワークに侵入（マルウェアによる脆弱性悪用ではなく、正規ログインのため検知が困難）
• 内部探索後、機密データを段階的に窃取（多くの場合MFA未設定のサービス・アカウントが踏み台になる）

身代金要求の流れ：侵入後48時間以内の連絡要求、10日間の支払い期限、Bitcoin払いというパターンが確認されている。グループのメッセージは「我々は想像以上のダメージを与えられる、連絡せよ」という定型文で、今回のGrafana掲示にも同様の文言が使われた。

他の著名な被害組織

coinbasecartelの被害は技術企業だけにとどまらない。InfoStealers.com / Bitdefenderが報じた主要被害組織には次のようなものがある。

これらの被害組織はいずれも内部の認証情報管理・MFA運用において完璧ではなかったとされ、coinbasecartelはこうした「正規ログインの隙」を組織横断的に突いてきた。業界・規模を問わずInfoStealer由来のクレデンシャル汚染は普遍的な脅威となっている。

Grafanaインシデントの侵入経路に関する推測分析

ここまで整理してきた情報を踏まえると、今回のGrafana侵害がどのような技術的経路で発生したかについて、いくつかの仮説を組み立てられる。ただし以下は推測であり、公式調査の結果を待つ必要がある。

公開情報を改めて整理すると、確定事項と推測事項は次のように分かれる。

推測の組み立てロジック：Coinbasecartelの過去170社の侵入経路の大多数がinfostealer由来のクレデンシャル購入であり（Bitdefender分析）、被害企業の80%が過去に何らかの形でinfostealer汚染を経験している。今回のGrafana事案では従業員端末の直接感染こそゼロだが、第三者経由のクレデンシャル漏洩が9件確認されている。この組み合わせから「サードパーティ端末のinfostealer感染 → そこに保存されていたGitHub PAT流出 → ダークウェブで購入 → 正規ログインでGitHub環境侵入 → コードベースクローン」という攻撃シナリオが過去パターンとして最も整合する。

ただしこれはあくまで「もっともらしい仮説」であり、Grafana Labsが公式スレッド (3/6) で「原因を特定済み」と述べた具体的手法はまだ未公表だ。公式PIRが公開されるまで断定は避けるべきだ。

推測が当たっていた場合に組織が取るべき教訓

仮にこの仮説が正しかった場合、自組織のセキュリティ対策に与える示唆は大きい。

1. 自組織のセキュリティだけ強化しても不十分 — パートナー・ベンダー・コントラクター・元従業員の端末も認証情報の流出経路になる
2. GitHub PATを「コードに書かない」だけでは足りない — 個人のNotion・Slack・スクリーンショット・パスワード管理ツール経由でも漏洩する
3. Have I Been Pwned / Hudson Rockなどのinfostealer監視サービスで自組織ドメインの汚染状況を定期チェックする運用が必要
4. GitHub OIDCへの全面移行で静的PAT自体を世界から消すのが最も根本的な防御
5. Canaryトークンの拡充でPAT流出時の検知時間を最小化

Grafana Labsの過去のセキュリティインシデントとの比較

Grafana Labsはオープンソース企業として、セキュリティインシデントへの透明性の高い対応で知られる。今回の事案と2025年4月のGitHub Actionsインシデントを比較する。

2025年のインシデントは「コードは見られていない、顧客データも無事」という比較的軽微な結果で終息した。今回はコードベースのダウンロード自体は確認されており、その意味では深刻だが、公式スレッドにより顧客データ・本番システムへのアクセス痕跡はなしと明確に否定された点は重要だ。

コードベース流出が持つ意味：なぜオープンソースでも危険なのか

Grafanaは主要なコードをオープンソースとして公開しているが、全てのコードが公開されているわけではない。

また、オープンソースであっても、コードベースの全体像を手に入れた攻撃者は以下のことが可能になる。

既知の脆弱性パターンの大規模探索：公開コードでは読みにくい部分も、ローカルにクローンすれば高度なSAST（Static Application Security Testing）ツールで網羅的にスキャンできる。例えば2026年3月に修正されたCVE-2026-27876（SQLエクスプレッション任意ファイル書き込み、CVSS 9.1）の類似パターンを新たに探索するといった用途が考えられる。

ゼロデイ脆弱性の発掘：OSSとして公開されていないプライベートコードに未修正の脆弱性が潜んでいれば、攻撃者がそれを発見・悪用する時間を得る。

内部アーキテクチャの把握：コードを読むことで内部APIのエンドポイント、認証フロー、データの流れを把握し、標的型攻撃の精度を高めることができる。

組織が今すぐ実施すべき対策

Grafana Labsを直接利用している組織だけでなく、GitHubを使って開発している組織全体に当てはまる対策を整理する。

1. 既存トークンの棚卸しと権限の最小化

まず自組織のGitHubトークンを全て洗い出し、不要・過剰スコープのものを即時失効させる。

# GitHub CLIで組織内のPersonal Access Tokensを確認（管理者権限が必要）
gh api /orgs/{ORG}/personal-access-tokens \
  --jq '.[] | {id: .id, name: .name, created_at: .created_at, expires_at: .expires_at}'

# Fine-grained PATに移行していない古いトークンを特定
gh api /orgs/{ORG}/personal-access-tokens \
  --jq '.[] | select(.token_last_eight != null) | {name: .name, login: .owner.login}'

# TruffleHogでリポジトリ内の漏洩シークレットをスキャン
docker run --rm -it \
  -v "$(pwd):/repo" \
  ghcr.io/trufflesecurity/trufflehog:latest \
  git file:///repo --only-verified

Fine-grained PATへの移行は組織ポリシーとして強制できる。GitHub Organizationの設定で「Personal access tokens → Fine-grained tokens」を必須化し、承認フローを設定することで、Classic PATの新規発行を防げる。

2. GitHub OIDCへの移行：トークンを発行しないCI/CDアーキテクチャ

最も根本的な対策は、静的なGitHubトークンをCI/CDパイプラインから完全に排除することだ。GitHub Actionsでは、OIDCフェデレーションを使って動的な一時トークンを発行する仕組みに移行できる。

# GitHub Actions で OIDC を使った安全なトークン生成の例
name: Secure Deploy

permissions:
  id-token: write   # OIDC トークン取得に必要
  contents: read    # コードのチェックアウトに必要

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # 静的なトークンをSecretに保存する代わりにOIDCで一時認証情報を取得
      - name: Configure AWS Credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
          aws-region: ap-northeast-1

      # GitHub App Token も OIDC 経由で動的生成
      - name: Generate GitHub App Token
        id: app-token
        uses: actions/create-github-app-token@v1
        with:
          app-id: $
          private-key: $

このアーキテクチャでは、長期間有効な静的トークンが存在しないため、トークンを窃取されるリスク自体を排除できる。

3. トークン使用のリアルタイム監視

トークンが漏洩・悪用された場合でも、早期検知によって被害を最小化できる。GitHubは組織の監査ログをAPIで取得できる。

# GitHub 組織の監査ログで不審なアクセスを検索
# 特に通常と異なるIPや未知のUser-Agentからのclone操作を確認
gh api \
  "/orgs/{ORG}/audit-log?phrase=action:git.clone&per_page=100" \
  --jq '.[] | {
    action: .action,
    actor: .actor,
    repo: .repo,
    created_at: .created_at,
    country_code: .country_code,
    user_agent: ."@type"
  }'

# 特定期間のgit.cloneイベントを抽出（大量クローンの検出）
gh api \
  "/orgs/{ORG}/audit-log?phrase=action:git.clone&after=$(date -u -v-24H +%Y-%m-%dT%H:%M:%SZ)" \
  --jq 'group_by(.actor) | .[] | {actor: .[0].actor, count: length}'

Grafana Labs自身が推奨するCanaryトークン（特定のURLや認証情報を含むダミートークンで、アクセスがあればアラートが発火する仕組み）を組み合わせることで、漏洩を秒単位で検知できる体制が作れる。

セキュリティ体制の成熟度チェックリスト

今回のGrafana Labs事案を踏まえ、自組織のGitHub環境の安全性を確認するためのチェックリストを示す。

過去のGrafana GitHub Actionsインシデント（2025年4月）との技術的相違点

2025年4月26日に発生したインシデントは、pull_request_targetトリガーを使ったGitHub Actionsワークフローの設定不備を突いた攻撃だった。攻撃者はフォークしたリポジトリから悪意のあるブランチ名を使ってコマンドインジェクションを実行し、GRAFANA_DELIVERY_BOT_APP_IDとGRAFANA_DELIVERY_BOT_APP_PEMの2つのGitHub Appシークレットを窃取した。

このインシデントで重要なのは、Canaryトークンが即座にアラートを発火させた点だ。土曜日の夜に発生したにもかかわらず、グローバルに分散したセキュリティチームが数時間以内に対応し、被害を最小化した。インシデント終結（2025年5月12日）時点で「コードの改ざんなし、本番システムアクセスなし、顧客データ漏洩なし」を確認した。

今回（2026年5月）の事案はこれとは性質が異なる。前回は自動化ボットによるワークフロー悪用だったが、今回はGitHub環境へのアクセス権を持つトークンの窃取とコードベースのダウンロードという、より意図的・目的的な攻撃の様相を呈している。

Grafana Labsは前回のインシデント後、以下の改善を実施していた：

• ZizmurとTruffleHogをCI/CDパイプラインに組み込み
• コンパートメント化されたVaultと短命トークンの導入
• オープンソースリポジトリとプライベートリポジトリの組織分離
• Canaryトークンの拡充

こうした対策を講じた後でも今回の事案が発生したことは、セキュリティ対策の継続的な更新が不可欠であることを改めて示している。

Grafana利用者への影響評価

公式スレッド（2/6）で「顧客データや個人情報がアクセスされた形跡はなく、顧客システムや業務への影響を示す証拠も見つかっていない」と明言された。これを踏まえた利用者カテゴリ別の影響評価は次の通り。

Grafana Cloud利用者：公式発表により本番システム・顧客データへのアクセス痕跡なしと確認された。即時のサービス利用への影響はないが、念のためAPIキー・サービスアカウントの権限棚卸しを推奨する。

Grafana OSS（セルフホスト）利用者：コードベースを入手した攻撃者が新たな脆弱性を発見・悪用するリスクは中長期で残存する。CVE-2026-27876（CVSS 9.1）などの既知の脆弱性はパッチ済みバージョン（12.4.2以降）への更新で対処できている。最新パッチの適用状況を確認すること。

Grafana Enterpriseライセンス利用者：プライベートリポジトリのコードが対象に含まれる可能性について、Grafana Labsからの個別連絡を確認すること。

自社でGrafanaのビルドパイプラインに依存している組織：公式声明では本番システム・コード改ざんへの言及はないが、ビルドアーティファクトの完全性確認（コンテナイメージのダイジェスト検証など）を推奨する。

最新パッチの適用確認

今回の事案とは別に、直近でGrafanaには複数の重大な脆弱性が修正されている。インシデント対応と並行してパッチ適用状況を確認する。

# 現在稼働しているGrafanaのバージョン確認
curl -s http://localhost:3000/api/health | jq .version

# Grafana公式APIで最新リリースを確認
curl -s https://api.github.com/repos/grafana/grafana/releases/latest \
  | jq '{version: .tag_name, published: .published_at, url: .html_url}'

# Dockerコンテナの場合：イメージのダイジェストを検証
docker inspect grafana/grafana:latest \
  --format=''

直近の主要修正パッチ：

• v12.4.2 / v12.3.6 / v12.2.8 / v12.1.10 / v11.6.14（2026年3月25日リリース）
  • CVE-2026-27876（CVSS 9.1 Critical）：SQLエクスプレッションによる任意ファイル書き込み→RCE
  • CVE-2026-27880（CVSS 7.5 High）：OpenFeature DoS

これらのCVEとは独立した脅威として、今回のコードベース流出リスクへの対処も並行して進める必要がある。

インシデント対応の透明性：Grafana Labsが示した開示姿勢

今回の発表で注目すべき点の一つは、身代金要求とその拒否を即日かつ公然と開示したことだ。2025年4月のインシデントでも、Grafana Labsはインシデント発生翌々日にはLinkedInとブログで詳細を公開し、調査終結後にはPost-Incident Review（PIR）を発表した実績がある。

今回は単なる被害公表に留まらず、6連投スレッドの中でFBIの公式見解を引用しつつ「身代金を支払わないことが適切な道だ」と明言した。これは業界全体にとって重要な意味を持つ。

この透明性の高い開示姿勢は、オープンソースコミュニティからの信頼を維持する上で重要な役割を果たしている。多くの組織がインシデントの存在自体を数週間〜数ヶ月隠蔽するなか、Grafana Labsの対応は業界標準として参照されるケースも多い。

詳細なPIRは調査完了後に公開される予定（公式スレッド6/6で明言）であり、続報のキャッチアップが望まれる。

組織として取るべきインシデント初期対応手順

Grafana利用組織が今すぐ実施すべき初期対応を時系列で整理する。

即時（Today）：

1. 組織内でGrafanaリポジトリにアクセスできるGitHubトークンを全て洗い出す
2. 不要・長期間未使用のトークンを即時失効させる
3. Grafana公式ブログ（grafana.com/blog）とGitHub Security Advisoriesをウォッチ登録する

今週中（This Week）：

1. TruffleHogでリポジトリ内のシークレットをスキャンし、残存シークレットを排除
2. GitHub監査ログで過去30日間の異常なgit.cloneイベントを確認
3. 本番Grafanaインスタンスを最新の修正パッチ（v12.4.2以降）に更新

今月中（This Month）：

1. Fine-grained PATへの全面移行計画を立案・実施
2. CI/CDパイプラインのGitHub OIDC移行スケジュールを設定
3. Canaryトークンをリポジトリと本番環境に配置

まとめ：コードベース流出インシデントから組織が学ぶべきこと

Grafana Labsの今回の事案は、どれだけセキュリティ意識の高い組織でも、GitHubトークン管理の盲点が残れば侵入を許すという現実を突きつけた。一方で、6連投スレッドで明らかになった事実は次の3点に集約できる。

詳細な攻撃手口・Attribution・PIRの公開は今後となるが、組織が今すぐ行動できることは明確だ。静的なGitHubトークンの棚卸しと最小化、GitHub OIDCへの移行、TruffleHogによるシークレットスキャン、Canaryトークンの配置——これらは「Grafana Labs事案が教えてくれた」ことではなく、業界のベストプラクティスとして長年言われてきたことだ。事案を機にアクションに移すかどうかが、次の被害者になるかどうかを分ける。

そして経営層が学ぶべき教訓がもう一つある。身代金要求に直面したとき、FBI公式見解に従って拒否する判断軸を事前に持っておくことだ。Grafana Labsはオープンソース企業として「コードは公開されても構わない」という覚悟があったからこそ拒否を即断できた。自社が同じ立場に立たされたとき何を守るのか、トレードオフを事前に整理しておくべきだ。

参照ソース

1. Grafana Labs公式X: @grafana 6連投スレッド（2026年5月17日）— GitHub環境への不正アクセスとコードベースダウンロード公表・身代金拒否表明
2. Grafana Labs公式ブログ: Grafana security update: no customer impact from GitHub workflow vulnerability（2025年4月）
3. Grafana Labs公式ブログ: Grafana security update: post-incident review for GitHub workflow vulnerability and what’s next（2025年5月）
4. StepSecurity: Grafana GitHub Actions Security Incident
5. Grafana Labs公式ブログ: Grafana security release: Critical and high severity security fixes for CVE-2026-27876 and CVE-2026-27880
6. Bitdefender Business Insights: No Encryptors, No Problem: The Coinbase Cartel Ransomware Group — 累計170社/34カ国・80%がinfostealer感染履歴あり・古いログ購入→正規ログイン手口の分析
7. InfoStealers.com: Inside the Coinbase Cartel: How Infostealer Credentials Fueled a 100-Company Ransomware Spree — Cognizant/ENGIE/SK Telecom等の被害組織分析
8. ransomware.live: Victim: Grafana – coinbasecartel（2026年5月15日 20:57 UTC掲載）— RedLine 813件・Lumma 757件・第三者9件・外部URL 88件の詳細メトリクス
9. Hudson Rock: 侵害認証情報追跡データ — Grafana Labs従業員端末からのinfostealer感染0件、第三者経由クレデンシャル漏洩9件、Grafana関連ユーザー2,985件
10. FBI Internet Crime Complaint Center (IC3): ランサムウェア身代金支払いに関する公式見解