#1051·server

Session elevation duration is unbounded, and large values silently overflow to a past timestamp

Author: lbellowsCreated Sep 17, 2026Updated Sep 17, 2026

ElevateRequest.DurationSeconds (model/elevate.go) is only validated as non-zero, and both elevation paths multiply it straight into a time.Duration:

  • api/client.go:128POST /client/:id/elevate
  • api/oidc.go:186 — the OIDC elevation callback

Two consequences, both reproduced on v3.1.1:

1. Elevation can be made effectively permanent. One call turns the hour-long elevation from login into a century:

bash
$ curl -s -o /dev/null -w '%{http_code}\n' -X POST localhost:8791/client/1/elevate \
    -H "X-Gotify-Key: $TOK" -H 'Content-Type: application/json' -d '{"durationSeconds":3153600000}'
204
$ curl -s localhost:8791/current/user -H "X-Gotify-Key: $TOK"
{"id":1,...,"elevatedUntil":"2126-08-23T23:11:49.409030064-04:00"}

The caller must already be elevated, so this is not a privilege jump on its own — but it means a single moment of elevation (or a token stolen inside the hour after login) yields a session that never needs basic auth again, which is the opposite of what elevation is for. The UI has no way to show or revoke "elevated until 2126" other than deleting the client.

2. Large values silently overflow instead of erroring. time.Duration(DurationSeconds) * time.Second wraps for anything past ~292 years:

bash
$ curl -s -o /dev/null -w '%{http_code}\n' -X POST localhost:8791/client/1/elevate \
    -H "X-Gotify-Key: $TOK" -H 'Content-Type: application/json' -d '{"durationSeconds":9223372036854775807}'
204
$ curl -s localhost:8791/current/user -H "X-Gotify-Key: $TOK"
{"id":1,...}        # elevatedUntil now in the past — 204, but elevation silently dropped

Suggestion: clamp durationSeconds with a binding:"min=1,max=…" tag (model.DefaultElevationDuration, or some multiple of it, seems like the natural ceiling) so both the century case and the overflow case become a 400.