CVE-2026-57221Disclosure(broadcom / rabbitmq_server)

CVE-2026-57219 allows an unauthenticated attacker who can reach the management port (commonly 15672) to retrieve the broker’s confidential OAuth client secret through the obsolete GET /api/auth endpoint. The root cause sits in two functions: is_authorized/2 is hard-coded to always return true for this path, and produce_auth_settings/2 copies the oauth_client_secret value directly into the JSON response. Once the attacker possesses the secret, they can exchange it at the configured identity provider for an administrative token and assume full control over messages, queues, users, virtual hosts, and broker configuration. The attack sequence is straightforward once the management port is reachable. The attacker issues the unauthenticated GET, receives the secret in the JSON body, and immediately presents that secret to the identity provider in a standard OAuth client-credentials flow. The resulting token carries the broker’s own administrative scope. From that point the attacker can create or delete queues, publish or consume messages at will, enumerate and modify users and permissions, and alter virtual-host configuration without ever authenticating as a legitimate application or user. The vulnerability affects RabbitMQ versions 3.13.0 and later when the management plugin is enabled and OAuth is configured with a confidential client secret. It does not affect deployments that use no OAuth secret at all or that run without the management plugin. Public clients and PKCE flows that never store a client secret are unaffected because there is nothing to leak. CVE-2026-57221 lets any authenticated user, even one with zero explicit permissions, enumerate queues and exchanges and read operational statistics. The flaw is missing authorization checks on passive-declare operations inside the management API. The issue does not expose message contents or permit modification, yet it leaks metadata that is valuable in multi-tenant or shared virtual-host environments where operational visibility itself is a boundary concern. An attacker with a low-privilege account can map the topology of every vhost, identify high-value queues by name or message rate, and gather the intelligence needed for targeted follow-on activity without triggering permission errors. Both issues were introduced when OAuth support expanded in early 2024 and were fixed in the coordinated releases 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15. The patch removes the obsolete /api/auth endpoint entirely; OAuth settings now flow only through the authenticated bootstrap.js path. Common identity providers named in the disclosure include Auth0, Microsoft Entra ID, Keycloak, and UAA. Miggo notes that RabbitMQ sees roughly fifteen million downloads per year and runs in approximately eight percent of containers according to industry census data. At the time of disclosure there was no evidence of in-the-wild exploitation of these specific flaws.

🐇 RabbitMQ OAuth Secret Exposure Vulnerabilities A RabbitMQ vulnerability, CVE-2026-57219 (CVSS 8.7), could allow an unauthenticated attacker to retrieve an OAuth client secret with a single GET /api/auth request and potentially obtain administrator privileges. The accompanying vulnerability, CVE-2026-57221, may allow a low-privilege account to enumerate queue and exchange structures belonging to other tenants. 🔎 Criminal IP findings: • About 4,100 Internet-exposed RabbitMQ management interfaces • About 1,800 assets exposed on default port 15672 • Additional assets identified with expired SSL certificates • Patched versions: 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0 or later Not every exposed RabbitMQ instance is vulnerable. However, publicly accessible management interfaces may increase reconnaissance and exploitation risk. 👉 Read the full analysis: https://criminalip.io/knowledge-hub/blog/36570 #RabbitMQ #Cybersecurity #ThreatIntelligence #OAuth #CVE

