In November 2023, Microsoft published an advisory about CVE-2023-36052, an information disclosure vulnerability in Azure CLI. The issue quickly got attention because it directly impacts how secrets and sensitive data can be accidentally exposed using a very common tool. If you’re relying on Azure CLI in scripts, DevOps, or troubleshooting, this is a must-read. We'll break down what happened, how it works, and how to avoid being caught out.
What Was the Vulnerability?
Azure CLI (the az command) is used by thousands daily to manage Azure resources. It has a rest command:
az rest --method post --uri https://management.azure.com/...
This lets you talk directly to Azure APIs, sending requests and getting JSON data back. But if your API response included secrets—like passwords, tokens, or connection strings—they could get logged in the CLI's local files without you realizing.
This means: Sensitive info you tried to keep safe might get saved to your disk. That’s the heart of CVE-2023-36052.
Why Does This Matter?
Attackers (or even well-meaning team mates) who have access to your computer could search logs and pull out keys, passwords, or private data which should never have lived outside Azure. On shared machines, build agents, or even old laptops, that's a disaster waiting to happen.
How Did It Happen? (Technical Details with Code)
The core of the issue is where and how Azure CLI stores its logs. When you use the az rest command, Azure CLI saves the entire HTTP response—sometimes including sensitive data—to a log file, often found in your user profile directory, e.g.:
C:\Users\<username>\.azure\logs\azure.log
- Linux/Mac:
~/.azure/logs/azure.log
Let’s say you run
az rest --method get \
--uri https://management.azure.com/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.KeyVault/vaults/{vault}/secrets/{secretName}?api-version=2019-09-01
If this API call returns the secret value, your log file might now contain a chunk like
DEBUG:msrest.http_logger:Response status: 200
DEBUG:msrest.http_logger:Response headers: {...}
DEBUG:msrest.http_logger:Response content:
{
"value": "super-secret-password-123",
"id": "...",
"attributes": {...}
}
That line "value": "super-secret-password-123" is now in clear text in a local file.
Exploitation Scenario
Suppose you’re a system admin or DevOps engineer, and you use Azure CLI on a shared or multi-user server to fetch and troubleshoot secrets. Months later, maybe you leave the company—but your old logs sit there, full of secrets.
A new admin comes along. Maybe they're benign, maybe not. They run
grep -r "super-secret-password" /home/*/.azure/logs/
or, more broadly,
grep -r '"value":' ~/.azure/logs/
And suddenly they see a list of all secrets, plain as day.
Microsoft Security Response Center advisory:
Official Azure CLI GitHub Issue & Patch PR (fix details):
Community write-ups:
- AQUA Security Blog
- KrebsOnSecurity Coverage
How Was It Fixed?
Starting with Azure CLI version 2.53.1, logs are more careful about what gets stored. The first thing you should do is upgrade your Azure CLI:
# For most systems
az upgrade
Or manually download the latest installer from the Azure CLI releases page.
Additionally, Microsoft recommends rotating any secrets you might have exposed, cleaning up old log files (delete ~/.azure/logs/*), and using tools like Key Vault to store sensitive values.
`bash
rm -rf ~/.azure/logs/*
- If you handle secrets, consider disabling detailed debug logs:
bash
export AZURE_CORE_COLLECT_TELEMETRY=no
<br>- Rotate all secrets that might have leaked.<br><br>---<br><br>## Conclusion<br><br>_CVE-2023-36052_ is a classic example of how “normal” CLI commands can leak sensitive data in ways you don’t expect. If you’re using Azure CLI's rest` command, review your systems, delete or secure your log files, and upgrade your tooling now.
Stay vigilant. Your logs are as sensitive as your source code and databases.
---
References:
- Microsoft CVE-2023-36052 Advisory
- Azure CLI Release Notes
- AquaSec Deep Dive
---
Did you find secrets in your logs?
Change them—fast! And tell your team.
Don't let a missed upgrade become your next incident headline.
Timeline
Published on: 11/14/2023 18:15:36 UTC
Last modified on: 11/20/2023 18:13:20 UTC