CVE-2021-41773・CVE-2021-42013とは｜Apache 2.4.49・2.4.50のRCEとログに来る攻撃文字列の読み方

アクセスログに /cgi-bin/.%2e/.%2e/.%2e/.../bin/sh が並んでいる、あるいはFortiGateのIPSログに Apache.HTTP.Server.cgi-bin.Path.Traversal が上がった。まず、その通知が攻撃の試行を示すのか、侵害の証拠なのかを切り分けます。正体はApache HTTP Serverのパストラバーサル脆弱性 CVE-2021-41773 と、その修正が不十分だったために公表された CVE-2021-42013 です。Apache公式勧告・NVD・CISA KEVの一次情報と、Apache Software Foundationのコミット差分をもとに、ログ文字列の読み分けと自サーバの影響判定を順に示します。

まとめ：CVE-2021-41773・CVE-2021-42013の要点

まず確認すべきは自分のApacheのバージョンで、そこで大半の判断が終わります。

• 影響を受けるのは 2.4.49 と 2.4.50 だけ。2.4.48以前と2.4.51以降はこの2件の対象外で、2026年11月6日公開の最新版2.4.70も当然対象外。
• Apache公式勧告はどちらも severity を critical と表記。NVDの基本値は両方9.8で、41773にだけCISA-ADPによる7.5の第二評価が併存する。
• 条件は2段構え。ドキュメントルート外がRequire all deniedで守られていなければファイルを読まれ、そこにCGIが有効だと任意コマンド実行(RCE)まで届く。
• ログの文字列で狙われているCVEが分かる。.%2e だけなら41773狙い、%%32%65 を含むなら2.4.50も対象に入れた42013狙い。%252e は二重にエンコードした変種で、稼働版と応答コードで判断する手順は同じ。
• CISA KEVには2021年11月3日に両方が収録済みで、ランサムウェアキャンペーンでの使用は Known と記録されている（2026年11月4日版のカタログで確認）。

スコアはNVDのCVE-2021-41773とCVE-2021-42013、KEVの値はCISAのカタログ（2026年11月4日版）で確認したものです。リリース日はApache公式勧告の Update 2.4.50 released: 2021-10-04 と Update 2.4.51 released: 2021-10-07 の記載によります。

ログとIPSアラートに出た攻撃文字列の読み分けと対象CVEの判別

アクセスログやIPS通知から調査を始める場合は、まず記録された文字列と、そのリクエストを処理した環境を確認します。文字列の形は大きく4種類あり、どれが来ているかで狙われているCVEと、自分が危ないかどうかの前提が変わります。

ディレクトリトラバーサル（パストラバーサル）が狙う公開範囲外のファイル

URLのパスに .. に相当する並びを混ぜ込み、公開を意図していないディレクトリのファイルへ到達させる攻撃です。分類はCWE-22で、NVDもApache Software Foundation自身も両CVEにこの識別子を割り当てています。

Apacheのこのケースで入口は任意のURLではありません。Apache公式のセキュリティ勧告は対象を the directories configured by Alias-like directives、つまりAliasやScriptAliasで別ディレクトリに割り当てたパスの配下と書いています。既定のScriptAliasである /cgi-bin/ を入口にした攻撃例が多いのはこのためで、自社で別名のAliasやScriptAliasを設定している場合はそちらも確認対象に含めてください。攻撃類型そのものの仕組みと実装側の防ぎ方はディレクトリトラバーサルとは？攻撃の仕組みと正規化後検証による実装対策を解説で扱っています。

.%2e型の攻撃文字列の特徴とCVE-2021-41773の対象版

CVE-2021-41773を狙うリクエストの例です。

GET /cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/etc/passwd HTTP/1.1

これが2.4.49で通る原因は、2.4.49で新規に入ったパス正規化の実装にあります。この版の ap_normalize_path() はパーセントエンコードされたunreserved文字を先にデコードする一方、.. を畳む判定は素のドット2文字しか見ていませんでした。.%2e は「1文字目だけがドットで、2文字目はまだデコード前」という状態になり、上の階層へ戻す処理の対象から外れて素通りします。

ドットの並びが10回続くのは、cgi-binの位置から確実にルートまで戻るための余裕です。7回でも12回でも同じ攻撃だと読んで構いません。

%%32%65型の特徴とCVE-2021-42013の対象版

