調べたいことを検索

PHPの開発チームは2026年10月21日、認証なしで遠隔からコードを実行される（RCE）おそれのある重大な脆弱性2件を直したPHP 8.5.12、8.4.27、8.3.36、8.2.35を公開し、すべての利用者にすぐ更新するよう求めた。脆弱性はメモリ不足の処理に関するCVE-2026-109618と、リクエストをまたいで古い内部状態が残るCVE-2026-109619で、どちらもCVSS v4.0で9.2。Webのリクエストを処理するPHP全般（PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeed）が対象で、開発チームはmod_phpの危険が最も高いとし、認証なしのリクエストでアプリケーションのコードが動く前に攻撃が成立する攻撃コードを確認したとしている。8.1以前は公式の更新がなく、7.4・8.0・8.1向けにはソースへの最小限の修正だけを提供した。Linuxの配布元には事前に修正が渡されている。完全な回避策はなく、更新だけが安全な選択だとしている。10月22日にはIPAとJPCERT/CCが注意喚起を出し、JVNもJVNVU#99905564を公開した。米CISAは、公表の時点で悪用を観測していないとしている。侵入が確定したという発表は、10月22日13時45分時点で見当たらない。レンタルサーバーは多くの事業者が適用の完了を知らせたが、まだ完了を知らせていない事業者もある。当サイトの結論：PHPを使うサイトは、自分で更新するのか事業者が更新するのかを確かめ、今日のうちに修正版へ上げる。レンタルサーバーでは、各社の完了のお知らせを公式サイトで確かめる。

