
Cloud Vulnerability DB
A community-led vulnerabilities database
OAuth2 client secrets were stored in plaintext by dynamic client registration.
confidentiality of client secrets at rest. Not a remote read; the exposure needs access to the storage backend.
auth-framework >= 0.5.0-rc18, <= 0.5.0-rc65; >= 0.6.0-rc41, <= 0.6.0-rc150. PATCHED VERSIONS: 0.5.0-rc70 (PR #320) and 0.6.0-rc158 (PR #318); the final releases that carry them are 0.5.0-rc71 and 0.6.0-rc159.
Reasoning: the secret is exposed only to someone who can already read the configured storage backend (database dump, backup, replica, an over-broad read role), so AV:L/PR:H; no remote read path was found. The consequence of that exposure is full: every registered confidential client's secret is in the clear, and holding it lets the holder authenticate as that client. Deployments that keep clients in a store readable by more people than the application itself are hit hardest.
Reachability: POST /oauth/register (RFC 7591, route in src/api/server.rs) generates the secret and stores it. It requires a Bearer token with the admin role or the Initial Access Token stored at oauth2_initial_access_token (checked in register_client, src/api/oauth2.rs), so an anonymous caller cannot register a client; the exposure is the stored secrets, not the endpoint. Clients seeded straight into the KV store by an operator are stored however the operator wrote them.
Not affected: all 0.4.x (no src/api/oauth2.rs, no oauth2_client: key; 0.4.43 included), 0.5.0-rc1.
Measured set (47 of the 71 published .crate files; census API total 71, 71 fetched): 0.5.0-rc18, 19, 25, 26, 27, 31, 45, 49, 51, 53, 60, 62, 63, 65; 0.6.0-rc41, 42, 45, 46, 47, 48, 50, 51, 52, 53, 54, 55, 69, 73, 85, 92, 97, 98, 101, 104, 106, 107, 109, 112, 114, 121, 126, 127, 128, 129, 131, 138, 150.
Method: searched src/api/oauth2.rs of each tarball for the line "client_secret": client_secret, in the registration handler and for the oauth2_client: key, and src/api/oauth_advanced.rs for the read of client_data["client_secret"]. Controls: the other 24 tarballs lack src/api/oauth2.rs (22 yanked 0.1-0.4.x, 0.4.43) or lack the pattern (0.5.0-rc1); the same pattern is present at origin/main 5da66c46 line 1761-1774.
first published fixed versions 0.5.0-rc71 and 0.6.0-rc159 (the change itself: 0.5.0-rc70, PR #320, and 0.6.0-rc158, PR #318): the client secret is stored only as an Argon2id hash; a record that still holds a plain client_secret is accepted on that client's first successful authentication and rewritten with a hash.
0.5.0-rc65 and 0.6.0-rc150 are the only live affected versions and are yanked; the other affected versions were yanked earlier. First published fixed versions: 0.5.0-rc71 (tag v0.5.0-rc71) and 0.6.0-rc159 (tag v0.6.0-rc159).
none for affected versions short of rotating every client secret after upgrading. After upgrading, an existing plaintext secret stays in storage until that client next authenticates; rotate secrets of clients that do not authenticate often, and treat any backup taken before the upgrade as holding the plaintext secrets. Credits: none (the issue was reported publicly as #90 on 2026-10-03).
Source: NVD
Free Vulnerability Assessment
Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.
Get a personalized demo
"Best User Experience I have ever seen, provides full visibility to cloud workloads."
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
"We know that if Wiz identifies something as critical, it actually is."