flowchart LR
A["配信ページURL"] --> B["135プラグインから 自動マッチ"]
B --> C["ストリームを列挙 best / 1080p / worst …"]
C --> D{"出力先"}
D --> E["プレイヤーへパイプ （既定）"]
D --> F["--record file.ts 録画"]
D --> G["--stdout ffmpeg等へパイプ"]
C --> H["--json plugin/metadata/streams"]
{"plugin":"youtube","metadata":{"id":"jNQXAC9IVRw","author":"jawed","category":"Film & Animation","title":"Me at the zoo"},"streams":{"240p":{"type":"http","method":"GET","url":"...","headers":{"User-Agent":"..."}},"worst":{"type":"http","method":"GET","url":"...","headers":{"User-Agent":"..."}}}}
日本のユーザーに関係が深いところでは、pixiv・fanbox・fantia・booth・skeb・seiga・kemonoが含まれていた。pixivのサブカテゴリはartworks / user / ranking / search / series / favorite / followed / sketch / unlisted / pixivisionなど18種類あり、さらにpixiv-novelが独立したCategoryとして小説（novel / series / user / bookmark）に対応している。「pixivの一括ダウンロード」でやりたいことのほとんどは、この時点で守備範囲に入っている。
flowchart LR
A["URL / URLリスト"] --> B["extractor 解決 269サイトから自動判定"]
B --> C{"認証が要る?"}
C -- "要る" --> D["config.json の token / cookies"]
C -- "不要" --> E["集合を展開 投稿者・タグ・検索結果"]
D --> E
E --> F{"動画 (HLS/DASH)?"}
F -- "はい" --> G["ytdl ダウンローダー yt-dlp へ委譲"]
F -- "いいえ" --> H["http ダウンローダー"]
G --> I["出力テンプレートで保存 + archive DB に記録"]
H --> I
発見から本番修正までは実質5日という迅速な対応が取られていた一方、NVDでのCVE公開は約5.5ヶ月遅れており、「速報」として煽らず時系列を正しく理解することが重要だ。in the wildでの悪用は観測されていないが、クライアント側の対応要否が公式に明記されていない点は、読者自身が今後の公式アナウンスを確認する必要がある。
]]>編集部AIコーディングエージェント 脆弱性｜GitHub Issue起点でCI/CDシークレットが漏れる攻撃チェーン2026-08-18T09:00:00+09:002026-08-18T00:00:00+09:00https://ai-heartland.com/security/ai-coding-agent-cicd-secrets-github-issue-attackAIコーディングエージェント 脆弱性は、Claude Code・Gemini CLI・OpenAI Codexという主要3社の製品で、独立に、しかし同じ形で見つかった。Black Hat USA 2026で開示された研究によれば、攻撃の起点は「誰でも作成できるGitHub Issue」で、そこからCI/CDワークフローが握るシークレット（APIキーやトークン）へ到達する経路が、3社それぞれのエージェントで成立していたという。単発のCVEではなく、AIエージェントとシステムを仲介する「ハーネス」の設計そのものが攻撃面になっていることを示す事例だ。
GitHub Issueを起点にCI/CDのシークレットへ到達する攻撃チェーン（出典: The Hacker News・Cloud Security Alliance research note）。
流れは次の通りだ。まず攻撃者は、対象リポジトリに誰でも投稿できるGitHub Issueを作成する。リポジトリ側のCI/CDワークフローが on: issues のようなIssue関連のイベントをトリガーにしていると、Issue作成だけでワークフローが起動する。このワークフロー内でAIコーディングエージェントが呼び出され、Issue本文を読み込んで処理する際、エージェントはその本文を「信頼できる指示」として扱ってしまう（プロンプトインジェクション）。ワークフローがCI環境のシークレット（APIキー・デプロイトークン等）にアクセスできる状態であれば、エージェントは細工されたIssue本文の指示に従い、そのシークレットを何らかの通信路経由で外部へ持ち出せてしまう。
タイムラインとして確認できているのは以下の通りだ。
・2026-08-07：The Hacker Newsが、Claude Code・Gemini CLIの脆弱性がGitHub Issueを起点にCI Workflow Secretsへ到達することを報じる
・2026-08-08：Cloud Security Allianceがresearch noteを公開し、3社（OpenAI Codexを含む）の技術詳細・CVE番号・修正版をまとめる
・Black Hat USA 2026：本件を含む攻撃チェーンが統合的に開示される（開示の正確な日付は各社アドバイザリ側では明示されておらず、上記2媒体の報道を通じて確認できる範囲にとどまる）
flowchart TD
A["対象エージェントは 修正版以降か？"] -- いいえ --> B["まずアップデート"]
A -- はい --> C{"CIワークフローに Issueトリガーとシークレットが 同居しているか？"}
C -- いいえ --> D["この攻撃チェーンの 対象外"]
C -- はい --> E{"Issue本文を処理する ステップとシークレットに アクセスするステップが 同一ジョブか？"}
E -- いいえ（分離済み） --> F["リスクは限定的"]
E -- はい --> G["ジョブ分離・許可リストの 見直しが必要"]
読者の3つの問いへの答え
① このAIコーディングエージェント 脆弱性は結局何なのか：GitHub Issueという誰でも作れる入力から、CI/CDのシークレットに到達する攻撃チェーンが3社で独立に成立していた事例。 ② 何を解決する記事か：3社の脆弱性の型・CVSS・ベンダー対応の違いを比較表で整理し、自分の環境で今すぐ実行できる確認コマンドを示す。 ③ 何を代替できるか：この記事自体は対策を代替しない。バージョンアップデートとCIワークフローの点検が唯一の実効的な対応になる。
Claude Codeの事例は、WebFetchの許可リストが「ドメイン単位」で緩く設定されていたことが起点だった。事前に許可されたHuggingFaceドメインへの通信自体は正当な機能だが、パスやリクエストの内容までは検証されておらず、その正当な通信路がAPIキーを1文字ずつ持ち出す帯域外チャネルに転用された。Gemini CLIの事例は、ヘッドレスモード（人間の確認を挟まない自動実行モード）でワークスペースを自動信頼する設計と、--yolo フラグによる許可リストバイパスという、どちらも「利便性のために追加された緩和機構」が攻撃面になっていた。OpenAI Codexは、マルチパス構成において前段の処理結果が後段では「信頼されたシステムプロンプト文脈」に昇格してしまう設計自体をOpenAIが仕様と認めており、これも広義には同じ構造の問題だ。
⚠️ Anthropic公式ではない
プロジェクト名に「Anthropic」を含むため誤解されやすいが、README末尾に "Community project by @mukul975. Not affiliated with Anthropic PBC." と明記されている。Anthropic社が開発・保証しているツールではない。
読者の3つの問いへの答え
① 何ができる：AIエージェントにセキュリティ実務のプレイブックを817本渡す ② 何を解決する：AIエージェントが「どのツールを・いつ・どう使うか」という現場の暗黙知を持たない問題 ③ 何を代替できる：汎用LLMの当てずっぽうな手順提案を、フレームワークに裏付けられた構造化ワークフローに置き換える
# Claude Codeのプラグイン形式（設定ファイルから確認できる導入経路。README本文には未記載）
/plugin marketplace add mukul975/Anthropic-Cybersecurity-Skills
/plugin install cybersecurity-skills@anthropic-cybersecurity-skills
Claude Codeでこのcybersecurity skillsを運用する場合、claude code セキュリティの観点では「どのスキルが読み込まれ、どのコマンドを実行しようとしているか」を都度確認できる対話的な承認フローを維持したまま使うのが安全だ。攻撃的なワークフローを含むスキル集である以上、自動承認モードで無人実行させるのは避け、Workflowセクションのステップごとに人間が確認する運用が現実的になる。
---name:performing-memory-forensics-with-volatility3description:>-Analyze memory dumps to extract running processes, network connections,injected code, and malware artifacts using the Volatility3 framework.domain:cybersecuritysubdomain:digital-forensicstags:[forensics,memory-analysis,volatility3,incident-response,dfir]atlas_techniques:[AML.T0047]d3fend_techniques:[D3-MA,D3-PSMD]nist_ai_rmf:[MEASURE-2.6]nist_csf:[DE.CM-01,RS.AN-03]version:"1.2"author:mukul975license:Apache-2.0---
本文側は## When to Use（発動条件）・## Prerequisites（必要ツール・権限）・## Workflow（実行手順）・## Verification（成功確認）という4セクションで統一されている。
README「What people are saying」には第三者からの評価も掲載されている。AI/技術系クリエイターのHasan Toor氏（@hasantoxr）は「AIエージェントがそのまま使える、本物の・整理されたセキュリティスキルのデータベース。チュートリアルでもブログ記事でもない」とコメントし、Medium執筆者のfazal-sec氏も「セキュリティスクリプトの寄せ集めではなく、AI駆動のセキュリティワークフロー向けに設計された構造化ナレッジベースだ」と評している（いずれもREADME掲載の引用）。コントリビューションは活発で、CONTRIBUTING.mdによれば新規スキルの追加はドメインテンプレートに沿ってPRを送る形式で受け付けており、Deception Technology（当時2スキル）・Compliance & Governance（当時5スキル）など手薄なドメインへの貢献を呼びかけている。PRは48時間以内にレビューされる運用で、実質1人が主導しつつもコミュニティからの追加を取り込む体制はある。
flowchart TB
A["攻撃者"] --> B["さくらインターネットの管理環境 （利用者からは操作できない層）"]
B --> C["顧客環境 A"]
B --> D["顧客環境 B （583アカウントに不正ログイン）"]
B --> E["顧客環境 C"]
F["利用者が管理できる範囲 パスワード・公開鍵・ファイル・CMS"] -.->|"この層の強化では 上流の侵害を防げない"| C
F -.-> D
F -.-> E
style B fill:#dc2626,color:#fff
style D fill:#f59e0b,color:#fff
style F fill:#0070f3,color:#fff
# WordPress の管理者ユーザーを一覧（DB名・ユーザー名・接頭辞は wp-config.php に合わせる）
mysql -h <DBサーバ名> -u <DBユーザー> -p <DB名> -e\"SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%administrator%';"# サーバー上に平文で置かれている認証情報の在処を洗い出す
find ~/www -type f \(-name"wp-config.php"-o-name".env"-o-name"*.ini"\)-execls-lT{}\;
]]>編集部DeepSeek Harness徹底解説｜「すべてがプラグイン」の実体を129行の構成ダンプと起動ゲートで測る2026-08-16T10:30:00+09:002026-08-16T10:30:00+09:00https://ai-heartland.com/agent/deepseek-harness2026年8月13日、DeepSeek AIがDeepSeek Harness（dsh）をMITライセンスで公開した。GitHubの deepseek-ai/deepseek-harness は公開から3日で115,000スターを超え、Hacker Newsのスレッドも本稿執筆時点で729ポイントに達している。掲げられた設計思想はただ一つ、「Everything is a Plugin（すべてがプラグイン）」だ。
graph TB
subgraph HOST["ホストプレーン（プロセス全体で1つ）"]
A["base.cordis.yml + web.cordis.yml"]
B["レジストリ・永続化・モデルルート"]
C["サンドボックス／承認スタック"]
end
subgraph AGENT["エージェントプレーン（セッションごと）"]
D["agent.cordis.yml（プリセット）"]
E["ツール登録・プロンプト断片"]
F["isolate レルム内のサービス"]
end
A --> B
A --> C
D --> E
D --> F
B -.->|"サービスを提供"| D
C -.->|"ポリシーを提供"| D
style HOST fill:#e3f2fd,stroke:#0070f3
style AGENT fill:#e0f7f2,stroke:#19c2a8
Minimalプリセットの62行は短いぶん、設計の意図が読み取りやすい。ペルソナはYou are a helpful software engineer assistant.の一文だけで、complete: trueが指定されている。これはこの文字列がシステムプロンプトの全体であり、以降のどの仕組みもプロンプトを追記できないという宣言だ。ランタイム情報のスナップショットも抑止され、コンテキスト圧縮も入らない。ベンチマークで条件を固定するための構成としては筋が通っている。
dsh: MISSING_CREDENTIAL: llm-deepseek: no API key for provider route
"deepseek-official"; store DEEPSEEK_API_KEY through the credentials service
(the web Models page writes it), or export DEEPSEEK_API_KEY in the launching
environment
ここで実務上有用な挙動が一つある。Web UI（dsh web）はAPIキーが無くても起動する。ブラウザでは初回に「Add an API key to get started」というダイアログが出るが、「Configure later」で閉じれば、UIの探索・プリセットの確認・設定画面の閲覧まではキー無しで行える。本記事冒頭のスクリーンショットは、まさにその状態で撮影したものだ。触ってみるだけならキーの用意は後回しでよい。
Claude Codeの構造をOSSとして再現するアプローチについてはOpenHarness徹底解説：Claude Codeの仕組みをOSS化したエージェント基盤で詳しく扱った。DeepSeek Harnessが違うのは、「完成品のエージェントを配る」のではなく「エージェントを組み立てる規約を配る」点にある。129行の構成ダンプも、4つのプリセットも、その規約の実例として読むのが正しい。
]]>reverse-skill徹底検証｜AI逆解析スキルルーター41ルールを実測、日本語で空振りする条件2026-08-16T10:00:00+09:002026-08-16T10:00:00+09:00https://ai-heartland.com/security/reverse-skill-ai-reverse-engineering-routerAIエージェントにAPKやバイナリの解析をやらせようとすると、最初に詰まるのは解析そのものではなく「jadxなのかapktoolなのかFridaなのかIDAなのか」という道具選びだ。reverse-skill（zhaoxuya520/reverse-skill）は、この振り分けを41本のルーティングルールに固定してしまうスキルルーターで、2026年8月16日時点でGitHub Star 25,491・フォーク3,450・MITライセンス。5月13日の公開から3か月でこの規模に達している。
reverse-skillが解こうとしている問題は、READMEの “Why this exists” に4行で書かれている。AIエージェントは与えられた対象に対してどのツールを使うべきか知らない、APK・ELF・JS・PCAP・CTFはそれぞれ別の手順書を必要とする、ツールとMCPサーバーはマシンごとに散らばっている、経験が再利用されないので同じ失敗を繰り返す——の4つだ。
flowchart TD
A["ヒント文字列を小文字化"] --> B{"49のキーワード規則を 正規表現で照合"}
B -->|"must が命中"| C{"mustAll を すべて満たす?"}
B -->|"命中なし"| F["候補ゼロ"]
C -->|"No"| F
C -->|"Yes"| D{"exclude に 該当する?"}
D -->|"Yes"| F
D -->|"No"| E["候補に加点（+1）"]
E --> G{"候補は何本?"}
F --> H["R0 へフォールバック confidence: low"]
G -->|"1本"| I["PRIMARY 確定 confidence: high"]
G -->|"2本以上"| J["priority 順で最高得点 confidence: medium"]
H --> K["route-scope.md を書き出す"]
I --> K
J --> K
・回避策1（即効・推奨）：ヒント文字列の英数字トークンの前後に半角スペースを入れる。「この APK を解析して」「IDA で開く」。1文字の追加で済み、リポジトリを変更しない
・回避策2：ヒントを英語で書く。analyze this apk and find the encryption は confidence: high でR1に届くことを確認済み
・回避策3（恒久）：skills/config/routing.json に日本語キーワードを追加する。単一のソースファイルなので変更箇所は1つで済む。追加後は必ず bash skills/scripts/test-routing.sh を実行して166ケースが緑のままか確認する
# 1. 自動導入される能力と、その取得元・ピン留め状況を一覧化する
python3 - <<'PY'
import json
m = json.load(open('skills/scripts/bootstrap-manifest.json', encoding='utf-8-sig'))
for c in m['capabilities']:
if not c.get('canAutoInstall'):
continue
pin = c.get('assetSha256') and 'sha256' or c.get('pinnedCommit') and 'commit' \
or c.get('pinnedVersion') or c.get('pinPolicy') or c.get('preferApiDigest') and 'api-digest' or 'NONE'
src = c.get('repo') or c.get('pipPackage') or c.get('npmPackage') or c.get('goPackage') or c.get('bootstrapKind')
print(f"{c['name']:18} {str(pin):16} {src}")
PY
# 2. git clone で入る外部リポジトリ（コミット固定の有無）を確認grep-o'"[^"]*github.com[^"]*"' skills/scripts/bootstrap-manifest.json | sort-u
flowchart TD
A["PDFが到着"] --> B["pdf-inspector で分類 （実測 3〜25ms）"]
B -->|"text_based"| C["ローカル抽出 （実測 96ms・課金なし）"]
B -->|"mixed"| D["pages_needing_ocr を取得 ※全ページ走査の経路を使う"]
B -->|"scanned / image_based"| E["全ページをOCRへ"]
D --> F["該当ページだけOCRへ"]
C --> G["Markdown をRAGへ投入"]
E --> H["OCR結果を整形"]
F --> H
H --> G