次の形が来ていたら、送り手は2.4.50も標的に含めています。

GET /cgi-bin/.%%32%65/.%%32%65/.%%32%65/.%%32%65/bin/sh HTTP/1.1

%32 は文字 2、%65 は文字 e に相当し、%%32%65 はデコードすると %2e に、さらに解釈されるとドットになります。2.4.50の対策は %2e という並びを見つけて上位階層への移動として畳む処理だったため、正規化を通る時点ではまだ %2e の形になっていないこの書き方が対象から外れます。2.4.50もCVE-2021-42013の影響対象です。ログにこの文字列がなくても安全とは判断せず、修正版への更新を進めてください。

%252e型（二重エンコード）の読み方と扱い

CVE番号と一緒に %252e という表記を見かけることがあります。%25 は記号 % そのものを表すエンコードなので、%252e を1回デコードすると %2e、もう1回デコードするとドットになります。二重エンコードは、前段のWAFやIPSと後段のサーバでデコードの回数や順序が違うことを当て込んだ書き方です。ただし2.4.50の正規化処理がデコードするのはunreserved文字だけで、% を表す %25 はその対象ではありません。%252e が %%32%65 と同じ結果になるとは限らず、文字列の見た目だけで成否を判断しないことが要点です。

スキャナは .%2e 型や %%32%65 型と並べて、この二重エンコード版も機械的に投げてきます。標準的なアクセスログ形式でリクエスト行を記録する%rを使用している場合、%252e はデコードされない形で記録されます。調べる順番はほかの形と同じで、稼働版が2.4.49・2.4.50か、その行にどの応答コードが返ったかで判断します。気をつけたいのは抽出のほうで、%2e だけで検索すると %252e は % と 2e の間に 25 が挟まるため一致しません。下の抽出例ではこの形も拾うようにしています。

素の../型とエンコード型の正規化処理の違いとログからの判断

次の形もよくログに残りますが、性質が違います。

GET /cgi-bin/../../../../../../../../../../bin/sh HTTP/1.1

エンコードを使わない素のドット2文字の形は、2.4.49の正規化処理でもそれ以前の版でも、上の階層へ戻す処理として正しく畳まれます。この形だけが来ている場合、CVE-2021-41773やCVE-2021-42013の標的にされたとは言えません。パス種を総当たりするスキャナが網羅的に投げているものと読むのが妥当です。Aliasの設定ミスや別ミドルウェアの脆弱性まで否定できるわけではないので、404以外が返っていれば設定側を点検してください。

FortiGateのIPSシグネチャ通知と攻撃の成否を判断する確認項目

FortiGateで表示される Apache.HTTP.Server.cgi-bin.Path.Traversal は、FortiGuardのIPSシグネチャ名で、名前のとおりApache HTTP Serverの /cgi-bin/ を入口としたパストラバーサルの検知を指します。ここで扱っている2件のCVEがまさにその形です。

取り違えやすいのは、シグネチャ名はリクエストを検知したという記録であって、攻撃が成功したという記録ではない点です。遮断アクションは有力な判断材料ですが、それだけで完結させず、リクエスト当時のApacheのバージョン・設定、アクセスログ、error_logを照合してください。自前でシグネチャを書いて検知側を組む場合の考え方はSuricata（スリカタ）とは？導入からルール作成・IPSモード運用まで【8.0対応】にまとめています。

アクセスログによる攻撃兆候の抽出と応答コードに基づく追加調査の判断

以下は掲載した4形式と大文字の%2Eを抽出する簡易例で、1行目がRHEL系、2行目がDebian・Ubuntu系の既定パスです。別のエンコード表現やローテーション済みログは網羅しないため、該当行がなくても攻撃がなかったとは判断できません。

grep -Ei '%2e|%252e|%%32%65|[.][.]/' /var/log/httpd/access_log
grep -Ei '%2e|%252e|%%32%65|[.][.]/' /var/log/apache2/access.log

403や404は拒否・未検出を示しますが、それだけで侵害を否定できません。500などの応答も調査対象に含めます。200が返っていればファイルを読まれた可能性があり、さらにメソッドがPOSTで宛先が /bin/sh のようなシェルのパスなら、コマンド実行を試みられたと考えて侵害調査に移ります。同時刻帯のerror_log、サーバ上の新規ファイル、cron、外向き通信もあわせて確認してください。何をどの順で見るかは不正アクセスの調べ方｜ログの確認方法と痕跡を見つけるコマンド例に、IPAの無償ツールで兆候を機械的に拾う方法はiLogScannerとは？IPA無料ツールのダウンロードと使い方、JDK 26で動かない原因にあります。

