vulnerability - Yuru Security

2026/05/17 security general malware vulnerability

# Microsoft "Quietly Fixes" Azure Backup AKS Privilege Escalation Bug — No CVE, No Official Announcement, Researcher Pushes Back

🔴 A privilege escalation vulnerability may have been silently patched — with no CVE issued and no official disclosure, making it difficult to gauge the full scope of impact.

"There's no vulnerability," they said — yet a fix was quietly shipped anyway. At least, that's what security researcher OLeary (@olearysec) is claiming. A disagreement between Microsoft and an independent researcher over a privilege escalation vulnerability in Azure Backup for Azure Kubernetes Service (AKS) has sparked serious questions about the vulnerability reporting and disclosure process itself.

From Discovery to "Quiet Resolution": What Happened?

The core issue OLeary discovered is straightforward: a user with only the "Backup Contributor" Azure role — a role that grants zero Kubernetes permissions — could obtain cluster-admin (cluster administrator) privileges on an AKS cluster.

That's a genuinely alarming finding. Holding cluster-admin privileges in Kubernetes means having access to every workload, secret, and configuration within that cluster. With many organizations running production environments on Kubernetes in Azure, the potential blast radius is far from trivial.

OLeary reported the issue to Microsoft, but the company rejected it, arguing that "an attacker would already need to have administrator privileges." OLeary pushed back, calling this assumption "factually incorrect" — the vulnerability doesn't require admin privileges; it grants them. That's a fundamental distinction.

OLeary further documented that CERT/CC independently validated the vulnerability and assigned it VU#284781. A third-party organization confirmed this was a real issue — and yet Microsoft's position remained unchanged.

"No Product Changes Were Made" — Microsoft's Position

According to BleepingComputer's reporting, Microsoft told them the behavior was "by design" and that "no changes to the product were made."

However, OLeary documented that the problematic behavior was fixed at some point after the initial report. An official statement claiming no product changes were made, alongside observable changes in behavior — how you reconcile that gap is ultimately up to you. From the outside, it's a difficult discrepancy to explain away.

The real-world consequences of skipping a CVE shouldn't be overlooked either. CVE numbers are one of the most basic tools security teams use to prioritize patching decisions. Without a number, organizations running affected environments may simply never connect the dots and realize they're impacted. Companies using Azure Backup for AKS in production may have gone without any awareness of this privilege escalation risk — with time simply passing them by.

The Deeper Problem With Silent Patches

It's not unusual for cloud vendors to fix vulnerabilities without issuing a CVE. In SaaS and PaaS environments where fixes happen entirely server-side, users don't need to apply patches themselves, so quiet remediation sometimes happens without any announcement.

But this case is a bit different from a standard "unannounced fix." The timeline here is: a researcher reports the issue, CERT/CC independently validates it and assigns VU#284781, Microsoft continues to insist it's "not a vulnerability" — and then, apparently, it gets fixed anyway. This is now on the record as a case where the normal vulnerability reporting, CVE assignment, and disclosure pipeline simply didn't work as intended.

To put it in concrete terms: if this bug had been exploited, an attacker with a single "Backup Contributor" account could have taken full control of an entire Kubernetes cluster. In enterprise environments running multitenant systems or large numbers of managed services, the potential damage would have been far-reaching.

✅ Action Items· If you're using Azure Backup for AKS, review your current role assignments and verify that the "Backup Contributor" role hasn't been granted to unintended users
· Review CERT/CC's VU#284781 and OLeary's detailed report to assess whether your organization is affected
· Check AKS cluster audit logs for any suspicious cluster-admin activity that may have gone unnoticed

A Question of Transparency

Which vulnerabilities get CVEs and which don't is ultimately left to vendor discretion — and that's not inherently wrong. But when something that both an independent researcher and CERT/CC have deemed a real vulnerability gets quietly closed out without making it into the public record, the security community's collective knowledge base ends up with a gap.

OLeary's report is still publicly available on their blog. No CVE, but the record remains.

2026/05/17 セキュリティ general malware vulnerability

