サーバー
このタグの記事 15 件
Linuxカーネル脆弱性 CVE-2026-98432：ネットワーク越しに突かれうるTCPの欠陥（CVSS 9.8）。修正版を入れて再起動し、MPTCPも確認
CVE-2026-98432は、LinuxカーネルのIPv4 TCP処理にある解放後使用（use-after-free）の脆弱性で、2026年10月15日に公表されました。カーネル開発チームの採番機関はCVSS v3.1で9.8（ネットワーク越し、権限不要、利用者の操作不要）と評価しています。AI企業の研究チームが、Multipath TCP（MPTCP）で待ち受けるサーバーに対し、実験環境でroot権限のリモートコード実行を実演したと報じられています（同社自身の報告にもとづき、報道機関は検証していません）。BleepingComputerは、MPTCPを使わないTCPサーバーでのリモートコード実行は公には示されておらず、実際の攻撃も確認されていないと伝えています。当サイトは11月1日時点で、米CISAのKEVにこのCVEが載っていないことを確認しました。上流の修正は5.10.272・5.15.223・6.1.190・6.6.159・6.12.113・6.18.56・7.2.10以降で、11月1日時点でDebianは修正版を出し、SUSEは一部を出し、UbuntuとRed Hatは修正を準備中としています。MPTCPを止めるだけでは完全な対策になりません。当サイトの結論：インターネットに公開したLinuxサーバーから、修正版が出た順に更新して再起動し、それまでは配布元の一時しのぎを使ってください。
PHPの緊急更新で見落としやすい点：WebとコマンドラインのPHPは別、set -e と diff の終了コード、更新後の侵入確認
2026年10月のPHPの重大な脆弱性への対応で、当サイトの運営者が関わるサイトでは、Web用のPHPを更新しても、cronが使うコマンドライン用のPHPが古い版のままだった。更新後の確認は、Webとコマンドラインを別々に行う。シェルスクリプトで set -e を使うと、diff や grep は『差がある・一致しない』だけで終了コード1を返し、スクリプトが止まる。0・1・2を区別して受ける。更新後は全サーバーに同じ侵入確認の項目を当て、疑わしいログは、本番のファイルと配布時のコピーを比べて決着させる。
VMware ESX脆弱性 CVE-2026-41709（CVSS 2.7）｜低い深刻度のログ不備を米CISAが悪用確認として登録。VMSA-2026-0006の全体を更新し、ホストを調べる
CVE-2026-41709は、VMware ESXのログ不備の脆弱性です（CVSS 2.7、深刻度は低）。すでに管理者権限を持つ攻撃者が、特定の操作をログに残さずに実行できます。Broadcomは2026年7月29日、勧告VMSA-2026-0006で修正版を出しました。回避策はありません。米CISAは2026年10月28日（米国時間）、悪用が確認された脆弱性の一覧（KEV）に追加し、米連邦政府機関の期限を11月11日としました。あるセキュリティ企業の脅威レポートは、中国と関連のあるグループがこの脆弱性をゼロデイ（修正版の公開前）で使い、米国の組織への複数の侵入で、2026年の初めまで使ったと述べており、SecurityWeekはその目的を監査の記録を見えにくくするためと伝えています。当サイトはこのレポートを独自には確認できていません。この脆弱性だけでは侵入できませんが、影響を受けたホストのログに、侵入者の行動が残っていないかもしれません。同じ勧告にはvCenterの深刻度9.8の脆弱性が2件あり、うち1件（CVE-2026-59310）は8月18日にCISAが悪用ありとして登録しています。ESXだけ直しても入口が残ります。当サイトの結論：勧告全体の修正版へESXとvCenterを更新し、ホストのログを別のサーバーへ送り、ログだけを信じずに侵害の形跡を調べる。
Linuxカーネル脆弱性 Fragnesia（CVE-2026-46300）｜米CISAが悪用を確認、期限は10月31日。PHPとカーネルを更新して再起動
CVE-2026-46300（通称Fragnesia）は、権限の低いローカルのユーザーがroot権限を得られるLinuxカーネルの脆弱性です（CVSS v3.1で7.8、攻撃元区分はローカル）。カーネルがネットワークの受信データの断片をほかのバッファーへ移すとき、「ファイルのメモリ上の写しと共有している」という目印が消えることがあり、IPsecのESP処理が、読み取り専用のファイルのキャッシュを上書きして復号してしまいます。カーネルの開発チームは2026年5月23日にCVEを公表し、修正は5.10.257・5.15.208・6.1.174・6.6.141・6.12.91・6.18.33・7.0.10以降に入りました。米CISAは2026年10月28日（米国時間）、悪用の証拠があるとして悪用が確認された脆弱性の一覧（KEV）に追加し、米連邦政府機関の期限を10月31日としました。CISAの説明は、PHPの脆弱性CVE-2026-109618・CVE-2026-109619と組み合わせて、PHPのウェブシェルを仕込みroot権限でコマンドを実行できる、としています。あるセキュリティ企業はこの組み合わせで25台のサーバー（大半はファイアウォール）がroot権限を奪われたと報告し、SecurityWeekも伝えていますが、当サイトは数字を独自には確認できていません。Ubuntu・Red Hat・Debianは修正版のカーネルを出していて、更新は再起動してはじめて効きます。当サイトの結論：LinuxでPHPのサイトを動かしているなら、PHPとカーネルを更新して再起動し、ウェブシェルの有無を調べる。
Nextcloudの組み込みCollabora（CODE）脆弱性 CVE-2026-110447（悪用確認）｜対象の確かめ方と対策
Collabora Onlineの開発元は2026年10月14日、Nextcloud用アプリ「Collabora Online - Built-in CODE Server」（アプリID richdocumentscode）に、認証なしでOSコマンドを実行される脆弱性CVE-2026-110447があると公表した。アプリのproxy.phpを通じて、Webサーバーの実行ユーザーの権限でコマンドが動くおそれがある。条件は、組み込みのCODEサーバーが動いていないとき（コンテナの再起動、更新、異常終了のあとなど）。対象は26.4.303より前で、修正版の26.4.303は9月11日に出ている。開発元はアプリを無効にしても防げないとし、更新か削除を求めている。サポートが終わったNextcloud 29以前は、Nextcloud本体を更新するかアプリを削除する。開発元は、単独で動かすCollabora Onlineサーバー、Dockerイメージ、RPM/DEBパッケージ、Nextcloud All-in-Oneは影響を受けないとしている。CVSS v4.0は9.2。米CISAは10月23日に悪用が確認された脆弱性の一覧（KEV）に加え、対応期限を10月26日とした。開発元のリポジトリには9月10日ごろからの攻撃の報告があり、報道によればWebシェルが置かれた例がある。当サイトの結論：組み込みCODEを入れているなら、無効にしたままでも今日バージョンを確かめ、更新か削除をしてから、9月10日以降の痕跡を確かめる。
GitLab脆弱性 CVE-2026-110264（CVSS 10.0）と悪用が確認されたCVE-2026-97229｜自前運用のGitLabを確かめて更新する手順
GitLabは2026年10月21日、Community Edition（CE）とEnterprise Edition（EE）の緊急パッチリリース19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10、18.11.13を公開した。最も深刻なCVE-2026-110264（CVSS 10.0）は、正規表現をコンパイルするときの整数オーバーフローにより、条件によっては認証していない利用者がGitLabサーバー上で任意のコードを実行できるおそれがあるというもので、7.0以降のほぼすべての版が対象。10月29日には、同種の脆弱性CVE-2026-97229（CVSS 10.0、CWE-190）が米CISAのKEV（悪用が確認された脆弱性の一覧）に登録され、対応期限は11月1日とされた。CI/CD設定の正規表現コンパイラの整数オーバーフローで、認証なしで到達できる点も同じ。GitLabは10月12日に19.4.2、19.3.5、19.2.8で修正済みで、対象は19.2.0から19.2.7、19.3.0から19.3.4、19.4.0から19.4.1だけ。19.4.2、19.3.5、19.2.8より前の版を使っている環境は、悪用が確認された脆弱性にさらされている。この記事が勧める版（19.5.1、19.4.3、19.3.6、19.2.9）に上げれば、CVE-2026-97229も直る。GitLab.comは修正済みで、自前で運用している環境（Self-Managed）は更新が必要。10月21日のリリースではHighの脆弱性2件（CVSS 8.2と7.5）なども修正されたが、こちらの修正は19.3.6以降の3系統だけに入っている。原因はRubyの正規表現エンジン（Onigmo）にあり、Rubyは10月23日に4.0.9、3.4.12、3.3.13を公開した。攻撃者が操作できる文字列から正規表現を作るアプリが対象で、Regexp.timeoutでは防げない。GitLabの告知にCVE-2026-110264が悪用されたという記載はなく、KEVにも入っていない（10月30日時点）。Alpine Linuxは、自社のGitLabが10月20〜21日にCVE-2026-97229を狙った攻撃を受けたこと、GitLabを19.3.6に上げただけでは直らず、修正版のRubyも必要だったことを公表した（インスタンスは作り直し、攻撃者のコードが動いた証拠は見つかっていない）。当サイトの結論：自前のGitLabは必須の経由版を確かめて今日更新し、最終的には19.3.6以降に上げる。GitLabを自分でビルドしたり独自のRubyで動かしたりしている場合は、Rubyも3.3.13、3.4.12、4.0.9以降か確かめる。Rubyのアプリは修正版のRubyに上げ、利用者の入力から正規表現を作らない。
SiteGuard Server Edition脆弱性 CVE-2026-106931（悪用確認）｜対象の確かめ方と対策
EGセキュアソリューションズは2026年10月14日、ホスト型WAF「SiteGuard Server Edition」の統計機能にOSコマンドインジェクションの脆弱性CVE-2026-106931があり、すでに悪用が確認されていると公表した。悪用されると、製品が動くサーバー上でrootまたはSYSTEM権限で任意のOSコマンドが実行されるおそれがある。対象はVer2.20以降で統計機能が有効（初期値は有効）な環境で、Apache版・Nginx版・IIS版はVer8.00 Update5より前、FreeBSD Apache版・Nginx版はVer7.00 Update6より前。IIS版のVer3.10からVer4.00 Update4は対象外。修正版はVer8.00 Update5とVer7.00 Update6で、更新が難しい場合はサポート終了版を含むパッチが提供されている。同社のCVSS評価は攻撃元区分がローカル、必要な特権レベルが低（v3.0で7.8、v4.0で8.5）。JPCERT/CCは国内で広く使われていることを確認したとして注意喚起を出し、統計機能の無効化で影響を回避できるとした。米CISAは10月20日に悪用が確認された脆弱性の一覧（KEV）に加え、対応期限を10月23日とした。当サイトの結論：Server Editionを運用しているなら、バージョンと統計機能を今日確かめ、更新の前に診断情報を保存してから、修正版かパッチを当てる。
PHP脆弱性 CVE-2026-109618・CVE-2026-109619｜米CISAが悪用を確認（KEV）・修正と確認
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月26日に2件を「悪用が確認された脆弱性」の一覧（KEV）に加え、米国の連邦政府機関に10月29日までの対応を求めた。報道によれば、あるセキュリティ研究者がおとり用に運用する修正前のPHP（8.4.26、mod_php）のサーバーで、10月24日に遠隔からのコード実行が成功した。大手クラウド事業者は、公表の4日前の10月17日からおとり用のサーバーで悪用の試みを観測していた。おとり用のサーバー以外で侵入の被害が公表された例は、10月27日時点で当サイトが確認した範囲では見当たらない。レンタルサーバーは主な事業者の多くが適用の完了を知らせたが、KAGOYAなど一部の事業者は完了を知らせていない。10月23日、PHPの開発チームは10月21日の修正版では直っていない3件目の問題（CVE-2026-115560）を公表した。設定とアプリケーションのコードが特定の組み合わせのときだけコード実行につながるもので、開発チームは実際には起きにくいとし、次の定例リリースで修正と詳しい勧告を出す。それまでは session.upload_progress.enabled=0 を設定するよう勧めている。影響を受けるバージョンとCVSSは未公表で、悪用の報告はない。10月29日にphp.netで確認した時点でも、この問題の修正版はまだ出ていない。米CISAは10月28日、Linuxカーネルの脆弱性 CVE-2026-46300 もKEVに加え（米国の連邦政府機関の期限は10月31日）、この2件と組み合わせてPHPのウェブシェルを仕込み、root権限でコマンドを実行できると説明している。当サイトの結論：悪用が確認されたので、PHPを使うサイトは、自分で更新するのか事業者が更新するのかを確かめ、今日のうちに修正版へ上げる。10月17日以降のログで侵入の跡がないかも確かめる。レンタルサーバーでは、各社の完了のお知らせを公式サイトで確かめる。
サイトのセキュリティとSEO｜改ざん・検索警告・HTTPS
脆弱性があるだけでは、Google は順位要因として挙げていない。問題になるのは悪用されたとき。改ざんでスパムページが増えると検索結果に「このサイトは第三者によってハッキングされている可能性があります」が付き、マルウェアやフィッシングでは Chrome に「危険なサイト」の警告画面が出る（他のブラウザもセーフ ブラウジングにもとづく警告を出す）。スパムポリシー違反のサイトは順位が下がるか表示されなくなることがある。HTTPS は2014年に、ウェイトを非常に小さく設定した順位シグナルとして発表されたが、現在の文書は Core Web Vitals 以外のページ エクスペリエンス要素は順位上昇に直接貢献しないとしている。当サイトの視点＝SEO のためにセキュリティの点数を上げるより、改ざんされない運用と、されたときに早く気づく仕組みに時間を使う。
サイトやサーバーが不正アクセスされたか調べる方法：レンタルサーバー・WordPress・VPS別の確認手順と、見つけたときの順番
サイトの侵入確認は『外から見える兆候』と『中に残る痕跡』の両方を見る。兆候＝Search Console の『セキュリティの問題』、検索結果の警告、事業者からの通知、知らない管理者、スマホや検索経由だけのリダイレクト。痕跡＝管理者ユーザー、コアファイルの改変（wp core verify-checksums）、ログイン履歴、authorized_keys、cron、待ち受けポート、最近変更されたファイル。当サイトの視点＝『何も見つからない』は安全の証明にならない。見つけたら、掃除の前に証拠を残し、きれいな端末から認証情報を全部変え、侵入前のバックアップか作り直しで戻し、入口を塞いでから再審査を依頼する。
公開ディレクトリに秘密ファイルを置き忘れていないか：webrootの棚卸し
webroot（公開ディレクトリ）に置いたファイルは、URLを叩けば誰でも取得できる。トークンや認証情報のJSON・.env・バックアップを置き忘れると即・実害。さらに共通テンプレート由来なら、全サイトの同じ場所に同じファイルがある。対策＝公開ディレクトリには公開してよい物だけ、秘密はwebroot外＋権限600、そして自分のサーバーを棚卸しして1か所見つけたら全台点検。
セキュリティの棚卸し：複数サーバーを個人運用する人が見落とす点検7項目
複数サーバーを個人運用する人の事故は「足りない対策」より「把握していない状態」が原因になりがち。守る境界は鍵を置いたPC。2FAはメール→ドメイン→課金の順に優先、SSH鍵は「どの鍵でどのサーバーに入れるか」を表にして重複・未使用・用途が消えた登録を消す、平文パスワードはクラウドから消す、是正は可逆に1つずつ、台帳に機密は書かない。派手な新ツールより棚卸しが先。
自前のGitサーバーとGitHub、セキュリティ的にどっちが安全か
自前Gitは『安全になる』のではなく『リスクを移し替える』。誤公開という事故クラスは消えるが、サーバのパッチ・バックアップ・コミット前の秘密検出という責任が自分に移る。条件を満たせば良い選択、放置すればGitHubより危険。当サイトの視点＝自前運用は、GitHubが担っていた作業を自分で続けることが前提。
SSH鍵の最小権限：侵害されるおそれのある一時環境に本番のroot鍵を置かない
一時的で侵害され得る環境（GPU pod・CIランナー・使い捨てVM）から本番へroot鍵を登録すると、その環境が侵害された時点で本番にroot権限で入られる。対策＝一時環境にroot鍵を置かない／使わなくなったら消す／再度必要なら非rootユーザー＋command制限鍵（command="..." restrict）で操作を1つに限定。使い回している鍵は最も重要な資産として扱い、1つ漏れたら全サーバーに入られる構成を作らない。
レンタルサーバーで .env を公開しないための配置と設定
最も効果のある対策は『アプリ本体をdocrootの外、public/ だけ公開』。まず .htaccess で応急処置をし、構造改修で恒久化、最後に自己点検。当サイトの視点＝これは個人のミスでなく、危険な配置が業界で標準になってしまった問題。だから注意力でなく仕組みで防ぐ。symlinkより bootstrap-redirect が安定する。