自サーバが影響を受けるかの判定：稼働版・アクセス権限・CGIの3条件

Apache公式勧告は、ドキュメントルート外のファイルが通常の既定設定である Require all denied で保護されていない場合にリクエストが成功し、さらにそれらのパスでCGIスクリプトが有効な場合にリモートコード実行が起こりうる、と成立条件を書いています。バージョンを含めて3条件として順に見ます。

条件1：稼働バージョンの2.4.49・2.4.50への該当確認

1行目がRHEL系やソースビルド、2行目がDebian・Ubuntu系の確認例です。表示されるのは実行したバイナリの版なので、公開サービスを稼働させているバイナリやコンテナと一致することも確認してください。

httpd -v
apache2 -v

2.4.49ならCVE-2021-41773とCVE-2021-42013の両方、2.4.50ならCVE-2021-42013のみが対象です。Apache公式のセキュリティ情報に記載されたリリース日は2.4.49が2021年9月16日、2.4.50が10月4日、2.4.51が10月7日で、対象版が現行リリースだったのは3週間でした。ただし対象版を使い続けている環境や、古い構築手順から対象版を再導入した環境では、今も影響が残ります。

条件2：Aliasの割り当て先の外にあるファイルの保護不足の確認

Apacheの既定設定には、ファイルシステム全体をまず拒否してから必要な範囲だけ許可する次のブロックが入っています。

<Directory />
    AllowOverride none
    Require all denied
</Directory>

この拒否が到達先ファイルに有効なら、アクセスは拒否されます。別のDirectoryやLocationの認可設定で上書きされていないことも確認が必要です。このブロックを削った構成や、Aliasの割り当て先の外まで許可している構成では、読み出しが成立し得ます。条件1に該当する版を使っていて、かつここを緩めている場合が実害の出る組み合わせです。

条件3：CGIが有効でRCEに届くかのモジュールと実行設定の確認

ファイル読み出しにとどまるか任意コマンド実行まで至るかを分けるのがこの条件です。RHEL系とDebian・Ubuntu系でコマンドと設定ディレクトリが異なります。

# RHEL系の標準パッケージ
httpd -M | grep -i cgi
grep -R 'ScriptAlias' /etc/httpd/conf /etc/httpd/conf.d
# Debian・Ubuntu系（apache2 -M は環境変数未設定で失敗するため apache2ctl を使う）
apache2ctl -M | grep -i cgi
grep -R 'ScriptAlias' /etc/apache2

ソースからビルドした環境では、設定ファイルの場所がビルド時のServerRootや起動時の -f 指定で決まります。既定のインストール先なら /usr/local/apache2/conf/httpd.conf で、httpd -V が表示する HTTPD_ROOT と SERVER_CONFIG_FILE で実際の場所を確認してから検索してください。

Debian系で apache2 -M を直接実行すると、${APACHE_RUN_DIR} is not defined などの警告や構文エラーで停止する場合があります。Debian系の標準設定では環境変数の設定が必要です。出力が空でも「CGI無効」と読み違えないよう、apache2ctl -M を使ってください。

cgi_module または cgid_module が読み込まれ、該当するAlias系パスでCGI実行が有効なら、条件1・2と合わせてRCEが成立し得ます。SetHandlerやAddHandler、Optionsの設定も確認してください。CGIを使っていなければ、同じ攻撃でも被害はファイルの読み出しまでです。

2.4.49と2.4.50の行は、条件2のRequire all deniedが外れていることが前提です。「影響なし」はこの2件に限った判定で、2.4.48以前には別のKEV掲載脆弱性（後述のCVE-2021-40438など）があります。

2つのCVEの違いと、2.4.50の不完全な修正から2.4.51への変更点

2.4.50のリリースから3日後に、不十分な修正へ対応した2.4.51がリリースされました。最初の修正が足りなかった理由は、2つのコミット差分を並べると具体的に説明できます。

CVSS 9.8と7.5の評価主体・影響指標の違いと優先度の判断

