「サイトは3年前に作ってもらって、そのあとは特に何も。問題なく表示されているので、触る理由もなくて」——これは、Webサイトを持つ会社と話していて最もよく聞く状態です。表示されている以上、動いているように見える。実際、見た目の上では何も壊れていません。
問題は、見た目が変わらないまま中身だけが危険になっていくことです。2025年末に公表された React の脆弱性、通称 React2Shell（CVE-2025-55182） は、危険度を示す CVSS スコアが上限の 10.0。修正版は公表とほぼ同時に出ています。それでも2026年7月のいま、長く放置されていた環境を調べたら攻撃の痕跡が見つかった、という報告が技術者コミュニティから上がってきました。半年以上前に塞げたはずの穴が、まだ開いたままの現場が残っているということです。
React2Shellは何がまずいのか — 表示は正常なまま乗っ取られる
この脆弱性が厄介なのは、影響範囲の広さです。React2Shell は React Server Components（RSC）に起因する遠隔コード実行の欠陥で、サーバー側で任意のコードを実行される——つまりサイトの改ざんや情報の抜き取り、その先の社内ネットワークへの足がかりにまで発展しうる種類のものです。しかも RSC の仕組みを使うアプリケーションは、自社で該当する機能を直接書いていなくても対象になり得ます。Next.js を既定の構成で使っている場合はとくに注意が必要とされました（トレンドマイクロによる CVE-2025-55182 の分析）。
そして、これは机上の危険ではありません。JPCERT/CC は2026年1月時点で、この脆弱性を悪用して国内の環境にマルウェアが設置された事例を確認したと注意喚起しています（JPCERT/CC）。修正版は React 19.0.3 / 19.1.4 / 19.2.3 として提供済みです。更新すれば塞がる。更新しなければ塞がらない。 それだけの話が、更新する人がいないという一点で止まり続けています。
見た目が正常なことは、安全であることの証拠になりません。攻撃者にとって、乗っ取ったサイトの表示を壊す理由はないからです。むしろ気づかれないほうが都合がいい。「問題なく表示されているので触っていない」という状態は、実は最も気づきにくい状態でもあります。
「作って終わり」の契約が生む空白
なぜ半年以上放置されるのかというと、多くの場合、誰の仕事でもないからです。制作会社との契約が納品で完了していれば、その後のライブラリ更新は契約の外側にあります。社内に技術者がいなければ、更新が必要だという情報が届く経路もありません。悪意も怠慢もなく、単に担当が存在しない空白が生まれます。
この空白は、WordPress のようなCMSを使ったサイトでも同じ形で起きます。本体やプラグインの緊急更新が必要になったとき、誰が気づいて誰が当てるのかが決まっていない。WordPress本体の緊急脆弱性で放置サイトがやるべきことで扱ったのも同じ構造の問題です。使っている技術が React でも WordPress でも、部品を借りて作っている以上、部品側の事情で更新が必要になるという点は変わりません。この「借りている部品」の連鎖が抱えるリスクの全体像はソフトウェアサプライチェーン攻撃の記事で整理しています。
保守契約で確認する4つの問い
「保守契約を結んでいます」だけでは足りません。保守という言葉が指す範囲は会社ごとにまったく違うからです。契約書や見積書を開いて、次の4点が読み取れるかを確かめてください。読み取れないなら、それは今のうちに詰めるべき曖昧さです。
- 脆弱性情報を誰が追うのか。 サイトで使っている技術に重大な脆弱性が出たとき、それを検知して知らせるのは制作会社側か、自社側か。「連絡があれば対応します」という契約は、実質的に誰も追っていない状態を意味します。
- 緊急更新の対応時間はどう決まっているのか。 重大度に応じた対応期限（たとえば緊急なら3営業日以内）が明記されているか。月次の定期作業だけの契約だと、公表から最大1ヶ月開いたままになります。
- 更新作業は保守費に含まれるのか、都度見積もりか。 含まれない契約自体は不当ではありませんが、「都度見積もり」だと発注判断を挟む分だけ確実に遅れます。緊急時にどう運用するかまで決めておく必要があります。
- 検証環境はあるのか。 更新して壊れないかを確かめる場所がないと、本番でいきなり当てるか、怖くて当てないかの二択になります。実際には後者に倒れがちです。
この4点は、新しくサイト制作を発注するときの要件にもそのまま使えます。納品物の話だけでなく、納品後の状態をどう保つのかを最初に決めておく。検収の場面で何をどこまで確認するかについては発注したシステムを受け取るときの検収の考え方も合わせて参考にしてください。
金額の話に触れておくと、「保守費が安いほうがいい」という基準だけで選ぶと、実質的に何もしない契約に落ち着きます。月額の中に何時間分の作業が含まれ、その時間が緊急対応に使えるのかどうか。ここを確認せずに単価だけを比べると、いざというときに「別途お見積りです」と返ってきて、判断と発注のやり取りで数日が溶けます。安さの中身が「連絡を受け付けるだけ」なのか「監視して先に動く」なのかは、契約前に必ず言葉で確かめておくべき差です。
今日できる棚卸し
契約の話に入る前に、まず現状を把握するところからです。自社が持っているWebサイト・Webシステムを列挙し、それぞれについて「最後に更新作業をしたのはいつか」「今それを頼める相手はいるか」を書き出してください。この二列の表を作るだけで、空白がどこにあるかは一目で分かります。
多くの会社で、キャンペーン用に作った小さなサイトや、数年前に立てた採用サイトが真っ先に浮かび上がります。本体サイトは保守していても、そうした周辺のサイトが誰の管轄でもないまま生き残っている。攻撃者から見れば、そこが最も入りやすい入口です。証明書の期限切れで突然落ちるケースも同じ経路で起きるので、SSL証明書の有効期限短縮への備えと合わせて棚卸ししておくと効率がいいでしょう。
「そもそも自社サイトが何で作られているのか分からない」「保守を頼める相手がいないサイトが残っている」——そうした状態の整理から、グリームハブでお手伝いできます。現状の把握と、リニューアルすべきか保守で延命すべきかの判断まで含めてご相談ください。要件によって最適な進め方は変わるため、個別にお見積りします。お問い合わせからご連絡いただけます。
