Threats tagged 'go'

A vulnerability in the Vikunja API allows project members with Write permission to delete admin-tier link shares on that project due to an authorization check flaw. The deletion handler does not load the stored share's permission and defaults to Read permission, causing the check to fall back to Write permission instead of requiring Admin. This enables Write members to revoke admin-level link shares, disrupting external access without granting elevated privileges or disclosing data.

Vikunja version 2.6.0 contains a regression in its project permission engine where explicit lower-permission shares on sub-projects are silently overridden by higher inherited permissions from parent projects. This causes intended access restrictions on child projects to be ignored, allowing users to gain higher privileges than intended. The issue stems from a change in permission resolution logic from 'nearest-ancestor-wins' in v2.5.0 to 'maximum permission wins' in v2.6.0. This vulnerability can lead to unauthorized modification, deletion, and re-sharing of sensitive sub-projects.

A vulnerability in Vikunja API versions from 0.22.0 through 2.6.0 allows a removed collaborator to retain live access to project contents via webhooks and link shares. Although the collaborator's direct read access is revoked, the webhooks and link shares they created before removal continue to deliver updates, including content created after revocation. The issue arises because the cleanup routine that deletes access-related data on revocation does not include webhooks and link shares. This results in a continuous feed of project data to former collaborators. The vulnerability has a medium severity rating with a CVSS score of 6.5.

In Vikunja v2.6.0, creating a saved filter with an empty filter string while the user has no accessible projects causes a task position recalculation that loses project scope and writes task position data across all tenants. This allows an authenticated user to write task position entries referencing tasks from other tenants, violating tenant data integrity and causing write amplification proportional to the instance size. The issue arises because the recalculation query executes without a project scope filter when no accessible projects exist, and the server writes position rows unconditionally. This flaw contradicts intended access controls and was confirmed with a proof-of-concept.

Vikunja versions 2.3.0 through 2.6.0 have a vulnerability where WebSocket authentication ignores server-side session revocation. Although sessions can be revoked via the REST API, the WebSocket endpoint does not validate the session ID claim against active sessions. This allows revoked tokens to continue receiving live push notifications indefinitely. The issue affects session revocation mechanisms including TOTP enrollment, undermining user expectations of session invalidation.

A vulnerability in Vikunja API allows deletion of task relations without verifying read access to the related task. This permits a user with write access to one project to remove relations linked to tasks in projects they cannot access. The issue affects the DELETE task relation API endpoints and results in silent removal of relations from the other project without data disclosure or privilege escalation.

A vulnerability in the Vikunja API causes assignee email addresses to be disclosed to read-only project members via the task assignees endpoint. Unlike other endpoints that obfuscate user email addresses, this endpoint returns the email field unmasked. This issue affects versions prior to 2.6.0 and allows unauthorized disclosure of email addresses without additional privileges.

Vikunja has a vulnerability where subtasks linked across projects are disclosed without proper access control. A user with read access to one project can retrieve full details of tasks in other private projects if those tasks are subtasks linked under accessible tasks. This cross-project disclosure exposes sensitive task data including titles, descriptions, dates, assignees, labels, and attachment metadata. The issue arises because subtask expansion does not enforce project access filtering. The vulnerability is read-only and depends on pre-existing cross-project subtask links. A fix is available to apply correct access filtering on expanded subtasks.

A vulnerability in Vikunja's CalDAV API allows an attacker to create task relations without proper permission checks. This bypass enables unauthorized writes to any task by specifying its UID, even in projects the attacker cannot access. The issue arises because the CalDAV relation creation path does not enforce the TaskRelation.CanCreate permission check, unlike the REST API. Task UIDs are exposed via CalDAV to users who previously had read access, enabling removed collaborators to exploit this. The flaw also facilitates cross-project subtask relation creation, which can lead to further information disclosure. A fix is available that routes CalDAV relation creation through the proper permission checks and scopes UID lookups to accessible projects.

