Froxlor EUVD-2026-87681

Requires an authenticated Froxlor account with API access (PR:L) - the lowest tier, an ordinary customer, is sufficient to retrieve that customer's own domain private keys via Certificates.get or Certificates.listing. Cross-tenant key theft additionally requires a reseller account or an admin account with the customers_see_all flag set. No user interaction, no special protocol, and no non-default configuration are needed beyond the API being enabled and TLS certificates (e.g. Froxlor-managed Let's Encrypt) existing for the targeted domains. Limiting factors: exploitation is gated on holding valid API credentials on the instance, so the practical exposure is highest on multi-tenant shared hosting where untrusted customers/resellers coexist; single-operator installs are largely self-limited.

This is a genuine, credible information-disclosure risk despite the absence of hype signals. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H) indicates trivially reachable network exploitation requiring only a low-privileged authenticated customer API account and no user interaction - a low bar in a multi-tenant hosting panel where customer accounts are the normal operating unit. There is no EPSS score, no CISA KEV listing, and no public POC provided, so exploitation is 'no public exploit identified at time of analysis' - this is not evidence of active exploitation and should be treated as a latent-but-easy-to-trigger flaw rather than an emergency. The severity floor is real: the sink returns raw PEM TLS private keys, including root-only (0600) Let's Encrypt keys the customer otherwise cannot read, so a legitimate API call crosses a clear privilege/authority boundary. The vendor's 4.0 base VC:H is defensible; I judge the vendor's VI:L generous since the API read itself has no integrity impact (impersonation/MITM are downstream consequences of the stolen key, not base integrity). Net: real priority in any environment where untrusted customers or resellers share a Froxlor instance, moderate elsewhere; not a widespread-internet-scan threat given the authentication requirement and Froxlor's niche footprint.

A low-privileged customer with API credentials on a shared Froxlor host calls Certificates.get or Certificates.listing and receives the raw PEM private keys for their own domains - including server-generated Let's Encrypt keys stored root-only that they could never read from disk. A reseller or an admin flagged customers_see_all can issue the same calls to dump other tenants' private keys, then use them for domain impersonation, passive decryption of captured TLS traffic, or active machine-in-the-middle. No public exploit code is required; the attack is a normal authenticated API request.