Just published.

OpenAM from 14.5.1 before 16.1.4 contains a cross-site request forgery vulnerability in the OAuth 2.0 device authorization flow that allows attackers to approve device codes when consent is skipped for implied-consent clients. Attackers can start a device authorization and lure a logged-in user to a crafted page, obtaining access and ID tokens to call APIs as that user.

Auth & access

OpenAM before 16.1.4 contains an open redirect and cross-site scripting vulnerability that allows remote attackers to control post-login and logout destinations via the goto and gotoOnFail parameters. Attackers can craft OpenAM login or logout links that redirect victims to phishing sites or run script in the XUI to steal session cookies.

XSS Web app

OpenAM before 16.1.4 contains an open redirect vulnerability that allows attackers to redirect users to external sites because RelayState is unchecked when no relayStateUrlList is configured. Attackers can craft single sign-on links with a malicious RelayState to send users from the trusted OpenAM origin to phishing sites and bypass URL filters.

Other Web app

OpenAM before 16.1.4 contains a server-side request forgery vulnerability that allows administrators, including delegated realm administrators, to make the server fetch arbitrary URLs through federation configuration wizard metadata URLs. Attackers can enter metadata or OpenID Connect discovery URLs pointing to internal hosts or cloud metadata endpoints to probe the internal network and read partial responses.

Disclosure Server

OpenAM before 16.1.4 contains a server-side request forgery vulnerability that allows parties registering UMA resource sets to trigger internal requests through unvalidated scope description URLs. Attackers can register resource sets with scope URLs pointing to internal hosts or cloud metadata endpoints, which OpenAM fetches when sending pending-request notification emails, enabling internal network probing.

Disclosure Server

OpenAM before 16.1.4 does not verify that a signed SAML 1.x assertion or response was signed by the partner named as its issuer, accepting a signature from any certificate in OpenAM's keystore. An attacker holding such a private key, such as a trusted SAML 1.x partner, can forge assertions claiming another partner's issuer and sign in as that partner's users, including privileged ones.

Crypto

OpenAM before 16.1.4 contains a stored cross-site scripting vulnerability that allows privileged attackers to inject script by placing markup in a user's display name. When the victim reaches the OAuth 2.0 / OpenID Connect consent page, the unencoded name executes script that can steal the OpenAM session cookie to impersonate the user.

XSS Web app

OpenAM before 16.1.4 contains an incomplete output encoding vulnerability that allows a SAML 1.x identity provider to alter attribute values by injecting unencoded content into the service provider auto-submitted form. Attackers controlling a trusted identity provider can craft assertion attribute names or values that reach the target application in modified form, undermining the integrity of received attributes.

Other

OpenAM before 16.1.4 contains an open redirect vulnerability that allows remote attackers to redirect users after SAML 1.x single sign-on by exploiting loose trusted-partner destination matching. Attackers can craft links to /SAMLAwareServlet or /SAMLPOSTProfileServlet with a destination host resembling a trusted partner to send authenticated users to attacker-controlled phishing sites.

Other Web app

Vikunja before 2.7.1 contains a missing authentication vulnerability that allows attackers holding a stolen session to enroll and enable TOTP without the account password. Attackers can call the TOTP enroll and enable endpoints with their own secret to lock the owner out, persisting even after password reset.

Auth & access

Vikunja from 1.0.0 before 2.7.1 contains an uncontrolled resource consumption vulnerability that allows authenticated users to bypass service.maxitemsperpage by sending page=0 to /api/v1 list endpoints. Attackers can self-register and repeatedly request page=0 to force unbounded SQL queries, memory materialisation, and per-row query fan-out, degrading availability for other users.

Denial of service Web app

gix-fs in gitoxide before 0.24.1 contains a credential disclosure vulnerability that allows remote attackers to capture NTLM credentials by supplying UNC symlink targets in a crafted repository. When a victim checks out the repository on Windows with symlinks enabled, gix_fs::symlink::create calls is_dir() on the UNC target, triggering SMB authentication that leaks the username, domain, and NTLMv2 hash.

Other

