Am 28.05.2026 um 11:10 schrieb go.al.ni@gmail.com:
I see a security concern in introducing a new file extension.
It's common to configure a web server to pass locations that end with .php to a PHP interpreter.
Nginx example:
location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.2-fpm.sock; }Apache2 example:
<FilesMatch \.php$> SetHandler application/x-httpd-php </FilesMatch>With a new file extension, users would be forced to change their configs, or a direct request to .phpX file would expose its source code.
This will come as a surprise to users who don't know about the pure syntax yet include libraries that use it.
Hi,
This is a legitimate concern and one the RFC must address head-on rather than wave away. Let me engage with it directly.
With a new file extension, users would be forced to change their
configs, or a direct request to .phpX file would expose its source
code. This will come as a surprise to users who don't know about the
pure syntax yet include libraries that use it.
The risk is real, and it is structurally identical to the problem that .inc files have caused for decades and that .module files caused in older Drupal setups. The path of attack is: a Composer library uses pure-code files, the consumer's web server has no handler for the new extension, an attacker requests the file by direct URL, and the server returns the source verbatim. Database credentials, API keys, business logic all exposed.
So I think the RFC has to do at least four things to take this seriously:
-
Mandatory Security section. A dedicated section in the RFC describing the exposure risk, the affected configurations, and the mitigations. Not buried, not phrased as "users should configure properly," but as a first-class concern.
-
Canonical web server configurations as part of the RFC. Apache (FilesMatch with SetHandler, plus a defensive deny rule for any other extension fallthrough), Nginx (location block extending the pattern to cover the new extension), Caddy, and FrankenPHP snippets. These would also go into php.net documentation on acceptance.
-
Composer ecosystem coordination. Before submitting the formal RFC, I plan to talk to the Composer maintainers about both autoload support and about whether the conventional vendor/ layout should be documented as the canonical mitigation (vendor outside web root, or vendor denied at the web server level). This is already a best practice for other sensitive files, but it should be promoted to documented requirement when pure-code libraries become possible.
-
Consideration of a transitional default. One option worth weighing: ship the pure-code extension support disabled by default at the SAPI level for the first PHP release that introduces it, requiring administrators to opt in via configuration. This trades some adoption friction for stronger safety during the transition period. I am not yet decided on this and would value the list's input.
What I do not think works as a mitigation:
- Engine-side refusal to serve pure-code files as text. By the time the web server is returning the file as static content, PHP is not in the request path at all. There is nothing the engine can do.
- Renaming the extension to something less guessable. The same path-traversal class of attack would still find it once libraries adopt a convention.
- Relying on users to figure it out. That is exactly the assumption that has made .inc and .module a recurring incident class.
The one structural argument in favor of the proposal here is that the population at risk is bounded by adoption: users who do not opt in to pure-code files do not have any new exposure, and users who do opt in are by definition aware of the new file type and can be expected (with proper documentation) to update their server config. But that argument only holds if the documentation is unmissable, which is exactly why the Security section has to be primary.
Thanks for surfacing this, it is going straight into the draft.
Hendrik Mennen
Maintainer, PHPolygon