Beszel CVE-2026-94382

Requires a valid authenticated Beszel account of any privilege level, including read-only users (confirmed by the patch's readOnlyUser test cases). The attacker must supply a valid target system ID in the POST/DELETE body of /api/beszel/user-alerts; because Beszel/PocketBase system record IDs are 15-character random identifiers, successful exploitation depends on knowing or guessing them (the CVSS AT:P requirement). Exploitation is most realistic on multi-user/multi-tenant instances; a single-user deployment or one running with SHARE_ALL_SYSTEMS=true has no meaningful boundary to cross. Impact is limited to disclosure of target system names/metrics and tampering with alert rules - no data destruction, code execution, or service disruption.

This is a genuine but low-severity authorization flaw, not a high-impact issue. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N, base 2.3) correctly captures modest impact: an authenticated, low-privileged user can cross an object-ownership boundary but only gains partial confidentiality (system names/metrics) and partial integrity (alert-rule creation/deletion) - no availability or code-execution impact. The AT:P (attack-requirement present) metric is well-justified because valid target system IDs must be known or guessed; Beszel is built on PocketBase, whose record IDs are 15-character random strings, so blind exploitation is non-trivial on a well-populated instance. No EPSS score, KEV listing, or POC is provided in the input, and VulnCheck reported it as a coordinated disclosure with a vendor patch rather than observed exploitation - so there is no signal of real-world attacks. My independent 3.1 assessment (~5.4, S:U/C:L/I:L) reads slightly higher than the vendor 4.0 figure, reflecting the known tendency of CVSS 4.0 to score all-Low, single-requirement bugs lower than 3.1; the two frameworks are consistent in substance. Net: real but low priority - patch during normal maintenance, prioritize on multi-tenant/shared instances.

On a shared Beszel instance, a low-privileged (even read-only) user sends a POST to /api/beszel/user-alerts with a JSON body containing another tenant's system ID, registering an alert rule on a system they have no access to. When that alert fires, the attacker receives notifications that disclose the target system's name and metric values, leaking monitoring data across the ownership boundary; the DELETE handler similarly lets them remove others' alerts. No public exploit code is identified in the provided data, though the fix commit and its tests concretely demonstrate the vulnerable request shape.