gix-commitgraph before 0.42.0, as used in gitoxide before 0.61.0, contains a denial of service vulnerability because its commit-graph parser does not validate parent graph positions against the declared commit count or check the EDGE chunk length for 4-byte alignment. Attackers can supply a repository containing a crafted .git/objects/info/commit-graph file to trigger panics that abort gix merge-base, gix blame, and applications embedding gix.

Denial of service Library

Tornado before 6.6 contains a path traversal vulnerability in RequestHandler.static_url() and get_version() that allows attackers to hash files outside static_path using ../ sequences. Attackers controlling input passed to static_url() can obtain SHA-512 hashes of readable files to confirm their existence, or reference /dev/zero to block the event loop indefinitely.

Disclosure Web app

Tornado before 6.6 does not validate the max_age argument of RequestHandler.set_cookie (also called by set_signed_cookie, set_secure_cookie, and clear_cookie), allowing injection of additional Set-Cookie attributes. When an application passes attacker-influenced input as max_age, an attacker can embed attributes such as Domain, Path, or Secure to widen the cookie's scope to parent paths or other subdomains.

Injection Web app

Vikunja before 2.7.1 allocates memory without limits in its Trello, Todoist and Microsoft To Do migration importers, which buffer remote attachment downloads and API responses in memory without size caps. Authenticated users can start a migration that references huge attacker-served attachments or yields oversized API responses, exhausting memory and crashing the shared API process for all tenants.

Denial of service

Vikunja before 2.7.1 contains a mass assignment vulnerability that allows any authenticated user to set the read-only external_id field through the team create and update endpoints. Attackers can tag a team they create or administer as externally managed, permanently blocking removal of every member and causing SSO members to be dropped from the team at their next login.

Other Web app

Vikunja from 2.4.0 before 2.7.1 contains an authorization bypass vulnerability that allows token holders to perform unintended operations due to colliding v1 and v2 API token permission keys. Attackers with a token scoped to read project backgrounds can delete them via the v2 DELETE background route, and bucket create-only tokens can update existing buckets.

Auth & access

Vikunja before 2.7.1 contains an insufficient session expiration vulnerability that allows holders of revoked access tokens to keep authenticating because SetupTokenMiddleware skips session and account-status checks. Attackers with a stolen token can, after logout, password reset, or account disabling, mint OAuth sessions via /oauth/authorize or tk_ API tokens for persistent access.

Auth & access Web app

Vikunja before 2.7.1 contains a stored CSS injection vulnerability that allows authenticated users with project write access to inject arbitrary CSS via unsanitized table-cell data-background-color attributes. Attackers can store crafted task descriptions or comments to render full-viewport phishing overlays or force zero-click outbound background-image requests that deanonymize viewers.

Other Web app

Vikunja before 2.7.1 contains a denial of service vulnerability that allows authenticated users to exhaust API process memory by uploading WeKan or vikunja-file imports with no item-count cap. Attackers can submit a ~22 MB WeKan JSON with hundreds of thousands of cards or duplicate IDs to the wekan migrate endpoint, triggering OOM and crashing the instance.

Denial of service

Vikunja from 0.18.0 before 2.7.1 contains a privilege escalation vulnerability that allows team owners to gain admin or ownership of read-only shared projects by deleting accounts. Attackers can create a bot, add it to their team, and delete it through the bots endpoint, triggering ensureProjectAdminUser to promote read-only shares and lock out the real owner.

Auth & access

Vikunja before 2.7.1 contains an improper restriction of excessive authentication attempts vulnerability that allows session holders to brute-force account passwords via unthrottled re-authentication endpoints. Attackers with a stolen session can guess the password via /user/settings/totp/disable without lockout, then disable TOTP without a code for persistent account takeover.

Auth & access Web app

Vikunja before 2.7.1 contains an authorization bypass vulnerability that allows authenticated users to read any task by injecting a crafted task object into a no-op Kanban bucket move. Attackers can set task.id to a victim task and task.project_id to their own project, routing full task contents to their webhook and forging mention notifications.

Auth & access Web app

Vikunja before 2.7.1 contains an uncontrolled resource consumption vulnerability that allows authenticated users to exhaust server memory by requesting avatars at many distinct sizes. Attackers can upload a noisy avatar and fetch it at each size up to 1024, caching roughly a gigabyte per account without eviction and causing the API process to be OOM-killed.

