Repository navigation
Session elevation duration is unbounded, and large values silently overflow to a past timestamp #1051
Description
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:128—POST /client/:id/elevateapi/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:
$ 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:
$ 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.
Activity
jmattheis commentedon Sep 20, 2026
When the attacker has an elevated session, they can just change the password, create new admin users. Which is much more intrusive than having an unlimited elevated session.
If there was a limit to the duration, the attacker still can extend the elevation period before it expires, so I don't think adding it makes much difference.
We can probably fix the overflow with having a really high limit, but I see this as low priority.
somaz94 commentedon Sep 28, 2026
I'd like to send a PR for the overflow. Two things came up while looking at it: the OIDC callback has its own copy of the field (
pendingElevationinapi/oidc.go), and the wrap also happens on the negative side, sodurationSeconds: -9223372037elevates the client until 2319 instead of cancelling.The UI sends -1 for "Cancel elevation" and at most one year, so I'd put
binding:"required,min=-1,max=3153600000"(100 years as the high limit) on both structs and add tests for both endpoints. Would that bound work for you, or would you prefer a different one?Bound client elevation duration to prevent overflow and permanent ele…