MicrosoftがAzure BackupのAKS特権昇格バグを"こっそり修正"、CVEなし・公式発表なしで幕引き——研究者の異議は続く

🔴 CVEなし・公式発表なしで修正された可能性のある特権昇格脆弱性。影響範囲の把握が困難な状況が続いています。

「脆弱性は存在しない」と言いながら、修正だけは行われていた——少なくともセキュリティ研究者のOLeary氏（ハンドルネーム：@olearysec）はそう主張しています。Azure Backup for AKS（Azure Kubernetes Service）における特権昇格の脆弱性をめぐって、Microsoftと独立系研究者の間で食い違いが生じており、脆弱性の報告・開示プロセスそのものへの問いを突きつける事案となっています。

発見から「黙認」まで：何が起きたのか

OLeary氏が発見した問題の核心はシンプルです。「Backup Contributor」というAzureロール——Kubernetesに対する権限はゼロ——しか持たないユーザーが、AKSクラスター上でcluster-admin（クラスター管理者）相当の権限を取得できるというものでした。

これは正直、かなり怖い話です。Kubernetesクラスターの管理者権限を持つということは、クラスター内のすべてのワークロード・シークレット・設定にアクセスできることを意味します。Azure上のKubernetesを使って本番環境を動かしている組織は多く、影響範囲は小さくありません。

OLeary氏はMicrosoftへ報告しましたが、同社は「攻撃者はすでに管理者権限を持っている必要がある」として受理を拒否。OLeary氏はこの前提が「事実として誤っている」と反論しています。脆弱性は管理者権限を「前提とする」のではなく、管理者権限を「付与する」ものだという指摘です。

その後、CERT/CCがこの脆弱性を独自に検証し、VU#284781を割り当てたとOLeary氏は記録しています。第三者機関が「これは実在する脆弱性だ」と認めた形ですが、それでもMicrosoftの判断は変わりませんでした。

「製品変更はなかった」——Microsoftの立場

BleepingComputerの取材に対し、Microsoftは「想定された動作であり、製品への変更は行われなかった」と回答したと報じられています。

しかしOLeary氏は、報告後のある時点で問題の動作が修正されていることを確認したと記録しています。「製品変更はなかった」という公式回答と、実際の挙動の変化——この矛盾をどう解釈するかは、読者それぞれの判断に委ねるほかありません。少なくとも外部からは、この乖離に対する説明がつきにくい状況です。

CVEが発行されなかったことの実務的な影響も見逃せません。CVE番号は、組織のセキュリティ担当者がパッチ適用の優先度を判断するための基本的な手がかりです。番号がなければ、影響を受ける環境を使っている組織が「これは自分たちに関係がある」と気づく機会が失われます。Azure Backup for AKSを本番環境で使っている企業が、特権昇格リスクを認識しないまま時間が過ぎていた可能性があります。

「サイレントパッチ」問題の根深さ

クラウドサービスにおいて、ベンダーがCVEを発行せずに脆弱性を修正すること自体は珍しいことではありません。サーバーサイドで完結するSaaSやPaaSでは、ユーザー側にパッチ作業が不要なため、告知なく修正が行われることもあります。

ただ今回の件は、単なる「告知なし修正」とは少し異なります。研究者が報告し、CERT/CCが独自に検証してVU#284781を割り当て、それでも「脆弱性ではない」という立場を貫いたうえで修正が行われたとされる——という流れだからです。脆弱性報告の受理・CVE採番・開示というプロセスが、正常に機能しなかったケースとして記録に残ります。

自分ごととして考えると、もしこのバグが悪用されていたとして、攻撃者は「Backup Contributor」権限を持つアカウント一つからクラスター全体を掌握できた計算になります。マルチテナント環境やマネージドサービスを多数抱えるエンタープライズ環境では、その影響は広範囲に及んだでしょう。

✅ やること・Azure Backup for AKSを使用している場合、現在のロール設計を見直し「Backup Contributor」ロールが想定外のユーザーに付与されていないか確認する
・CERT/CCのVU#284781およびOLeary氏の詳細レポートを参照し、影響範囲を自組織で評価する
・AKSクラスターの監査ログを遡り、不審なcluster-admin操作が記録されていないか確認する