NVDのCVE-2021-41773には評価が2つ並んでいます。NVD自身によるPrimaryが9.8 CRITICAL、ベクタは CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H。もう一方はCISA-ADPによるSecondaryで7.5 HIGH、こちらは C:H/I:N/A:N と機密性への影響だけを計上しています。

差は完全性と可用性への影響を計上するかどうかです。9.8はCGIが有効でRCEに至る構成、7.5はファイル読み出しにとどまる構成の評価とみると整合しますが、これはベクタからの解釈で、評価主体が採点理由をそう説明しているわけではありません。CVE-2021-42013はPrimaryもSecondaryも9.8で一致しています。

優先度の判断基準は、スコアの数字ではなく前節で示した3条件です。7.5だけを見てCGI有効の環境を後回しにするのは危険ですし、静的配信だけのサーバでも、到達先に認証情報や鍵が置かれていれば読み出しだけで重大な被害になります。スコアの読み方そのものはCVSSv3とは？v3.1のスコアの目安・計算式と計算機の使い方を解説で整理しています。

2.4.50の修正：2つ目のドットのエンコード表記への対応と限界

CVE-2021-41773の修正はリビジョンr1893775として2.4.xブランチに入りました。中身は、.. を畳む判定に %2e と %2E のリテラル一致を足すというものです。現行の2.4.xソースの server/util.c にも残るコメントが設計意図を語っています。

/* Remove /xx/../ segments (or /xx/.%2e/ when
 * AP_NORMALIZE_DECODE_UNRESERVED is set since we
 * decoded only the first dot above).
 */

1つ目のドットだけを先にデコードしてしまう挙動を前提に、そのまま残る2つ目のドットの表記 %2e を文字列として追加照合する直し方です。観測された攻撃の形には効きますが、防いでいるのは「その書き方」だけでした。

2.4.51の修正：再デコードの抑制と不正エンコードの入口での拒否

%%32%65 の表記で回避されたあと、2.4.51ではリビジョンr1893977ほかで方針が切り替わります。新設された AP_UNESCAPE_URL_KEEP_UNRESERVED フラグにより、unreserved文字をデコードせずエンコードされた形のまま保持できるようになりました。server/request.c のコメントが、パターン照合ではなくデコードの回数を管理する設計に変わったことを示しています。

/* Unreserved chars were already decoded by ap_normalize_path() */
unsigned int unescape_flags = AP_UNESCAPE_URL_KEEP_UNRESERVED;

同じ差分で ap_normalize_path() にも変更が入り、% の直後が16進2桁でない場合を Invalid encoding として失敗させるようになりました。%%32%65 は % の次がまた % なので、ドットに解釈される前の入口で落ちます。

教訓は、正規化後に追加のデコードが行われると、正規化時の検査をすり抜ける表記が生じ得るということです。2.4.50では正規化後の再デコードによる回避が残り、2.4.51で追加修正されました。両版のリリース間隔は3日です。自社実装で同種の対策を書くときも、危険な表記を列挙して弾くのではなく、デコードを終えて正規化した結果に対して境界を検証してください。入力検証の原則はセキュアコーディングとは？10原則とIPA・JPCERTのガイドライン、脆弱性別のコード対策にまとめています。

対策：2.4.70への更新と、サーバをすぐ止められない場合の緩和

恒久対策：上流の修正版またはディストリビューションの修正済みパッケージへの更新

両方のCVEに一度で対応するには2.4.51以降へ上げます。2.4.50への更新は41773の対策にしかならず、42013の対象のままです。実運用では過去版で止めず現行版に合わせるのが妥当で、Apache公式のダウンロードページによれば2026年11月7日時点の最新版は2026年11月6日公開の2.4.70です。2.4.70の変更一覧（CHANGES_2.4.70）はmod_dav_lockのヒープバッファオーバーフローやmod_authnz_ldapのクラッシュなどの修正で、この2件のCVEとは関係しません。2.4.5x以降にも別系統の脆弱性が続いており、2026年に公表されたCVE群の影響範囲はJVNが公表したApache HTTP Server 2.4系の複数脆弱性：2.4.68・2.4.69の33件の影響範囲とディストリ別の修正状況、版ごとの更新手順はApache HTTP Server 2.4の脆弱性まとめ｜CVE-2026-33523ほか2.4.67〜2.4.69の該当判定と更新手順【2026年10月】で追えます。

ディストリビューション版のバックポートと導入済みパッケージの修正状況の確認

RHEL系やUbuntuのApacheパッケージは、古い版番号のまま修正だけを取り込むバックポート方式を取ります。httpd -v が2.4.62や2.4.58と表示されても、それだけでは脆弱とも安全とも判断できません。影響の有無はディストリビューションの公式CVE情報とパッケージ版を照合し、導入済みパッケージの変更履歴は補助確認に使います。

# RHEL系（導入済みパッケージの変更履歴）
rpm -q --changelog httpd | grep -E 'CVE-2021-(41773|42013)'
# Debian・Ubuntu系（apt changelog は候補版を取りに行くため、導入済みのファイルを見る）
zgrep -nE 'CVE-2021-(41773|42013)' /usr/share/doc/apache2/changelog.Debian.gz

変更履歴の検索結果だけでは影響の有無を確定できません。上流の更新履歴としてCVE番号が含まれていても、そのディストリビューションが脆弱な版を出荷した証拠にはなりません。該当するCVE番号が見つからない場合も、脆弱な版を一度も出荷していない可能性があるため、ディストリビューションの公式CVE情報と導入済みパッケージ版を照合してください。

今回の2件は2.4.49と2.4.50という狭い版域の問題なので、長期サポート系ディストリの標準パッケージは最初から対象外であることがほとんどです。影響を受けやすいのは、その時期にソースからビルドした、あるいはコンテナイメージのタグで版を固定した環境です。

サーバをすぐ更新できない場合のアクセス制限・CGI無効化による緩和策

メンテナンス枠が取れない場合の時間稼ぎとして、次の3つが効きます。

• 既定の <Directory /> に Require all denied を戻し、ドキュメントルート外への到達を拒否する。
• CGIを使っていなければ cgi_module と cgid_module の読み込みとScriptAliasを外し、RCEの条件を消す。
• 前段のWAFやIPSで両CVEに対応したベンダー提供ルールを適用する。大文字・小文字や別のエンコード表現による回避があるため、この2文字列の一致だけを防御条件にしない。

これらは恒久対策ではありません。CISA KEVが両CVEに記載した requiredAction は Apply updates per vendor instructions. で、米国連邦機関向けの是正期限は2021年11月17日でした。単発のCVE対応ではなくWebサーバ全体の守りを組み直す段階なら、Webサーバーのセキュリティ対策｜運用で塞ぐ10項目とパッチの優先順位で優先順位のつけ方を確認してください。

公開から5年以上が経過したCVEへの攻撃試行と運用上の判断

2021年10月の公開から5年以上が経ちますが、このパターンのリクエストがログから消えない要因は2つ考えられます。

1つ目として考えられるのは、公開された検証コードや攻撃モジュールによって、攻撃試行を自動化しやすいことです。Apache公式勧告はCVE-2021-41773について This issue is known to be exploited in the wild. と明記し、JPCERT/CCの注意喚起（JPCERT-AT-2021-0043）は検証コードが複数公開されている状況を、IPAの注意喚起は2021年10月7日の更新で国内での攻撃観測の情報を伝えました。CISA KEVにはApache HTTP Serverとして、この2件のほかCVE-2019-0211（2021年11月3日）、CVE-2021-40438（2021年12月1日）、CVE-2024-38475（2025年5月1日）も載っています。一度キャンペーンに組み込まれたペイロードは、スキャナのテンプレートに残り続けます。

2つ目は、危険な版が今も入手できることです。2.4.49と2.4.50の配布アーカイブはArchive of Apache HTTP Serverに2021年当時の日付のまま置かれています。当時の構築手順書やDockerfileが版番号を固定したまま残っていれば、2026年に実行しても2021年の脆弱な版がそのまま再現されます。

運用上の判断ははっきりしています。この2件について、ログに文字列が来るたびに侵害調査を起こすのは無駄です。一度バージョンを確認して2.4.51以降だと分かり、稼働バイナリと構成が変わらず別の異常もなければ、この2件だけを理由に毎回調べる必要はありません。逆に、条件1に該当する版を使っている環境は、WAFルールを足して様子を見るのではなく即座に更新してください。Metasploit FrameworkにRCEまで実行するモジュールが収録されている脆弱性で、観測期間を設ける判断は割に合いません。

見落としやすい失敗パターンは、2021年にソースからビルドして以来バージョンを固定している構成と、コンテナイメージのタグを当時のまま pin している構成です。前者はパッケージ管理情報だけを調べる棚卸しでは漏れる可能性があり、後者は脆弱な版を取得する指定が残っていると再ビルド時に再導入されます。外部からの診断で棚卸しの漏れを洗い出したい場合は、一創の脆弱性診断・セキュリティ診断で公開サーバのバージョン露出と設定を確認できます。

よくある質問

CVE-2021-41773・CVE-2021-42013について、検索で多い質問に答えます。

Apache 2.4.41や2.4.52はこの脆弱性の対象ですか？

CVE-2021-41773とCVE-2021-42013については対象外です。2.4.41はUbuntu 20.04、2.4.52はUbuntu 22.04、2.4.58はUbuntu 24.04の標準パッケージの版で、2.4.41は対象版より前、2.4.52と2.4.58は修正版の2.4.51より後にあたります。ただし2.4.52以降にも別系統の脆弱性が公開され続けており、2026年だけでも2.4.67・2.4.68・2.4.69の3回で計44件が修正されました（Apache公式のセキュリティ情報で集計。11月6日公開の2.4.70の分は11月7日時点で未掲載）。「この2件は対象外」と「脆弱性がない」は別の話で、現行版までの対応はApache HTTP Server 2.4の脆弱性まとめ｜CVE-2026-33523ほか2.4.67〜2.4.69の該当判定と更新手順【2026年10月】を参照してください。

CVE-2021-41773のPoCやMetasploitモジュールは公開されていますか？

公開されています。GitHubには検証コードのリポジトリが複数あり、Metasploit Frameworkにも脆弱性の有無を調べる auxiliary/scanner/http/apache_normalize_path と、RCEまで実行する exploit/multi/http/apache_normalize_path_rce の2つのモジュールが収録されています。攻撃は自動化されている前提で緊急度を決めてください。本記事は防御側の判断材料を目的としているため、エクスプロイトの手順は掲載していません。

ログに攻撃文字列があれば侵害されたことになりますか？

なりません。判定材料は、当時のバージョンが2.4.49または2.4.50であるかと、該当リクエストに200が返っているかです。ただし200以外でも攻撃失敗とは断定できません。CGIは実行後に出力形式の不備で500を返す場合もあるため、リクエスト当時のバージョン・設定と、error_logやプロセス・通信の記録を照合してください。

CVE-2021-41773のCVSSは7.5ですか、9.8ですか？

どちらも正しく、評価主体が異なります。NVD自身によるPrimaryが9.8 CRITICAL、CISA-ADPによるSecondaryが7.5 HIGHで、両方がNVDのレコードに併記されています。ベクタ上の差は完全性と可用性への影響を計上するかどうかで、RCEまで見るか読み出しまでで止めるかの違いと解釈できます（公表された採点理由ではありません）。社内の脆弱性管理では採用する評価主体を明記し、CGIやアクセス制御の設定は自環境の影響と対応優先度を判断する材料として別に扱ってください。

CVE-2021-41773とCVE-2021-42013は両方に対応が必要ですか？

2.4.51以降へ更新すれば一度で両方に対応できます。注意が必要なのは2.4.50で止めた場合で、41773の対策にはなりますが42013の影響を受ける版のままです。当時の緊急対応で2.4.50を適用したまま更新を止めた環境が残っていないか、この機会に確認し、ソース導入なら最新の上流版へ、ディストリビューションのパッケージなら提供元がサポートする修正済みパッケージへ更新してください。

関連記事

• Apache HTTP Server 2.4の脆弱性まとめ｜CVE-2026-33523ほか2.4.67〜2.4.69の該当判定と更新手順【2026年10月】
• JVNが公表したApache HTTP Server 2.4系の複数脆弱性：2.4.68・2.4.69の33件の影響範囲とディストリ別の修正状況
• ディレクトリトラバーサルとは？攻撃の仕組みと正規化後検証による実装対策を解説
• 不正アクセスの調べ方｜ログの確認方法と痕跡を見つけるコマンド例
• iLogScannerとは？IPA無料ツールのダウンロードと使い方、JDK 26で動かない原因