Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
53 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
When a user account is disabled or locked, the status check is only enforced on the local login and JWT token refresh paths. Three other authentication paths — API tokens, CalDAV basic auth, and OpenID Connect — do not verify user status, allowing disabled or locked users to continue accessing the API and syncing data. Details User status (StatusDisabled, StatusAccountLocked) is checked in only two places: 1. Local/LDAP login (pkg/routes/api/v1/login.go:74) — prevents issuing new JWTs 2. JWT token refresh (pkg/routes/api/v1/login.go:247) — prevents refreshing expired JWTs Three other authentication paths fetch the user from the database via GetUserByID but never inspect the returned user's status: 1. API Token Authentication (pkg/routes/apitokens.go:76-103) API tokens are long-lived (up to years) and have no refresh cycle. A disabled user's API tokens remain fully functional until they expire naturally. 2. CalDAV Basic Auth (pkg/routes/caldav/auth.go) The CalDAV basic auth…
Recommended action: Upgrade to 2.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
- Vulnerability: Unbounded image decoding and resizing during preview generation lets an attacker exhaust CPU and memory with highly compressed but extremely large-dimension images. - Affected code: - Decoding without bounds: taskattachment.go:GetPreview - Resizing path: resizeImage - Endpoint invoking preview: GetTaskAttachment - Impact: First preview generation per attachment can allocate large memory and spend significant CPU; multiple attachments or concurrent requests can degrade or crash the service. - CVSS v3.1: 7.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) Preconditions - API running locally (http://localhost:8080). - Task attachments enabled: taskattachmentsenabled=true in Info. - Any authenticated user with write access to a task. How It Works - Preview generation decodes the full image via image.Decode and resizes to a target width. There are no guards on width/height or total pixels. A 10,000×10,000 PNG (~284 KB on disk) expands to ~100M pixels in memory during decode…
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The DELETE /api/v1/projects/:project/background endpoint checks CanRead permission instead of CanUpdate, allowing any user with read-only access to a project to permanently delete its background image. Details The RemoveProjectBackground handler (pkg/modules/background/handler/background.go) reuses checkProjectBackgroundRights, a helper originally written for the read-only GetProjectBackground endpoint. This helper only verifies CanRead permission. In contrast, the handler for setting a background (setBackgroundPreparations) correctly checks CanUpdate. As a result, destructive write operations (deleting the background file from storage and clearing the project's backgroundfileid and backgroundblurhash fields) are gated behind a read-only permission check. Impact A user with read-only access to a project — via direct sharing, team membership, link share tokens with read permission, or read-scoped API tokens — can permanently delete the project's background image. The…
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.