Jitsu Console CVE-2026-115509

Exploitation requires (1) a valid authenticated Jitsu console account (PR:L) and (2) knowledge of another workspace's sync ID (the configurationObjectLink/syncId), which is the AT:P attack requirement. The flaw lives specifically in the GET/write handlers of the /api/[workspaceId]/sources/state endpoint, where db.prisma().configurationObjectLink.findFirst(...) is invoked without await, so the ownership comparison always sees a (truthy) Promise and never fails. Limiting factors that reduce realistic risk: the attacker must be authenticated rather than anonymous, must know or obtain the victim's sync ID (not derivable from the vector alone), and only deployments running a version before 2.14.0-beta.41 are affected; impact is scoped to stream cursors (causing data re-ingestion or skipped data), not full system compromise. No user interaction is required (UI:N).

All signals point to genuinely low real-world priority, consistent with the vuln.today 'monitor' decision label and the CVSS 4.0 base score of 2.3 (Low). The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N) shows the two factors that constrain risk: PR:L means the attacker must already hold an authenticated Jitsu account, and AT:P reflects that exploitation additionally requires knowing a specific target sync ID belonging to another workspace - this is fundamentally a cross-workspace/insider threat in multi-tenant deployments, not an anonymous internet attack. Impact is limited to a single data primitive (stream cursors), hence VC:L/VI:L and no availability-of-system impact. On the exploitation-likelihood side the signals are weak-to-absent: there is no CISA KEV listing (not actively exploited), no EPSS score was provided in the input (exploitation-probability signal missing), and no public exploit code is identified - though the vendor's patch commit does publicly reveal the trivial root cause (a missing 'await'), which modestly lowers the bar for someone to reproduce it. No signals conflict; everything is mutually consistent with a low-severity authorization flaw. The one caveat is that EPSS data is missing, so probabilistic exploitation cannot be independently gauged. Bottom line: patch in a normal maintenance cycle; this is not an emergency and does not warrant out-of-band response.

In a multi-tenant Jitsu deployment, an authenticated user of one workspace learns a sync ID belonging to a different workspace and sends a request to the /api/[workspaceId]/sources/state API. Because the ownership check calls findFirst without awaiting it, the returned Promise is always truthy and the check never rejects, so the attacker can read, overwrite, or delete that other workspace's stream cursors - forcing data re-ingestion or silently skipping data. No public exploit code is identified, though the patch commit publicly discloses the exact missing-await root cause.