CVE-2026-79920: Ajenti Root Code Execution
TL;DR - Ajenti versions before 2.2.16 expose privileged plugin-management tasks to authenticated users. - A low-privileged account may trigger root-run
pipoperations and achieve code execution. - Upgrade to Ajenti 2.2.16 or later immediately, restrict panel access, and investigate unexpected package or plugin changes.
Summary
CVE-2026-79920 is a critical Ajenti privilege escalation vulnerability affecting the plugin-management task endpoint in Ajenti, a modular administration panel for Linux and BSD systems. An authenticated user without the required administrative authorization may install, remove, or upgrade plugins through operations executed by a root-privileged worker.
The issue can enable root code execution on the underlying host. Although an attacker needs valid Ajenti credentials or another way to authenticate to the panel, the account may have low privileges and does not need full administrative authorization.
| Field | Assessment |
|---|---|
| CVE ID | CVE-2026-79920 |
| CVSS score | 9.9 |
| CVSS vector | Not included in the retrieved NVD record |
| Attack vector | Network-accessible Ajenti administration interface, based on the exposed API endpoint |
| Authentication | An authenticated Ajenti account is required |
| Privileges required | Low privilege is sufficient; administrator authorization is not properly enforced |
| Patch available | Yes |
| Fixed version | Ajenti 2.2.16 |
| CISA KEV status | Not listed |
The practical risk is substantially higher than that of a normal administrative-plane bug. An attacker still needs valid Ajenti credentials or another way to authenticate to the panel, but the vulnerable functionality can turn a limited account into root-level execution on the host.
Treat exposed Ajenti panels and accounts issued to untrusted or semi-trusted users as high-priority assets.
Root Cause
The vulnerable functionality is associated with the /api/core/tasks/start endpoint and plugin-management tasks in plugins/plugins/tasks.py. The affected task types include:
InstallPluginUnInstallPluginUpgradeAll
According to the available vulnerability description, any authenticated user can queue these tasks even though they require stronger plugin-management authorization.
The flaw is compounded by insufficient validation of the name and version fields used to construct a pip package specification. The task worker then invokes pip with root privileges. An account that should have limited panel access can therefore influence a package-management operation performed by a root process.
The resulting impact depends on the package specification accepted by the vulnerable code and the host’s package and network configuration. Successful exploitation can install or update code that executes during installation or later service operation. It can also alter the host’s Python environment or Ajenti installation.
The security outcome is arbitrary code execution as root and potential complete compromise of the server.
Who Is Exposed?
The directly affected product is the Ajenti open-source server administration panel hosted by the Ajenti project. The affected version range is:
| Product | Affected versions | Fixed version | Platform scope |
|---|---|---|---|
| Ajenti | All versions before 2.2.16 | 2.2.16 and later | Supported Linux and BSD installations where the vulnerable plugin-management functionality is available |
The available record does not identify separate operating-system-specific version ranges. Assume that any Ajenti installation earlier than 2.2.16 is exposed if the panel is reachable and the vulnerable task functionality is enabled.
This includes deployments where Ajenti is bound to an internal address. Compromise of an internal management panel can still provide root access to a production or infrastructure host.
Exposure requires more than merely running an old Ajenti release. The attacker needs an authenticated Ajenti account, but the account does not need full administrative privileges. Systems with shared, legacy, contractor, service, or otherwise weakly governed Ajenti accounts deserve particular attention.
Internet-facing panels are especially risky because credential attacks, stolen sessions, and account reuse can satisfy the authentication requirement. Use unique credentials and a reputable password manager, such as Try 1Password →, for accounts that can access administrative interfaces.
Severity Breakdown
NVD assigns CVE-2026-79920 a CVSS base score of 9.9, classified as critical. The score reflects a vulnerability that can lead from access to a network-reachable administration interface to root-level code execution and full compromise of the host.
The required authentication condition reduces exploitability compared with an unauthenticated flaw, but the affected account can be low privilege.
The retrieved NVD response did not include the CVSS vector string. As a result, the individual vector components—including exact attack complexity, user interaction, scope, and confidentiality, integrity, and availability impact values—cannot be stated reliably here.
Defenders should not infer missing components from the 9.9 score. For risk prioritization, the confirmed facts are sufficient:
- The vulnerable functionality is available through a network-accessible panel.
- An authenticated low-privileged account may be enough.
- Package operations run with root privileges.
- Successful exploitation may result in complete host compromise.
A high CVSS score does not establish active exploitation. It does, however, justify emergency remediation where vulnerable Ajenti systems are reachable by users outside the trusted administration team or where panel credentials may have been exposed.
Analyst’s Take: The authentication requirement narrows the initial access condition, but it does not make this a routine panel vulnerability. Because a low-privileged account can reach root-run package operations, exposed panels and accounts should be reviewed while the upgrade is being scheduled, not afterward.
Exploitation Status
No confirmed in-the-wild exploitation was identified in the primary-source records reviewed for this assessment. CVE-2026-79920 is also not listed in the CISA Known Exploited Vulnerabilities catalog. No CISA KEV date, due date, required action, or ransomware-campaign designation has been added for this CVE.
No confirmed public proof-of-concept repository was identified in the sources checked. The NVD record, upstream commits, release information, and security advisory document the vulnerability and its fix, but they do not establish that a working exploit has been published.
This status can change quickly after disclosure, particularly because the vulnerable endpoint, task names, and privilege boundary are described publicly.
The absence of a public PoC or KEV listing is not evidence that exploitation is impossible. Organizations should assume that exploitation may become practical without a public repository, especially where Ajenti is exposed to untrusted networks.
Apply the fix based on exposure and impact rather than waiting for exploitation confirmation.
Technical Verification
A basic service and package verification sequence is:
sudo systemctl status ajenti --no-pager
python3 -m pip show ajenti
python3 -m pip check
Where the service uses a virtual environment, locate the configured interpreter before checking the version:
sudo systemctl cat ajenti
sudo find / -path '*/bin/ajenti' -type f -print 2>/dev/null
The remediation target is unambiguous: Ajenti 2.2.16 or later.
If the installed version cannot be verified, treat the deployment as vulnerable until its package source, interpreter, and running service are confirmed.
Prioritize upgrade or isolation first for panels reachable by untrusted networks and for installations with low-privileged or weakly governed accounts. After that, use the detection steps to determine whether plugin, package, or host changes require incident response.
Sources
The primary vulnerability record is the NVD entry for CVE-2026-79920:
Upstream project material identifies the relevant changes and the release containing the fix:
- Ajenti security advisory: GHSA-j8xf-5fw2-f99q
- Ajenti fix commit
- Ajenti fix commit
- Ajenti v2.2.16 release
CISA catalog status can be checked against the current Known Exploited Vulnerabilities catalog:
The available records support the affected range of versions before 2.2.16, the 9.9 CVSS score, the root-level impact, and the absence of a current KEV listing. They do not provide a CVSS vector string, confirmed public PoC, or confirmed in-the-wild exploitation for this CVE.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection Guidance
Start with Ajenti and host-level evidence around plugin-management activity. Look for requests to /api/core/tasks/start, especially when the authenticated account is not an administrator or when the request is followed by installation, removal, or upgrade activity.
The exact log format varies by deployment, and the available vulnerability information does not identify a universal Ajenti log filename or message format.
A useful initial search is:
sudo grep -RInaE \
'/api/core/tasks/start|InstallPlugin|UnInstallPlugin|UpgradeAll|pip(3)? .*install|pip(3)? .*uninstall' \
/var/log /var/lib 2>/dev/null
For environments shipping web or reverse-proxy logs to a SIEM, search for the endpoint and correlate the source address, authenticated username, HTTP status, and timestamp with process execution:
url.path:"/api/core/tasks/start"
OR message:(InstallPlugin OR UnInstallPlugin OR UpgradeAll)
Then correlate those events with process telemetry for:
pippip3- Python package installers
- Changes under the Ajenti installation directory
- Changes under Python package directories
- Outbound connections to package repositories
A high-value pattern is a non-administrative Ajenti account accessing the task endpoint, followed shortly by a root-owned pip install, package removal, plugin-directory modification, or outbound connection to a package repository.
Detection should also include inventory comparison. Record currently installed Python packages and Ajenti plugins, then compare them with approved baselines. For organizations formalizing these controls, a documented vulnerability-management process can help connect inventory, remediation, and incident response requirements. See our guide to building a practical vulnerability management program.
For example:
python3 -m pip list --format=freeze | sort > /tmp/pip-list.current
find /var/lib/ajenti /usr/lib/python* /usr/local/lib/python* \
-type f -mtime -14 -print 2>/dev/null
These commands are investigative rather than definitive. Legitimate administrative work can produce the same process and file patterns, so validate findings against approved change tickets, the initiating account, package source, and the time of the operation.
Remediation Steps
1. Upgrade Ajenti
Upgrade every affected installation to Ajenti 2.2.16 or later. The exact package-management command depends on how Ajenti was installed and which operating system repository is used.
First identify the installation source and test the upgrade through the organization’s normal change process. Do not blindly run a distribution-specific command in production.
For a Python package installation, an administrator may use the project’s supported package workflow, for example:
python3 -m pip install --upgrade 'ajenti>=2.2.16'
Confirm the result using the installation’s actual executable and package environment:
python3 -m pip show ajenti
ajenti --version
If Ajenti was installed from a distribution package, vendor repository, container image, or source checkout, use the corresponding supported upgrade path and verify that it reports version 2.2.16 or later.
Upgrading a system-wide Python package does not necessarily update a virtual environment or service-specific installation.
2. Restrict Panel Access
Until the upgrade is complete, restrict access to the Ajenti interface using one or more of the following controls:
- Firewall rules
- A management VPN
- An IP allowlist
- An authenticated reverse proxy
- Network segmentation
- Temporary service shutdown where operationally acceptable
Disable or remove unnecessary Ajenti accounts, rotate credentials for accounts that may have been exposed, and avoid granting panel access to untrusted users.
If immediate isolation is not possible, stop the Ajenti service where operationally acceptable. There is no confirmed configuration-only workaround in the available advisory material that reliably corrects the authorization and root-executed package-management flaws.
3. Investigate Potential Compromise
After upgrading, review Ajenti and host logs for unexpected requests and package activity. Audit the following for unauthorized changes:
- Installed Python packages
- Ajenti plugins
- Service files
- Scheduled tasks
- SSH keys
- Local users
- Privileged binaries
- Startup scripts
- Network connections
If an untrusted user could authenticate to a vulnerable panel, treat the host as potentially compromised rather than relying solely on version remediation. Preserve relevant logs and investigate before rebuilding or erasing evidence.
Recommended Response Priority
Organizations can prioritize affected Ajenti systems as follows:
- Immediately isolate internet-facing panels that run versions before 2.2.16.
- Identify all Ajenti accounts, including legacy, contractor, service, and shared accounts.
- Upgrade to Ajenti 2.2.16 or later using the correct installation-specific process.
- Review authentication and task logs for suspicious access.
- Compare installed packages and plugins against approved baselines.
- Investigate the host for persistence or unauthorized changes if a vulnerable panel was accessible to untrusted users.
- Rotate potentially exposed credentials after containment and evidence preservation.
Security teams should also review whether Ajenti management interfaces are appropriately covered by their broader access-control, logging, and incident-response procedures.