PHP security team warns of unpatched RCE flaw in non-default configurations

What happened

The PHP security team has warned of a new remote code execution (RCE) vulnerability that currently has no official patch, according to a security write-up published on dev.to. The flaw is not believed to affect every PHP installation. Instead, it puts at risk servers running certain non-default configurations — in particular, custom php.ini settings that expand what an attacker can reach.

How the flaw is described

The dev.to post, which carries a disclosure that it was written with AI assistance, summarises what it describes as the official PHP security advisory. It says an attacker can run arbitrary code on a server when a carefully constructed request reaches a PHP process in which vulnerable configuration options are switched on. With no fixed release available, the security team has shared interim configuration changes meant to close off the attack route until a patched PHP release appears.

Two gaps are worth flagging: the post names no CVE identifier and lists no affected PHP versions. Administrators should treat the summary as a starting point and confirm the details against official PHP channels before acting.

The recommended mitigations

According to the post, the security team advises the following php.ini changes, applied only where they suit a particular environment:

• Set expose_php = Off so PHP stops advertising its version in HTTP headers.
• Set allow_url_fopen = Off to block remote file access through URL wrappers.
• Set allow_url_include = Off so remote PHP files cannot be included.
• Use disable_functions to remove high-risk calls such as exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file and show_source.
• Set open_basedir to confine file system access to the application's directory tree.
• Review any custom auto_prepend_file or auto_append_file directives, which the report says could be turned against the server.

After changing settings, whether in php.ini or in per-pool configuration, the PHP service needs a restart for them to take effect. Testing first is wise, since removing functions or URL wrappers can break applications that rely on them.

Part of a broader wave of developer-focused attacks

The same post frames the PHP alert within a run of incidents aimed at developers and supply chains. It cites a compromise of the LiteLLM project's PyPI package and Docker images, used to spread info-stealing malware that harvests credentials and environment variables; a warning from the cloud platform Railway, which told customers to rotate secrets after suspicious activity in its environment-variable storage; and a UEFI bootkit dubbed BlackX that exploits the Baton Drop flaw to get around Secure Boot.

On that basis, the post recommends that engineering teams rotate API keys, database credentials and environment variables where relevant, audit dependency manifests such as composer.json and package.json for tampered packages, and watch official PHP channels for the formal patch.

Why it matters

An unpatched RCE in one of the web's most widely deployed runtimes would be serious on its own, but the configuration-dependent scope makes triage harder. There is no version number to check against; the question for every sysadmin becomes what their php.ini actually enables. Shared hosting, legacy applications and hand-tuned deployments are precisely where non-default settings accumulate, and each of those now needs an audit rather than a routine upgrade.

Until a patch lands, configuration hardening is the only defence, which makes the directives above the practical to-do list. The episode is also a reminder that verification matters: the details circulating so far come from a secondary, AI-assisted summary, so confirming against the official advisory — and testing changes before production — belongs at the centre of the response, not the edge.