diff --git a/crates/auth-framework/RUSTSEC-0000-0000.md b/crates/auth-framework/RUSTSEC-0000-0000.md
new file mode 100644
index 0000000000..851278fd5d
--- /dev/null
+++ b/crates/auth-framework/RUSTSEC-0000-0000.md
@@ -0,0 +1,21 @@
+```toml
+[advisory]
+id = "RUSTSEC-0000-0000"
+package = "auth-framework"
+date = "2026-10-04"
+categories = ["privilege-escalation"]
+keywords = ["oauth2", "token-revocation", "refresh-token", "api-server"]
+aliases = ["GHSA-rf2h-7m78-hhjm"]
+
+[versions]
+patched = [">= 0.4.30, < 0.5.0-rc1", ">= 0.5.0-rc26, < 0.6.0-rc1", ">= 0.6.0-rc41"]
+unaffected = ["< 0.4.0"]
+```
+
+# Revoking an OAuth2 refresh token does not prevent it from minting new access tokens
+
+Revoking an OAuth2 refresh token through `POST /oauth/revoke` (feature `api-server`) has no effect on that token's ability to mint new access tokens, so a compromised or intentionally revoked refresh token keeps working.
+
+On the 0.5 line the revoke handler stores a revocation marker but never deletes the refresh-token record, and `handle_refresh_token_grant` never checks the marker. On 0.4.x the handlers `revoke_token` and `handle_refresh_token_grant` in `src/api/oauth.rs` are unimplemented stubs (explicit `// In a real implementation` comments), so revocation is a no-op and the refresh grant does not validate the token, giving the same user-visible defect.
+
+Affected: every published 0.4.x version (0.4.0 up to 0.4.29) and 0.5.0-rc1 up to 0.5.0-rc25. Fixed in 0.5.0-rc26 (per the GHSA patched version); 0.4.30 is not affected: in its published source the OAuth2 handlers of `api::oauth` (including `revoke_token`) answer HTTP 501 Not Implemented and the refresh grant is gone, so no 0.4.x refresh token can mint access tokens there; the GHSA itself records no patched 0.4.x version. No workaround short of a code change is known.