Shiori
CVE-2026-61463
HIGH
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network endpoint with low complexity requires only an existing low-privilege account (PR:L) and no interaction; escalation to admin grants full confidentiality, integrity and availability, scope unchanged within the app.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
3DescriptionCVE.org
Shiori contains a privilege escalation vulnerability in the account update endpoint that allows authenticated users to modify the owner field without authorization checks. Attackers can escalate to administrator by submitting a crafted PATCH request with owner: true, then re-authenticate to obtain an admin JWT token granting full system access.
AnalysisAI
Vertical privilege escalation in Shiori (go-shiori), the self-hosted Go bookmark manager, lets any authenticated low-privilege user promote themselves to administrator. By sending a crafted PATCH request to the /api/v1/auth/account update endpoint with owner: true - a field that lacked an authorization check - the user flips their own owner flag, then re-authenticates to receive an admin JWT granting full system access. Disclosed by VulnCheck with a vendor fix committed upstream; no public exploit identified at time of analysis and it is not listed in CISA KEV.
Technical ContextAI
Shiori is a lightweight, self-hosted bookmark/read-later application written in Go (cpe:2.3:a:go-shiori:shiori). The flaw lives in HandleUpdateLoggedAccount in internal/http/handlers/api/v1/auth.go, the self-service account-update handler. It mapped a client-supplied owner boolean directly onto the account without verifying the caller's existing privilege level, a textbook CWE-269 (Improper Privilege Management) mass-assignment / missing-authorization issue. Because Shiori issues JWTs whose claims reflect the stored account role, mutating the persisted owner flag and re-logging-in yields a token minted with administrator authority. The upstream patch (commit 6c8a7dbc) adds a guard: if payload.Owner != nil && !account.IsOwner() the request is rejected with HTTP 403, restricting owner-flag changes to existing owners.
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed - upgrade to a Shiori build that includes commit 6c8a7dbc11b131609bfda736b14d61c51f9027b2, which enforces that only existing owners may change the owner flag, and consult the VulnCheck advisory (https://www.vulncheck.com/advisories/shiori-authenticated-privilege-escalation-via-patch-api-v1-auth-account) and issue https://github.com/go-shiori/shiori/issues/1196 for release status. Because an exact tagged release was not confirmed in the available data, verify the running binary actually contains the guard before relying on it. Until patched, disable open/self-service account registration so untrusted users cannot obtain the low-privilege foothold the attack requires, restrict network access to the Shiori instance to trusted users via a reverse proxy or VPN, and audit the accounts table for any non-owner accounts that have unexpectedly gained the owner flag - noting these controls limit who can reach the endpoint but do not fix the underlying missing authorization check.
Server-Side Request Forgery in Shiori's bookmark download function allows any authenticated user to force the server to
Privilege persistence in Shiori, the self-hosted bookmarks manager (go-shiori/shiori), allows a deleted or demoted owner
A lack of rate limiting in the login page of shiori v1.7.4 and below allows attackers to bypass authentication via a bru
Same weakness CWE-269 – Improper Privilege Management
View allSame technique Privilege Escalation
View allShare
External POC / Exploit Code
Leaving vuln.today