SveltyCMS EUVD-2026-82904

Exploitation requires an authenticated low-privilege account (PR:L) that can reach the User Attribute Update Endpoint at src/routes/api/[...path]/+server.ts on a SveltyCMS 0.0.6 instance; the attack works remotely over the network with no user interaction. The specific precondition is that the endpoint accepted privileged attributes (role/isAdmin/roleIds/permissions) from a client-supplied profile update body and did not restrict non-admins to updating only their own record. Limiting factors: the attacker must already possess valid credentials, and the product is a pre-release version with essentially no production deployment; there is no unauthenticated path.

This is a genuine authorization flaw (CWE-284) but its real-world priority is low, driven almost entirely by the affected product rather than the bug class. The vendor/VulDB CVSS 4.0 vector is 5.3 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L) - network-reachable, low complexity, but requiring low-privilege authentication and rated only limited impact across confidentiality/integrity/availability. The source-code evidence tells a more serious story than the 'limited' impact suggests: the patch and the added AGENTS.md hardening rules ('Never accept role/isAdmin/permissions/lockout/2FA secrets from client profile bodies... Non-admins may only update self') indicate the User Attribute Update Endpoint accepted privileged fields via mass-assignment, meaning a non-admin could potentially set isAdmin/role/permissions and escalate to full administrator - which would justify HIGH impact, not the LOW the vendor assigned. This is a conflict worth noting: vendor scored VC:L/VI:L/VA:L, but the fix strips role/isAdmin/roleIds/permissions and adds an allowPrivilegeEscalation fail-closed guard, consistent with privilege escalation. No EPSS score, no CISA KEV listing, and no public exploit were provided; VulDB is the sole reporting source. Netting these signals: the technical severity may be understated, but exploitation requires an existing authenticated account on a specific pre-release CMS with negligible deployment, so this is not a widespread emergency - patch on normal cadence.

An attacker who holds any low-privilege authenticated account on a SveltyCMS 0.0.6 instance sends a crafted profile/user-attribute update request to src/routes/api/[...path]/+server.ts including privileged fields (e.g. role, isAdmin, permissions) that the endpoint failed to strip. Because non-admin updates were not restricted to self and privileged fields were accepted from the client body, the attacker escalates their own privileges toward administrator. No public exploit code was identified, but the fix commit and its accompanying security notes clearly describe the mass-assignment/privilege-field acceptance being closed.