Goatcounter
Monthly
Privilege escalation in GoatCounter through 2.7.0 lets an authenticated user - even one holding only read-only access - promote their own account to superuser by sending a form-encoded POST to /user/pref containing protected fields such as user.access[all]=* and user.email_verified=true, which the userPrefSave handler mass-assigns despite its readonly tags. Because the attacker must already hold a valid low-privilege account (PR:L in both the CVSS 4.0 vector and our assessed CVSS 3.1 vector), the realistic exposure is shared, hosted, or multi-tenant instances where registration or account provisioning is available to untrusted parties; fully anonymous exploitation is not possible. No public exploit code was identified at time of analysis and there is no confirmed vendor-released fix version, so operators should treat this as a credible, actionable escalation flaw rather than a mass-exploitation emergency.
Privilege escalation in GoatCounter through 2.7.0 lets an authenticated user - even one holding only read-only access - promote their own account to superuser by sending a form-encoded POST to /user/pref containing protected fields such as user.access[all]=* and user.email_verified=true, which the userPrefSave handler mass-assigns despite its readonly tags. Because the attacker must already hold a valid low-privilege account (PR:L in both the CVSS 4.0 vector and our assessed CVSS 3.1 vector), the realistic exposure is shared, hosted, or multi-tenant instances where registration or account provisioning is available to untrusted parties; fully anonymous exploitation is not possible. No public exploit code was identified at time of analysis and there is no confirmed vendor-released fix version, so operators should treat this as a credible, actionable escalation flaw rather than a mass-exploitation emergency.