## Summary The task-position endpoint authorizes only the task side of the write: `TaskPosition.CanUpdate` delegates to `Task.CanUpdate` (write access to the task's own project) and the request body's `project_view_id` is never validated to belong to the task's project, nor is any access to that view required. Any authenticated user with a single writable task of their own can persist `(task_id, project_view_id, position)` rows into any other tenant's project view (view IDs are small sequential integers and enumerable). Low position values (below `MinPositionSpacing`, 0.01) enter the recalculation branch, but `RecalculateTaskPositions` aborts on its own project read-access check before recalculating and the whole transaction rolls back, so no cross-tenant recalculation actually executes — only the plain row insert (position ≥ 0.01) persists. This is the same root-cause pattern as GHSA-569v-q83c-3j3g (kanban bucket relocation via project_view_id mass-assignment, fixed with a dual-side check for buckets in 2.4.0) surviving in the sibling position endpoint. Verified on Vikunja 2.5.0. ## Details Affected endpoints (both verified): - v1: `POST /api/v1/tasks/{id}/position` - v2: `PUT /api/v2/tasks/{id}/position` Root cause in `pkg/models/task_position.go`: - `CanUpdate` (lines 61-64) checks only `Task.CanUpdate` — i.e. the caller's write access to the task's own project. - `updateTaskPosition` (lines 174-232) upserts `(task_id, project_view_id, position)` directly; there is no check that the view belongs to the task's project and no access check on the view's project. - `ProjectViewID` is body-bindable (`json:"project_view_id"`, no readOnly/param restriction, line 42). Contrast with the fixed sibling: the bucket-move endpoint (`POST /projects/{project}/views/{view}/buckets/{bucket}/tasks`, `pkg/models/kanban_task_bucket.go:53-68`) validates both the bucket and the task after the GHSA-5pg6/GHSA-569v family fixes — the position endpoint was never given the equivalent view-side check. Observed behavior (two independent verification runs): an attacker with zero access to the victim project receives `200 {"task_id": ..., "project_view_id": <victim view>, "position": ...}` on both v1 and v2, and the row is persisted (verified directly in the `task_positions` table: rows for the victim view went 0 to 1). Positioning the victim's own task is correctly refused with 403, isolating the missing view-side check. The victim's listings do not surface the foreign task (no confidentiality impact demonstrated), and a low-position (< 0.01) injection enters the recalculation branch but `RecalculateTaskPositions` returns 403 (`getRelevantProjectsFromCollection` → `CanRead` on the victim project) before any recalculation runs, rolling the whole request back — so the low-position variant persists nothing and never rewrites the victim's ordering. ## PoC Steps use the owner of the victim project (token `$OWNER`) and an attacker with only their own project (token `$ATTACKER`). All requests were executed against a local Vikunja 2.5.0 instance. 1. Owner creates a private project (default views included) and lists its views to obtain a victim view ID: ``` curl -X PUT "$BASE/api/v1/projects" -H "Authorization: Bearer $OWNER" \ -H 'Content-Type: application/json' -d '{"title":"victim"}' # -> {"id":200,...} curl "$BASE/api/v1/projects/200/views" -H "Authorization: Bearer $OWNER" # -> [{"id":771,"view_kind":"kanban",...}, ...] # remember VIEW=771 ``` 2. Attacker creates their own project and a task in it: ``` curl -X PUT "$BASE/api/v1/projects" -H "Authorization: Bearer $ATTACKER" \ -H 'Content-Type: application/json' -d '{"title":"attacker"}' # -> {"id":201,...} curl -X PUT "$BASE/api/v1/projects/201/tasks" -H "Authorization: Bearer $ATTACKER" \ -H 'Content-Type: application/json' -d '{"title":"evil"}' # -> {"id":105,...} ``` 3. Baseline — attacker positions their task in their own view (succeeds, expected): ``` curl -X POST "$BASE/api/v1/tasks/105/position" -H "Authorization: Bearer $ATTACKER" \ -H 'Content-Type: application/json' -d '{"project_view_id": <OWN_VIEW>, "position": 100}' # -> 200 ``` 4. Mutation — attacker writes their task's position into the victim's view (no access to it whatsoever): ``` curl -X POST "$BASE/api/v1/tasks/105/position" -H "Authorization: Bearer $ATTACKER" \ -H 'Content-Type: application/json' -d '{"project_view_id": 771, "position": 100}' # -> 200 {"task_id":105,"project_view_id":771,"position":100} curl -X PUT "$BASE/api/v2/tasks/105/position" -H "Authorization: Bearer $ATTACKER" \ -H 'Content-Type: application/json' -d '{"project_view_id": 771, "position": 101}' # -> 200 (v2 twin behaves identically) ``` 5. Control — attacker positioning the victim's own task is correctly refused (the task-level gate works; only the view side is missing): ``` curl -X POST "$BASE/api/v1/tasks/<VICTIM_TASK>/position" -H "Authorization: Bearer $ATTACKER" \ -H 'Content-Type: application/json'

