Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I have an Debian server with Apache which is serving various PHP applications
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
I start apt dist-upgrade which updated apache2 to a newer version
   * What was the outcome of this action?
During the run of apt dist-upgrade, apache suddenly delivered the .php files uninterpreted in cleartext to the clients, revealing any secrets, database connection strings, passwords, API keys, ... to the user requesting the page.
After apt dist-upgrade was complete, apache correctly interpreted the .php files again
   * What outcome did you expect instead?
I would have expected apache2 to not leak the .php sourcecodes, to either correctly interpret .php files during the migration, or to have apache2 stopped during the migration if that is not possible.

I have sent this report to the Debian Security Team first, and they told me to file a public report instead.

Dear Philipp,

please tell us how exactly are you running the PHP interpreter in your apache
(mod_php or PHP-FPM or...)?

Also, please include relevant configuration parts from mods-enabled, conf-
enabled, sites-enabled.

Regards,
Moritz

I've noticed the same with upgrades of systems at $DAYJOB where libapache2-mod-php8.4 did not get enabled automatically after the upgrade of libapache2-mod-php.

The upgrade procedure for those systems added steps to explicitly enable it:

  a2enmod php8.4
  service apache2 restart

Kind Regards,

Bas

Hi,

Le Sat, Dec 13, 2025 at 08:54:04AM +0100, Sebastiaan Couwenberg a écrit :

Thanks for the feedback. The initial bug report also seem to imply that
the issue happens “During the run of apt dist-upgrade”, i.e., during a
major upgrade. Maybe this issue should rather be documented in the
release notes actually, and it may not be specific to PHP either.

Regards,

taffit