てがろぐに認証回避の脆弱性、全旧版が対象

【更新 2026-08-03】本記事を見直し、修正しました。主な修正点：「情シスはどうすべきか」で紹介していたIPA「脆弱性対策情報」へのリンクがリンク切れ（404）になっていたため、現行のURL（https://www.ipa.go.jp/security/vuln/index.html）に差し替えました。本文の記述内容（CVE-2026-64940の事実関係・対処手順）に変更はありません。

国内で広く使われている無料CGI「てがろぐ -Fumy Otegaru Memo Logger-」に、権限のない第三者が管理画面にログインできる脆弱性（CVE-2026-64940）が公表されました。対象はVer 4.8.4以前のすべて（Ver 1.0.0〜4.8.4）で、修正版はVer 4.9.0です。JVNの公表は2026年7月29日ですが、修正版は1か月前の6月29日にすでに出ています。

そして本件でいちばん厄介なのは、脆弱性そのものよりも「自社のどこに設置されているか情シスが把握していない」という点です。この記事では該当判定の具体的な手順まで踏み込みます。

この記事でわかること

• CVE-2026-64940の内容と、JVNの表題から誤読されやすい点
• 自社サイトに「てがろぐ」が設置されているかを5分で確かめる方法
• バージョン番号が公開ページのHTMLに出力されているという構造的なリスク
• 更新しただけでは終わらない、あと1手の必須操作

何が起きたのか

にししふぁくとりーが配布するマイクロブログCGI「てがろぐ」に、認可の不備が見つかりました。JPCERT/CCが開発者との調整を行い、情報セキュリティ早期警戒パートナーシップに基づいてJVNで公表されています。

ベクタが示すとおり、ネットワーク経由・認証不要・利用者の操作不要で成立します。CGIが公開されているサーバであれば、インターネット側から直接狙える条件です。なお執筆時点（2026年8月2日）で、悪用の報告や検証コード（PoC）の公開は確認できていません。

「正規表現の脆弱性」はReDoSのことではない

JVNの表題は「制限が不十分な正規表現を使用している脆弱性」です。ここで手が止まる方が多いのではないでしょうか。正規表現の脆弱性と聞くと、まず思い浮かぶのはReDoS（正規表現によるサービス拒否）で、影響はサービス停止どまり、優先度は中程度——という判断になりがちです。

しかし本件はReDoS（CWE-1333）ではなく、CWE-625: Permissive Regular Expression（寛容な正規表現）です。MITREの定義では、正規表現が許可すべき値を十分に絞り込めていない欠陥を指し、典型的な原因は文字列の先頭・末尾を示すアンカー（^ や $）の欠落や、ワイルドカードの使い過ぎです。部分一致してしまうために、本来通してはならない入力が検査をすり抜けます。想定される結果はパフォーマンス低下ではなく、アクセス制御の回避です。

JVNの表題（種類）だけを見て一覧を仕分けている運用では、この1件が「DoS系だから後回し」の山に入りかねません。種類ではなく「想定される影響」の欄を読む——当たり前のようでいて、大量のJVN項目をさばく現場では抜けやすいところです。

CVSSベクタと影響記述には少しズレがある

細かい点ですが、CVSS v4.0のベクタは機密性への影響を VC:L（低）としています。一方で影響の記述は「管理画面で使用可能な任意の操作を実行される」です。管理画面に入られれば投稿の閲覧・改ざん・削除も設定変更も可能になるため、数字と記述のあいだには開きがあります。

てがろぐが本来「公開するためのミニブログ」であることを踏まえた評価と考えられますが、実際に何を失うかは設置場所で決まります。社外向けの更新情報欄なのか、限られた関係者だけが見る連絡板なのかで意味がまったく違います。スコアの数字ではなく、自社のその設置がどう使われているかで優先度を判断してください。

自社に設置されているかを5分で確かめる

てがろぐはPerl製のCGIで、データベースを必要とせず、ZIPを解凍してサーバにアップロードするだけで動きます。手軽さが長所である反面、資産管理ツールの「インストール済みソフトウェア一覧」には絶対に出てきません。導入したのも情シスとは限らず、広報担当や店舗、部活動・サークル単位のページということも珍しくありません。