## Summary A user who has only read permission on a project can call the single link-share read endpoint and receive the share's `hash` field — the secret credential that the anonymous `POST /shares/{share}/auth` endpoint exchanges for a link-share JWT carrying the share's permission (read / read-write / admin). A read-only member can therefore mint a write- or admin-level token for the project and perform writes they are not entitled to, while their own user token is correctly refused. This is the remaining variant of the link-share hash disclosure class: GHSA-8hp8-9fhr-pfm9 fixed the list endpoint (ReadAll now requires project admin) but the single-read endpoint's gate was never aligned. Verified on Vikunja 2.5.0; the weak gate has existed since the endpoint, so earlier versions are likely affected too. ## Details Affected endpoints (both verified with a complete chain): - v1: `GET /api/v1/projects/{project}/shares/{share}` - v2: `GET /api/v2/projects/{project}/shares/{share}` Permission gate: `LinkSharing.CanRead` (`pkg/models/link_sharing_permissions.go`) delegates to `project.CanRead(s, a)` — i.e. any user with read access to the project passes. The response serializes the `hash` field (`pkg/models/link_sharing.go`, field tag `json:"hash"`), which is the share's bearer credential. The share `password` field is correctly cleared before returning, but the hash is not restricted. Inconsistent with the sibling list endpoint `GET /projects/{project}/shares` (`LinkSharing.ReadAll`, `pkg/models/link_sharing.go:243-256`), which requires `project.IsAdmin` — the protection level the project chose when the class was fixed for the list endpoint in 2.3.0 (GHSA-8hp8). The v1 and v2 APIs share the same model-level gate (the v2 `handler.DoReadOne` wrappers call the same `CanRead`), so both surfaces are affected. Impact chain: hash -> `POST /api/v1/shares/{hash}/auth` (unauthenticated by design) -> link-share JWT at the share's permission level -> full API access at that level for that project. Mitigating factors: the attacker must already be a member of the project at read level; password-protected shares (sharing_type=2) still require the password at the auth step; share IDs are small sequential integers and enumerable by members. ## PoC Steps below use two accounts: the owner (token `$OWNER`) and an attacker who has been granted read-only access to the project (token `$READER`). All requests were executed against a local Vikunja 2.5.0 instance. 1. Owner creates a private project and a read-write link share (permission=1): ``` curl -X PUT "$BASE/api/v1/projects" -H "Authorization: Bearer $OWNER" \ -H 'Content-Type: application/json' -d '{"title":"poc"}' # -> {"id":123,...} curl -X PUT "$BASE/api/v1/projects/123/shares" -H "Authorization: Bearer $OWNER" \ -H 'Content-Type: application/json' -d '{"name":"poc","permission":1}' # -> {"id":7,"hash":"<SECRET_HASH>",...} ``` 2. Owner adds the attacker as a read-only member (permission=0): ``` curl -X PUT "$BASE/api/v1/projects/123/users" -H "Authorization: Bearer $OWNER" \ -H 'Content-Type: application/json' -d '{"username":"attacker","permission":0}' ``` 3. Attacker reads the single share — the weak gate — and receives the hash (this is the disclosure; the list endpoint would correctly return 403 here): ``` curl "$BASE/api/v1/projects/123/shares/7" -H "Authorization: Bearer $READER" # -> 200 {"id":7,"hash":"<SECRET_HASH>","permission":1,...} # v2 twin behaves identically: curl "$BASE/api/v2/projects/123/shares/7" -H "Authorization: Bearer $READER" # -> 200 {"hash":"<SECRET_HASH>",...} ``` 4. Attacker exchanges the hash for a link-share JWT (no authentication required): ``` curl -X POST "$BASE/api/v1/shares/<SECRET_HASH>/auth" \ -H 'Content-Type: application/json' -d '{}' # -> 200 {"token":"<LINK_JWT>",...} ``` 5. Negative control — the attacker's own user token cannot write to the project: ``` curl -X PUT "$BASE/api/v1/projects/123/tasks" -H "Authorization: Bearer $READER" \ -H 'Content-Type: application/json' -d '{"title":"direct"}' # -> 403 Forbidden ``` 6. Escalation proof — the link-share JWT writes successfully: ``` curl -X PUT "$BASE/api/v1/projects/123/tasks" -H "Authorization: Bearer <LINK_JWT>" \ -H 'Content-Type: application/json' -d '{"title":"escalated"}' # -> 201 Created ``` Observed result: steps 3, 4 and 6 all succeed (200 / 200 / 201) while step 5 is refused with 403 — the read-only member has escalated to write access. If the project has an admin-level share (permission=2), the same chain yields project-admin capabilities (member management is still refused for link principals, but project settings, shares of the project, and all write operations become available). ## Impact Broken access control / privilege escalation within shared projects (CWE-862, CWE-639: the link-share hash is a bearer capability disclosed to a lesser-privileged member; CWE-200 for the information exposure). Any read-level member of a project tha

