Ajenti CVE-2026-79920

Requires a valid authenticated account on the Ajenti panel of ANY privilege level - the vulnerability is precisely that no plugin-management permission is enforced on the /api/core/tasks/start task API (InstallPlugin, UnInstallPlugin, UpgradeAll). Exploitation works against default configurations (the missing authorization is the default state prior to 2.2.16) and needs no user interaction. The only limiting factors are: the attacker must hold or obtain a low-privileged account, and the target must run a version below 2.2.16; the task worker must be running as root (its normal operating mode) for the pip invocation to yield root code execution.

This is a genuine top-priority vulnerability, not a high-CVSS-but-low-risk case. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 9.9) is well-justified: a network-reachable, low-complexity, no-user-interaction flaw that lets a low-privileged authenticated user reach root code execution with a scope change (breaking out of the app context to the host OS). The source-code evidence corroborates the root cause - the fix commit (3a8cbee3) introduces a PermissionProvider and @authorize decorators on tasks that previously had none, confirming CWE-862 missing authorization on InstallPlugin/UnInstallPlugin/UpgradeAll. The single mitigating factor is PR:L: an attacker needs some valid (even minimal) account on the panel, so this is not fully unauthenticated. No EPSS score, no CISA KEV listing, and no public exploit are present in the provided data, so predicted/active exploitation is unquantified - the severity here rests on impact and ease of exploitation rather than confirmed in-the-wild activity. Given a server admin panel is inherently a high-value target and the pip-as-root path yields trivial, reliable root RCE, defenders should treat this as urgent regardless of the missing EPSS/KEV signals.

An attacker with any low-privileged Ajenti account (or a compromised limited account) sends a crafted POST to /api/core/tasks/start enqueuing an InstallPlugin task with an attacker-chosen package name/version. The task worker, running as root, invokes pip with that unvalidated spec, installing a malicious or attacker-controlled package whose setup code executes as root, yielding full host compromise. No public exploit is identified in the provided data, but the attack is straightforward given the documented API and root-level pip invocation.