CVE-2025-34030

What it actually does

CVE-2025-34030 is an unauthenticated OS command injection vulnerability in sar2html 3.2.2 and earlier. The vulnerable index.php endpoint passes the user-controlled plot parameter into a system-level command context without proper sanitization. A remote attacker can append shell metacharacters and commands to the plot value, causing the server to execute arbitrary operating-system commands with the privileges of the web server process. Because exploitation is network-accessible, requires no authentication, has low complexity, and can affect confidentiality, integrity, and availability, successful exploitation can lead to full host compromise, payload download, persistence, lateral movement, or service disruption.

Why it matters to the business

An exposed sar2html instance can be turned into a remote entry point for attackers without requiring credentials. Since exploitation has been observed in the wild by Shadowserver and exploit maturity is weaponized, organizations running vulnerable versions face a realistic risk of server takeover, data theft, malware deployment, cryptomining, or disruption of monitoring and reporting services. The EPSS score is high, indicating meaningful probability of exploitation activity, so internet-facing deployments should be treated as urgent even though the vulnerability is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies a reachable sar2html web interface, usually by scanning for exposed index.php pages or sar2html-specific content. The attacker then sends a crafted GET request to index.php with shell syntax embedded in the plot parameter, such as appending a semicolon followed by a command. Because the application fails to neutralize shell metacharacters before invoking a system command, the injected command is executed by the underlying operating system. Initial probes commonly use simple commands such as id, whoami, uname, or pwd to confirm execution. After confirmation, the attacker may issue commands to enumerate the host, retrieve payloads with curl or wget, establish a reverse shell, add persistence through cron or web-accessible files, or deploy malware. Command output may be reflected in the application interface after interacting with the host selection UI, giving the attacker confirmation that the command ran successfully.

How to fix it

Upgrade sar2html to a version that fixes the plot parameter command injection issue if a maintained fixed release is available. If no fixed version is available from the project or package source, remove sar2html, disable the web interface, or replace it with a maintained alternative. As an immediate mitigation, restrict access to sar2html to trusted administrative networks only, place it behind strong authentication, and block public internet access. Add web server or WAF rules that reject plot parameter values containing shell metacharacters such as semicolon, pipe, ampersand, backticks, $(), newline characters, or URL-encoded equivalents. Run the web server under a least-privileged account, disable unnecessary outbound network access from the host, and review local hardening controls to limit post-exploitation impact. Sanitization should not rely only on filtering; the application should avoid shell invocation where possible and use safe argument handling or allowlisted values for plot selection.

How to confirm the fix worked

Confirm all sar2html deployments are inventoried and verify that no instance is running version 3.2.2 or earlier unless it is isolated and otherwise mitigated. Validate exposure by checking whether the sar2html web interface or index.php endpoint is reachable from untrusted networks. Test mitigations safely by sending a benign request containing encoded shell metacharacters in the plot parameter and confirming it is blocked, rejected, or treated as inert input rather than executed. Review package inventories, web roots, container images, and appliance bundles for sar2html files. Confirm WAF and web server access-control rules are active and logging. Where an upgrade or removal was performed, restart the relevant web service and verify the vulnerable endpoint is no longer exploitable.

Typical attack path

1. Scan for internet-facing sar2html instances or pages exposing index.php.
2. Confirm the target is running sar2html 3.2.2 or earlier, or test for vulnerable behavior directly.
3. Send a crafted request to index.php with command separators in the plot parameter, for example a semicolon followed by a benign command.
4. Review the application response or UI behavior to confirm command execution output.
5. Run host discovery commands such as id, whoami, uname, hostname, ip addr, or env.
6. Download and execute follow-on payloads using curl, wget, Python, Perl, Bash, or similar tooling.
7. Establish persistence through cron jobs, modified web files, SSH keys, or service changes.
8. Use the compromised host for data access, lateral movement, cryptomining, botnet activity, or further scanning.

How to detect it

To determine whether exploitation already occurred, review web server access logs, reverse-proxy logs, WAF events, EDR telemetry, command execution logs, shell history, process creation events, cron files, and outbound network connections from hosts running sar2html. Focus on requests to index.php where the plot parameter contains shell metacharacters or URL-encoded equivalents, especially probes using id, whoami, uname, pwd, env, cat, curl, wget, bash, sh, nc, python, or perl. Correlate suspicious HTTP requests with process execution by the web server user, such as www-data, apache, nginx, httpd, or daemon spawning /bin/sh, /bin/bash, curl, wget, or scripting interpreters. Look for command output reflected in application responses, unusual files written under the web root or /tmp, new scheduled tasks, new SSH authorized_keys entries, unexpected outbound connections, reverse shells, cryptomining processes, and failed or blocked WAF requests matching command injection patterns. Because Shadowserver observed exploitation evidence on 2025-02-04 UTC and exploit maturity is weaponized, logs should be reviewed back to at least that date where retained, and any exposed instance should be assumed targeted until proven otherwise.

• GET /index.php?plot=;id
• GET /index.php?plot=%3Bid
• GET /index.php?plot=;whoami
• GET /index.php?plot=%3Bwhoami
• GET /index.php?plot=;uname
• GET /index.php?plot=%3Buname
• GET /index.php?plot=;pwd
• GET /index.php?plot=%3Bpwd
• /index.php?plot=|
• /index.php?plot=%7C
• /index.php?plot=`
• /index.php?plot=%60
• /index.php?plot=$(
• /index.php?plot=%24%28
• /index.php?plot=&&
• /index.php?plot=%26%26
• /index.php?plot=%0a
• /index.php?plot=%0A
• /index.php?plot=;curl
• /index.php?plot=%3Bcurl
• /index.php?plot=;wget
• /index.php?plot=%3Bwget
• /index.php?plot=;bash
• /index.php?plot=%3Bbash
• /index.php?plot=;sh
• /index.php?plot=%3Bsh
• /index.php?plot=;nc
• /index.php?plot=%3Bnc
• /index.php?plot=;python
• /index.php?plot=%3Bpython
• /index.php?plot=;perl
• /index.php?plot=%3Bperl
• /bin/sh -c
• /bin/bash -c
• www-data sh
• www-data bash
• apache sh
• apache bash
• nginx sh
• nginx bash
• httpd sh
• httpd bash
• /tmp/
• /var/spool/cron/
• /etc/cron.d/
• authorized_keys

What your security team should do

• Immediately identify all sar2html deployments, including unmanaged web directories, containers, appliances, and legacy monitoring hosts.
• Prioritize internet-facing sar2html instances for emergency remediation because exploitation is weaponized and in-the-wild scanning has been observed.
• Upgrade to a fixed maintained release where available; otherwise remove sar2html or disable access to the web interface.
• Restrict access to trusted administrative networks and require authentication for any remaining deployment.
• Deploy WAF or reverse-proxy rules to block shell metacharacters and URL-encoded command separators in the plot parameter.
• Hunt web logs for suspicious index.php requests containing plot= followed by semicolons, pipes, backticks, command substitution, or encoded equivalents.
• Investigate any web server child process spawning shell utilities or network download tools such as sh, bash, curl, wget, nc, python, or perl.
• Check for post-exploitation artifacts such as new cron entries, unexpected web files, unauthorized SSH keys, reverse shell activity, miners, or outbound connections to unknown infrastructure.
• If exploitation is suspected, isolate the host, preserve logs and volatile evidence, rotate credentials or secrets accessible from the server, and rebuild from a trusted image if integrity cannot be assured.