Critical Vulnerability in CSF MESSENGER (CVE-2026-67402)-03/Sep/2026

Check: <https://nvd.nist.gov/vuln/detail/CVE-2026-67402>

A critical vulnerability was found in the MESSENGER service in the ConfigServer Firewall (CSF) software which could allow for unauthorized code execution.
An insecure Apache configuration in ConfigServer Security & Firewall maps /usr/bin as CGI programs through the Messenger v3 HTTPS virtual host. A remote unauthenticated attacker whose address is blocked can request a mapped executable and run arbitrary commands as the Apache user. The vulnerability affects installations where CSF Messenger v3 and its HTTPS mode are enabled. WebPros (Cpanel team) addressed the vulnerability in version 16.31.

This has a public CVE record listed with further information: CVE-2026-67402

Note: By default, the MESSENGER service is disabled.

Affected Product versions:
Product: csf

Affected Versions: CSF 16.30-1 and older

Patched Versions: 16.31+

Impact:
Exploiting this could allow an attacker to execute code as the Apache user.


Mitigation:

It is highly recommended that you update the installed CSF version as soon as possible.

If this is not possible, you can disable the MESSENGERV3 setting in CSF.

Access the server as the root user via SSH, or the Terminal in WHM.

Edit the CSF configuration file:

Code: [Select]

# nano /etc/csf/csf.conf
Update the MESSENGERV3 option to be disabled:

Code: [Select]

MESSENGERV3 = 0
Save and restart the CSF and LFD services:

Code: [Select]

# csf -ra

Version from Aetherinox was not updated yet. Is recommmended you use mitigation above.

Do it as soon as possible, my self server already was attacked.

Regards,
Netino

Cheers mate

Another very helpful post! Thanks much!

Thanks for posting this, especially the note that your own server was already attacked.

If exploitation actually reached the server, I wouldn't stop at upgrading CSF or setting MESSENGERV3 = 0. Those close the known entry point, but they don't establish whether anything was left behind.

I would also check recent systemd service creation/modification, unexpected cron entries, new or modified SSH authorized_keys, unusual listening ports/processes, recent executables in /tmp and similar writable locations, and suspicious processes that return after being killed.

Comparing timestamps around the suspected attack window can be particularly useful. If something was executed as the Apache user, I'd also inspect files/directories writable by that context and correlate them with the web/access logs.

I develop the CWP7 Security Audit Module, which automates a number of these evidence checks specifically for CWP7 servers and reports them as PASS / INFO / REVIEW / FAIL. I built it largely because checking these persistence indicators manually after CWP incidents became repetitive. If useful, I can explain the checks it performs — but regardless of the tool, I would definitely do a post-compromise review after applying the CSF fix.