CVE-2025-29972 is a critical (CVSS 9.9) server-side request forgery in the Azure Storage Resource Provider. The record says an authorized attacker can perform spoofing over a network. I could not retrieve Microsoft's guide, so confirm there whether customers need to take any action, and which steps apply.
What's affected
The record lists the Azure Storage Resource Provider as affected and gives no version numbers. Because it is a cloud service component, versions may not apply to you in the usual sense.
I could not load the Microsoft update guide page, so I cannot say whether customers had to take any action, or whether Microsoft fixed the service on its side. Read the guide before concluding that you are or are not exposed.
The record does not flag the CVE as known exploited (not in the CISA KEV catalog at the time of writing). It also says the attacker must be authorized, meaning some level of access is needed first.
How to check if you're exposed
For a cloud service flaw, the check is about your tenant and your controls, not a package version.
- Open the MSRC guide for CVE-2025-29972 and read whether action is required from customers.
- Review which identities in your subscriptions can manage storage accounts, since the record says the attacker is authorized.
- Check activity logs for unusual storage account configuration changes, new access keys, and new shared access signatures.
If you manage Azure with infrastructure code, also check that role assignments in code match what exists in the portal.
What to do now
- Read Microsoft's guide and note any customer actions or dates it gives.
- Review role assignments on storage accounts and resource groups, and remove permissions that are not needed.
- Turn on and review activity logs and storage diagnostic logs so that you can see management operations.
- Rotate storage account keys that were shared widely, and prefer identity based access over long lived keys.
- Record what you checked so that you can answer a questionnaire later.
Why it matters
The record maps the flaw to CWE-918 (Server-Side Request Forgery). With SSRF, a service is tricked into making a request on the attacker's behalf, and that request can reach places the attacker cannot reach directly, such as internal endpoints. Because the request comes from a trusted service, it may carry that service's trust.
The 9.9 score reflects a change of scope in the vector: the impact goes beyond the vulnerable component. That is typical of SSRF in a management layer. The need for an authorized attacker narrows the risk, but many organizations have broad access groups, which is why least privilege review is worth doing.
I have kept this post to what the record supports. The vendor guide is the source for fixed status.
Quick check
Do I need to patch anything?
For cloud service components, Microsoft often fixes the service itself. Read the MSRC guide to see whether customers must act.
Why does least privilege matter here?
The record says the attacker is authorized. Fewer people with management rights means fewer accounts that could be misused.
Sources
Last reviewed: 19 October 2026.
