security - 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 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 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.