Add advisory for azure_core: authorization header written to logs

[mspiegel]

Affected crate(s)

• azure_core (6,582,265 recent downloads per crates.io) — and transitively
  the legacy client crates that depend on it (azure_identity,
  azure_storage, azure_storage_blobs, the generated azure_mgmt_* crates)

Links to upstream issue(s) or PR(s)

• Legacy azure_core (<= 0.21.0): inverted authorization-header redaction logs live credentials at debug level (CWE-532) Azure/azure-sdk-for-rust#5074 — public disclosure
  (2026-08-15); a maintainer replied 2026-08-26 and closed it as not planned:
  the legacy branch is unsupported, no fix will ship, users should move to
  azure_core >= 1.0.0. The technical finding was not disputed.
• Redact the authorization header from Debug impl Azure/azure-sdk-for-rust#1699 — the upstream attempt
  to redact the header (0.21.0), whose condition is inverted.
• Also reported to MSRC (VULN-211331), which determined it does not meet the
  Microsoft Security Servicing Criteria definition of a vulnerability because
  the affected code exists only on the unsupported legacy branch. The
  technical finding was not disputed there either.

Severity

Credential exposure via logs (CWE-532). With debug-level logging enabled (or
trace, for the retry-policy path present across the whole range), the legacy
SDK writes the outgoing authorization header value to application logs. The
leaked value is a live credential — an Entra ID bearer token, Storage
SharedKey signature, or SAS token — replayable by anyone with log read access
until it expires. In 0.21.0 the redaction added by upstream PR #1699 is
inverted: authorization is printed in the clear while every other header
shows [redacted], giving log auditors false evidence that sanitization
works. Earlier versions redact nothing.

Affected: 0.1.1, and 0.2.1 through 0.21.0. Patched: >= 0.22.0 (the rewritten
SDK, which contains neither the affected code nor any request logging).
0.2.0 is unaffected — despite the version number it predates 0.1.1 and the
policy pipeline, logs no requests, and has been yanked. The range was
verified by inspecting every published legacy version.

Checklist

• Advisory filename(s) starts with RUSTSEC-0000-0000 as the ID
• date field is set to the public disclosure date
• Contains a concise and descriptive title after advisory metadata
• Asked maintainer(s) if publishing an advisory is appropriate — issue
  #5074 asked them to confirm the behavior so an advisory could be filed;
  they confirmed no fix is planned and did not object

rustsec-admin lint passes. Several legacy client crates have no release on
the new SDK, so this advisory exists to alert their users and point at the
supported one.

[djc]

Please use the pull request template.

If you are not one of the maintainers, one of the maintainers should sign off on publishing an advisory; if you are, it would be good to see some kind of evidence/proof that you are.

[mspiegel]

Done — the PR description now follows the template, and I've also corrected the advisory's date field to the public disclosure date (2026-08-15, when Azure/azure-sdk-for-rust#5074 was opened) rather than the filing date.

On sign-off: I'm not a maintainer of azure-sdk-for-rust — I'm the reporter. The upstream maintainers were asked via issue #5074; they confirmed the legacy branch is unsupported, said no fix will ship, closed it as not planned, and didn't dispute the finding or object to an advisory. It was also reported to MSRC (VULN-211331), which declined it as out of servicing scope for the same reason. So there's no upstream fix or upstream-filed advisory coming — happy to provide anything further you need to review it.