GPU VulnDB

Database/Control plane, storage & DevOps

OneUptime: password reset tokens written to INFO logs allow account takeover from log access

CVSS 6.9CVE-2026-32598Control plane, storage & DevOpscurated

Impact

OneUptime's password reset flow logs the full reset URL, including the plaintext token, at INFO level - which is on by default in production. Anyone who can read the application's logs can take over any account, including administrative ones. For an operator this inverts the usual trust direction: log aggregation, Docker logs and Kubernetes pod logs are typically readable by a much wider group (SRE, on-call, anyone with kubectl logs on the namespace, anyone querying the log backend) than the monitoring platform's own admin role. Taking over the monitoring and status-page system means altering alerting and on-call routing for the fleet, so the cluster can be made to look healthy while it is not.

Who can reach it

Any principal able to read OneUptime's application logs - log aggregation search, docker logs, kubectl logs on the pod - combined with triggering a password reset for the target account. No OneUptime credentials needed.

What to do

Upgrade OneUptime to 10.0.24 or later and restart/redeploy the containers; this is an application-level update, no node drain involved. Because tokens already sitting in retained logs stay valid until they expire, also purge or restrict access to historical logs containing reset URLs, force a password reset for privileged accounts, and tighten who can read the log backend.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.