I encountered this same issue with many PHP modules failing to load after updating PHP packages including php8.2-curl and libapache2-mod-php8.2 from 8.2.34-1~deb12u1 to 8.2.35-1~deb12u1 on Devuan Daedalus (based on Debian 12 (Bookworm)). Also on a Debian 13 (Trixie) system after upgrading libapache2-mod-php8.4 (etc.) from 8.4.26-1~deb13u1 to 8.4.27-1~deb13u1.
The libapache2-mod-php package's post-install script (libapache2-mod-php.postinst.extra) triggers an Apache "restart" action via the apache2_reload function in /usr/share/apache2/apache2-maintscript-helper after the updated package is installed. This appears to be equivalent to running "apache2ctl restart". However Apache still continues to run the old PHP module already loaded in memory, as seen in the output of the "phpinfo()" function run from a PHP script accessed via HTTP, which still reports the previous version number and build date. But Apache does attempt to reload PHP's own modules, which are for the new Apache PHP module and therefore fail to load due to missing symbols in the old Apache PHP module that's still running. Running "apache2ctl stop", then "apache2ctl start" causes the Apache PHP module to be truely reloaded, and "phpinfo()" then reports the newly-installed PHP version as well as now showing details of the PHP modules that were failing to load before. I would guess that before this manual stop/start is done, the server also remains vulnerable to the PHP2Shell exploit. Kevin Koster.
