Threat database

Trigger.dev before 4.5.12 contains an authorization bypass vulnerability that allows holders of capability-restricted user-actor tokens to create alert channels by using the legacy personal access token helper. Attackers with a read-only UAT can POST to the project alertChannels endpoint to create production webhook channels, routing future deployment and error alerts to attacker-controlled infrastructure.

Trigger.dev versions before 4.5.10 contain a server-side request forgery (SSRF) vulnerability. Authenticated project members can bypass webhook SSRF protections by targeting the non-global 198.18.0.0/15 benchmarking IP range. This allows attackers to configure alert-channel webhooks to internally routed services within this range, enabling blind internal probing and limited state-changing POST requests.

Trigger.dev CLI versions before 4.5.9 have an information disclosure vulnerability where sensitive environment variables are logged in debug deployment logs without redaction. This exposure allows attackers with access to terminal transcripts, CI debug logs, or support bundles to recover sensitive data such as database connection strings and service credentials. The vulnerability has a CVSS 4.0 base score of 6.8, indicating medium severity.

The Trigger.dev webapp before 4.5.12 contains a cross-site request forgery vulnerability in its organization-level Slack OAuth flow, which uses the organization ID as the OAuth state without binding it to the initiating session. Attackers who know a target organization ID can trick an authenticated member into opening an unredeemed /integrations/slack/callback URL, connecting an attacker-controlled Slack workspace that may receive the organization's operational alerts.

Trigger.dev versions before 4.5.12 have an authorization bypass vulnerability allowing authenticated project members to complete another member's DEVELOPMENT environment waitpoint. This bypass occurs by skipping the per-user environment ownership check if the attacker knows the victim's waitpoint friendly ID. The attacker can submit specific waitpoint types with a timeout flag to prematurely mark the waitpoint as completed.

Trigger.dev 4.5.0 before 4.6.0 contains an information disclosure vulnerability in the Dashboard Agent input proxy that stores a delegated user-actor token in browser-readable session input records. Attackers holding a chat's public session token can read the in records endpoint to recover the token from payload.metadata.userActorToken and replay it for environment JWT exchange.

Trigger.dev versions before 4.6.0 have an improper authorization vulnerability in the GET /api/v1/projects/:projectRef/envvars endpoint. This flaw allows users with restricted read:envvars permission to access the environment's root API key (TRIGGER_SECRET_KEY) for staging, production, and preview environments. Exploiting this, attackers can retrieve plaintext secrets, trigger tasks, and mint admin public JWTs, leading to significant privilege escalation.

Trigger.dev versions before 4.6.0 have an authorization bypass vulnerability in the waitpoint token wait endpoint. Authenticated attackers with any secret API key can block runs from other organizations indefinitely by supplying a victim's run ID with their own waitpoint. They can also inject resume data into the victim's run, potentially disrupting workflow execution.

Trigger.dev 4.5.0 before 4.6.2 contains an improper authorization vulnerability in the PUT snapshot-url session endpoint that allows public session token holders to obtain presigned S3 write URLs. End users can overwrite their own session's durable chat snapshot to forge the agent's conversation history, since the route lacks a secret-key-only check.

Trigger.dev versions before 4.7.0 have an authorization bypass vulnerability that allows users with unrestricted environment API keys to interfere with runs they do not own. By supplying a foreign parentRunId to certain batch-creation API endpoints, attackers can suspend, block indefinitely, or inject errors into production or cross-organization runs.

Trigger.dev before 4.7.3 contains a tenant filtering bypass vulnerability that allows authenticated users to read other tenants' data by using placeholder table syntax in POST /api/v1/query. Attackers can submit queries with FROM {database.table} expressions, including within subqueries, to skip table allowlist and tenant filters and expose run metadata and payloads.

Snipe-IT versions before 8.7.0 have a server-side request forgery (SSRF) vulnerability in the webhook testing feature. This flaw allows super-admin users to send requests to internal network addresses, including loopback and private RFC1918 ranges. By analyzing differences in HTTP response codes (4xx vs 5xx), attackers can map internal network hosts and open ports.

SvelteKit versions from 2.10.0 up to but not including 3.0.0 have a path traversal vulnerability in the vite preview server on Windows. This flaw allows unauthenticated attackers with network or tunnel access to the preview server to read files outside the intended prerendered output directory. Exploitation can expose sensitive files such as source code, configuration files, or credentials accessible by the server process.

SvelteKit before 3.0.0 contains a server-side request forgery vulnerability that allows remote attackers to reach internal services because self-fetch fallbacks follow HTTP redirects automatically. Attackers can manipulate the Host or forwarded headers to point fallback requests at their server, which redirects them to internal services.

SvelteKit versions before 3.0.0 have a low-severity cross-site scripting (XSS) vulnerability in prerendered pages. This occurs because a cache-control header value set via setHeaders is inserted without escaping into a <meta http-equiv="cache-control"> tag. An attacker able to influence this untrusted value at prerender time can inject HTML or JavaScript that executes when users visit the page.

SvelteKit (@sveltejs/kit) before 3.0.0 contains an open redirect vulnerability in enhanced form actions (use:enhance) on routes accepting paths beginning with a double slash. Attackers can craft action paths starting with // that become protocol-relative URLs, causing non-redirect form results to navigate victims to attacker-controlled sites.

ArcadeDB versions before 26.10.1 have a remote code execution vulnerability due to insufficient authorization checks in the GremlinQueryEngine.command() method. Authenticated users, including those with read-only roles, can execute Groovy code via the POST /api/v1/command/{database} endpoint if the Groovy engine is enabled. This allows execution of OS commands with the privileges of the server process user.

ArcadeDB versions from 26.2.1 up to but not including 26.10.1 have a missing authorization vulnerability in the Bolt protocol handler. This flaw allows authenticated users with access to one database to read schema metadata of other databases by manipulating the db field in RUN or BEGIN messages. The vulnerability enables unauthorized enumeration of schemas via commands like db.labels() or SHOW INDEXES. The CVSS 4.0 base score is 5.3, indicating a medium severity issue.

ArcadeDB from 26.2.1 before 26.10.1 contains a missing authorization vulnerability in the Bolt protocol handler that allows authenticated users to enumerate all database names. Attackers with credentials for any single database can issue a SHOW DATABASES query over the Bolt port to reveal unauthorized database names, exposing tenant or project identifiers.

ArcadeDB versions from 26.8.1 up to but not including 26.10.1 have an authorization bypass vulnerability. This flaw allows users with read-only permissions to modify edge type schema flags without having the required UPDATE_SCHEMA permission. Specifically, attackers can alter edge storage declarations by sending an ALTER TYPE command over supported APIs.