WordPressは世界最大シェアのため最も狙われるが、侵入経路はほぼ決まっている（プラグイン/テーマの脆弱性・放置更新・弱い管理者・露出した管理画面）。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝更新の自動化・プラグイン/テーマ最小化・強い管理者＋2FA・管理画面の露出削減(xmlrpc/REST列挙/ファイル編集)・wp-configと秘密・ファイル権限・HTTPS/バックアップ・PHP/依存の更新 (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。

WordPress本体（4.7〜7.1.1）の認証なしローカルファイルインクルード（CWE-98）。テーマとサーバー設定の条件がそろうとRCE。修正は9/22（7.1.2ほか各系列）、CISAは9/25にKEV追加。当サイトの結論＝EPSSは3%でも、KEVに載った時点で最優先。更新に加えて、PHPの register_argc_argv を無効にして、RCEに必要なサーバー側の条件もなくす。

セッション固定は、攻撃者が用意した既知のセッションIDを被害者に使わせ、ログイン後にそのIDでなりすます攻撃。基本の防御は『ログイン（と権限変化）のたびにセッションIDを再生成する』こと。URLからのID受け取りを禁じ、Cookieには HttpOnly/Secure/SameSite を付ける。

サービス側でパスワードを安全に保存する実践ガイド。平文・暗号化・素のハッシュがなぜダメかを理解し、『ユーザーごとのソルト＋わざと遅い専用ハッシュ（Argon2id推奨、次点bcrypt/scrypt）』に集約する。自前実装せず標準関数を使い、コストは定期的に見直し、既存の弱いハッシュはログイン時に再ハッシュして移行する。

デシリアライズの危険は『変なデータが入ること』ではなく、形式によっては『どの型のオブジェクトを組み立てるか』を外部データが決められることにある。だから被害はデータの破損では終わらず、OWASPはサービス停止・アクセス制御の迂回・リモートコード実行を挙げる。対策の軸は2つ。JSONやXMLのような純粋なデータ形式に切り替えて型を選ばせない、そしてシリアライズ時に署名し、署名の無いものは復元しない。一部の仕組みは設定では安全にできず、使うのをやめる以外にない。

フレームワークが変わっても、狙われる弱点の種類（アクセス制御・秘密の扱い・インジェクション・依存CVE・設定ミス）はほぼ共通。違うのは『既定の危険な設定』と『その技術でよく狙われる場所』。当サイトは各フレームワークの既定の注意点とハードニング手順をそれぞれまとめている。まずは自分が使っているフレームワークの章へ。

Laravelの既定は安全寄りだが、本番事故は設定・運用から起きる。本ページは実務リファレンス。(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)危険な既定設定の一覧表 (3)領域別の具体対策＝秘密/APP_KEY・本番設定(APP_DEBUG/キャッシュ)・認可(Policy/Gate・Mass Assignment)・インジェクション/出力(Eloquentバインド・Blade)・セッション/CSRF/Cookie・アップロード・HTTPS/ヘッダ/レート制限・依存(Composer)CVE (4)自己検証チェック。攻撃手順は扱わず、防御と点検に限定。

SQLiは、入力が“データ”でなく“命令の一部”として解釈され、DBへの問い合わせの意味が変わる脆弱性。読み出し・改ざん・全削除に直結。基本の防御は『文字列連結をやめ、プレースホルダ（プリペアドステートメント）で値を渡す』こと。

原因は『アプリ本体をpublic_html直下に置いた』こと。public/ だけを見せるべきだった。応急処置→キーの再発行→構造改修の三段で直し、再発を仕組みで防ぐ。

最も効果のある対策は『アプリ本体をdocrootの外、public/ だけ公開』。まず .htaccess で応急処置をし、構造改修で恒久化、最後に自己点検。当サイトの視点＝これは個人のミスでなく、危険な配置が業界で標準になってしまった問題。だから注意力でなく仕組みで防ぐ。symlinkより bootstrap-redirect が安定する。

Rank Mathは2026年10月16日（UTC）、有料版のWordPressプラグインRank Math PROのv3.0.123で、10月15日20:02〜10月16日07:12（UTC。日本時間10月16日5:02〜16:12）に入手した一部の利用者のファイルにマルウェアが含まれていたと発表した。プラグインを有効化するとサイトが侵害されるおそれがあり、隠れたバックドアは訪問のたびに作り直されることがあるとしている。同社は該当ファイルを取り除き、問題のないv3.0.124を公開した。WordPress.orgで配布している無料版は対象外。影響を受けた利用者は「限られた数」とされ、件数と、マルウェアが混入した原因は公表されていない。10月20日時点で、発表は10月19日に無料版が対象外である旨の注記が加わったのが最後の更新。当サイトの結論：対象期間内に入手した3.0.123を有効化したサイトは侵害されたものとして扱い、期間より前のバックアップから戻すか、同社の順番どおりにプラグインのフォルダごと削除して調べる。どちらの場合も、サイトから読めた認証情報はすべて変える。

GMOインターネット株式会社は2026年9月20日、レンタルサーバー「ConoHa WING」の一部の収容ホスト（Webサーバー）で、一部の利用者のWebサーバー領域に第三者が不正にアクセスし、不正なプログラムを設置したと発表した。対象は426アカウントで、対象の情報は「お客様のWebサーバー領域に保存されたデータ」。不正アクセスと設置は9月3日に始まり、9月16日に検知、9月18日に原因と影響範囲を特定して不正プログラムを排除した。原因は特定したとしているが、内容は公表していない。会員情報・契約情報・支払い情報は別の環境で管理しており、漏えいはないとしている。Webサーバー領域のデータが外部に持ち出されたかどうかは、発表に書かれていない。対象者には登録メールアドレスへ個別に連絡しており、連絡がない利用者は対象ではないとしている。10月15日時点で続報はない。当サイトの結論：まず個別の連絡が届いているかを確かめ、届いていればその指示に従う。そのうえで、Webサーバー領域に置いていた認証情報（wp-config.phpのデータベースのパスワード、.envのAPIキーなど）は読まれたものとして変え、9月3日以降に増えたファイル・管理者・定期実行を確かめる。

サイトの侵入確認は『外から見える兆候』と『中に残る痕跡』の両方を見る。兆候＝Search Console の『セキュリティの問題』、検索結果の警告、事業者からの通知、知らない管理者、スマホや検索経由だけのリダイレクト。痕跡＝管理者ユーザー、コアファイルの改変（wp core verify-checksums）、ログイン履歴、authorized_keys、cron、待ち受けポート、最近変更されたファイル。当サイトの視点＝『何も見つからない』は安全の証明にならない。見つけたら、掃除の前に証拠を残し、きれいな端末から認証情報を全部変え、侵入前のバックアップか作り直しで戻し、入口を塞いでから再審査を依頼する。

事業者側の管理環境が侵害される類型は、利用者の設定では防げない。9月10日の調査結果で、販売管理システムへの不正アクセスが2023年4月から2026年3月までの間に発生していたこと、対象は583から951アカウントへ増えたこと、一部の初期パスワードがハッシュ化されていなかったことが公表された。だから守り方は『防ぐ』から『被害範囲を縮める』に切り替える。当サイトの視点＝共用サーバーに置いた情報は読まれた前提で設計し、認証・バックアップ・秘密の置き場所を事業者の外へ分散させる。発行時の初期パスワードを使い続けている契約は、今日変更する。

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』の型を設計で防ぐこと。

JoomShaper製 SP Page Builder 6.6.1以前に、未認証の任意ファイルアップロード→RCE（CVSS 10.0・KEV掲載）。カスタムアイコンのアップロード処理に認証・型検証が無かったと報じられている。最も確実な対応は『6.6.2以降へ更新』＋侵害確認（不審な管理者・Webシェル）。恒久的な対策は『未認証アップロード→RCE』の型を防ぐ設計。

パスワードのハッシュ化＝元に戻せない一方向変換でパスワードを保存する方法。平文保存はNG。暗号化と違い復号できないのが利点。ただしMD5/SHA-256を素で使うとレインボーテーブルや総当たりで破られる。安全な方法は『ユーザーごとのソルト』＋『わざと遅い専用ハッシュ（bcrypt/Argon2/scrypt）』。自前実装せず標準ライブラリに任せる。

ソルト＝パスワードをハッシュ化する前に足す、利用者ごとに違うランダムな値。同じパスワードでも保存値が全員バラバラになり、事前計算したレインボーテーブルが無効化され、1回の解析で複数人を破ることもできなくなる。ソルトは秘密ではなくハッシュと一緒に保存してよい。bcrypt/Argon2なら自動で付与される。

webroot（公開ディレクトリ）に置いたファイルは、URLを叩けば誰でも取得できる。トークンや認証情報のJSON・.env・バックアップを置き忘れると即・実害。さらに共通テンプレート由来なら、全サイトの同じ場所に同じファイルがある。対策＝公開ディレクトリには公開してよい物だけ、秘密はwebroot外＋権限600、そして自分のサーバーを棚卸しして1か所見つけたら全台点検。

Magento 2 拡張 Mirasvit Full Page Cache Warmer 1.11.12未満に、認証なしでRCEに至るPHPオブジェクトインジェクション（CWE-502）。CVSS 9.3。最も確実な対応は『1.11.12以降へ更新』。根本的な防御は信頼できないデータをデシリアライズしないこと。