Nginx-UIに認証不要でバックアップを取得できる重大な脆弱性(CVE-2026-27944)|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年03月10日更新日時: 2026年03月10日

Nginx-UIに、認証なしでシステムバックアップを取得でき、しかも復号に必要な暗号化鍵まで同時に漏えいする重大な脆弱性が公開されました。対象は 0xJacky/nginx-ui の 2.3.3 未満で、修正版は 2.3.3 です。GitHub Advisory DatabaseではCVE-2026-27944として管理され、深刻度はCritical、CVSS 3.1は9.8と評価されています。

今回の問題は、管理系機能の中でも特に重要なバックアップ取得APIが認証なしで公開されていた点にあります。さらに、取得したバックアップは暗号化されているものの、その暗号化に使うAES-256の鍵とIVがHTTPレスポンスヘッダーにそのまま含まれていたため、第三者がバックアップをダウンロードした直後に復号できる状態でした。

1 概要
2 影響
3 原因
4 情シス部門が取るべき対応

概要

脆弱性の中核は /api/backup エンドポイントです。このAPIが認証を要求しない実装になっていたため、外部から到達可能な環境であれば、未認証の攻撃者がフルバックアップを取得できる状態でした。本来、管理画面のバックアップは最も厳格に保護すべき機能ですが、今回の実装では復元用の処理にはミドルウェアが適用されている一方で、バックアップ取得側には保護が入っていませんでした。

しかも問題はそれだけではありません。バックアップ取得時のレスポンスヘッダー X-Backup-Security に、暗号化済みバックアップを復号するための鍵とIVが平文同然で返されていました。つまり、暗号化の仕組み自体は存在していても、鍵管理が完全に破綻していたことになります。結果として、実質的には平文バックアップを誰でも取得できるのと同じ状態でした。

影響

影響は極めて重く、単なる設定情報の漏えいでは済みません。公開された内容によると、バックアップには database.db、app.ini、server.key や証明書、nginx.conf、sites-enabled 配下の仮想ホスト設定、ssl 配下の秘密鍵などが含まれます。これらにはユーザー認証情報、セッショントークン、アプリケーション設定、各種シークレット、SSL秘密鍵、Nginx構成情報が入る可能性があります。

このため、攻撃者は管理基盤の構成を把握するだけでなく、認証情報やトークンを悪用して追加侵入を試みたり、証明書や秘密鍵を利用してなりすましや中間者攻撃の足場を得たりするおそれがあります。環境によっては、Nginx-UI単体の問題ではなく、背後のWeb基盤全体の信頼性を崩す起点になり得ます。

原因

原因は大きく二つあります。第一に、重要機能に対する認証制御の欠落です。バックアップ取得は最重要管理操作の一つですが、そのAPIが未認証で呼び出せるようになっていました。これは典型的な認証不備であり、CWE-306に該当します。

第二に、暗号化鍵の扱いが不適切だったことです。バックアップ自体はAES-256-CBCで暗号化されていても、その鍵とIVを同じレスポンスで配ってしまえば保護の意味はありません。暗号化そのものではなく、鍵管理の失敗で機密性が失われた典型例であり、CWE-311として整理されています。

実装面では、バックアップを取る処理と、秘密情報をどう返すかの設計が分離できていなかったことが根本にあります。暗号化を入れたことで安全になったように見えても、運用と実装の境界で鍵が漏れれば、結果は無防備と変わりません。

情シス部門が取るべき対応

最優先は、Nginx-UIを2.3.3へ更新することです。インターネットから到達可能な管理ポートで運用している場合は、更新完了まで外部公開を止める、アクセス元を制限する、VPNや踏み台経由に限定するなどの暫定措置も必要です。

ただし、今回の脆弱性は更新だけで終わりません。すでにバックアップを取得された可能性を前提に動くべきです。具体的には、Nginx-UIの認証情報、セッショントークン、アプリ設定内のシークレット、TLS証明書と秘密鍵、リバースプロキシ配下の関連資格情報を洗い出し、必要に応じてローテーションや再発行を進める必要があります。特に秘密鍵がバックアップに含まれる構成では、証明書の差し替えまで含めて検討するのが妥当です。