Pipelines-as-Code versions prior to 0.48.0, 0.42.1, 0.39.6, and 0.37.8 are vulnerable to credential exfiltration via the GitHub App webhook endpoint. The vulnerability arises because the application accepts the X-GitHub-Enterprise-Host header without proper validation before generating GitHub App tokens, allowing an attacker to redirect token requests to a malicious host. This can lead to exposure of the GitHub App JWT, enabling token minting within the JWT validity window. The issue is fixed by validating webhook signatures before token generation and verifying the Enterprise host against the repository URL. Operators are advised to block or strip unexpected headers and restrict webhook endpoint access until patched.
Vikunja versions up to 2.4.0 have a principal-type confusion vulnerability where link-share principals are incorrectly treated as user principals during permission checks. This allows attackers with a link-share JWT to remove users from teams, delete bot users, and read team rosters due to ID collisions. The vulnerability has a high severity with a CVSS score of 7.5. This advisory is a duplicate and references GHSA-32r8-5843-4qw2. No patch links are provided, and no known exploits are reported in the wild.
## Summary
Vikunja's `web.Auth` interface (`pkg/web/web.go`, single method `GetID() int64`) is satisfied by BOTH `*user.User` and `*models.LinkSharing`. A link-share's `GetID()` returns the **raw positive** `share.ID` (`pkg/models/link_sharing.go:83-85`), which lives in the same positive autoincrement ID space as `users.id`. The safe negated form `getUserID() = share.ID * -1` (`link_sharing.go:126-128`) exists but is NOT used at three permission sinks. As a result, a link-share principal with id `N` — which should have zero authority over teams or bot users — is treated as the *user* whose `users.id == N` at three permission checks that lack the `a.(*LinkSharing)` guard their sibling methods have. This is the same principal-type-confusion class as CVE-2026-68581 (GHSA-vvcv-vpph-h844), but at three code paths that advisory/fix never touched.
## Root Cause
`web.Auth` is a one-method interface (`GetID() int64`). `*LinkSharing.GetID()` returns the raw positive share id. Three permission methods compare this raw id directly and omit the link-share type guard used elsewhere in the same files:
1. **`TeamMember.CanDelete`** (`pkg/models/team_members_permissions.go:31-40`): the self-removal fast path `if u.ID == a.GetID() { return true }` (:36) executes **before** `IsAdmin`. `IsAdmin` (:48-51) is the ONLY place that rejects link shares (`if _, is := a.(*LinkSharing); is { return false }`, :50) — and it is never reached when the fast path returns true.
2. **`BotUser.isOwner`** (`pkg/models/bot_users_permissions.go:47-56`): `return u.BotOwnerID == a.GetID()` (:55), used by `CanRead`/`CanUpdate`/`CanDelete` (:36-45). Unlike `CanCreate` (:27-30) which type-asserts `a.(*user.User)`, these three paths have no principal guard.
3. **`Team.CanRead`** (`pkg/models/teams_permissions.go:68-78`): matches membership on `And("user_id = ?", a.GetID())` (:76) with no link-share guard, unlike sibling `IsAdmin` (:45-49, guard at :47).
Link-share JWTs reach these routes: `SetupTokenMiddleware` validates the signature only, `GetAuthFromClaims` returns `*models.LinkSharing`, and the `/user`/`/teams` route groups add no link-share rejection. Link sharing is enabled by default (`config.go` `ServiceEnableLinkSharing.setDefault(true)`).
## Impact
A link-share principal (obtainable from any public share link, or self-registered via a share on the attacker's own project) whose id `N` collides with a victim's `users.id == N` can, without being that user or any user:
- **Integrity (I:H):** remove the victim from any team they belong to (`DELETE /api/v1/teams/{T}/members/{username}`) → revokes all project permissions the victim inherited through that team.
- **Availability/Integrity (A:H, I:H):** enumerate the victim's bot users (`GET /api/v1/user/bots` → `bot_owner_id = a.GetID()`), then disable/rename or **permanently delete** them (`DELETE /api/v1/user/bots/{id}` → `DeleteUser`), destroying data owned solely by those bots.
- **Confidentiality (C:H):** read the roster + metadata (name, description, full member list) of any team the colliding user belongs to (`GET /api/v1/teams/{T}`), plus read bot-user records via `isOwner`-gated reads.
## Attack Chain
### Sink 1 — TeamMember.CanDelete (integrity)
1. **Entry:** `POST /api/v1/shares/{hash}/auth` → link-share JWT with `id = N`. **Guard:** JWT middleware — signature only. **Bypass proof:** `GetAuthFromClaims` returns `*models.LinkSharing`; no route-group link-share rejection on the `/teams` group.
2. **Action:** `DELETE /api/v1/teams/{T}/members/{usernameOfUserN}` with the link-share bearer, targeting a team `T` (≥2 members) that user `N` belongs to. **Guard:** `CanDelete` → `GetUserByUsername(tm.Username)` returns user N, then `u.ID == a.GetID()` (`team_members_permissions.go:36`). **Bypass proof:** `a.GetID()` returns `N` (raw positive `share.ID`, `link_sharing.go:84`) == user N's id → `true`. No `a.(*LinkSharing)` check on this branch (only `IsAdmin` at :50 has it, never reached).
3. **Sink:** `Delete` (`team_members.go`) removes user N from team T (last-member check passes when team has ≥2 members). **Impact:** victim loses all project access inherited through team T.
### Sink 2 — BotUser.isOwner (bot takeover / destruction)
1. **Entry:** link-share JWT id N (as above). **Guard:** signature-only; `/user` group adds no link-share reject.
2. **Enumerate:** `GET /api/v1/user/bots` → `ReadAll` runs `Where("bot_owner_id = ?", a.GetID())` = bots owned by user N. **Bypass proof:** `a.GetID()` = N; returns victim's bot ids self-contained (removes the id-guessing barrier).
3. **Sink:** `DELETE /api/v1/user/bots/{botId}` → `CanDelete` → `isOwner` → `u.BotOwnerID == a.GetID()` (`bot_users_permissions.go:55`) → true; `Delete` calls `DeleteUser`. **Bypass proof:** no `a.(*LinkSharing)` guard here (Create-only, :28). **Impact:** disable/rename/permanently delete victim's bot automation identities.
### Sink 3 — Team.CanRead (info disclosure)
1. **Entry:** link-share JWT id N. **Guard:** signature-onl
SiYuan before version 3.7.4 has a vulnerability in 17 block metadata and content endpoints within kernel/api/block.go. These endpoints lack proper authorization checks and publish-access filtering, allowing anonymous users to access private block content and metadata without authentication. This issue affects handlers such as getRefText, checkBlockExist, and getBlockBreadcrumb.
CVE-2026-74904 is a missing authorization vulnerability in the siyuan-note software affecting multiple API endpoints under /api/block/*. Seventeen handlers in kernel/api/block.go return block content-derived text, structural metadata, or existence information for any block ID without proper access checks or admin role requirements. This allows anonymous users to retrieve sensitive workspace content and metadata without authentication. The vulnerability affects siyuan versions from 0 up to but not including 3.7.4. The CVSS 4.0 score is 8.7 (high severity).
uniget CLI versions prior to 0.27.6 contain a command injection vulnerability in the hooks edit command. The vulnerability arises because the UNIGET_EDITOR or EDITOR environment variables are split on spaces and each segment is passed as an argument to the editor executable without shell evaluation. This can allow an attacker who controls the editor environment and triggers hook editing to supply unexpected editor arguments, potentially causing unintended actions with the privileges of the uniget process. The issue is fixed in version 0.27.6.
uniget is a universal installer and updater for (container) tools. Prior to 0.27.6, the hooks edit command in cmd/uniget/hooks.go concatenates an unvalidated hook filename with the selected hooks directory, allowing parent-directory components to escape that directory. The resulting path is passed to the configured editor, which can access or modify files outside the hooks directory with the privileges of the uniget process account. This issue is fixed in version 0.27.6.
A logic error in the uniget CLI causes metadata signature verification to run only when the environment variable UNIGET_IGNORE_METADATA_SIGNATURE is set, which is the opposite of the intended behavior. This flaw allows unverified, potentially malicious metadata.json files to be loaded and executed, leading to arbitrary command execution as the user running uniget. The issue affects uniget versions from 0.27.4 up to, but not including, 0.28.9. A patch is available to correct this verification logic.
Terragrunt versions prior to v1.0.4 are vulnerable to an arbitrary file deletion flaw via a maliciously crafted .terragrunt-module-manifest file in remote modules. This flaw allows deletion of files anywhere on the local filesystem accessible to the Terragrunt process during module download and initialization. The vulnerability does not enable code execution or data exfiltration but can cause denial of service or loss of local files. The issue is fixed in Terragrunt v1.0.4.
CVE-2026-64865 is a race condition vulnerability in QuantumNous new-api, an AI asset management system. Before version 1.0.0-rc.16, concurrent PUT requests to update user data could cause improper synchronization in quota management, allowing authenticated users to artificially maintain a higher cached quota. This issue is fixed in version 1.0.0-rc.16.
New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. Prior to 1.0.0-rc.18, user-controlled image n, video seconds and duration, max_tokens, max_completion_tokens, maxOutputTokens, audio duration, and billing-expression quantities can overflow conversions in common/quota_math.go and related settlement paths, allowing a low-privileged account with positive balance or an active subscription to turn a negative charge into account credit and potentially drain upstream funds. This issue is fixed in version 1.0.0-rc.18.
New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. From 0.9.1.3 until 1.0.0-rc.7, AdminResetPasskey in controller/passkey.go lacks the canManageTargetRole authorization check for DELETE /api/user/:id/reset_passkey, allowing a lower-privileged administrator to remove a passkey from a same-level or higher-privileged account, including a root account. This issue is fixed in version 1.0.0-rc.7.
New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. Prior to 1.0.0-rc.11, POST /api/stripe/webhook, POST /api/creem/webhook, and POST /api/waffo/webhook read and log full request bodies before signature validation in router/api-router.go and the payment controllers, allowing an unauthenticated attacker to cause memory pressure, container restarts, or disk exhaustion without forging a successful payment. This issue is fixed in version 1.0.0-rc.11.
New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. Prior to 1.0.0-rc.7, the admin user list and user lookup APIs, including GET /api/user/, return User.AccessToken as access_token because User model objects are serialized after queries use Omit("password"), allowing an authenticated administrator to obtain the root user's bearer token and access root-only system configuration APIs. This issue is fixed in version 1.0.0-rc.7.
SiYuan versions before 3.7.4 have a cross-site WebSocket hijacking vulnerability in the admin-only /ws/network/proxy endpoint. This endpoint disables origin validation by setting CheckOrigin to always return true, allowing attackers to establish WebSocket connections from malicious webpages. This enables authenticated network pivoting through the victim's machine by proxying arbitrary network traffic.
CVE-2026-74802 is a high-severity vulnerability in the siyuan-note software (version 3.7.3 and earlier) involving an origin validation bypass in an admin-only WebSocket proxy endpoint. The endpoint disables origin checks by overriding the gorilla/websocket library's default origin validation, allowing cross-site WebSocket hijacking. This enables an attacker to leverage a victim's active admin session to proxy arbitrary network traffic through the victim's machine, potentially accessing internal or localhost-only services. No patch is currently available for this issue.
Fabric CA versions prior to 1.5.21, when configured with an LDAP backend, are vulnerable to LDAP injection due to unescaped usernames in the LDAP UserFilter during authentication. This allows an unauthenticated attacker with network access to manipulate LDAP searches before password validation, potentially redirecting authentication attempts to victim accounts. Deployments not using LDAP backends are not affected. The issue is fixed in version 1.5.21.
A vulnerability in Authorizer's OAuth callback handler allows an attacker to take over user accounts without user interaction by exploiting unverified email accounts. The system links OAuth identities to existing accounts matched by email without verifying the email was originally verified by the account owner. This flaw enables an attacker who pre-registers an account with a victim's email (unverified) to gain persistent password access after the victim logs in via OAuth. The attacker’s password remains valid and the victim is not notified of the linked OAuth identity.
chi versions before 5.2.2 contain an open redirect vulnerability in the RedirectSlashes middleware. This vulnerability arises because the middleware uses the Host header to construct redirect URLs, allowing attackers to manipulate the Host header to redirect users to arbitrary hosts. This can facilitate phishing attacks and credential theft. The advisory is a duplicate and has been withdrawn in favor of GHSA-vrw8-fxc6-2r93. No patch links are provided in this advisory, but the fixed version is 5.2.2.
SiYuan versions before v3.7.4 have a missing authorization vulnerability in the /api/ref/refreshBacklink endpoint. This flaw allows anonymous users to trigger persistent server-side writes and perform resource amplification attacks by invoking the endpoint with attacker-controlled input. The advisory is a duplicate and has been withdrawn in favor of GHSA-wgwx-479j-23vq. No patch information is provided in this record.