Denial of service Web app

Vikunja from 0.23.0 before 2.7.1 contains an information disclosure vulnerability that allows project collaborators with write access to read tasks from inaccessible projects by registering webhooks. Because webhook payloads are built with the triggering user's permissions, attackers receive related_tasks titles, descriptions and metadata from private projects whenever another user modifies a linked task.

Auth & access

Vikunja before 2.7.1 contains a credential exposure vulnerability that allows attackers to steal stored auth tokens by inducing users to switch the frontend API URL. Because checkAndSetApiUrl leaves origin-independent localStorage tokens in place, the bearer token and desktop OAuth refresh token are sent to the attacker's server, enabling account takeover.

Disclosure Web app

Vikunja before 2.7.1 contains an improper resource cleanup vulnerability that leaves full-data export archives orphaned on disk after re-exports, failed exports, or account deletion. Authenticated users can repeatedly re-trigger exports containing all their attachments to exhaust disk storage, while deleted users' personal data remains retained indefinitely.

Denial of service

Vikunja before 2.7.1 contains a client-side request forgery vulnerability that allows users with write access to make viewers' clients request loopback or LAN addresses by storing img elements in rich text. Attackers can plant images in tasks, comments, project descriptions, or imported Markdown to trigger blind GET requests against local services and track when viewers open content.

XSS Web app

Vikunja before 2.7.1 contains a resource exhaustion vulnerability in the vikunja-file ZIP importer that allows authenticated users to consume CPU and memory by uploading archives with excessive entries. Attackers can upload export ZIPs containing many empty or non-files/ entries that bypass the per-entry caps, forcing scanArchive to process every entry twice.

Denial of service

Vikunja before 2.7.1 contains an information disclosure vulnerability that allows authenticated users to determine whether private teams exist by calling the team member self-removal endpoint. Attackers can send DELETE requests to /teams/{id}/members/{own username} for arbitrary team ids and use the distinguishable responses to learn if a team exists, is SSO-managed, or has a single member.

Disclosure

Vikunja before 2.7.1 contains an incorrect authorization vulnerability in TaskBucket.CanUpdate, which checks write access to the bucket's project and to the task separately but never verifies that both belong to the same project. Authenticated users with write access to two projects can move a task into another project's kanban bucket. This persists cross-project task_buckets rows that count toward bucket limits and, for done buckets, toggle the task's done state.

Auth & access

Vikunja before 2.7.1 contains a supply chain vulnerability in its mage release targets that fetch the xgo module and Docker image by mutable latest references. Attackers who compromise the upstream xgo module, image, or registry can inject malicious code into subsequently built release binaries shipped under a valid signature.

Other Library

Vikunja before 2.7.1 contains an uncontrolled resource consumption vulnerability that allows project writers or view admins to create unlimited kanban buckets due to missing count caps. Attackers can create thousands of buckets so every kanban read runs a task SELECT and COUNT per bucket, generating heavy database load.

Denial of service Web app

Vikunja before 2.7.1 fails to re-anchor PluginsDir and LogPath to service.rootpath, allowing plugins to load from and logs to be written in the startup working directory. Local attackers able to write to that directory can plant plugins loaded into the server when plugins are enabled, or read misplaced logs including audit.log.

Code execution Server

Vikunja before 2.7.1 contains an uncontrolled resource consumption vulnerability that allows authenticated CalDAV clients to create unbounded dummy tasks by sending VTODOs with thousands of RELATED-TO properties. Attackers can repeat unknown related UIDs in a single PUT request to generate thousands of task, relation, and event rows, bloating the database and overloading the event pipeline.

Denial of service Server

Vikunja before 2.7.1 embeds live password-reset, email-confirmation and account-deletion tokens in the URL query string of emailed links, so the full request URI, including the token, is written to Vikunja's HTTP access log and any reverse-proxy logs when a user clicks the link. Attackers with read access to those logs can replay an unredeemed password-reset token to take over the account or an account-deletion token to confirm the deletion.

Disclosure

