CVE-2024-46506

What it actually does

NetAlertX versions 23.01.14 through 24.x before 24.10.12 expose a settings update path where function=savesettings does not require authentication. An unauthenticated HTTP request can modify settings and inject operating-system command syntax that is later passed through vulnerable handling in settings.php/util.php, resulting in arbitrary command execution with the privileges of the NetAlertX/web application process. Because the issue is unauthenticated and has weaponized exploitation, exposed instances can be compromised without valid credentials.

Why it matters to the business

A vulnerable NetAlertX deployment can be remotely taken over, allowing attackers to run commands, alter monitoring behavior, steal locally accessible data or credentials, deploy persistence, and pivot into networks that NetAlertX is intended to monitor. The EPSS score is high and exploitation was reported in the wild in May 2025, so internet-accessible or broadly reachable instances should be treated as urgent even though the issue is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies a reachable NetAlertX instance, commonly by scanning for exposed web interfaces. They then send an unauthenticated request to the settings update functionality, specifying function=savesettings. Because the endpoint lacks an authentication requirement, the request is processed as a legitimate settings change. The attacker places command-control characters or encoded shell syntax into a setting value that is later handled by the vulnerable code path in settings.php and util.php. When NetAlertX processes that value, the injected content is interpreted by the operating system, allowing the attacker to execute commands as the application user. After initial execution, attackers typically confirm command execution, retrieve host and network information, download additional tooling, create persistence such as cron jobs or startup scripts, and use the compromised monitoring host as a foothold for credential theft, internal reconnaissance, or lateral movement.

How to fix it

Upgrade NetAlertX to version 24.10.12 or later. For source deployments, update to a version containing commit d36486ef6de3985dac19195cf333e4de31601bcb or a later trusted release. Where Mageia 8 nodejs packaging is relevant, ensure nodejs is updated to 14.17.4-1.mga8 or later from trusted repositories, but do not treat the Node.js package update as a substitute for updating NetAlertX itself. If immediate upgrade is not possible, remove public exposure, restrict access to the NetAlertX interface using VPN or trusted administrative networks, enforce authentication at a reverse proxy, and block unauthenticated requests to settings.php and requests containing function=savesettings. Review and reset NetAlertX configuration after patching because exploitation may have modified settings. If compromise is suspected, rebuild from a known-good image, rotate credentials and API keys accessible to the service, and review downstream systems that the NetAlertX host can reach.

How to confirm the fix worked

Confirm the installed NetAlertX version is 24.10.12 or later, or that the deployed source includes commit d36486ef6de3985dac19195cf333e4de31601bcb or later. Verify the settings update path requires authentication and authorization before accepting function=savesettings requests. From an unauthenticated session, requests to settings.php with function=savesettings should be rejected with an authentication or authorization failure and should not change configuration. Review reverse proxy, WAF, and application routing rules to ensure the endpoint is not reachable anonymously. Validate that no unexpected NetAlertX settings were changed before the upgrade and that the web service account did not spawn shell, downloader, or scripting processes during the exposure window.

Typical attack path

1. Scan for reachable NetAlertX web interfaces, especially internet-facing instances.
2. Send an unauthenticated HTTP request to the settings update endpoint with function=savesettings.
3. Inject shell metacharacters or encoded command syntax into a setting value processed by the vulnerable settings.php/util.php code path.
4. Trigger processing of the malicious setting so the command executes under the NetAlertX/web service account.
5. Run discovery commands to identify the host, privileges, network interfaces, mounted paths, and reachable internal systems.
6. Download or stage additional tools using outbound HTTP, HTTPS, DNS, or other permitted egress paths.
7. Establish persistence through modified configuration, cron entries, systemd units, startup scripts, or added users where privileges allow.
8. Use the compromised system to collect secrets, alter monitoring visibility, pivot to adjacent systems, or support further intrusion activity.

How to detect it

Review web server, reverse proxy, load balancer, WAF, and NetAlertX application logs for requests to settings.php containing function=savesettings, especially requests without a valid authenticated session, requests from unfamiliar IP addresses, or requests with URL-encoded shell metacharacters. Pay close attention to the period before patching and to May 2025 or later, when in-the-wild exploitation was reported. Correlate suspicious HTTP requests with endpoint telemetry from the NetAlertX host: process creation events where the web server or NetAlertX process spawns shells or utilities such as sh, bash, dash, curl, wget, nc, ncat, python, perl, php, busybox, chmod, chattr, or base64 are high-confidence signs of exploitation. Check file integrity and timestamps for NetAlertX configuration files, settings.php, util.php, web-accessible directories, temporary directories, cron locations, systemd unit paths, and user shell startup files. Review outbound network connections, DNS queries, proxy logs, and firewall logs from the NetAlertX host for unusual downloads, command-and-control, or connections shortly after suspicious savesettings requests. Also inspect authentication logs, newly created users, SSH authorized_keys files, scheduled tasks, and modified startup scripts for persistence.

• settings.php
• util.php
• function=savesettings
• /settings.php?function=savesettings
• POST /settings.php
• GET /settings.php
• function=savesettings%3B
• function=savesettings%26
• function=savesettings%7C
• %3Bcurl
• %3Bwget
• %7Ccurl
• %7Cwget
• %24%28
• %60
• /tmp/
• /var/tmp/
• /dev/shm/
• /etc/cron.d/
• /etc/crontab
• /var/spool/cron/
• /etc/systemd/system/
• authorized_keys
• /bin/sh
• /bin/bash
• /bin/dash
• curl
• wget
• nc
• ncat
• busybox
• python -c
• perl -e
• php -r

What your security team should do

• Immediately inventory all NetAlertX deployments and determine whether any are versions 23.01.14 through 24.x before 24.10.12.
• Prioritize internet-facing or broadly reachable NetAlertX systems for upgrade or isolation because exploitation is weaponized and has been observed in the wild.
• Upgrade NetAlertX to 24.10.12 or later, or deploy source containing commit d36486ef6de3985dac19195cf333e4de31601bcb or later.
• Until upgraded, restrict access to the NetAlertX web interface to trusted administrative networks and block unauthenticated access to settings.php/function=savesettings at a reverse proxy or WAF.
• Search historical web, proxy, EDR, and process telemetry for suspicious unauthenticated savesettings requests and child processes spawned by the web or NetAlertX service account.
• If suspicious activity is found, treat the host as compromised: preserve evidence, isolate it, rotate credentials accessible from the host, rebuild from known-good media, and investigate lateral movement.
• Add detections for unauthenticated settings update attempts, encoded shell metacharacters in settings requests, and web service child processes such as sh, bash, curl, wget, nc, python, perl, or busybox.
• Review network egress from NetAlertX hosts and limit outbound connectivity to required destinations only.