# 0day Rubbish
> **AI時代において、0day脆弱性はゴミと化した。**
[](./LICENSE)
[](https://0day-rubbish.com/blog)
[](https://0day-rubbish.com/blog)
[](https://0day-rubbish.com/blog)
[](https://0day-rubbish.com)
[](https://github.com/Exploit-Garbage/0day-Rubbish/subscription)
[](https://github.com/Exploit-Garbage/0day-Rubbish/discussions)
[](https://github.com/Exploit-Garbage/0day-Rubbish/commits)
**🌐 公式ウェブサイト**: <https://0day-rubbish.com/blog>
---
## 🎯 このプロジェクトの目的
従来の脆弱性開示は破綻している。遅く、官僚的で、効果がない。AI時代においては、0dayを大規模に量産できる——個々の脆弱性の価値は下がるが、直接開示した際のインパクトは大きくなる。
我々は**イベントドリブンなセキュリティ強化**が最も効果的なアプローチだと信じている。ベンダーが現実的で悪用可能な脅威に直面したとき初めて、彼らは修正を優先するのだ。
## 🔄 開示プロセス
### ステップ1: AIによる発見
自動化されたAIシステムが実世界のソフトウェアを継続的にスキャンし、パターン分析、ファジング、インテリジェントなコードレビューを通じて潜在的な0dayを特定する。
### ステップ2: 検証とPoC開発
各発見は手動で検証される。我々は悪用可能性を確認し、実世界への影響を評価するために、動作する概念実証（PoC）エクスプロイトを開発する。
### ステップ3: 定期的な公開開示
毎週——月曜日または火曜日——我々が発見・検証した、悪用可能な0day脆弱性の新たなバッチを開示する:
- 完全な技術分析と根本原因
- 動作するPoCエクスプロイトコード
- 影響を受けるバージョンとシステム
- 影響評価
- 推奨される緩和策
遅延なし。官僚主義なし。ただ事実のみ。
**すべてのベンダーへ**: ハッカーがこれらの脆弱性を悪用する前に、修正を完了していただけることを願っている。
## ⚡ 基本原則
- **実世界への影響のみ**: 実際のユーザーベースを持つ実世界のシステムに影響する脆弱性のみを開示する
- **価値のない対象は除外**: 悪用不可能な脆弱性や、ユーザー採用率がごく僅かなデバイスは除外される——それらは価値ゼロのゴミである
- **プロトコルよりスピード**: 直接開示は従来のチャネルよりも迅速な対応を促す
- **主張より証拠**: すべての開示には動作するエクスプロイトが含まれる
- **量より影響**: 深刻度が高く、広く展開されている脆弱性に焦点を当てる
- **透明性**: 完全な技術的詳細、隠された意図はなし
- **非営利**: 金銭的利得ではなく、セキュリティ研究への情熱によって駆動される
## 🤝 コラボレーション
我々は以下と提携している:
- 自動化されたセキュリティ研究を推進するトップAIモデルプロバイダー
- AIを活用した発見を探求するセキュリティ研究者
## 🤖 使用しているAIモデル
我々の自動脆弱性発見は、主要なAIプロバイダーの最先端大規模言語モデルを活用している:
- **Anthropic (Claude)** - 深いセキュリティパターン認識と推論
- **OpenAI** - 高度な推論とコード分析
- **DeepSeek** - 特化型の脆弱性検出
- **Z.ai (GLM)** - 長文コンテキストのコード分析
- **Moonshot (Kimi)** - 長文コンテキストのセキュリティ分析
---
## 📋 開示された脆弱性
AI駆動の研究プロセス（マルチLLMアンサンブル: Claude、OpenAI、DeepSeek、GLM、Kimi）が実世界のエンタープライズソフトウェアの0dayを発見する。以下の各アドバイザリには**完全な根本原因分析**と**動作する再現可能なエクスプロイトスクリプト**が含まれる——検出のみの記事や、詳細を伏せたものは一切ない。
### 最新バッチ — バッチ16（6件のアドバイザリ）
*監査人自身の計器で証明する必要があった6件の所見であり、いずれも計器が示した以上のことを主張していない。2007年時代の認証モデルから脱していないPHPエンドポイントに対する匿名アップロードのペア1件、自身のホスト名バリデータを反転させたルーティングデーモンの診断エンドポイント1件、SOAPのアプリインストールフィールドがシェルと化したコンシューマ向けルーター1件、そして産業用セルラールーターのシェルで組み立てられた設定面への3つの異なる侵入経路。6件のうち4件は、生のソース記録が示唆した値より低い数値を公開しており、そうした下方修正はいずれも、訂正対象のスコアの隣にその算術とともに明記されている。*
| # | 製品 | 影響を受けるバージョン | CVSS | 分類 | アドバイザリとPoC |
|---|---------|------------------|------|-------|-----------------|
| 1 | NETGEAR RAX120 (Nighthawk AX12) | V1.2.5.18 | **6.8** \* | LAN側管理プレーンのSOAP InstallAppアクションが、`apName`引数を介して`rm -rf`シェルコマンドを組み立てる。`$(...)`置換が、コマンド語が解決される前にroot権限で設定されたWebスタックへ到達する | [InstallApp apName → シェルコマンド置換](https://0day-rubbish.com/blog/soap-installapp-apname-command-injection-root-rce) |
| 2 | NUUO Crystal Server | 3.19.0.85 | **9.8** \* | セッションも拡張子ゲートもパスチェックもない裸の`copy()`アップロードエンドポイントで、ベンダーの廃止製品ラインが有名にしたWebルートへの着地パターンを引き継いでいる。単一の匿名リクエストペアが実行可能なページを書き込み、それを取得し返す | [upload.php → Webルート書き込み → Web側コード実行](https://0day-rubbish.com/blog/nuuo-crystal-server-unauth-upload-php-webroot-write-rce) |
| 3 | Raritan PX3 PDU G4 | ファームウェア 4.3.14 | **8.8** \* | 診断用`ping`/`traceroute`ハンドラで、そのホスト名バリデータが自身の戻り値チェックを反転させている。あらゆる通常の認証済みセッションから到達可能であり、一方で`netstat`は診断ペアに欠けている管理者専用属性を備えている | [diag ping → 戻り値の反転 → シェルインジェクション](https://0day-rubbish.com/blog/raritan-px3-pdu-g4-diag-ping-traceroute-command-injection) |
| 4 | Moxa MAR-2000 FWR_MAR2000 V1.0 Build 15010909 | V1.0 Build 15010909 | **7.2** \* | 管理UIのプログラムテーブルが、その`argument`フィールドをユーザープログラムランチャーのコマンドラインへそのまま渡す | [Executer argument → プログラム起動インジェクション](https://0day-rubbish.com/blog/mar-2000-executer-program-argument-command-injection) |
| 5 | Moxa MAR-2000 (同一製品、同一バッチ) | V1.0 Build 15010909 | **7.2** \* | 5つの別個の`ipsec.py`ハンドラが、トンネルアドレスフィールドからの攻撃者テキストを伴ってルート管理コマンドへシェルアウトする。1製品の所見がバッチをまたいで分割されることはない | [トンネルアドレス → ルート管理シェル](https://0day-rubbish.com/blog/mar-2000-network-ipsec-command-injection) |
| 6 | Moxa MAR-2000 (同一製品、同一バッチ) | V1.0 Build 15010909 | **7.2** \* | シナリオエンジンが保存された`ping`条件を定期的に再評価し、そのスレッドが各パスでシェルコマンドを再形成するため、保存されたペイロードは攻撃者がリクエストを再送することなく発火する | [scenario ping → 自動実行スレッド](https://0day-rubbish.com/blog/mar-2000-scenario-ping-command-injection) |
\* 6件すべてが複数の読み値を公開している。各アドバイザリは、自身が採用する読み値の隣に、却下した、または条件付きとした読み値を、それぞれ独自のベクターと算術とともに記載している:
> - **Finding 1** — `AV:A/PR:H` における **6.8** は公開済み: 出荷された成果物のいずれも WAN 側の露出を裏付けておらず、またこのアクションは管理者層に属するため、素朴な 8.8 かつネットワーク到達可能という解釈の両半分が成果物チェックで崩れ、ソースレコード自身の 8.8 は見出しとしてではなく、算術とともに `PR:L` バリアントとして内部に示されている。7.2 の `AV:N` は、管理プレーンを意図的に露出させたデプロイメント向けの、ラベル付き条件付き評価である。
> - **Finding 2** — `PR:N` における **9.8**。単一の匿名リクエストペアであり、Web 層は自身が書き込んだものをそのまま再配信する。実行はレプリケーション環境の Web サービスアカウントとして成立し、まさにそのとおりに報告される: デバイス側のサービス ID は測定されておらず、主張もされていない。10.0 の `S:C` は算術とともに記載され、棄却される; `AV:A` 8.8 は管理 VLAN 分離向けのラベル付き条件付き評価である; デバイス ID 不明という注意書きは Summary に目立つ形で記載され、ファイル名と本文でも繰り返される: 本 finding の見出し、スラッグ、本文のいずれにも「root」や「system」の主張は一切含まれていない。ベンダーの販売終了ラインにおけるファミリーモデルのアップロード系譜は、本アドバイザリシリーズの内部ルールに従い、識別子を一切含まないパターンとして記述されている。
> - **Finding 3** — `PR:L` における **8.8**: 出荷された `netstat` と診断機能の属性非対称性こそが、通常のセッションが意図されたプリンシパルクラスであることを証明する成果物である; 工場出荷時のデフォルトアカウントペアは、本 finding のベクターとしてではなく、独自の条件付き `PR:N` 9.8 評価を持つ別個の隣接する脆弱性として開示される。7.2 の `PR:H` は記載され、棄却される。
> - **Findings 4-6** — 3 件すべて `PR:H` における **7.2** であり、ソースレコードの 8.8 は修正済み 881 関係ファミリールールの下での `PR:L` 算術であるという訂正とともに記載され、棄却バリアントの算術として併記される。3 件の工場出荷時デフォルト認証情報の条件付き評価(各 9.8、未変更の場合)はラベル付けされ、見出しには決してされず、`S:C` 9.1 は 3 件すべてについて記載され、棄却される。3 件すべては、scenario-ping シンクにおけるセミコロンペイロードが失敗し評価スレッドをブロックするという正直なネガティブ結果を伴い、動作する形式(`$(...)`、改行)はテストとともに記載される。
> - **検証境界、一律に明記** — 本バッチにおけるすべてのサンドボックスマーカー `uid=0` は、テストに使用されたレプリケーション環境の特性であり、出荷イメージが自身の Web スタックを root として構成している場合、それはイメージ内の事実としてそのまま記載される。いかなる finding もデバイス側 ID をマトリクス上で主張せず、本バッチのどこにも実機に対する主張はなされていない: 3 件の finding は `隔離されたクラウドホスト型サンドボックス上でのシンクレベルレプリケーション` によってテストされ、1 件(Crystal Server)は自身の VM イメージ内でのエンドツーエンド HTTP チェーンによって、1 件(PX3)はイメージからの命令レベルおよびシンクのコマンドレベルレプリケーションによって(エンドツーエンドなし; RPC→cfgd→ハードウェアのチェーンはエミュレーション下では完了しなかった)、1 件(RAX120)は命令レベルのリクエストパス逆アセンブリに加え、3 つの相互に独立したマーカーと 1 つの良性コントロールに対するネイティブ gcc によるシンクレプリケーションによってテストされた。
> - **root および ID に関する主張、1 件ずつ検証済み**: 公開された 9.8(`Finding 2`)は root や system を明示的に主張していない; 公開された `Findings 4-6` のスラッグは「管理スタックへのシェルインジェクション」までで主張を止めており、レプリケーションサンドボックスの ID が `uid=0` 行の出所として開示されている; RAX120 の finding のスラッグとインラインの主張は、本バッチで唯一 root という語を含むものであり、その両方のアンカーはイメージ内の lighttpd `User root` 設定に加え、3 つのゼロ ID マーカーと 1 つのコントロールであり、実機ではない。
**合計**: 6件のアドバイザリ · 4製品 · 4ベンダー組織（NETGEAR、NUUO、Raritan/Legrand、Moxa）。MAR-2000シリーズがそのうち3件を占めるのは、1製品の該当する所見がバッチをまたいで分割されることが決してないため · 未認証チェーン1件 · 認証済みチェーン5件（うち4件は明示的に管理者クラスのセッションを要求し、1件は任意の通常セッションを要求）。単一の6.8が有名ブランド枠の見出しを担っており、これは意図的にこのバッチで最も劇的でない数値である。`AV`と`PR`はいずれも、素朴なモデルのテンプレートが示唆する値ではなく、出荷された成果物が証明した値まで下がっており、公開された`Totals`はそのことを率直に示している。6件のうち4件は、生のソース記録が示唆した値よりも少なくとも1つの数値を低く公開している — 証拠のないWAN側が2回、誤入力されたPR階層が4回 — そしてそれらすべての格下げは、読者の目に触れる場所に印刷されており、却下された算術、ベクター、根拠、訂正履歴が存続するスコアのそばに並べられている。
**計測器が実際に示したもの** — このバッチの信頼性がまさにこの点に懸かっているため明記する:
- **2つのチェーンはエンドツーエンド、4つはシンクまで。** 所見2は、ベンダー自身のVMイメージに対して完全な匿名HTTPリクエストのペアを実行し、記述されたページの実行を確認した。所見3の`diag`ハンドラは、リリースされたファームウェアからの命令レベル検証に加え、3つのペイロード形状のコマンドレベル注入（良性コントロール付き）によって検証された。所見4〜6は、ファームウェアソース解析に加え、各正確なシンク構築のnative-gccシェル複製（マーカーと良性コントロールを含む）によって検証された。所見1は、逆アセンブリ内のリクエストパス行で検証され、その後、3つの独立したマーカーと良性コントロールに対するnative-gccシンク複製によって検証された。非ライブの所見についてはエンドツーエンドの主張は行わず、各所見のREADME行には「disassembly」または「replication」と明記されている。
- **視点は一律に:** このバッチのどの所見においても、リクエストや実行が信頼できないネットワーク境界を越えることはなかった。所見が複製環境より広いスコープを主張する場合、その主張は出荷された成果物 — イメージ内のバインディングまたはイメージ内のWebスタック設定 — に固定されており、その旨を明記している。
- **当社自身のハーネスが提供したもの** — 当社が作成した状態は製品のデフォルトではないため: 複製ホスト環境（サンドボックスアカウントの識別情報をホストの特性として測定し、その後、デバイス側で主張されない内容に関する所見の主張に反映）; 所見と偶発事象を区別する良性コントロール; エントリポイントが初回使用後に閉じられる単一使用クロージャマーカー（一方通行の窓）。
*過去のすべてのバッチとそのアドバイザリは[Releases](https://github.com/Exploit-Garbage/0day-Rubbish/releases)に掲載されています。*
*過去のすべてのバッチとそのアドバイザリは[Releases](https://github.com/Exploit-Garbage/0day-Rubbish/releases)に掲載されています。*
---
## 🔁 継続シリーズ — 毎週の開示
これは**継続的開示シリーズ**である。継続的な最適化により、AI駆動の発見パイプラインは現在、安定した毎日のペースで新たな0-day所見を生み出しており、当社は検証済みのバッチを**毎週のペース**で開示している。
- **最新バッチ**: バッチ16 — アドバイザリ6件、16バッチ累計144件
- **次回公開**: 毎週月曜日または火曜日
- **将来の範囲**: エンタープライズITを超え、**ICS / SCADA、エネルギー、航空宇宙**システムへ拡大
次回公開が届いた瞬間にキャッチしたい場合:
[](https://github.com/Exploit-Garbage/0day-Rubbish) [](https://github.com/Exploit-Garbage/0day-Rubbish/subscription) [](https://0day-rubbish.com/blog)
> ⭐ **Star**でブックマーク · 👁 **Watch**（カスタム → Releases + Discussions）で新バッチを通知 · 🌐 **Follow**でブログのアドバイザリごとの更新をフォロー。
---
## 📂 脆弱性提出フォーマット
開示されたすべての脆弱性は、標準化されたディレクトリ構造に従っています:
```
product/
└── <vendor>/
└── <version>/
└── <vulnerability_type>/
├── exploit/ # Exploit scripts and PoC code
├── analysis.md # Detailed vulnerability analysis
└── summary.md # Brief vulnerability overview
```
### ディレクトリルール
- **product/**: すべての脆弱性のルートディレクトリ
- **<vendor>/**: ベンダーまたは製品名（例: `apache`、`cisco`、`sonicwall`）
- **<version>/**: 影響を受けるバージョン範囲（例: `6.11.0`、`12.4.2`）
- **<vulnerability_type>/**: 分類（例: `unauth-rce`、`auth-bypass`、`deserialization-rce`）
### 各脆弱性ディレクトリに必要なファイル
1. **exploit/**: 動作するエクスプロイトスクリプトとPoCコードを含むディレクトリ
2. **analysis.md**: 根本原因、攻撃ベクトル、影響を含む包括的な技術分析
3. **summary.md**: 影響を受けるバージョンと迅速な緩和手順を含む簡潔な脆弱性概要
### 例
```
product/
└── sonicwall/
└── sma-12.4/
└── preauth-deserialization-rce/
├── exploit/
│ └── poc.py
├── analysis.md
└── summary.md
```
---
**AI時代の脆弱性開示を共に再定義しましょう。**
