Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:131035
Content-Type: text/plain;
	charset=us-ascii
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Subject: Re: [PHP-DEV] [Pre-RFC] Pure-code source files via .phpc extension
In-Reply-To: <CAPUh_1Y4HMigpyE4vCCP488ZQhu9UC2GKKiMjCrt3Mw2z4wk5g@mail.gmail.com>
Date: Thu, 28 May 2026 11:33:05 +0200
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <942370FC-4278-42B1-9A64-76CF428D7B7C@gmail.com>
References: <DD0DF2CC-1F18-A844-B7B8-B00FA2679A47@hxcore.ol>
 <9E95EA03-B86A-D248-A980-B1E838F94C13@hxcore.ol>
 <20260527131921.086BB1A00BD@lists.php.net>
 <8AE9A269-2E40-42F0-A0F8-C6690B2935FE@gmail.com>
 <20260528023149.C97961A00BD@lists.php.net>
 <76D39851-7DAC-4F56-9615-B98B0A918770@gmail.com>
 <20260528043224.2CDD51A00BD@lists.php.net>
 <690e2bc4-d6c9-488b-bbd7-0010437f6c15@gmail.com>
 <878E83EF-DBA2-429A-A17B-55238600E834@gmail.com>
 <CAPUh_1Y4HMigpyE4vCCP488ZQhu9UC2GKKiMjCrt3Mw2z4wk5g@mail.gmail.com>
To: go.al.ni@gmail.com
From: hmennen90@gmail.com (Hendrik Mennen)



> Am 28.05.2026 um 11:10 schrieb go.al.ni@gmail.com:
>=20
> I see a security concern in introducing a new file extension.
>=20
> It's common to configure a web server to pass locations that end with =
.php to a PHP interpreter.
>=20
> Nginx example:
>=20
> ```
> location ~ \.php$ {
>     include snippets/fastcgi-php.conf;
>     fastcgi_pass unix:/run/php/php8.2-fpm.sock;
> }
> ```
>=20
> Apache2 example:
>=20
> ```
> <FilesMatch \.php$>
>     SetHandler application/x-httpd-php
> </FilesMatch>
> ```
>=20
> 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.
>=20
> 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:

1. 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.

2. 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.

3. 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.

4. 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=