A security researcher submitted a bug report to Microsoft about Azure Backup for AKS. Microsoft rejected it. Then, by the researcher’s account, Microsoft quietly fixed it anyway. No CVE was issued. No advisory went out. When BleepingComputer asked, Microsoft told them no product changes were made.

This is the part of cybersecurity nobody puts in a brochure: the work that happens after a vendor closes a ticket, the patch that ships without an advisory, the bug that lives in your environment but not in your scanner. If your risk register depends on what CVE feeds publish, you have a blind spot bigger than you think.

When the fix ships but the CVE doesn’t

The Azure Backup for AKS report describes what the researcher considered a clear authentication boundary problem. Microsoft’s response, as reported, was that the behavior was expected. The researcher then documented evidence that the underlying behavior changed. Microsoft’s official line: no product changes were made.

Take both statements at face value and something doesn’t add up. Either the behavior was always fine and the observable change was cosmetic, or the behavior changed and the company isn’t acknowledging it. The researcher’s side has technical detail. The company’s side has a legal department.

This kind of standoff happens more often than the security press covers. Vendors have strong incentives to avoid CVEs: a CVE creates a paper trail, drives customer questions, complicates SLAs, and gives competitors something to point at. A silent fix has none of those costs. It also has none of the benefits to you, the customer actually running the product.

The Funnel Builder skimmer story this week lives in the same uncomfortable category. Sansec documented active exploitation of a WordPress plugin used on WooCommerce checkouts, with attackers injecting payment-skimming JavaScript directly into the checkout flow. The bug is real. It’s being exploited right now. It doesn’t have an official CVE identifier either.

Your patch program has a hole the size of “expected behavior”

Most enterprise vulnerability management programs run on a simple pipeline. CVEs get published, scanners ingest them, tickets get created, patches get applied, auditors get reports. The whole stack assumes CVE numbers exist for the things that matter.

When a managed cloud service silently fixes an issue, none of that fires. Your scanner doesn’t flag the affected resource, because there’s nothing to flag. Your detection engineering team doesn’t write a rule, because there’s no signature, no IOC, no advisory text to anchor on. The auditor reads your last vulnerability report and signs off because the report is clean.

For SaaS and managed services the gap is worse. With on-premises software you control the patch decision and can usually see the diff. With Azure Backup for AKS, or any managed service, the fix appears or doesn’t appear inside the vendor’s perimeter. You audit the side effects.

This is where the marketing language around shared responsibility gets thin. The vendor is responsible for patching the service. The customer is responsible for knowing the service got patched and for understanding what it did and didn’t fix. When the vendor decides not to tell you, the second half of that contract evaporates.

Building cybersecurity that doesn’t depend on CVE feeds

You can’t audit what a vendor won’t disclose. You can build controls that don’t depend entirely on disclosure, and you can pressure vendors with documentation when their public statements drift away from observable behavior.

Start with the basics. Behavioral baselining on cloud control plane activity catches drift even when you don’t know what changed. Egress monitoring on managed clusters catches data movement that “expected behavior” doesn’t explain. Configuration drift detection on AKS, EKS, and GKE clusters flags when permissions, network policies, or backup settings shift in ways your team didn’t authorize. Treat the managed control plane as part of your attack surface, with logs forwarded to a SIEM you actually control.

Backup configuration is its own discipline. Validate that snapshots are encrypted, that access to backup vaults is logged, that restore operations require the same identity rigor as production access. Write a runbook that explicitly tests authorization boundaries on restore. Don’t trust the docs; test the behavior. The Azure Backup for AKS report involved backup behavior specifically, and brute-force boundary probing on restore endpoints belongs in every red team rotation against your own cloud accounts.

Defense in depth applies to vendor relationships as much as it does to networks. Combine firewall rules at the cluster level with identity-side controls, IAM scoping, and least-privilege role bindings. Layer threat detection on top of vendor-provided controls instead of replacing your stack with the vendor’s offering. The point of layered hardening is exactly this scenario: when one trust assumption breaks, the other layers buy you time for incident response.

Track vendor responses as procurement signal. If you submit a finding and the vendor denies it, keep the technical evidence, the timeline, and any observable behavioral changes. Coordinated disclosure works when there’s a paper trail. Without one, vendor accountability becomes a he-said, she-said. Ask vendors during procurement how many CVEs they’ve issued in the past year, how they handle external reports, and whether they have a documented coordinated disclosure policy. Vendors who answer well tend to behave well later. Vendors who get prickly about the question tend to ship silent fixes.

The Microsoft and Funnel Builder stories share a structural problem more than a technical one. Real exploitation and real fix evidence exist outside the CVE system. Security teams who only consume CVE feeds miss both. Teams who consume CVE feeds plus vendor advisories plus behavioral telemetry plus their own internal hunting catch most of what gets through. Threat-protection programs that stop at the published advisory line are budgeting against the wrong threat model.

Frequently Asked Questions

What should I do if a vendor rejects a vulnerability report I submitted?

Keep all technical evidence, including request and response samples, timestamps, and reproduction steps. Document any subsequent behavioral changes you observe. Consider engaging a coordinated disclosure body or trusted journalist if the vendor’s response materially conflicts with observable behavior.

How do I track vulnerabilities that don’t have CVE numbers?

Maintain a vendor advisory feed and a researcher-publication watchlist separate from your CVE pipeline. Build an internal tracker for unnumbered findings affecting your stack. Treat “no CVE assigned” as a tracking attribute, not a reason to ignore the issue.

Are managed cloud services riskier than self-hosted equivalents here?

Less transparent rather than riskier. Managed services typically patch faster, which is a security gain. The cost is reduced visibility into what was patched, when, and why. You trade patch velocity for audit clarity.

Sources

• Microsoft rejects critical Azure vulnerability report, no CVE issued
• Funnel Builder Flaw Under Active Exploitation Enables WooCommerce Checkout Skimming