Revoking an API key does not invalidate the dashboard sessions minted from it #60

New issue

Open

opened 2026-10-26 15:38:26 +00:00 by james.oates · 0 comments

james.oates commented

2026-10-26 15:38:26 +00:00

Owner

From the v2.0.0 security audit.

src/session.rs stores only created_at/expires_at per session. There is no link to the key that created it, validate never re-checks the database, and remove() is called only from destroy_session.

So: a key leaks, an attacker POSTs it to /api/session and gets a cookie, the operator revokes the key with DELETE /api/keys/<id>. X-API-Key auth stops immediately — but the attacker's cookie keeps full admin access for up to the 12-hour absolute deadline, sliding on every use. There is no session-list or session-kill API, so the only revocation is restarting the process.

A master-key change does clear sessions, because it only happens at startup and the store is in memory. Revoking a service key does not.

Fix

Record the key id on the session and have validate reject a session whose key is revoked or gone. That is a DB read per authenticated dashboard request, which is consistent with how access rules are already read per request deliberately.

A session-kill endpoint would be the fuller answer but is a feature rather than a fix.

Until it is fixed this is worth a line in the release notes: revoking a key does not end dashboard sessions already established with it; restart ER if that matters.

From the v2.0.0 security audit. `src/session.rs` stores only `created_at`/`expires_at` per session. There is no link to the key that created it, `validate` never re-checks the database, and `remove()` is called only from `destroy_session`. So: a key leaks, an attacker POSTs it to `/api/session` and gets a cookie, the operator revokes the key with `DELETE /api/keys/<id>`. `X-API-Key` auth stops immediately — but the attacker's cookie keeps full admin access for up to the 12-hour absolute deadline, sliding on every use. There is no session-list or session-kill API, so the only revocation is restarting the process. A master-key *change* does clear sessions, because it only happens at startup and the store is in memory. Revoking a service key does not. ## Fix Record the key id on the session and have `validate` reject a session whose key is revoked or gone. That is a DB read per authenticated dashboard request, which is consistent with how access rules are already read per request deliberately. A session-kill endpoint would be the fuller answer but is a feature rather than a fix. Until it is fixed this is worth a line in the release notes: revoking a key does not end dashboard sessions already established with it; restart ER if that matters.

james.oates referenced this issue from a commit

2026-10-26 16:20:40 +00:00

docs: bring the README and CLAUDE.md up to the current build

james.oates added this to the v2.1 milestone

2026-10-26 17:53:26 +00:00

james.oates referenced this issue

2026-10-26 17:53:55 +00:00

The WebSocket path has no connect timeout, no idle timeout and no connection cap #62