該当判定は次の順で行うのが確実です。

手順1：公開ページのHTMLを見る（外側からの確認）

てがろぐは、無料利用の条件として出力ページへのPowered-by表記を必須にしています。そしてこの表記にはバージョン番号がそのまま入ります。公式デモページのHTMLを確認すると、フッタに次の形で出力されていました。

<p class="poweredby"><!-- てがろぐ Version: -->Powered by <a href="...">てがろぐ</a> Ver 4.9.0.</p>

したがって、自社ドメインに対して site:example.com "Powered by てがろぐ" のようにサイト内検索をかければ、設置ページを洗い出せます。見つかったページのHTMLソースで poweredby を検索すればバージョンも即座に分かります。

ただし、法人向けの商用ライセンスではPowered-by表記を外せます。表記が見つからないことは「設置されていない」証明にはなりません。手順2と併せて確認してください。

手順2：サーバ側でファイルを探す（内側からの確認）

本体ファイル名は既定で tegalog.cgi、共通ライブラリが fumycts.pl、更新用のPHPが tegup.php です。Webサーバのドキュメントルート配下をこの名前で検索します。設置者がCGIファイル名を変更しているケースもあるため、fumycts.pl を手がかりにするほうが取りこぼしが少なくなります。

開発者自身も注意喚起ページで、「昔にセットアップしたっきり最近は使わなくなっていたので存在を忘れている」ものがないか思い出してほしい、と書いています。使っていないから安全ではなく、放置されているものほど古いバージョンのまま動き続けています。不要であれば更新ではなく削除が正解です。

攻撃者からも同じ方法で見えている

手順1は裏を返すと、攻撃者も同じ手段で「脆弱なバージョンが動いているサイト」を機械的に列挙できるということです。バージョン番号が公開ページのHTMLに常時出力されている以上、探索のためにサーバへ何かを送り込む必要すらありません。

これは製品の作りが悪いという話ではなく（バージョン表示は利用者にとって親切な仕様でもあります）、この種の脆弱性では「まだ狙われていないから大丈夫」という時間的な猶予が通常より短いという事実の指摘です。優先度を下げる材料がひとつ減る、と理解してください。

更新しただけでは終わらない：あと1手

対処自体は簡単です。開発者は次のように案内しています。

• 推奨は管理画面から専用PHP「TegUp」（tegup.php）でクリック更新
• 手動なら、最新版ZIPから tegalog.cgi / fumycts.pl / tegup.php の3ファイルだけを上書きアップロード
• 過去のどのバージョンからでも更新でき、データと設定はすべて引き継がれる

「互換性の検証が必要だから来月」という先送りの理由が立ちにくい形です。ここは素直にありがたい設計だと思います。

そのうえで見落としてはならないのが、更新後に管理画面下部の「全員を強制ログアウト」ボタンを1回押すという手順です。この操作で、すべてのブラウザのログイン状態を一括解除できます。開発者は「バージョンアップしないままでこの操作をしても対処したことにはなりません」とも明記しています。

つまり、すでに侵入されていた場合、パッチを当てるだけでは相手のログイン状態が残るということです。脆弱性の入口は塞いだのに居座られる、というのは認証まわりの脆弱性で繰り返し起きる型で、パスワードやセッションの再発行までを1セットで考える必要があります。手順書を作るなら「更新 → 強制ログアウト → 管理者パスワードの変更 → 投稿・設定に不審な変更がないか確認」まで書いておくと安全です。

修正版は1か月前に出ていた

本件の時系列を並べると、情報の入り口をどこに置くかという問題が見えてきます。

JVNやCVEの公表を待っていた組織は、1か月遅れてこの情報を受け取ったことになります。さらに言えば、CVE-2026-64940はNVD（米国の脆弱性データベース）では執筆時点で参照できません。JVN経由で採番されたCVEがNVDに反映されるまでには時間差があるため、NVDやCVEのフィードだけを監視する運用では、国内製品の情報は取りこぼします。

