src/auth/device_grant.rs: POST /v1/auth/device/code (:293) inserts a grant into the pending map with an expires_at (:33-51), and expiry is only checked on lookup (410 expired_token, ~:774, :936). Nothing retains/prunes expired entries, so the map only grows over the node's uptime. Not an exploit on its own (no auth is expected on the code-request leg of a device flow), but a long-lived node accumulates every code ever requested.
Ask: prune expired grants (on insert, or a periodic sweep), and cap pending grants per client_id.
Found by CIRISClient's identity-group review (CSD-055).
🤖 Generated with Claude Code
src/auth/device_grant.rs:POST /v1/auth/device/code(:293) inserts a grant into the pending map with an:33-51), and expiry is only checked on lookup (410expires_at(expired_token, ~:774, :936). Nothing retains/prunes expired entries, so the map only grows over the node's uptime. Not an exploit on its own (no auth is expected on the code-request leg of a device flow), but a long-lived node accumulates every code ever requested.Ask: prune expired grants (on insert, or a periodic sweep), and cap pending grants per
client_id.Found by CIRISClient's identity-group review (CSD-055).
🤖 Generated with Claude Code