Vikunja versions prior to 2.4.0 store sensitive tokens such as password-reset, email-confirmation, and account-deletion tokens in plaintext within the user_tokens database table. This cleartext storage allows an attacker with read access to the database to use these tokens to take over user accounts without needing passwords. The issue is fixed in version 2.4.0.

Vikunja versions 1.0.0 through 2.3.0 contain an improper authentication vulnerability in the OpenID Connect provider's email fallback feature. When enabled, the system links an SSO login to a local account using only the email claim without verifying the email or requiring the account password. This allows an attacker who obtains a token with a victim's email to log in as that victim without their consent. The issue is fixed in version 2.4.0.

Vikunja version 2.3.0 contains an improper privilege management vulnerability where a scoped API token limited to the oauth.authorize permission can be used to obtain a bearer JWT and refresh token without scope restrictions. This allows access to API routes beyond the token's original permissions. The issue is fixed in version 2.4.0.

Vikunja versions prior to 2.5.0 contain a principal-type confusion vulnerability in the web.Auth interface that allows a link-share principal to be mistaken for a user with the same ID. This flaw enables unauthorized removal of users from teams, takeover and deletion of bot users, and disclosure of team rosters and bot metadata. The issue arises because link-share IDs share the same positive ID space as user IDs, and three permission checks fail to distinguish between these principal types. The vulnerability is fixed in version 2.5.0.

CVE-2026-107840 is an uncontrolled resource consumption vulnerability in the Prometheus metrics middleware of jhaals yopass before version 14.7.0. The middleware uses the HTTP request method directly as a label value in metrics, allowing an attacker to send requests with arbitrary method strings. This causes unbounded growth in Prometheus metric time series, leading to memory exhaustion and degraded metrics scrape performance.

