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

Hi,

* David Prévot [Mon Jan 19, 2026 at 03:57:46PM +0100]:
the behavior, but wasn't able to do so. This might indeed be
configuration/setup specific?

This feels like a *different* bug report than the original bug
report (the one from Philipp)?

I tried to reproduce also the issue from Sebastiaan, but couldn't -
it seems to be working as expected for the bookworm->trixie upgrade
situation (as long as libapache2-mod-php is/was present on bookworm,
and not only libapache2-mod-php8.2 was explicitly installed, because
then libapache2-mod-php8.4 would be missing on trixie of course).

Situation on bookworm:

  root@f4e23b69b69f:/# ls -la /etc/apache2/mods-enabled/php*
  lrwxrwxrwx 1 root root 29 Jul 18 20:10 /etc/apache2/mods-enabled/php8.2.conf -> ../mods-available/php8.2.conf
  lrwxrwxrwx 1 root root 29 Jul 18 20:10 /etc/apache2/mods-enabled/php8.2.load -> ../mods-available/php8.2.load

After the upgrade to trixie:

  root@1f7465dbdcb4:/# ls -la /etc/apache2/mods-enabled/php*
  lrwxrwxrwx 1 root root 29 Jul 18 20:20 /etc/apache2/mods-enabled/php8.4.conf -> ../mods-available/php8.4.conf
  lrwxrwxrwx 1 root root 29 Jul 18 20:20 /etc/apache2/mods-enabled/php8.4.load -> ../mods-available/php8.4.load

I'm wondering whether any *further* php version might also have been
present (like the ones thankfully being provided at
https://deb.sury.org/) before the upgrade to trixie?

FTR, my STR:

  podman run --pull=always --rm -i -t -v $(pwd)/:/code:rw debian:bookworm bash
    apt update ; apt -y install apache2 libapache2-mod-php
    sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/debian.sources
    apt update
    apt -y dist-upgrade

regards
-mika-