EUVD-2026-96906
GHSA-4f43-5hgr-4m7r
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege read-only user
-
DeliveryCraft form-encoded POST to /user/pref
-
ExploitInject user.access[all]=* and user.email_verified=true
-
ExecutionBypass readonly field tags via mass assignment
-
ImpactGain persistent superuser/admin access
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V4 - API and Web Service Object attribute protection
|
| Exploitation Conditions | Requires a valid authenticated session on the target GoatCounter instance - even an account limited to read-only access is sufficient (PR:L), so fully anonymous exploitation is NOT possible. The specific trigger is a form-encoded HTTP POST to the /user/pref endpoint supplying the protected fields user.access[all]=* (to grant superuser/all-site access) and user.email_verified=true, which the userPrefSave handler mass-assigns despite readonly tags. Affects default configurations of all versions through 2.7.0; the principal limiting factor is that the attacker must already be able to register or obtain a low-privilege account, making shared/multi-tenant deployments the realistic risk surface. |
| Impact | This is a credible, actionable privilege-escalation flaw but not a mass-exploitation emergency. The CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N) confirms a network-reachable, low-complexity attack requiring only low privileges - any authenticated user, even one holding read-only access, can escalate to superuser/admin, which is a severe trust-boundary violation (CWE-915 mass assignment). The vendor-supplied impact rates confidentiality as Low (VC:L) while integrity and availability are High (VI:H/VA:H); this is arguably conservative, since gaining superuser typically also exposes all sites' analytics data, so real confidentiality impact may be higher than the published vector suggests - verify against the actual admin capabilities of your deployment. No EPSS score, SSVC decision, or CISA KEV status was provided in the input, so probabilistic exploitation likelihood cannot be quantified. There is no KEV listing and no explicit POC flag, but a public hackMD technical writeup documents the exact exploit request, which materially lowers the bar for opportunistic abuse. The key limiting factor is PR:L: the attacker must already hold a valid (even if read-only) account on the target instance, making this most relevant to multi-tenant or shared GoatCounter deployments rather than single-operator installs. Net: prioritize patching on any instance where untrusted or low-trust users can register, but it is not a wormable internet-wide threat. |
| Exploit ScenarioDerived | An attacker who has been granted only read-only access to a shared GoatCounter instance sends a single form-encoded POST to /user/pref containing user.access[all]=* and user.email_verified=true. The userPrefSave handler binds these attacker-controlled fields despite their readonly tags, silently promoting the account to superuser/admin. A public hackMD writeup documents the exact payload, so no original exploit development is needed; the network, low-complexity vector means the request succeeds in one step once authenticated. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 11, 2026
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.
RemediationAI
No vendor-released fixed version was identified at time of analysis, so the immediate priority is compensating control rather than a version pin: upgrade to the first GoatCounter release published after 2.7.0 as soon as upstream tags one, and until then treat the readonly tags as non-enforcing. Because the trigger is a form-encoded POST to /user/pref carrying user.access[all] or user.email_verified, the most direct mitigation is a reverse-proxy or WAF rule that rejects requests to /user/pref whose bodies contain "user.access[" or "user.email_verified"; the trade-off is that this blocks only these parameter names (legitimate profile edits using other fields continue to work, and no legitimate user flow requires setting either field). Where feasible, disable open self-registration or gate account creation to trusted operators, which removes the low-privilege foothold the attack requires, at the cost of onboarding friction. Auditing existing accounts for unexpected superuser/all-site access or forced email_verified flags is advisable so any pre-existing abuse is detected, and if you build from source, patch the userPrefSave handler to use an explicit allowlist of assignable fields (dropping access, email_verified, and other privileged attributes from the bind step) - a code fix requires rebuilding and redeploying the application and must be re-applied on each upstream update. Monitor web logs for POST /user/pref requests containing access[all] as a detection signal. Reference material: https://www.vulncheck.com/advisories/goatcounter-through-2.7.0-privilege-escalation-via-user-pref-mass-assignment and https://hackmd.io/@haind03/goatcounter-user-pref-access-mass-assignment-20261011.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
GoatCounter is a Go-based web analytics application; the flaw is CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes), i.e. classic mass assignment. In the vulnerable code paths referenced by the advisory (handlers/settings_user.go lines 33-99 and user.go lines 191-218), the userPrefSave handler accepts form-encoded input and binds submitted parameter names directly onto user-model fields. The model marks sensitive attributes such as access and email_verified with readonly semantics, but the handler's binding step does not enforce an allowlist, so an attacker-supplied parameter named user.access[all]=* is written to the same field the application itself uses to represent all-site/superuser privileges, and user.email_verified=true flips the account verification flag. Any Go web application that auto-binds request parameters to persistent models without an explicit assignable-field allowlist is exposed to this class of bug; the mitigating factor here is the attacker's need for an existing authenticated session, and the aggravating factor is that the escalation target (superuser over all sites) makes the flaw directly useful for lateral movement across tenants in a shared deployment.
Know when Goatcounter gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N
Network-reachable endpoint, no special conditions beyond a low-privilege login (PR:L), no user interaction; escalation to superuser yields full read, modify, and delete control, so C/I/A all High.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
GoatCounter through 2.7.0 contains a mass assignment privilege escalation vulnerability in the userPrefSave handler that allows logged-in users to modify protected account fields via form-encoded requests. Attackers with read-only access can POST user.access[all]=* and user.email_verified=true to /user/pref, bypassing readonly tags to gain superuser or admin access.
Executive ViewAI
GoatCounter versions through 2.7.0 contain a privilege escalation flaw that allows any authenticated user, even those with read-only access, to promote their account to superuser. This poses the greatest risk to shared, hosted, or multi-tenant deployments where untrusted parties can self-register, as a malicious user could gain full administrative control over analytics data and instance configuration. Leadership should prioritize remediation for externally accessible instances, though no public exploit code has been identified at this time.
No vendor-released patch identified at time of analysis. Restrict or disable public registration, audit accounts for unauthorized privilege changes, block or monitor POST requests to /user/pref with suspicious parameters, and enforce network-level access controls. Apply vendor patch when available.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
Exploit-DB