Notifications
Clear all
Topic starter
12/06/2026 12:38 am
TL;DR: Azure Machine Learning invoker scripts stored in a linked Storage Account could be modified to execute attacker code under the AML compute identity, opening paths to secret access and privilege escalation, according to Orca Security. The finding shows machine learning pipelines inherit identity risk when storage, compute, and managed identities are not tightly separated.
NHIMG editorial — based on content published by Orca Security: Azure Machine Learning privilege escalation vulnerability analysis
By the numbers:
- 33% of Azure customers are using the AML, g the AML service.
Questions worth separating out
Q: What breaks when AML pipeline scripts can be modified in linked storage?
A: The execution boundary breaks.
Q: Why do managed identities make AML privilege escalation more dangerous?
A: Managed identities can expand the blast radius of a successful code injection because the malicious code runs with whatever rights the AML identity already has.
Q: How do security teams know whether AML identity scope is too broad?
A: Look for mismatches between the job’s purpose and the rights attached to the compute instance or workspace identity.
Practitioner guidance
- Restrict write access to AML-linked storage Limit write permissions on the storage account that holds pipeline components, invoker scripts, and YAML execution files.
- Remove inherited human privilege from compute instances Disable SSO where it causes the compute instance to run under the permissions of the user who created it, and replace that path with a controlled system-assigned identity that has only the permissions required for the job.
- Enforce immutability for executable AML artefacts Apply immutability policies and versioning to critical script blobs so unauthorised edits can be blocked or rolled back.
What's in the full article
Orca Security's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step reproduction of the Azure Machine Learning privilege escalation path
- Blob storage directory structure and invoker script examples used in the proof of concept
- Code snippets showing how identity context changes under user-assigned and system-assigned managed identities
- The Microsoft documentation changes and configuration nuances that affect the attack surface
👉 Read Orca Security’s analysis of Azure Machine Learning privilege escalation →
Azure ML storage-backed code execution: what IAM teams need to know?
Explore further
12/06/2026 10:01 am
AML storage write access is effectively execution authority when scripts are fetched at runtime. The article shows that the trust boundary was not between code and storage, but between authorised and unauthorised modification of executable pipeline artefacts. Once storage can alter what the job runs, the control failure is identity-to-code coupling, not merely weak file permissions. Practitioners should treat writable pipeline storage as part of the runtime trust chain.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means many teams cannot reliably trace which non-human identities can reach sensitive workloads.
A question worth separating out:
Q: Who is accountable when AML jobs inherit a user’s permissions through SSO?
A: Accountability sits with the identity and platform owners who allowed human privilege to flow into machine execution. If SSO makes a compute instance act under the creator’s permissions, then the governance problem is not isolated to the developer who submitted the job. It is a programme-level failure to separate human authentication from workload authorisation.
👉 Read our full editorial: Azure Machine Learning privilege escalation exposes identity risk