Vikunja before 2.7.1 contains an information exposure vulnerability that allows log readers to obtain link-share hashes because the request logger records the raw URI of the /shares/:share/auth route. Attackers with access to Vikunja or reverse proxy access logs can reuse non-expiring, non-password-protected share hashes to obtain a project JWT with read, write or admin permission.

Disclosure Web app

Vikunja before 2.7.1 contains an improper authorization vulnerability in canDoBucket that allows users with project write access to delete buckets via a mismatched view ID. Attackers can request deletion through another view's bucket endpoint to bypass the last-bucket rule, leaving dangling default/done bucket references and inconsistent task buckets.

Auth & access

Vikunja from 0.22.0 before 2.7.1 contains an information disclosure vulnerability that allows read-only project members to view full webhook target URLs by listing project webhooks. Attackers can extract incoming-webhook tokens or API keys embedded in target_url values to post to receiving channels or reuse keys until rotated.

Disclosure Device

Vikunja before 2.7.1 contains an insecure file permissions vulnerability that allows local users to read stored data because localStorage.Write creates blobs world-readable. Local attackers on a shared host can read attachments, project backgrounds and exports, and copy the SQLite database to crack password hashes offline.

Auth & access Server

Vikunja from 2.2.0 before 2.7.1 contains an authorization bypass vulnerability that allows holders of tokens scoped only to projects_webhooks to manage the owner's user-level webhooks by supplying user_id in request bodies. Attackers can register user webhooks to their own receiver to obtain reminders and task payloads from all owner projects, and read, change or delete existing user webhooks.

Auth & access

Vikunja from 0.24.0 before 2.7.1 contains a nil pointer dereference vulnerability that allows project admins to break project views by saving a filter-mode bucket configuration with a null filter. Because validateProjectViewFilters skips nil entries, every subsequent read of the view panics in kanban and task collection code, returning HTTP 500 to all project members.

Memory safety Web app

Vikunja veans before 2.7.1 contains a protocol downgrade vulnerability in serverCandidates that allows on-path attackers to force plain HTTP during veans init and login. Attackers can block HTTPS ports so discovery accepts an unverified HTTP response, capturing passwords, TOTP codes or bot tokens and persisting cleartext API traffic.

Disclosure

Vikunja veans before 2.7.1 contains a prompt injection vulnerability that allows project members with write access to inject instructions by setting project titles or task content rendered verbatim inside the coding agent's authoritative instruction block. Attackers can craft ProjectTitle or task descriptions that the prime hook loads on SessionStart and PreCompact, causing the agent to modify the developer's checkout or run commands.

Injection

Vikunja veans before 2.7.1 contains a credential exposure vulnerability that allows malicious repository authors to capture API tokens by specifying an attacker-controlled server in .veans.yml. When veans runs in an untrusted checkout, it sends VEANS_TOKEN as a Bearer token, or login passwords, TOTP codes and tokens, to that server, granting attackers the victim's Vikunja access.

Other Server

Vikunja before 2.7.1 contains an insecure file permissions vulnerability that allows local users to read dump archives created with umask permissions by the vikunja dump command. Local attackers on a shared host can read the world-readable zip in the rootpath to obtain config, password hashes, TOTP secrets, tokens, and stored files.

Auth & access

Vikunja before 2.7.1 contains an uncontrolled resource consumption vulnerability that allows authenticated users to exhaust server memory through concurrent image decodes in avatar and background uploads. Attackers can send several parallel tiny, highly compressible PNGs decoded at up to 50 megapixels each, pushing the API process into memory pressure or an OOM kill.

Denial of service Server

Vikunja from 2.4.0 before 2.7.1 contains an authentication bypass vulnerability that allows disabled or locked users to retain access through API tokens owned by their bot users. Because token validation only checks the bot's own status, attackers holding pre-minted bot tokens can keep reading and modifying shared projects via the HTTP API, CalDAV, MCP and feeds.

Auth & access

Vikunja before 2.7.1 contains a cross-site request forgery vulnerability that allows attackers to import their data into a victim's account because the Todoist, Microsoft To Do, and Trello migration OAuth callbacks lack a bound state parameter. Attackers can authorize their own account, keep the unused callback code or token, and lure a logged-in victim to the migration callback route to auto-import attacker-chosen projects and tasks containing phishing links.

Auth & access Web app