CVE-2026-61463: Shiori Privilege Escalation Vulnerability

CVE-2026-61463 Overview

CVE-2026-61463 is a privilege escalation vulnerability in Shiori, an open-source self-hosted bookmarks manager written in Go. The flaw resides in the account update endpoint PATCH /api/v1/auth/account, which failed to enforce authorization checks on the owner field. Any authenticated user can submit a crafted request setting owner: true on their own account. After re-authenticating, the attacker receives a JSON Web Token (JWT) with owner privileges, granting full administrative access to the Shiori instance. The issue is tracked under CWE-269: Improper Privilege Management.

Critical Impact
Any authenticated Shiori user can escalate to owner (administrator) with a single PATCH request, gaining full control over bookmarks, accounts, and system configuration.

Affected Products

Shiori bookmarks manager (go-shiori/shiori) — versions prior to the commit 6c8a7dbc11b131609bfda736b14d61c51f9027b2
Deployments exposing the /api/v1/auth/account endpoint to authenticated users
Self-hosted Shiori instances that permit user registration or multi-user access

Discovery Timeline

2026-07-13 - CVE-2026-61463 published to the National Vulnerability Database
2026-07-13 - Last updated in NVD database

Technical Details for CVE-2026-61463

Vulnerability Analysis

Shiori exposes a self-service account update endpoint at PATCH /api/v1/auth/account that lets authenticated users modify attributes of their own account, such as password and configuration preferences. The handler in internal/http/handlers/api/v1/auth.go deserialized the incoming payload and applied fields directly to the caller's account record.

The payload structure includes an Owner boolean field. The handler did not verify whether the requesting account already held owner status before applying that field. As a result, a standard authenticated user could set their own owner flag to true. After re-authenticating, the newly issued JWT reflected owner privileges, permitting administrative actions such as creating, deleting, and modifying other accounts.

Root Cause

The root cause is a missing authorization check on a privileged attribute inside a self-service endpoint [CWE-269]. The handler conflated authentication with authorization: possession of a valid session was treated as sufficient to modify every field, including the field that determines administrative status.

Attack Vector

Exploitation requires only low-privileged authenticated access. The attacker sends a PATCH request to /api/v1/auth/account with a JSON body containing "owner": true, then obtains a new token via the standard login endpoint. No user interaction or additional privileges are required. Because the flow uses the application's own API contract, the request appears legitimate in standard access logs.

// Security patch in internal/http/handlers/api/v1/auth.go
// fix: prevent users from self-escalate to owners (#1199)

	account := c.GetAccount()

+	// Only owners are allowed to change the owner flag. Without this check any
+	// authenticated user could escalate their own privileges to administrator
+	// through this self-service endpoint.
+	if payload.Owner != nil && !account.IsOwner() {
+		response.SendError(c, http.StatusForbidden, "Only owners can change the owner status")
+		return
+	}
+
	if payload.NewPassword != "" {
		_, err := deps.Domains().Auth().GetAccountFromCredentials(c.Request().Context(), account.Username, payload.OldPassword)
		if err != nil {

Source: go-shiori/shiori commit 6c8a7db

Detection Methods for CVE-2026-61463

Indicators of Compromise

HTTP PATCH requests to /api/v1/auth/account containing the JSON field "owner": true in the request body.
Login events immediately followed by JWT issuance where the account's owner flag changed within the preceding minutes.
Unexpected accounts appearing in the Shiori owners list, or existing non-admin accounts suddenly performing owner-only administrative actions.

Detection Strategies

Enable request body logging on the reverse proxy in front of Shiori and alert on PATCH requests to /api/v1/auth/account that include the owner key.
Query the Shiori database periodically for accounts with the owner flag set and reconcile against an approved list of administrators.
Correlate account modification events with subsequent authentication events from the same source IP within a short time window.

Monitoring Recommendations

Forward Shiori application logs and reverse proxy access logs to a centralized logging platform for retention and query.
Monitor for administrative actions (user creation, deletion, or configuration changes) originating from accounts that were recently modified.
Track anomalous patterns in /api/v1/auth/login calls that follow account update requests from the same session or IP.

How to Mitigate CVE-2026-61463

Immediate Actions Required

Update Shiori to a build that includes commit 6c8a7dbc11b131609bfda736b14d61c51f9027b2 or later.
Audit all accounts in the Shiori database and revoke owner status from any account not explicitly authorized as an administrator.
Invalidate existing JWT sessions by rotating the signing secret and forcing all users to re-authenticate.
Review reverse proxy and application logs for prior PATCH requests to /api/v1/auth/account containing the owner field.

Patch Information

The fix was committed upstream to the go-shiori/shiori repository. The patch introduces an authorization check that rejects requests with a 403 Forbidden response when a non-owner account attempts to modify the owner field. Details are available in the GitHub commit, the GitHub issue tracker, and the VulnCheck Security Advisory.

Workarounds

Restrict access to the /api/v1/auth/account endpoint at the reverse proxy layer, blocking PATCH requests that contain the substring "owner" in the JSON body until the patch is applied.
Disable public account registration and limit Shiori access to trusted users only.
Place Shiori behind an authenticating reverse proxy or VPN to reduce the pool of potential attackers.

bash

# Example nginx snippet to block PATCH requests containing an owner field
location /api/v1/auth/account {
    if ($request_method = PATCH) {
        access_by_lua_block {
            ngx.req.read_body()
            local body = ngx.req.get_body_data() or ""
            if body:find('"owner"') then
                ngx.exit(403)
            end
        }
    }
    proxy_pass http://shiori_backend;
}