OpenPanel EUVD-2026-110513

Exploitation requires an authenticated session as a read-level (or higher) member of the target OpenPanel project (CVSS PR:L; the client.list query correctly enforces requireProjectAccess at read level), and the attacker must supply a valid project ID. No user interaction, admin rights, or non-default configuration is needed - the leak is inherent to the unfiltered db.client.findMany call (no select/omit) in versions before 3.0.0. Limiting factors that reduce realistic risk: membership in the project is mandatory (not remote-unauthenticated), and the exposed secrets are ~80-bit random values stored as argon2id hashes, making offline recovery impractical, so the disclosure chiefly enables silent offline verification of already-leaked secrets rather than direct credential theft.

This is a genuinely low-priority, low-real-risk issue despite being a confirmed information disclosure (CWE-200). Every signal agrees: the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) yields a base of 5.3 but with only partial confidentiality impact (VC:L, VI:N, VA:N, no scope change); EPSS is 0.22% (12th percentile), indicating very low predicted exploitation; SSVC records Exploitation:none, Automatable:no, Technical Impact:partial; and there is no CISA KEV listing. The vuln.today decision label is 'this_month', consistent with 'fix in normal cycle, not an emergency.' Crucially, the disclosed material is argon2id hashes (memoryCost 19456, timeCost 2) of ~80-bit random (crypto.randomBytes) ingestion secrets, so the advisory itself assesses offline recovery as impractical - the value is defense-in-depth, not direct compromise. The one apparent conflict is patch status: the input says 'Patch: Available from vendor' and a fix commit (e37d15c) is present, while the GHSA advisory body still reads 'fixed in: not yet patched' - the fix exists in commit form; verify the released fixed version (3.0.0 per the description/EUVD) with the vendor.

An authenticated read-level member of an OpenPanel project issues the client.list tRPC query with the project ID and receives full Client rows including the secret column - the argon2id hashes of every ingestion credential they can neither mint nor revoke. A public PoC request exists in the GHSA advisory but is not verified as working exploit code; practical abuse is limited because the hashed secrets are ~80-bit random values, so the main realistic use is silently confirming a secret-to-project pairing obtained through another channel, offline and without any audit trail.