Privilege Escalation Risk Discovered in Azure’s AZNFS Utility
A high-impact security issue has been identified in AZNFS-mount, a utility within Azure’s ecosystem that connects Linux systems to Azure Storage via NFS. The flaw, present in all releases up to version 2.0.10, enables local attackers to elevate their permissions from standard user to full system control (root). This utility is automatically included in Azure HPC/AI virtual machine images.
The vulnerability, uncovered by researchers at Varonis, stems from a well-known privilege escalation vector involving a Set User ID (SUID) binary. In this case, the mount.aznfs binary—part of the AZNFS installation—can be manipulated to grant elevated access due to insecure coding practices.
Designed to streamline access to NFS-mounted Azure Blob Storage, the AZNFS utility manages dynamic IP mapping using a privileged script installed through aznfs_install.sh. This installation script operates with root-level permissions, setting up executable files that retain those privileges to manage mount configurations and adjust DNAT rules.
At the heart of the issue is the mount.aznfs executable, configured with the SUID bit (file mode 4755), which allows any user to launch it. When the command mount -t aznfs is invoked, it executes this binary, which then calls a secondary Bash script located at /opt/microsoft/aznfs/mountscript.sh.
The critical weakness lies in the use of the execv system call, which executes the script while preserving the caller’s environment—a scenario that can be exploited to run arbitrary commands as root.

Root Access Through Environment Variable Abuse in AZNFS-mount
Security researchers have revealed a critical flaw in the AZNFS-mount tool, used to link Linux machines with Azure Blob Storage over NFS. The vulnerability revolves around the misuse of the BASH_ENV environment variable, which can be exploited to execute commands with elevated privileges.
By assigning BASH_ENV a specially crafted value like $(command), attackers can trick Bash into running arbitrary commands and interpreting the output as a file to be loaded—an avenue that can lead directly to root-level access. This type of exploit opens doors for unauthorized mounting of storage containers, lateral movement within cloud environments, and even malware deployment.
Though Microsoft initially labeled the issue as low severity, a fix has already been released in version 2.0.11 of the utility. Users running Azure HPC images or leveraging NFS to access Blob Storage should immediately verify that their systems are either set to auto-update or are manually upgraded to the latest secure version.
Microsoft’s Kubernetes CSI Blob driver has already incorporated the patched version into its releases, underscoring the urgency of remediation despite the low-severity rating.
Azure Blob Storage—frequently accessed via REST, SFTP, or NFS—offers scalable cloud data solutions, but it’s important to recognize a key caveat: NFS-based access operates outside of Azure’s native access control frameworks. This means anyone with endpoint access can freely interact with all contents within a container, regardless of role or attribute-based security models.
To reduce risk exposure, organizations should regularly audit their storage permissions and verify the integrity and currency of any tools interfacing with Azure services.




