CVE-2026-27975: Critical Unauthenticated RCE in Ajenti Lets Attackers Take Over Servers Without Login

Ajenti – Unauthenticated Remote Code Execution (RCE)

CVE ID: CVE-2026-27975
Product: Ajenti (web-based server administration panel)
Affected Versions: Prior to 2.2.13
Fixed Version: 2.2.13 and later
Severity: High / Critical
CVSS v4.0 Score: 8.1
Attack Vector: Network
Authentication Required: None
User Interaction: None
Impact: Full remote code execution on the underlying server

An unauthenticated remote code execution vulnerability was identified in Ajenti versions prior to 2.2.13. The flaw allows remote attackers to execute arbitrary commands on the server without logging in. Since Ajenti is typically installed with elevated privileges to manage system services, exploitation may result in full system compromise.

This issue was resolved in version 2.2.13. Immediate upgrade is strongly advised.

Official Patch / Upgrade Link: Link provided below.

Technical Summary

The vulnerability stems from improper access control within Ajenti’s web application layer. Certain backend functionality that should have required authentication was exposed to unauthenticated requests. Through crafted HTTP requests, backend functionality capable of executing system-level operations could be triggered.

Because Ajenti operates as a privileged service and interacts directly with system components (processes, terminal sessions, configuration files), exploitation enables arbitrary command execution in the context of the Ajenti service account. In many deployments, this results in root-level execution.

The flaw is categorized under:

CWE-284 – Improper Access Control
Remote command execution via exposed administrative functionality

Affected Environment

Ajenti is commonly deployed on:

Linux servers (Ubuntu, Debian, CentOS, etc.)
VPS infrastructure
Cloud-hosted management servers
Internet-facing administrative panels

Risk significantly increases when:

Ajenti is directly exposed to the internet
No IP restriction or firewall filtering is in place
It is running with root privileges (default in many setups)

Exploitation Conditions

For successful exploitation, the following conditions are sufficient:

The server is running Ajenti version < 2.2.13
The Ajenti web interface is reachable over the network
No WAF or restrictive filtering blocks malicious HTTP requests

No valid credentials are required. No user interaction is required.

Attack complexity is low.

How Exploitation Could Occur

Although detailed exploit code is not published here, exploitation would generally follow this pattern:

Attacker identifies exposed Ajenti instance.
Crafted HTTP requests are sent directly to vulnerable endpoints.
Backend logic processes request without enforcing authentication.
Command execution functionality is triggered.
Arbitrary system commands are executed.

Typical post-exploitation behavior may include:

Reverse shell execution
Creation of new administrative users
Deployment of persistence mechanisms
Data exfiltration
Installation of backdoors or ransomware

Because Ajenti provides system-level administrative capabilities, exploitation impact is equivalent to full server takeover.

Proof of Concept (Educational)

At the time of documentation, no widely published public exploit kit has been observed. However, due to the simplicity of the vulnerability (unauthenticated RCE), proof-of-concept development is considered straightforward for experienced attackers.

Indicators of a potential exploitation attempt may include:

Direct POST requests to administrative endpoints
Unexpected invocation of system commands
Creation of new processes spawned by the Ajenti service

MITRE ATT&CK Mapping

Initial Access

T1190 – Exploit Public-Facing Application

Execution

T1059 – Command and Scripting Interpreter

Persistence

T1543 – Create or Modify System Process
T1053 – Scheduled Task / Cron

Privilege Escalation

T1068 – Exploitation for Privilege Escalation

Defense Evasion

T1070 – Indicator Removal on Host

Impact

T1486 – Data Encrypted for Impact
T1490 – Inhibit System Recovery

Detection Strategy

Detection should focus on three layers:

Web traffic monitoring
Application log analysis
Host-level process monitoring

Because exploitation requires no authentication, abnormal unauthenticated API calls are primary indicators.

Log Sources to Monitor

Web server access logs (Nginx / Apache)
Ajenti application logs
Linux auditd logs
Syslog / journald
EDR process creation logs
Firewall and IDS telemetry
Netflow logs

Detection Queries (SIEM / Log Analysis)

1. Suspicious HTTP POST Requests to Ajenti

Splunk

index=web_logs host="ajenti_server"
method=POST
| stats count by clientip, uri, useragent
| where count > 5

2. Large HTTP Request Bodies

index=web_logs host="ajenti_server"
| eval body_length=len(_raw)
| where body_length > 800
| stats count by clientip, uri

Large payloads may indicate encoded command injection attempts.

3. Ajenti Spawning Shell Processes

index=linux_process_logs
parent_process="ajenti"
process_name IN ("bash","sh","nc","python","socat")

Ajenti normally should not spawn arbitrary shell interpreters without administrator interaction.

4. Unexpected Outbound Connections

index=netflow_logs host="ajenti_server"
| where dest_ip NOT IN (trusted_internal_ranges)
| stats count by dest_ip, dest_port

Reverse shells commonly generate outbound traffic to uncommon external IP addresses.

5. Creation of New System Users

index=linux_audit_logs
command="useradd" OR command="adduser"

6. Cron Job Persistence

index=linux_audit_logs
file_path="/etc/cron*" OR command="crontab"

Behavioral Indicators of Compromise

Unknown administrative users created
Suspicious cron entries
Modified systemd service files
Unexpected SSH authorized_keys changes
Outbound traffic to unfamiliar IP addresses
Base64-encoded strings in logs
Long POST bodies with encoded payloads

Response Recommendations

If exploitation is suspected:

Immediately isolate the server from the network.
Preserve logs before rebooting.
Capture running processes and open network connections.
Check integrity of system binaries.
Rotate all credentials stored or managed by the server.
Rebuild system from trusted image if compromise is confirmed.

Because root-level execution is possible, full system rebuild is often safer than partial remediation.

Mitigation and Hardening

Upgrade to Ajenti 2.2.13 or later immediately.
Restrict access to Ajenti to internal IP ranges.
Place Ajenti behind VPN.
Implement firewall rules to block public exposure.
Enable multi-factor authentication.
Monitor process execution continuously.
Deploy file integrity monitoring.
Enable auditd with execve logging.

Risk Assessment

If Ajenti is exposed to the internet and running a vulnerable version:

Likelihood of exploitation: High
Impact of exploitation: Critical
Time to compromise: Potentially minutes after exposure

Servers running vulnerable versions should be treated as high-risk assets.

Official Patch

Upgrade to the fixed version immediately:

https://github.com/ajenti/ajenti/releases/tag/v2.2.13

No workaround fully mitigates the issue other than upgrading or completely restricting network access.