開発者が6月末から8月上旬まで、SNS・公式サポートページ・フォーラム・リリースノートと繰り返し告知を出し、7月には管理画面の案内ボタンをわざわざ目立つ点滅表示に変えているという事実も重いところです。作り手側が手を尽くしても、設置されたきり忘れられたCGIには声が届かない——これは製品側ではなく、利用する組織側の資産管理の問題です。

現場目線の所感

正直なところ、この手の脆弱性がいちばん困ります。CVSSは8点台で立派に高いのに、社内の脆弱性管理台帳には製品名すら載っていない。載っていないものは検知できないし、対応漏れとしてカウントされることもありません。台帳の上では今日も対応率100%です。

WordPressのような大物なら、まだ「使っているかどうか」を全社に聞いて回る発想が出てきます。しかし数百KBのCGIを1つ、10年前に誰かがFTPで置いた——という規模のものは、事故が起きるまで誰も思い出しません。しかも今回のように「更新は3ファイル上書きで済み、データも引き継がれる」対処コストの低いケースほど、難しいのは作業ではなく、そこに存在すると気づくことだという事実がはっきり出ます。

裏返せば、本件は自社の外部公開資産の棚卸しが実際に機能しているかを試す、ちょうどよい抜き打ちテストでもあります。今日サイト内検索を1回かけて何も出てこなければ良し、何か出てきたなら、それは今回の脆弱性以上に価値のある発見です。

情シスはどうすべきか

本件そのものの対処は前述のとおり、更新と強制ログアウトで完了します。より本質的な課題は、「情シスが把握していない外部公開資産をどう見つけるか」のほうです。自前で長大なチェックリストを作るより、まずは公的機関の指針に沿って自社の現状を測ることをおすすめします。

• 中小企業の情報セキュリティ対策ガイドライン（IPA） — 情報資産の洗い出しと管理台帳の作り方が具体例つきで示されています。まず「どこに何があるか」から始める組織に適しています。
• 脆弱性対策情報（IPA） — JVNを含む国内の脆弱性情報の入り口です。海外フィードだけを見ている場合は、購読先にJVNを加えてください。
• 対策のしおり（IPA） — 部門の担当者にそのまま配れる啓発資料です。「業務でWeb上のツールを設置したら情シスに連絡してほしい」という地道な周知は、結局これがいちばん効きます。

あわせて、社内の公開サイト運用ルールに「導入した公開ツールは種類・バージョン・設置URL・管理者を届け出る」という1行を足しておくと、次に同じ形の脆弱性が出たときの調査時間が大幅に変わります。

まとめ

1. てがろぐ Ver 4.8.4以前のすべてが対象。第三者に管理画面へログインされる恐れがあり、修正版はVer 4.9.0です。JVNの表題は「正規表現」ですがReDoSではなく、実態は認証回避です。
2. 該当判定は公開ページのPowered-by表記とサーバ上のファイル名検索の二段構え。バージョン番号がHTMLに出力されるため、攻撃者からも同じように見えている点を考慮して優先度を決めてください。
3. 更新後に「全員を強制ログアウト」を1回実行する。パッチ適用だけでは、既存のログイン状態が残ります。

関連記事

• EASMとは？外部攻撃対象領域管理の仕組みを解説
• WordPress SSOプラグインに認証回避の脆弱性
• Appsmithに保存型XSS、内製ツール基盤の盲点
• Tomcatサンプルアプリに脆弱性、修正版は未公開

出典

• JVN#99975039 てがろぐ -Fumy Otegaru Memo Logger-における制限が不十分な正規表現を使用している脆弱性（JPCERT/CC・IPA、2026年7月29日）
• JVNDB-2026-000104（IPA）
• てがろぐ 脆弱性対処報告と注意喚起（にししふぁくとりー、2026年6月30日公開・8月1日更新）
• お手軽マイクロブログCGI「てがろぐ」配布ページ
• CWE-625: Permissive Regular Expression（MITRE）

※本脆弱性は、三井物産セキュアディレクション株式会社の東内裕二氏がIPAへ報告し、JPCERT/CCが開発者との調整を行ったものです（JVNの記載による）。