Skip to content
KitploitKITPLOIT
ツールエクスプロイトブログ
Log in
提出
ツールエクスプロイトブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

フィードお問い合わせプライバシー© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
CVE-2026-103977 — セッション単位のTOTPレート制限により、繰り返しの検証試行が可能になる | Kitploit
ツール/GitHubGitHub/pervinzahidli/cve-2026-103977
認証と認可防御ツール脆弱性分析認証論文と研究
GitHubpervinzahidli/cve-2026-103977

CVE-2026-103977

セッション単位のTOTPレート制限により、繰り返しの検証試行が可能になる

リポジトリを見る
2日前未レビュー

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有

概要

FileRise 3.23.0 より前のバージョンでは、失敗した TOTP 検証試行が PHP セッション状態に保存されていました。カウンターは 1 つのセッション内での試行回数を制限していましたが、新しく作成されたセッション間では保持されませんでした。

対象アカウントの有効なプライマリ資格情報をすでに所持している攻撃者は、ログインワークフローを再開し、新しい保留中ログインセッションを受け取り、TOTP 試行許容量を復元することができました。このプロセスを繰り返すことで、意図された 5 回の試行制限を超えてオンラインでの TOTP 推測を継続することが可能でした。

詳細

TOTP 検証フローは、失敗カウンターを $_SESSION で管理していました。5 回の失敗送信後、そのセッションでの以降の試行は HTTP 429 を返しました。

しかし、新しいセッションでプライマリ認証を正常に完了すると、新しい TOTP 失敗カウンターを持つ新しい保留中ログイン状態が作成されました。したがって、以前のアカウントの TOTP 失敗は引き継がれませんでした。

この問題は、同じ永続的な制限を適用していなかった別の保留中ログイン TOTP ハンドラーにも影響していました。そのため、修正はすべての保留中ログイン TOTP 検証パスに一元的に適用されました。

この問題は CWE-307: 過剰な認証試行の不適切な制限に分類されます。

影響

悪用には、資格情報の再利用、フィッシング、またはその他の侵害によって取得されたパスワードなど、対象アカウントの有効なプライマリ資格情報を所持している必要があります。

この脆弱性は資格情報を開示したり、TOTP を直ちにバイパスしたりするものではありません。アカウント全体で永続的な制限なしに、自動化された TOTP 推測を継続することを可能にします。推測が成功すると、影響を受けるアカウントの権限(管理者権限を含む可能性があります)で認証が完了します。

TOTP が有効になっていないアカウントは、この特定の第二要素レート制限の問題による影響を受けません。

修正

FileRise 3.23.0 では、集中化された永続的な TOTP 試行制限が導入されています:

  • 各アカウントは、15 分間のウィンドウごとに 5 回の TOTP 検証試行に制限されます。
  • アカウント制限は PHP セッションおよびクライアントアドレスの変更をまたいで保持されます。
  • より高いソース全体の制限により、アカウント間に分散された試行が制限されます。
  • 試行は、ロックされた永続状態を使用して検証前に予約されます。
  • すべての保留中ログイン TOTP 検証パスが同じリミッターを使用します。
  • TOTP 検証が成功すると、アカウントの試行予算がクリアされます。
  • パスワードまたは ID プロバイダー認証は TOTP 失敗をリセットしません。

既存のアカウント、TOTP シークレット、セッション、Docker インストール、およびデプロイメント設定に移行は不要です。

ユーザーは FileRise 3.23.0 以降にアップグレードする必要があります。

メンテナーの回答

責任ある開示と詳細な再現手順をありがとうございます。

私たちは TOTP 検証ワークフローをレビューし、根本的な問題を確認しました。失敗した TOTP 送信は、プライマリフロントエンド検証エンドポイントの PHP セッションカウンターによってのみ制限されていました。したがって、新しいセッションでプライマリ認証の成功ステップを繰り返すことで、第二要素の試行予算を復元することができました。私たちのレビューでは、同じ試行カウンターを適用していなかった別の保留中ログイン TOTP ハンドラーも特定したため、修正は報告されたエンドポイントだけでなく、検証パス全体に一元的に適用されました。

修正は FileRise v3.23.0 に実装されています:

  • 構文的に有効な TOTP 送信は、検証前に永続的なアカウント全体の予算から試行を予約するようになりました。
  • アカウント予算は PHP セッションおよびクライアントアドレスから独立しているため、セッションを置き換えたり送信元アドレスをローテーションしたりしても試行は復元されません。
  • より高い永続的なソース全体の予算により、アカウント間に分散された試行が制限されます。
  • 両方の保留中ログイン TOTP ハンドラーが同じリミッターを使用し、フォーム、Basic Auth、および OIDC で確立された保留中ログインセッションをカバーします。
  • パスワードまたは ID プロバイダーの成功は、第二要素の失敗予算をリセットしなくなりました。
  • TOTP 検証が成功すると、アカウント予算がクリアされ、ソース予算から成功した予約が削除されるため、共有ネットワーク上の通常の成功ユーザーが失敗を蓄積することはありません。
  • 試行状態は、ハッシュ化されたアカウント/ソース識別子、ロックされた更新、アトミックなファイル置換、自動有効期限、およびリミッターストアが利用できないか破損している場合のフェイルクローズ処理を使用します。
  • リカバリーコードの使用が成功すると、アカウントの TOTP 試行状態がクリアされます。

アカウント制限は 15 分間のウィンドウで 5 回の試行です。ソース全体の制限は、共有ネットワークでの誤検知を減らすために、同じウィンドウで意図的に 50 回と高く設定されています。既存のアカウント、TOTP シークレット、セッション、Docker インストール、およびデプロイメント設定に移行は不要です。


Credit: Pervin Zahidli (@ech0void ) Ref : https://github.com/error311/FileRise/security/advisories/GHSA-4hfj-6478-5cv7

ツールをダウンロード