RCE
このタグの記事 7 件
CVE-2026-0770 — Langflow の未認証リモートコード実行（解説と対応策）
Langflow（AIエージェント構築ツール）の validate エンドポイントの未認証RCE（CVE-2026-0770・CWE-829）。exec_globals パラメータ経由で信頼できないコードが exec() 実行され、認証なしで任意コード実行に至る（CVSS 9.8・KEV掲載・実際に悪用中）。掲載時点でZDI/GitHub Advisory/NVDは修正版を明示せず、ZDI推奨は『製品への到達を制限』。本命の対応は『公開停止＝ネットワーク隔離＋認証＋最新版更新』。Langflow は過去にも validate 系RCEが再発しており、単発パッチ依存は危険。
CVE-2026-63030 / CVE-2026-60137 — WordPressコアの未認証SQLi→RCE（解説と対応策）
WordPressコアのREST APIバッチエンドポイントのルート混同（CVE-2026-63030・CWE-436）が、WP_Queryのauthor__not_inのSQLインジェクション（CVE-2026-60137・CWE-89）と連鎖し、未認証のSQLi→RCEに至り得る（CVSS 9.8・KEV掲載）。両者は同一リリースで修正済み。本命の対応は『6.8.6 / 6.9.5 / 7.0.2 以降へ更新』＋侵害確認。WordPressはコア＝影響範囲が極めて広く、更新が最優先。
CVE-2026-48939 — iCagenda（Joomla）の未認証ファイルアップロードでRCE（解説と対応策）
iCagenda（Joomlaのイベントカレンダー拡張）3.2.1–3.9.14 / 4.0.0–4.0.7 に、未認証の任意ファイルアップロード→RCE（CVSS 10.0・KEV掲載）。公開のイベント登録フォームの添付処理で認可がview層のみに掛かり、コントローラ側で強制されていなかったと報じられている。本命の対応は『3.9.15 または 4.0.8 以降へ更新』＋侵害確認。恒久的な守りは『未認証アップロード→RCE』の型を設計で潰すこと。
ファイルアップロードの脆弱性とは — Webシェル/RCEを防ぐ設計と設定
アップロードの穴の本質は『受け取ること』ではなく『どこに置き、実行させてしまうか』。認証なしの投稿口＋型検証なし＋Web公開領域に保存＋そこでスクリプトが実行できる、が揃うとWebシェル→RCEで乗っ取られる。守りは多層：①エンドポイントに認証/権限＋CSRF②サーバー側で許可リスト＋中身検査③保存先はWeb公開領域の外（or実行無効化）④ファイル名を乱数化しパスは信用しない。1枚の壁でなく、各段の止め所を複数持つ。
CVE-2026-48908 — SP Page Builder（Joomla）の未認証アップロードでRCE（解説と対応策）
JoomShaper製 SP Page Builder 6.6.1以前に、未認証の任意ファイルアップロード→RCE（CVSS 10.0・KEV掲載）。カスタムアイコンのアップロード処理に認証・型検証が無かったと報じられている。本命の対応は『6.6.2以降へ更新』＋侵害確認（不審な管理者・Webシェル）。恒久的な守りは『未認証アップロード→RCE』の型を防ぐ設計。
RCE（リモートコード実行）とは — なぜ最悪クラスの脆弱性なのか
RCEは攻撃者がサーバー上で任意のコードを実行できてしまう脆弱性。情報漏洩にとどまらず乗っ取りに直結する最悪クラス。被害範囲は『そのプロセスの権限』で決まる。防御の要は迅速な更新・CVE監視・最小権限。
AIで書いたコードからAPIキーが漏れ、不正課金された——本当の原因は放置したCVSS 10.0だった
請求の暴騰は氷山の一角。真因は放置した公開済みCVSS 10.0のRCEだった。固有名詞を伏せた事例から、防御の教訓を抽出します。