CVE-2026-107839 is a high-severity vulnerability in luskaner's ageLANServer prior to version 1.15.2. The vulnerability arises from the POST /game/cloud/getFileURL handler, which lacks limits on the size of the request body and the length of an attacker-controlled JSON array. This can lead to uncontrolled memory allocation, causing the server to crash or hang, disrupting active players and making the service unavailable until restarted. The issue is resolved in version 1.15.2.

### Impact Argo CD runs a shell command in the repo-server when it clones or fetches an SSH Git repository that has a proxy URL. The proxy host and port are copied into an SSH `ProxyCommand`. A host that contains shell metacharacters breaks out of that command and runs in the repo-server. All versions from v2.11.0 onward are affected, including every currently supported release. v2.10.20 and earlier are not. The behavior was introduced in [9b27aeb1a4](https://github.com/argoproj/argo-cd/commit/9b27aeb1a4fb15d11a0f01cad65dea1fdfc60205) (2024-01-09, [#15864](https://github.com/argoproj/argo-cd/pull/15864)), the change that added SOCKS5 proxy support for SSH Git URLs, and was first released in v2.11.0. The repository must use SSH. `http`, `https`, and `socks5` proxy URLs all take this path when they are set on an SSH repository. An HTTPS Git repository uses the proxy as an HTTP proxy and does not build this command. Anyone who can create or update a repository or a repository credential template can set the proxy. That includes a project-scoped repository permission, `argocd repo add --proxy`, and a repository Secret. A credential template applies its proxy to every matching SSH repository that does not have its own credentials. Argo CD runs the command when it tests the repository connection and on later fetches. The process can read other Git, Helm, and OCI credentials stored for the repo-server. ### Patches A patch for this vulnerability has been released in the following Argo CD versions: * v3.6.0-rc2 * v3.5.4 * v3.4.10 * v3.3.15 The fix stops passing the proxy host and port through a shell. Argo CD 2.x and 3.0 through 3.2 are out of support and will not receive a patch. Upgrade to a patched 3.3 or newer release. ### Workarounds There is no setting that keeps SSH repository proxies and removes the shell command. * Do not grant repository create or update to untrusted users, including project-scoped repository access. See [RBAC resources](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#rbac-model-structure) and [project-scoped repositories](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#project-scoped-repositories-and-clusters). * Do not set a proxy on an SSH repository or on a credential template that matches SSH repositories. The proxy field is documented in [Configure repositories with proxy](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#configure-repositories-with-proxy). Credential templates are documented in [Credential templates](https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/#credential-templates). The `--proxy` flag is documented in [`argocd repo add`](https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_repo_add/). An HTTPS Git repository with an HTTP proxy does not use this command. Review existing repository and credential-template Secrets for unexpected `proxy` values. ### Credits The Argo CD team would like to thank @kamil-sawicki, @yuvalelarat, @cherez0ff, @McCaulay, @gehan-psbc, @ria-labs-security, @parameter-ai-security, and @zwindler for responsibly disclosing this issue according to our [security reporting guidelines](https://github.com/argoproj/argo-cd/blob/master/SECURITY.md#reporting-a-vulnerability). ### References * Introducing commit: [9b27aeb1a4fb15d11a0f01cad65dea1fdfc60205](https://github.com/argoproj/argo-cd/commit/9b27aeb1a4fb15d11a0f01cad65dea1fdfc60205) ([#15864](https://github.com/argoproj/argo-cd/pull/15864)), first released in v2.11.0 * [Configure repositories with proxy](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#configure-repositories-with-proxy) ### For more information * Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions) * Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd

## Summary Incomplete fix of GHSA-5v7c-xpfp-p65m: the secure-session (OTP step-up) requirement added to the nginx, cert, dns, backup, site, and stream mutation routers was not applied to the parallel api/cluster router, so cluster node management and cluster-wide nginx reload/restart run with only a JWT and no step-up. An authenticated user whose JWT is stolen or persisted, but who does not hold a fresh secure-session, can perform cluster node CRUD (including reading and rewriting a node token secret) and trigger cluster-wide nginx reload/restart. Confirmed at HEAD 2cb7ee9102c9d87274de2fa104db804841d140a0. ## The defect GHSA-5v7c-xpfp-p65m required a fresh secure session (an OTP step-up beyond the JWT) for sensitive mutation routes. The fix wrapped the nginx, cert, dns, backup, site, and stream mutation handlers in middleware.RequireSecureSession() and added reload/restart to the MCP sensitive-tool list. It did not touch the physically separate api/cluster package, whose router registers the same class of sensitive operations on the bare authenticated group. The fixed sibling, api/nginx/router.go: ```go o := r.Group("", middleware.RequireSecureSession()) // line 28 { o.POST("nginx/reload", Reload) // line 30 o.POST("nginx/restart", Restart) // line 31 } ``` The missed router, api/cluster/router.go, registers every sensitive operation directly on r with no RequireSecureSession wrapper: ```go nodeGroup := r.Group("nodes") // line 9, no step-up { nodeGroup.POST("", AddNode) // line 12 nodeGroup.POST("/:id", EditNode) // line 13 nodeGroup.DELETE("/:id", DeleteNode) // line 14 } r.POST("nodes/reload_nginx", ReloadNginx) // line 17 r.POST("nodes/restart_nginx", RestartNginx) // line 18 r.POST("namespaces", AddNamespace) // line 22 r.POST("namespaces/:id", ModifyNamespace) // line 23 r.DELETE("namespaces/:id", DeleteNamespace) // line 24 ``` Both routers mount on the same group in router/routers.go: `g := root.Group("/", middleware.AuthRequired(), middleware.Proxy())` (line 87); nginx.InitRouter(g) creates its own RequireSecureSession subgroup, cluster.InitRouter(g) does not. So the cluster routes inherit only AuthRequired and Proxy, exactly the pre-fix posture the advisory closed for the nginx routes. AuthRequired has no role gate, so any authenticated user reaches them. ## Attacker model and impact An authenticated, OTP-enabled user who does not present a fresh X-Secure-Session-ID (the parent advisory's model: a stolen or persisted JWT used without the step-up). Such a user can: add/edit/delete cluster nodes (AddNode/EditNode store an AES-serialized node token, the secret used to control a remote node, so this reads back and rewrites a cross-node credential); trigger nodes/reload_nginx and nodes/restart_nginx across the cluster (the exact reload/restart action class the fix protected on the single-node path); and add/modify/delete/reorder namespaces. Proof of concept: with a valid JWT but no fresh secure session, call POST /api/nodes (AddNode) or POST /api/nodes/reload_nginx. The nginx equivalent POST /api/nginx/reload returns the secure-session challenge; the cluster route succeeds. ## Verification Source-verified at HEAD: the nginx router wraps reload/restart in RequireSecureSession, the cluster router registers node/namespace/reload/restart directly on the group with no such wrapper, and both mount on the AuthRequired+Proxy-only group. I did not stand up a live nginx-ui. ## Suggested fix Wrap the cluster router's mutation handlers (node CRUD, nodes/reload_nginx, nodes/restart_nginx, namespace CRUD) in middleware.RequireSecureSession(), mirroring api/nginx/router.go. Secondary lower-confidence items worth checking in the same pass: the system/restart handler, the core-upgrade websocket, and the upstream socket PUT also appear to run without the step-up (I did not fully trace these).

nginx-ui versions 2.0.0 up to but not including 2.5.0 have a vulnerability in their self-upgrade mechanism where the binary and its checksum are downloaded from the same source without cryptographic signature verification. This allows an attacker controlling the download source or performing a man-in-the-middle attack on an HTTP proxy to substitute a malicious binary and matching digest, resulting in root code execution upon upgrade. The upgrade process replaces the running executable and restarts it as root. The vulnerability arises because integrity is only checked by comparing the binary's digest to a digest file fetched from the same origin, and the github_proxy setting accepts HTTP URLs, enabling cleartext interception. No official patch or fix is indicated in the provided data.