透明性の問題として

CVEが発行されるケースとされないケースの基準はベンダーの裁量に委ねられており、それ自体を一概に否定するものではありません。しかし研究者とCERT/CCが「実在する脆弱性」と判断したものが記録に残らない形で閉じられていくとしたら、セキュリティコミュニティ全体の知識ベースが欠損することになります。

OLeary氏の報告は、今もブログで公開されています。CVEがなくても、記録は消えません。

2026/05/17 security general vulnerability

# CVE-2026-42945: An 18-Year-Old Heap Buffer Overflow in NGINX, Uncovered by AI

🔴 CVSS v4 score of 9.2. Exploitable without authentication, PoC already public.

A heap buffer overflow had been hiding in NGINX for 18 years — and it wasn't a human security researcher who finally found it. It was an AI agent.

An LLM-based platform developed by security startup depthfirst analyzed the NGINX codebase and identified multiple vulnerabilities. The most severe of them is CVE-2026-42945, carrying a CVSS v4 score of 9.2 and classified as CWE-122 (Heap-based Buffer Overflow). The flaw resides in ngx_http_rewrite_module and is said to potentially enable unauthenticated remote code execution (RCE) or denial of service (DoS).

Vulnerability Overview

This vulnerability affects both NGINX Plus and NGINX Open Source. An attacker could trigger heap memory corruption in NGINX worker processes simply by sending a specially crafted HTTP request. A proof-of-concept (PoC) exploit has already been made public.

DoS is the near-certain outcome, with the possibility of escalating to full RCE depending on the conditions.

The Dawn of AI-Powered Bug Hunting

There's another aspect of this story worth paying attention to: how the vulnerability was found. The flaw, uncovered by depthfirst's LLM-based platform, managed to slip past countless security researchers, code reviews, and static analysis tools over 18 years.

New tools bring new perspectives — and that's genuinely a good thing. But the flip side is that this likely signals the existence of similar undiscovered vulnerabilities lurking in other widely-used software, not just NGINX, that predate the age of AI-assisted analysis.

What You Should Do

✅ Action Items · Upgrade NGINX Open Source and NGINX Plus to the fixed versions specified in F5's official security advisory
· Restart NGINX after applying the patch
· Review your nginx.conf for any problematic patterns in rewrite directives
· If using NGINX as a Kubernetes ingress controller, include auto-generated configuration files in your review

💡 CVE-2026-42945 affects both NGINX Plus and NGINX Open Source. Refer to F5's official security advisory for details on the fixed versions.

The ngx_http_rewrite_module has been a core component of NGINX for years. A flaw that went unnoticed for 18 years is now out in the open — with a working PoC to go with it.

2026/05/17 セキュリティ general vulnerability

18年間見逃されていたNGINXのヒープバッファオーバーフロー、AIが発見したCVE-2026-42945

🔴 CVSS v4スコア9.2。認証不要で攻撃可能、PoC公開済み。

NGINXに、18年間誰も気づかなかったヒープバッファオーバーフローが潜んでいました。発見したのは人間のセキュリティ研究者ではなく、AIエージェントです。

セキュリティスタートアップのdepthfirstが開発したLLMベースのプラットフォームがNGINXのコードベースを解析し、複数の脆弱性を特定しました。そのうち最も深刻なものがCVE-2026-42945です。CVSS v4スコアは9.2、CWEの分類はCWE-122（ヒープベースのバッファオーバーフロー）。ngx_http_rewrite_moduleに存在するこの欠陥は、認証不要のリモートコード実行（RCE）やサービス妨害（DoS）につながる可能性があるとされています。

脆弱性の概要

この脆弱性はNGINX Plus、NGINX Open Source双方に影響します。攻撃者は細工したHTTPリクエストを送信するだけでNGINXのワーカープロセスにヒープメモリ破壊を引き起こせるとみられ、PoC（概念実証コード）はすでに公開されています。

DoSが確実なラインで、条件次第ではRCEにまで発展する可能性があるとされています。

AIによるバグハンティングの時代

