HestiaCP EUVD-2026-103049

Requires a valid, authenticated HestiaCP administrator account that is NOT the protected ROOT_USER, on an instance configured with more than one admin-level account. The attacker must invoke the built-in loginas impersonation to assume the protected ROOT_USER context (which is supposed to be read-only), then submit a write request to /add/cron/ (POST with 'ok' set). The flaw is that the read_only flag is never validated before executing the write, so the same gap also affects the parallel /add/db/, /add/dns/, /add/key/, /add/mail/, /add/user/, /add/web/, /add/webapp/ and bulk endpoints per the fix diff. LIMITING FACTORS: exploitation is impossible for unauthenticated users and for ordinary hosting users; it needs administrator-level access (PR:H) and a deployment where a protected ROOT_USER is meant to be shielded from other admins - single-admin installs have little to bypass.

The vendor-supplied CVSS 4.0 vector (8.6, AV:N/AC:L/AT:N/PR:H/UI:N, VC:H/VI:H/VA:H) is internally consistent with the description: once an attacker holds a non-ROOT_USER administrator account, exploitation is network-reachable, low-complexity, and needs no user interaction, yielding full confidentiality/integrity/availability impact via command execution as the protected admin's system account. The critical limiting signal is PR:H - this is NOT an unauthenticated internet-facing bug; it is a privilege-boundary bypass that presupposes an already-authenticated administrator, so it matters most in multi-admin / multi-tenant HestiaCP installs where a protected ROOT_USER is meant to be isolated from lesser admins. No EPSS score, no CISA KEV listing, and no public POC were provided in the input, so there is no current evidence of mass or automated exploitation; this reads as a genuine but bounded privilege-escalation issue rather than an internet-scale emergency. Discovery by VulnCheck (a research vendor) indicates analyst attention, not active exploitation - do not conflate the two. Net: patch promptly on any instance with more than one admin account, but raw severity overstates spray-and-pray risk because of the PR:H precondition.

A non-root administrator on a shared HestiaCP server uses the loginas impersonation feature to enter the protected ROOT_USER context (intended to be read-only), then POSTs a crafted cron entry to /add/cron/. Because the read-only flag is never enforced on the write path, crond installs and runs the job as ROOT_USER's system account, giving the attacker command execution under a higher-privileged operator. No public exploit code was identified at time of analysis, though the fixing commit publicly reveals the exact missing read-only check.