【サイバーセキュリティ動向分析】 2026年7月13日時点の主なサイバーセキュリティニュースまとめ 以下に、今日の主なトピックについて、背景・影響・対策を詳しく長文でまとめます。各トピックは独立して読めるように構成しています。 1. RabbitMQの管理インターフェース脆弱性（CVE-2026-5721） 背景 RabbitMQは、企業システムで広く使われるオープンソースのメッセージブローカーで、アプリケーション間の非同期通信を効率的に実現します。脆弱性は2024年初頭にリリースされたバージョン3.13.0で導入され、2年以上にわたってコードベースに残っていました。この問題は、OAuth 2.0 / OIDC認証を有効にした構成（Auth0、Azure AD/Entra ID、Keycloakなどを使用する場合）で発生します。具体的には、管理Webインターフェースの古いエンドポイントが、認証なしでブローカーの機密OAuthクライアントシークレットを返してしまうというものです。関連する別の脆弱性（CVE-2026-57221）も存在し、認証済みユーザーによるキューやエクスチェンジの列挙を可能にします。 影響 CVSSスコア8.7（高深刻度）と評価されるこの脆弱性により、攻撃者が管理ポートに到達できれば、OAuthクライアントシークレットを盗み、アイデンティティプロバイダーを騙して管理者トークンを取得できます。これにより、ブローカーの完全な制御が可能になり、メッセージの改ざん・盗聴、キュー操作、仮想ホストの管理、さらなる攻撃の足がかりとなります。特にマルチテナント環境やクラウド展開で管理インターフェースがインターネットや信頼できないネットワークに露出している場合、リスクが非常に高く、機密データの漏洩やシステム全体の可用性低下につながる可能性があります。現在、野放しでの悪用事例は確認されていませんが、脆弱な構成の組織は潜在的な標的となります。 対策 RabbitMQを最新バージョン（4.3.0、4.2.6、4.1.11、4.0.20、または3.13.15など）に直ちにアップデートしてください。これらのバージョンで問題が修正されています。アップデートがすぐにできない場合は、管理インターフェースへのアクセスをインターネットや信頼できないネットワークから完全に遮断し、ネットワークセグメンテーションを徹底してください。また、OAuthクライアントシークレットをローテーションし、不要な管理プラグインを無効化することを推奨します。クラウドや共有環境では特に厳格なアクセス制御が重要です。 2. ZimbraのClassic Web Clientにおけるクリティカルな保存型XSS脆弱性 背景 Zimbraは、メールサーバー、ウェブクライアント、カレンダー、ファイル共有などを統合したコラボレーションツールで、多くの企業や組織で利用されています。この脆弱性は、Classic Web Client（従来のユーザーインターフェース）で発見された保存型クロスサイトスクリプティング（XSS）の欠陥で、Google Threat Analysis Group（GTIG）によって報告されました。GTIGは国家支援型グループや商用スパイウェアベンダーが標的とする脆弱性を追跡することで知られています。影響を受けるのはバージョン10.1.19より前のZimbra（10.0.x、9.0.x、8.8.15を含む）で、特にClassic Web Clientを使用している環境です。脆弱性はまだCVE識別子が割り当てられていない段階ですが、深刻度がクリティカルとされています。 影響 特別に細工されたメールを開封するだけで、悪意のあるコードが実行される可能性があります（ゼロクリック攻撃の要素を含む）。これにより、攻撃者はメールボックスの情報、セッションデータ、アカウント設定などにアクセスし、データの窃取やアカウントの乗っ取り、さらなる内部ネットワークへの侵入の足がかりを得る恐れがあります。メールを日常的に扱う組織にとって、業務継続性や機密情報の保護に深刻な打撃を与える可能性が高いです。特に国家レベルの脅威アクターが関与する可能性が指摘されている点が懸念材料です。 対策 Zimbraバージョン10.1.19に直ちにアップグレードしてください。このバージョンで脆弱性が修正されています。バージョン10.0.x、9.0.x、8.8.15からアップグレードする場合は、SNMP緩和策を再適用する必要があります。Classic Web Clientを使用しているすべてのユーザーは優先的に対応し、可能であればModern Web Clientへの移行も検討してください。アップデート完了まで、疑わしいメールの開封を避ける運用ルールを強化し、メールセキュリティゲートウェイでのフィルタリングを強化することを推奨します。 3. Joomla拡張機能（Balbooa FormsおよびiCagenda）におけるクリティカルなRCE脆弱性 背景 Joomlaは世界中で広く使われるコンテンツ管理システム（CMS）で、数百万のウェブサイトが稼働しています。今回警告されているのは、人気の拡張機能であるBalbooa FormsとiCagendaに存在する任意ファイルアップロードの脆弱性です。Balbooa FormsのCVE-2026-56291とiCagendaのCVE-2026-48939は、いずれもCVSSスコア10.0（クリティカル）と極めて深刻です。これらの脆弱性はゼロデイとしてすでに悪用されており、CISAのKnown Exploited Vulnerabilities（KEV）カタログに2026年7月10日に追加されました。Balbooa Formsはバージョン2.4.0以前、iCagendaはパッチ適用前のバージョンが影響を受けます。 影響 認証なしの攻撃者が脆弱なエンドポイントを悪用して任意のPHPファイルをアップロードし、リモートコード実行（RCE）を達成できます。これにより、ウェブサイトの完全な乗っ取り、機密データの窃取、バックドアの設置、ボットネットへの組み込みなどが可能になります。Joomlaサイトを運用する組織や、顧客向けウェブサイトを持つ企業にとって、ブランド毀損や法的責任、事業中断のリスクが極めて高いです。すでに自動化された攻撃スキャンが確認されており、広く標的にされている状況です。 対策 影響を受ける拡張機能を直ちにアップデートしてください。Balbooa Formsはバージョン2.4.1以降、iCagendaは4.0.8または3.9.15以降に更新します。パッチが適用できない場合は、拡張機能を無効化または削除することを強く推奨します。CISAのKEVリストを定期的に確認し、該当する脆弱性への対応を優先してください。また、ウェブアプリケーションファイアウォール（WAF）の導入、ファイルアップロード機能の制限、定期的なセキュリティ監査を実施することが有効です。Joomla本体とすべての拡張機能を常に最新状態に保つ運用が基本です。 4. Progress ShareFile Storage Zone Controllerの緊急シャットダウン指示 背景 Progress SoftwareのShareFileは、安全なファイル共有・ストレージサービスです。オンプレミスのStorage Zone Controller（SZC）を使用する顧客に対し、2026年7月10日頃に「信頼できる外部からのセキュリティ脅威」が確認されたとして、Windowsサーバーの即時手動シャットダウンを指示する緊急メールが送信されました。クラウドのみの利用者は影響を受けませんが、オンプレミスSZCを利用している組織は対応を迫られました。脅威の詳細や攻撃者については現時点で公表されていませんが、調査が進行中です。 影響 SZCをシャットダウンすることで、関連するShareFileアカウントへのアクセスが一時的に無効化され、ファイル共有業務に大きな支障をきたす可能性があります。データ漏洩やシステム侵害のリスクを回避するための予防的措置ですが、事業継続計画に影響を与えるケースもあります。脅威が「信頼できる外部からのもの」とされる点から、標的型攻撃や既知の脆弱性を突いた侵入の可能性が考えられます。 対策 Progressの指示に従い、該当サーバーを直ちにシャットダウンし、調査完了までオフラインにしてください。クラウド版への移行を検討している組織は、この機会に評価を進めることを推奨します。復旧の際はProgressからの公式ガイダンスを厳守し、追加のセキュリティ監査やログ分析を実施してください。類似のオンプレミスストレージシステムを利用する組織は、アクセス制御の強化と脅威インテリジェンスの監視を徹底してください。 5. Centers Laboratoryのデータ侵害（WorldLeaksによる主張） 背景 米国の医療検査・診断サービス企業Centers Laboratoryで、2025年8月頃に発生したデータ侵害が最近公表されました。WorldLeaksというデータ窃取・恐喝グループが2025年10月に主張し、720GB（160万ファイル以上）のデータを漏洩させたとしており、2026年6-7月頃に公式通知が行われました。影響を受けるのは54万人以上とされ、個人情報や健康関連データが含まれています。 影響 漏洩した可能性のあるデータには、患者の検査記録、診断情報、従業員情報、運転免許証、社会保障番号などの機密性の高いものが含まれます。医療機関特有の規制（HIPAAなど）違反のリスク、患者のプライバシー侵害、アイデンティティ盗用の可能性が高く、組織の信頼失墜や法的・金銭的負担が懸念されます。侵害から1年近く経過しての公表であり、攻撃者がすでにデータを悪用している可能性もあります。 対策 影響を受けた可能性がある個人には、通知に基づきクレジットモニタリングやID保護サービスの利用を推奨します。組織側は、侵害の詳細を徹底的に調査し、再発防止のためのセキュリティ強化（多要素認証の導入、データ暗号化、アクセス制御の見直し、定期的な脆弱性診断）を実施してください。医療・ヘルスケア分野の組織は、特にデータ最小化と暗号化を徹底し、インシデント対応計画を最新化することが重要です。