- Exploited
- No known exploitation
- Fix
- Fixed in 1.0.1, 1.1.0-beta.2
- Who is exposed
- Not reported
Do first: Upgrade to a fixed version: 1.0.1, 1.1.0-beta.2.
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 10/100 · provisional
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Affected versions of azure_security_keyvault_certificates cache an authentication scope from a rejected challenge, so a later request through the same client can disclose a bearer token and request body to an attacker-controlled endpoint if the credential can obtain a token for that scope. The first request's validation error does not stop this later disclosure.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
Read the original description
Affected 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.
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure?/25Unknown. No advisory context yet
- Reach10/20Affects crates.io packages
- Severity?/10Unknown. No CVSS score or vendor rating
- No patch0/5No signal
What would change the score
- Would score about 65 if added to CISA KEV
- Would score about 60 if CISA's SSVC rates exploitation active
- Would score about 32 if advisories confirm default setups are exposed
What to do
Upgrade to a fixed version: 1.0.1, 1.1.0-beta.2.
Timeline
- Advisory published73 days
- Record last updated
Affected versions
- azure_security_keyvault_certificatescrates.io
From 0.9.0 · fixed in 1.0.1; From 1.1.0-beta.0 · fixed in 1.1.0-beta.2
Evidence 5
- Advisory
- Repository
- Repository
- Repository
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about RUSTSEC-2026-0437
Is RUSTSEC-2026-0437 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
Which versions are affected by RUSTSEC-2026-0437?
azure_security_keyvault_certificates (crates.io): from 0.9.0 before 1.0.1; from 1.1.0-beta.0 before 1.1.0-beta.2.Source: cve.now feed data
How do I fix RUSTSEC-2026-0437?
Upgrade to a fixed version: 1.0.1, 1.1.0-beta.2.Source: cve.now feed data