CVE-2023-36414 is a remote code execution vulnerability in Microsoft's Azure Identity SDK for .NET, disclosed in October 2023, that carries a CVSS 3.1 base score of 8.8 (High). It affects Azure Identity for .NET versions before 1.10.2, and the fix is simply to upgrade to 1.10.2 or later. What makes it worth understanding rather than just patching is the shape of the bug: it is a command injection (CWE-77) that turns an SDK property into a path to arbitrary OS commands.
How CVE-2023-36414 works
The Azure Identity SDK provides credential types that authenticate .NET applications to Azure services. Some of those credential flows shell out to a local CLI — for example, invoking the Azure CLI to obtain a token on a developer machine or in an environment configured to use CLI-based auth.
The vulnerability is that a specific SDK property, which feeds into the command the SDK constructs for that CLI, is not sanitized. An attacker who can control that property can smuggle an OS-level command into the string the SDK builds and hands to the shell. When the SDK invokes the CLI, the injected command runs with the privileges of the process. That is the remote code execution.
The advisory notes the attacker needs to be authenticated as a normal user for the CVSS 8.8 vector to apply. That is not much of a barrier in a multi-tenant service or any application where lower-privileged users can influence credential configuration. The severity is high because the payoff — arbitrary command execution — is total, even if reaching the injectable property takes some access first.
Which versions are affected
Every Azure Identity for .NET release before 1.10.2 is vulnerable. The fix shipped in 1.10.2. Because this is a NuGet package that other Azure client libraries depend on, you may pull it in transitively rather than referencing it directly.
To see what your project resolves:
dotnet list package --include-transitive | grep -i azure.identity
If that returns a version below 1.10.2, you are exposed. Do not stop at your direct references; Azure SDK client libraries (storage, key vault, service bus, and others) frequently bring Azure.Identity along as a transitive dependency, and that transitive copy is just as exploitable.
How to remediate CVE-2023-36414
Upgrade Azure.Identity to 1.10.2 or later. This is the whole fix. Add or bump the package reference:
dotnet add package Azure.Identity --version 1.10.2
If a transitive dependency is holding an older version, add a direct top-level reference to Azure.Identity at 1.10.2 or newer. A direct reference wins over a transitive one in NuGet resolution, so pinning it at the project level forces the patched version even when a client library still asks for something older.
Rebuild and redeploy, do not just restore. A dotnet restore against a cached lockfile can quietly keep the old version. Bump the reference, delete obj/ and bin/ if you are being careful, and confirm the built output ships 1.10.2 or later before you call it done.
Review where credential configuration comes from. The exploit needs an attacker to influence the property that feeds the CLI command. Audit whether any credential-related configuration in your app derives from user input, request data, or a source lower-privileged users can touch. Even after upgrading, treating credential configuration as untrusted input is good hygiene against the next bug in this family.
Because Azure.Identity spreads through the Azure SDK as a transitive dependency, a single application can carry several copies at different depths. An SCA tool such as Safeguard can trace which client library pinned the vulnerable version, which usually points you straight at the direct reference to add.
Why "just an SDK" bugs deserve attention
It is tempting to treat vendor SDK vulnerabilities as low priority because the code is not yours. CVE-2023-36414 is a reminder that the opposite is often true. SDKs run in your process, with your privileges, and they touch the most sensitive thing in a cloud application: authentication. A command-injection bug in the credential path is close to a worst case, because the code that runs the injected command is the same code trusted to obtain your tokens.
The broader lesson is to scan dependencies continuously rather than at release time. Azure.Identity is updated frequently, and the version your app resolved six months ago is not the version a fresh scan flags today. If you want the wider picture on catching this class of issue, our application security scanning guide covers where SCA fits alongside SAST and DAST.
FAQ
How serious is CVE-2023-36414?
It is High severity, CVSS 3.1 base score 8.8. Successful exploitation gives an attacker remote code execution in the context of the affected .NET process, though the attacker must be authenticated as a normal user for that vector.
What version fixes CVE-2023-36414?
Azure Identity for .NET version 1.10.2 and later. Upgrade the Azure.Identity NuGet package to at least 1.10.2 to close the vulnerability.
Does CVE-2023-36414 affect the Azure Identity SDK for other languages?
This CVE is specific to the .NET implementation. Other language SDKs have their own advisories and version histories; check the relevant package rather than assuming a shared fix.
I only reference Azure.Storage, not Azure.Identity. Am I safe?
Not necessarily. Azure SDK client libraries such as storage and key vault commonly pull in Azure.Identity as a transitive dependency. Run dotnet list package --include-transitive to check the resolved version, and add a direct reference to 1.10.2+ if a transitive copy is below the fix.