What is the CVSS score of CVE-2026-71206?

CVE-2026-71206 has a CVSS 3.1 base score of 8.3 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L. EPSS exploitation probability: 0.2%.

Which versions of Shiori are affected by CVE-2026-71206?

Shiori bookmarks manager (all versions) contains a privilege persistence flaw allowing deleted or demoted owners to retain full administrative access for up to 30 days post-revocation through JWT…

How to fix or mitigate CVE-2026-71206?

Within 24 hours: Identify all Shiori deployments in use and audit owner account changes; retrieve and analyze authentication/access logs for any activity from revoked accounts. Within 7 days: Implement interim mitigations-restart Shiori services to force token expiration (reducing the 30-day window to hours), implement strict network access controls limiting Shiori to approved IP ranges, and enable comprehensive audit logging with export to external SIEM for real-time anomaly detection. Within 30 days: Complete a risk assessment determining whether Shiori remains acceptable for production use; if retention is required, migrate to bookmarks solutions with proper token revocation, or implement external authentication (reverse proxy with SAML/OAuth/OIDC) to enforce independent access control and session management.

Shiori CVE-2026-71206

EUVD-2026-53203 HIGH

Insufficient Session Expiration (CWE-613)

2026-08-05 TuranSec

GHSA-m8xp-ww9g-3j6j

Information Disclosure Shiori Go Shiori

8.3

CVSS 3.1 · Vendor: TuranSec

Severity by source

Vendor (TuranSec) PRIMARY

8.3 HIGH

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L

vuln.today AI

8.3 HIGH

PR:L reflects that a previously-issued owner JWT is required; AV:N and AC:L are appropriate for a straightforward token replay over HTTP with no special conditions.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (TuranSec).

CVSS VectorVendor: TuranSec

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

Low

Lifecycle Timeline

Analysis Updated

Aug 05, 2026 - 08:34 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Aug 05, 2026 - 08:22 vuln.today

cvss_changed

CVSS changed

Aug 05, 2026 - 08:22 NVD

8.2 (HIGH) 8.3 (HIGH)

Analysis Generated

Aug 05, 2026 - 07:56 vuln.today

CVE Published

Aug 05, 2026 - 06:59 cve.org

HIGH 8.2

DescriptionCVE.org

Shiori's CheckToken function (internal/domains/auth.go) validates only the JWT's HMAC signature and returns the embedded claims.Account object unmodified, never re-fetching the account from the database. No session store or token-revocation mechanism exists in the codebase. Deleting an account or demoting it from owner to a regular role has no effect on tokens already issued to that account - a deleted or demoted owner's token continues authenticating with its original owner-level privileges until natural expiry, which can be up to 30 days with 'remember me' enabled.

AnalysisAI

Privilege persistence in Shiori, the self-hosted bookmarks manager (go-shiori/shiori), allows a deleted or demoted owner to continue authenticating with full owner-level privileges for up to 30 days after account revocation. The root cause is that CheckToken in internal/domains/auth.go validates only the JWT HMAC signature and trusts the embedded claims without re-querying the database, and no token revocation or session store mechanism exists anywhere in the codebase. An attacker who previously held an owner-level account - such as a terminated employee - retains full read/write access to all bookmarks and administrative functions until the token's natural expiry. No active exploitation confirmed (no CISA KEV listing); no public exploit code identified at time of analysis.

Technical ContextAI

Shiori is a self-hosted, Go-based bookmarks manager (CPE: cpe:2.3:a:go-shiori:shiori:*:*:*:*:*:*:*:*). It uses JSON Web Tokens (JWT) for session management. The flaw maps to CWE-613 (Insufficient Session Expiration): the CheckToken function in internal/domains/auth.go validates the HMAC signature to confirm the token is cryptographically authentic but immediately returns the embedded claims.Account object as authoritative - without querying the database to confirm the account still exists or retains its current role. Because there is no server-side session store and no token blocklist or revocation endpoint, the server has no mechanism to invalidate an issued token before its TTL expires. With 'remember me' enabled, this TTL extends to 30 days. The trust boundary violation is that the JWT claim is treated as the ground truth for identity and role, while the database - the actual source of truth for account state - is never consulted post-issuance.

RemediationAI

No vendor-released patch has been identified at time of analysis - no fixed version appears in the available references or EUVD-2026-53203 data. Administrators should monitor https://github.com/go-shiori/shiori for a remediation release that introduces server-side token revocation (e.g., a token blocklist or session store) or enforces database re-validation on each authenticated request in CheckToken. As a compensating control, disabling the 'remember me' feature reduces maximum token lifetime and narrows the exploitation window, though this does not eliminate the flaw. Restricting Shiori access to trusted internal networks or VPN-only reduces exposure in the event a former user retains a token. For deployments with sensitive bookmarks, consider rotating the JWT signing secret (HMAC key) when revoking an owner account - this invalidates all previously issued tokens system-wide but also forces all current users to re-authenticate. Note that the signing-key rotation approach is a blunt instrument with operational impact. A true fix requires implementing server-side session tracking or per-request database role verification in the application code.