プラットフォームはオンプレミス版のユーザーに最新バージョンへのアップグレードを警告している。SaaS版とWeb版はパッチ適用済みだ。
GitLabアプリケーション開発プラットフォームのCommunity版およびEnterprise版に存在する重大な二要素認証（2FA）バイパス脆弱性は、直ちにパッチを適用する必要があると専門家は述べている。
この欠陥は、GitLabの新バージョンの一部として水曜日に修正された5件の脆弱性のうちの1つだ。うち3件は深刻度がHigh（高）に分類され、2FAバイパス問題もその1つで、残り2件はMedium（中）に分類されている。
GitLabによると、2FAの欠陥であるCVE-2026-0723は、未パッチのシステムで悪用された場合、被害者のID認証情報を知っている人物が、偽造したデバイス応答を送信することで二要素認証を回避できる可能性があるという。
専門家の注目を集めているのは、この欠陥がもたらす影響の大きさだ。
多要素認証の目的は、ユーザー名とパスワードが盗まれた場合に備え、追加の検証ステップでログインアカウントを保護することにある。脅威アクターがアカウントにアクセスできてしまえば、ITシステムに対してほぼ無制限の損害を与え得る。
GitLabの場合、重要なコードが開発者のアカウントに置かれていると、脅威アクターがそれを侵害し得ると、カナダ拠点のセキュリティ意識向上トレーニング企業Beauceron Securityの責任者であるDavid Shipleyは指摘する。そのコードが他組織にダウンロードまたは販売されるソフトウェアに使われるのであれば、挿入されたマルウェアがサプライチェーン攻撃として拡散する可能性がある。直近の例としてShipleyは、npmレジストリの開発者アカウントがハッキングされたことで拡散しているShai-Huludワームを挙げた。
コードにクラウドのシークレットが含まれていれば、脅威アクターがAzure、Amazon Web Service、Google Cloud Platformといったクラウド基盤にアクセスできる可能性もある、と彼は付け加えた。
2FAバイパスの欠陥の発見は「これらの［セキュリティ］コントロールが重要であることを思い出させるものだ」とShipleyはインタビューで語った。「総当たり攻撃、パスワードスプレーなど、さまざまなリスクを減らすのに確実に役立つ。しかし、決して完全無欠ではない。
「2FAのチャレンジを回避する巧妙な方法が見つかったのは今回が初めてではない。2FAを打ち破ることを目的とした、セッションCookieの取得をめぐる攻撃も一連のものがある。だから、『この魔法の解決策が［認証の］問題を解決する』とか『それはダメなMFAだ。これが新しいMFAだ』といった“銀の弾丸”を誰かが持ち出したときに、これを忘れないことが重要だ。私は［Yubikeyだけを信頼することも］含めて言っている」と彼は述べた。「Yubikeyは素晴らしい。次世代の2FAだ。しかし人間のために作られている以上、いずれ何らかの欠陥は出てくる。」
たとえこれらのコントロールに欠陥がなかったとしても、従業員がソーシャルエンジニアリングによって認証情報を手放すようだまされる可能性がある、と彼は付け加えた。
この特定の2FAバイパスを悪用するためにデバイス認証情報を偽造するよりも、フィッシングのような手法でユーザー認証情報を収集するほうが攻撃者にとっては容易だと、SANS Instituteの研究部門責任者であるJohannes Ullrichは述べた。しかし、攻撃者が有効なパスワードにアクセスできてしまえば、正規ユーザーと同様にGitLabサーバーへログインし、ソースコードに対して—ダウンロード、改変、削除—といった操作を実行できる、と彼は付け加えた。
情報セキュリティ責任者が取るべきこと
だからこそ、アイデンティティおよびアクセス管理においては、サイバーセキュリティの基本—多層防御—が不可欠だとShipleyは述べた。これには、従業員に長く一意のログインパスワードを強制すること、ネットワーク上の不審な活動を監視すること（例えば、MFAチャレンジの記録がないまま誰かが侵入した場合など）、そして万一すべてが破られた場合に備えたインシデント対応計画が含まれる。
MFAバイパスの脆弱性は非常に一般的だとUllrichは指摘する。「根本的な問題は、通常、MFAが既存製品に後から追加されたことだ」と彼は述べ、「その結果、一部の機能がMFAが正常に完了したかどうかを適切に確認しない場合がある」とした。
多要素認証ソリューションをテストする際、情報セキュリティ責任者は、ユーザー名とパスワードの検証後にアプリケーションが認証完了としてマークしていないことを常に確認すべきだ。MFAを有効化したからといってパスワード要件を緩めてはならない、と彼は強調した。ユーザーは引き続き一意で安全なパスワードを選び、パスワードマネージャーで管理しなければならない。安全なパスワードは、MFAの失敗の大半を緩和するとUllrichは述べた。
GitLabで見つかる脆弱性はどれも重大だ、と彼は付け加えた。GitLabは通常、自社コードの機密性を重視する組織が、プラットフォームをオンプレミスで運用したい場合に利用される。
GitLabはアップグレードを「強く」推奨
水曜日に公開されたパッチについて説明する中で、GitLabは、自己管理（self-managed）のGitLabインストールはすべて、GitLab Community Edition（CE）およびEnterprise Edition（EE）向けの3つの新バージョン（18.8.2、18.7.2、18.6.4）のいずれかへアップグレードすることを「強く」推奨すると述べた。GitLab.comまたはGitLab Dedicated（単一テナントのSaaS版）を利用している場合は、何も対応する必要はない。
水曜日の更新で修正されたその他の脆弱性は次のとおり：
- CVE-2025-13927：Jira Connect連携におけるサービス拒否（DoS）の問題。未パッチのシステムで悪用された場合、認証されていないユーザーが、不正な形式の認証データを含む細工されたリクエストを送信することでDoS状態を引き起こす可能性がある。CVSS深刻度スコアは7.5。
- CVE-2025-13928：不適切な認可の問題。未パッチのシステムで悪用された場合、認証されていないユーザーが、APIエンドポイントにおける誤った認可検証を悪用してDoS状態を引き起こす可能性がある。CVSS深刻度スコアは7.5。
- CVE-2025-13335：Wikiリダイレクトにおける無限ループの問題。特定の状況下で、この欠陥により、認証済みユーザーが、循環検出を回避する不正なWikiドキュメントを設定することでDoS状態を作り出せる可能性がある。CVSSスコアは6.5。
- CVE-2026-1102 – APIエンドポイントにおけるサービス拒否（DoS）の問題。認証されていないユーザーが、不正な形式のSSH認証リクエストを繰り返し送信することでDoS状態を引き起こす可能性がある。CVSSスコアは5.3。
GitLabの標準的な運用に従い、セキュリティ脆弱性の詳細は、修正が含まれたリリースから30日後にissue tracker で公開される。
新バージョンにはバグ修正も含まれており、その一部にはデータベース移行が含まれる可能性があるとGitLabは述べた。シングルノードのインスタンスでは、パッチ適用によりアップグレード中にダウンタイムが発生する。マルチノードのインスタンスでは、適切なGitLabのゼロダウンタイムアップグレード手順に従う管理者は、ダウンタイムなしでパッチを適用できる。
