The PHP project recently announced two critical security vulnerabilities. You can read more about these on their websites:
https://www.php.net/archive/2026.php#2026-10-21-5
As IT teams are handling these vulnerabilities, figuring out where they are affected and what systems need to be upgraded, we’ve gotten requests from customers to clarify if our products are affected. Thus, to make this information easily available to everyone we’ve decided to put this clarification here;
Impact
CFEngine Enterprise Hub uses PHP and is assumed to be affected by these vulnerabilities.
With the limited information available, we have not been able to confirm that these vulnerabilities are exploitable in CFEngine, but we are working with the assumption that they are. In order to exploit one of these vulnerabilities, an attacker would need network access to your hub. We recommend limiting network access to your CFEngine hub to the systems / users / subnets which are necessary, for example using a firewall or VPN technology (if you haven’t done so already). If an attacker can open up the Mission Portal login page in their browser, we can assume they will be able to use these vulnerabilities to take over the hub.
Normally, we try to notify customers in advance of such announcements, to give them time to upgrade, however in this case we do not have this luxury - the PHP vulnerabilities are widely known and publicized, and it is publicly documented that CFEngine uses one of the vulnerable PHP versions. Thus, we urge all customers to address this as urgently as possible, either fixing the issue through an upgrade, or applying one of the mitigations listed below.
Fix
To fix these vulnerabilities upgrading the version of PHP is necessary. This is done by upgrading the CFEngine Enterprise Hub package (which includes PHP).
- CFEngine Enterprise 3.24.6 upgrades PHP from 8.3.35 to 8.3.36 (patched version).
- CFEngine Enterprise 3.27.3 upgrades PHP from 8.5.11 to 8.5.12 (patched version).
Upgrading the hub package (.rpm or .deb) is enough in this case, it is not necessary to upgrade all the clients since they do not use PHP.
For more information on upgrading, see our documentation:
https://docs.cfengine.com/docs/lts/getting-started/01-installing-cfengine/upgrading
Mitigation
Until an upgrade is possible, these issues can be mitigated using one of the following approaches:
- Use your firewall to completely block all traffic to Mission Portal (block incoming traffic on port 80 and 443).
- Shut down Apache on the hub.
Warning: These mitigations will make Mission Portal unavailable for users / integrations which rely on it.
Shutting down Apache
By default, CFEngine and systemd work to keep Apache up and running, thus, disabling it takes a few steps. Apply this diff to your policy to prevent CFEngine from restarting Apache automatically when it sees that it’s not running:
diff --git a/cfe_internal/enterprise/mission_portal.cf b/cfe_internal/enterprise/mission_portal.cf
index 6348154..ce06a50 100644
--- a/cfe_internal/enterprise/mission_portal.cf
+++ b/cfe_internal/enterprise/mission_portal.cf
@@ -524,11 +524,11 @@ bundle agent cfe_internal_webserver(state)
commands:
start_cfe_httpd::
- "LD_LIBRARY_PATH=$(sys.workdir)/lib:$LD_LIBRARY_PATH $(sys.workdir)/httpd/bin/apachectl start"
- comment => "Start CFE httpd process if not exist",
- classes => kept_successful_command,
- handle => "cfe_internal_webserver_commands_start_cfe_httpd",
- contain => in_shell;
+ # "LD_LIBRARY_PATH=$(sys.workdir)/lib:$LD_LIBRARY_PATH $(sys.workdir)/httpd/bin/apachectl start"
+ # comment => "Start CFE httpd process if not exist",
+ # classes => kept_successful_command,
+ # handle => "cfe_internal_webserver_commands_start_cfe_httpd",
+ # contain => in_shell;
}
bundle agent cfe_enterprise_selfsigned_cert
Commit and deploy this patched policy set through your usual means.
Then shut down Apache:
systemctl stop cf-apache ; systemctl disable cf-apache ; systemctl mask cf-apacheIn case Apache was not started by systemd, run:
/var/cfengine/httpd/bin/apachectl stopNot affected
Our websites (cfengine.com, docs.cfengine.com, build.cfengine.com) do not use PHP and are not affected.
CFEngine Community (Open Source) does not use PHP and is not affected.
The CFEngine Enterprise client is also not directly affected, although taking over the hub normally gives you access to control the clients as well.
Please reach out to support if you need further assistance:
