Silent Fixes vs. "Expected Behavior": The Azure AKS Backup Controversy
Has anyone else dug into the recent report regarding Microsoft rejecting the critical Azure Backup for AKS vulnerability? According to BleepingComputer, a researcher submitted a flaw that allows for significant privilege escalation, but Microsoft rejected the report, claiming the behavior was "expected" and that "no product changes were made."
However, the researcher has documented evidence suggesting a silent fix was deployed anyway. This is a nightmare for vulnerability management. Without a CVE, we don't get a CVSS score, we don't get a bulletin, and our scanners won't flag it. If a fix was indeed deployed silently, how do we verify our tenant is actually patched against a vulnerability that "officially" doesn't exist?
We might need to start auditing the versioning of the Azure Backup extension more aggressively to catch these undocumented shifts. I've thrown together a quick KQL query to hunt for recent extension installation or update activities on AKS clusters, just to see if we can spot the change ourselves.
AzureActivity
| where Category == "Administrative"
| where ResourceProvider == "MICROSOFT.KUBERNETESCONFIGURATION"
| where OperationNameValue contains "Microsoft.KubernetesConfiguration/extensions/write"
| project TimeGenerated, SubscriptionId, Caller, OperationName, Properties_d
| order by TimeGenerated desc
Has anyone else noticed discrepancies in their AKS backup logs recently, or are we just relying on blind trust here?
This is exactly why I hate the 'designated feature' defense for cloud providers. If the behavior changes from 'vulnerable' to 'secure' without a version bump or a CVE, it's a silent patch—plain and simple. We've started baselining the digest hashes of our installed extensions. If the hash changes but the version number doesn't, we raise an internal ticket.
az aks show --resource-group --name --query "addonProfiles" -o
It’s not perfect, but it catches when they hotfix something on the backend without telling us.
From a SOC perspective, the lack of a CVE makes correlating this threat in our SIEM nearly impossible. We usually feed the CISA catalog into our detection rules, but 'ghost' vulns slip right through. I’d recommend focusing detection on the impact rather than the patch status. If the flaw grants backup access, monitor for unusual restore operations or modifications to the Backup Vault role assignments.
Get-AzRoleAssignment -Scope "/subscriptions//resourceGroups//providers/Microsoft.DataProtection/backupVaults/"
If you see new principals added there outside of a change window, assume the worst.
Without a CVE, you have to rely on build timestamps to track these changes. I recommend querying the Azure extension versions directly to see when the "silent fix" hit your tenant. Run this to check the AzureBackup extension version across your clusters:
az k8s-extension list --cluster-type managedClusters --cluster-name --resource-group --query "[{name:name, version:version}]" -o table
Compare this version timestamp against your vulnerability scans to manually create a remediation timeline.
From a compliance perspective, this creates a massive audit gap. If a vendor denies a vulnerability exists but silently patches it, you cannot map the risk to a remediation date, leaving your risk register invalid. We treat these undocumented behavior shifts as 'unauthorized changes' until proven otherwise. I recommend running a monthly Azure Resource Graph query to detect changes in your AKS environment that don't correlate with announced maintenance.
kusto resources
| where type =~ 'microsoft.containerservice/managedclusters'
| project name, location, properties.agentPoolProfiles
| diff ...
This provides an internal paper trail when vendors ghost you.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access