RUSTSEC-2026-0437
Vulnerability from osv_rustsec – Published: 2026-08-24 12:00 – Updated: 2026-11-05 08:50 – Source websiteAffected versions of KeyVaultAuthorizer::on_challenge cache the authentication
scope from a WWW-Authenticate response before verifying that the challenge
resource matches the requested endpoint. When verification rejects the challenge,
the scope remains cached. A subsequent request through the same client uses that
scope to authorize the request without repeating challenge resource verification.
For azure_security_keyvault_certificates, the affected versions are 0.9.0
through 1.0.0, inclusive, and 1.1.0-beta.1. Versions before 0.9.0 do not
use this challenge-scope cache and are unaffected by this issue.
Impact
An application that sends requests to an attacker-controlled endpoint and reuses the same client after a rejected challenge can disclose a bearer token and request body to that endpoint, if its credential can obtain a token for the supplied scope. The first request's validation error therefore does not prevent disclosure on a later request. Changing the request origin between requests is not required.
Fix
Update to 1.0.1 on the stable release line or 1.1.0-beta.2 on the preview
release line.
The fix caches the scope only after challenge resource verification succeeds when verification is enabled. Rejected challenges no longer populate the cache. The existing option to disable challenge resource verification is unchanged; this fix does not add exact-origin binding.
| URL | Type | |
|---|---|---|
{
"affected": [
{
"database_specific": {
"categories": [],
"cvss": null,
"informational": null
},
"ecosystem_specific": {
"affected_functions": null,
"affects": {
"arch": [],
"functions": [],
"os": []
}
},
"package": {
"ecosystem": "crates.io",
"name": "azure_security_keyvault_certificates",
"purl": "pkg:cargo/azure_security_keyvault_certificates"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.0"
},
{
"fixed": "1.0.1"
},
{
"introduced": "1.1.0-beta.0"
},
{
"fixed": "1.1.0-beta.2"
}
],
"type": "SEMVER"
}
],
"versions": []
}
],
"aliases": [],
"database_specific": {
"license": "CC0-1.0"
},
"details": "Affected versions of `KeyVaultAuthorizer::on_challenge` cache the authentication\nscope from a `WWW-Authenticate` response before verifying that the challenge\nresource matches the requested endpoint. When verification rejects the challenge,\nthe scope remains cached. A subsequent request through the same client uses that\nscope to authorize the request without repeating challenge resource verification.\n\nFor `azure_security_keyvault_certificates`, the affected versions are `0.9.0`\nthrough `1.0.0`, inclusive, and `1.1.0-beta.1`. Versions before `0.9.0` do not\nuse this challenge-scope cache and are unaffected by this issue.\n\n## Impact\n\nAn application that sends requests to an attacker-controlled endpoint and reuses\nthe same client after a rejected challenge can disclose a bearer token and request\nbody to that endpoint, if its credential can obtain a token for the supplied scope.\nThe first request\u0027s validation error therefore does not prevent disclosure on a\nlater request. Changing the request origin between requests is not required.\n\n## Fix\n\nUpdate to `1.0.1` on the stable release line or `1.1.0-beta.2` on the preview\nrelease line.\n\nThe fix caches the scope only after challenge resource verification succeeds\nwhen verification is enabled. Rejected challenges no longer populate the cache.\nThe existing option to disable challenge resource verification is unchanged;\nthis fix does not add exact-origin binding.",
"id": "RUSTSEC-2026-0437",
"modified": "2026-11-05T08:50:49Z",
"published": "2026-08-24T12:00:00Z",
"references": [
{
"type": "PACKAGE",
"url": "https://crates.io/crates/azure_security_keyvault_certificates"
},
{
"type": "ADVISORY",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0437.html"
},
{
"type": "WEB",
"url": "https://github.com/Azure/azure-sdk-for-rust/pull/5121"
},
{
"type": "WEB",
"url": "https://github.com/Azure/azure-sdk-for-rust/pull/5125"
},
{
"type": "WEB",
"url": "https://github.com/Azure/azure-sdk-for-rust/pull/5410"
}
],
"related": [],
"severity": [],
"summary": "Rejected authentication challenges can poison the Key Vault scope cache"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.