CVE-2026-57104

Azure Storage Explorer's stored XSS in blob metadata (CVE-2026-57104) exploits a fundamental assumption that infrastructure-adjacent tooling consistently gets wrong: data sitting in your own storage account is not inherently safe. When Storage Explorer renders blob names, metadata, container properties, or queue messages, it treats that content as trusted internal data. Attackers who can write blobs to any storage account that a victim will browse can embed JavaScript in metadata fields. When the victim's browser renders the unsanitized content, the script executes and exfiltrates session tokens — giving the attacker access to the management plane. The privilege escalation is real, but 'lateral movement' is more precise: the attacker moves from 'can write blobs' to 'can steal tokens for the entire management interface.' Storage Explorer is often used with broad Azure permissions, so the blast radius isn't limited to one storage account — stolen tokens may grant access to resource groups, Key Vaults, and the full management plane. Worse, this payload persists. The crafted blob sits dormant until someone browses that container — tomorrow, next month, a new employee. The blast radius compounds over time. Your defense priorities: First, audit which users and applications can write blobs to storage accounts that Storage Explorer users browse — treat every write from less-trusted sources as potentially hostile. Second, implement detection for XSS patterns in blob metadata in your logging pipeline. Third, update your Azure security baseline to explicitly classify blob metadata, file names, and queue messages as untrusted input requiring the same sanitization rigor as web form data. Fourth, review Storage Explorer usage patterns — who has it installed, what accounts they access, and whether broad permissions are necessary. The vulnerability class will recur; your baseline needs to account for it.

Reviewed through automated stages and approved by a human before publication.