OpenPanel CVE-2026-116807

Requires an authenticated OpenPanel account with read access to at least one project (PR:L); there is no privilege escalation step and no victim interaction. The attacker sends a crafted zChartEventFilter.name (an unconstrained z.string()) through the tRPC event.events query (the same flaw also reaches getEventsCount and the funnel service), using a 'profile.'-prefixed value whose fragment after the first dot contains spaces, parentheses, ClickHouse USING(...) syntax and a trailing '-- ' comment to close the profiles JOIN subquery and comment out the outer 'WHERE project_id' scope. No special or non-default configuration is needed - default deployments of OpenPanel before 3.0.0 are vulnerable. The only limiting factor is that the attacker must hold a valid authenticated session; exploitation is otherwise remote, single-request, and returns cross-tenant results directly.

This is a genuine but moderate-priority data-confidentiality flaw, not a top-tier emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P) and the 7.0 (High) score reflect network-reachable, low-complexity exploitation that requires authentication (PR:L). The impact is cross-tenant read: an authenticated user of one project can dump event data from every project/tenant, which maps to high confidentiality impact (VC:H) with only incidental integrity effect and no availability impact. The signals are consistent with 'important but not critical': EPSS is low at 0.27% (19th percentile), the CVE is NOT on CISA KEV (no confirmed active exploitation), and the vuln.today decision label is 'this_week' rather than act_now/emergency. The one signal that raises attention is the detailed, working proof-of-concept published in the vendor's own GHSA advisory, which lowers the barrier to opportunistic abuse by any user who already has an account. Note two conflicts to verify: (1) the vendor 4.0 vector sets UI:P (passive user interaction), yet the described attack is a direct attacker-issued tRPC request with no victim interaction - UI:P appears unjustified and likely overstates one mitigating factor; (2) the GHSA 'source code evidence' block states 'fixed in: not yet patched,' which conflicts with the EUVD/vendor 'patch available' status and the presence of fixing commit a2aa053 - treat 3.0.0 as the fixed release but confirm with the vendor. Overall: real priority for any multi-tenant OpenPanel deployment because tenant isolation is broken and a PoC is public, but the authentication requirement and low EPSS argue against emergency ranking.

A legitimate low-privilege OpenPanel user with read access to a single project calls the tRPC event.events query and supplies a crafted profile filter name containing a trailing SQL comment (e.g. 'profile.email, project_id FROM profiles) AS p USING (project_id) -- '), which closes the profiles JOIN subquery and comments out the outer 'WHERE project_id' tenant scope. The response then returns events belonging to all other projects/tenants (paths, geo, profile_id, revenue, etc.). A step-by-step working PoC is published in the vendor GHSA advisory, so exploitation requires only a valid account and a single crafted API request (AV:N/AC:L).