今回の件で注目されているもうひとつの側面は、発見の経緯です。depthfirstのLLMベースプラットフォームが見つけ出したこの脆弱性は、18年の間、多数のセキュリティ研究者やコードレビュー、静的解析ツールをかいくぐってきました。

ツールが変われば見える景色も変わる。それ自体は歓迎すべきことですが、裏を返せば「AI以前から存在していた未発見の脆弱性」がNGINX以外にも残っている可能性を示唆しています。

対応のポイント

✅ やること・NGINX Open Source / NGINX Plus をF5の公式セキュリティアドバイザリで案内されている修正済みバージョンにアップグレードする
・パッチ適用後は必ずNGINXを再起動する
・nginx.conf 内の rewrite ディレクティブに問題のある記述パターンがないか確認する
・Kubernetesのingressコントローラーとして利用している場合は自動生成された設定ファイルも対象に含める

💡 CVE-2026-42945はNGINX Plus・NGINX Open Sourceの双方に影響します。修正バージョンの詳細はF5の公式セキュリティアドバイザリを参照してください。

ngx_http_rewrite_moduleは長年にわたりNGINXの根幹を担ってきたコンポーネントです。18年間見落とされてきた欠陥が今、PoCとともに公開されている。

2026/05/17 security general enterprise vulnerability

# cPanel Auth Bypass Vulnerability: Multiple PoCs Surface Almost Immediately as Attacks Surge — Researcher Warns of Possible Zero-Day Exploitation "At Least a Month Before Disclosure"

🔴 Critical: Multiple proof-of-concept exploits have emerged shortly after public disclosure. Infrastructure supporting over 70 million domains is under active attack, with in-the-wild exploitation confirmed.

The situation surrounding cPanel's authentication bypass vulnerability is unfolding at a pace that security researchers are calling a "frenzy" — with multiple proof-of-concept (PoC) exploits already circulating within a short window of public disclosure.

cPanel and WHM (WebHost Manager) are web hosting management platforms used by more than 70 million domains worldwide. WHM serves as the interface for server administrators, while cPanel handles individual account management — together, they form the very foundation of web hosting infrastructure. And that foundation, it turns out, had a flaw that could allow authentication to be completely bypassed.

Multiple PoCs Drop Almost Simultaneously With Disclosure

The vulnerability is described as allowing remote attackers to access the management panel without credentials, potentially giving them full control over servers and the websites hosted on them.

What makes this even more serious is that multiple PoCs surfaced almost in lockstep with the vulnerability's disclosure. Once PoCs go public, threat actors with limited technical analysis skills can replicate the same attack techniques. The high barrier of "finding and analyzing the vulnerability yourself" essentially disappears overnight — and the pool of potential attackers expands dramatically. That's exactly the dynamic playing out here.

"May Have Been Exploited as a Zero-Day at Least a Month Before Disclosure"

There's one particularly alarming aspect of this situation: a researcher has claimed that this vulnerability may have been actively exploited in the wild as a zero-day for at least a month before it was assigned a CVE and publicly disclosed.

If true, there's a real possibility that some instances were already compromised before any official patch existed. Simply patching and moving on isn't enough — administrators would need to go back and audit logs covering the period before the patch was released. That's a significant burden, and not one that can be taken lightly.

The full extent of any damage during that potential zero-day window remains unclear, but given that this platform underpins over 70 million domains, the potential scope of impact is impossible to ignore.

The Attack Window Is Already Open

✅ What You Should Do Now ・Update cPanel/WHM to the latest version immediately (and verify that automatic updates are enabled)
・Review access logs for your management panel — look back for any suspicious logins or unauthorized configuration changes
・Don't overlook the pre-disclosure period — given the possibility of zero-day exploitation, the window before the patch is exactly where blind spots tend to hide

With multiple PoCs already circulating and active exploitation confirmed in the wild, a "wait and verify before acting" approach may already be too slow.

cPanel is effectively the standard infrastructure of the web hosting world — which also makes it an attractive, high-value target for attackers. The question now is whether administrators can move faster than their adversaries. This is that inflection point.