Critical PHP updates

My Centos 7 is secure?

=== /usr/local/php56/bin/php ===
5.6.40
=== /usr/local/php74/bin/php ===
7.4.33
=== /usr/local/php81/bin/php ===
8.1.34
=== /usr/local/php83/bin/php ===
8.3.36
 
hello, I have updated the php version yesterday, is there a way to check if someone tried to use this exploit or maybe was even succesfull at that?
 
alinajafi said:
Title: Safely updating PHP 8.2 with CustomBuild: empty configure.php82 and preserving extensions / Supervisor workers

Hello,

I would like to update PHP 8.2 to a patched release following the recent PHP security advisory:
https://www.php.net/archive/2026.php

My server configuration:

  • OS: AlmaLinux 8.10
  • Control panel: DirectAdmin with CustomBuild; exact DirectAdmin version not yet collected
  • Web server: Apache is installed, with a custom WebSocket reverse proxy configuration
  • Current PHP CLI: 8.2.26, NTS
  • PHP binary: /usr/local/php82/bin/php
  • /usr/bin/php resolves to /usr/local/php82/bin/php
  • Loaded php.ini: /usr/local/php82/lib/php.ini
  • Additional INI directory: /usr/local/php82/lib/php.conf.d
  • ionCube Loader: 14.0.0
  • Zend OPcache: 8.2.26
  • CustomBuild also lists PHP 7.4, but I have not yet checked which domains use it.
Loaded extensions include pcntl, posix, sockets, Redis, Imagick, intl, mbstring, curl, OpenSSL, mysqli, PDO MySQL, ZIP, and ionCube.

Current CLI settings:

  • disable_functions: empty
  • memory_limit: 512M
  • max_execution_time: 0
  • open_basedir: empty
  • opcache.enable_cli: 1
I run a Laravel application with Supervisor managing queue, reverb, and schedule. All three processes currently show RUNNING. Their commands use /usr/bin/php, and I confirmed that pcntl and stream_socket_server are available when PHP is executed as the application user.

Apache proxies /app to ws://127.0.0.1:8080/app using a per-domain custom configuration entered through DirectAdmin.

My main concern:

<span>da build used_configs</span> reports this PHP build configuration:

/usr/local/directadmin/custombuild/configure/php/configure.php82

However, that file is currently empty (0 bytes). I do not know why it became empty. The following custom configuration file does not exist:

/usr/local/directadmin/custombuild/custom/php/configure.php82

I previously added --enable-pcntl manually to the default configure.php82 file and rebuilt PHP. The installed PHP still has pcntl enabled, but the current build configuration no longer contains that flag.

I have backed up the PHP configuration and have not started rebuilding PHP.

Could you please advise on:

  1. The supported way to restore the empty default configure.php82 file. Is <span>da build update</span> sufficient?
  2. The correct way to preserve --enable-pcntl and other custom build options across future updates.
  3. The recommended command to update only the configured PHP 8.2 branch to at least 8.2.35, without changing the PHP 7.4 installation or domain PHP selections.
  4. Which existing extensions, particularly ionCube, Redis, and Imagick, may require updating or rebuilding.
  5. Whether this operation preserves php.ini, additional INI files, Supervisor configuration, and DirectAdmin per-domain Apache customizations, and which relevant services/workers should be restarted afterward.
I would appreciate a safe sequence of steps for this existing production setup.

Thank you.
Click to expand...

First of all, stop using AI for your posts. It's annoying, shows no interest, and half the stuff it says is unnecessary. Like you didn't even bother to look up your current DirectAdmin version.

Have you even tried to just run the DirectAdmin update command and check which updates are available? That's perfectly safe without changing anything in your current production. Do:
Code: 
da build update
da build versions
That list will show you which packages have updates.

And you can forget about updating PHP 8.2 without updating PHP 7.4. But why wouldn't you update both? Both versions are compromised anyway. If you installed the entire server using CustomBuild than there is no reason to suspect updates would suddenly fail you.
 
AGAIN!?

On October 23, 2026, the PHP team disclosed CVE-2026-115560, a new PHP session vulnerability tied to session upload progress. It can lead to remote code execution. PHP advises setting session.upload_progress.enabled=0 OR session.upload_progress.enabled = Off until the next bugfix release.
https://www.php.net/archive/2026.php#2026-10-23-1
 
Last edited:
ASUS said:
AGAIN!?
Click to expand...

They say:

Applications that never change the serialize handler at runtime can keep the feature enabled. Since this setup is unlikely in practice, we are handling it in the regular release cycle and will publish a full advisory for CVE-2026-115560 with the next release.
Click to expand...

No reason to panic
 
I wanted to warn people there is a problem with the php update path, or maybe just lack of knowing how to update the php. I had thought
1 update directadmin and all the packages.
2 selecting the newer php under php setting in my case i just used 8.5(8.5.12)
I thought this was all i needed to do and i think others will assume they are good with this.
You should log into the user goto Account Manger/Databases then PHPMYADMIN
Look under Web Server and PHP version. If this isnt 8.5.12 or what ever patched version of php your using then your not updated.
I don't even know what I did to fix this but it was mostly messing the main admin Server Manager/Custom build Under here i messed with options
Changing php1 to php 8.5, i updated the mariadb to the newest 12.3 i believe that's all i changed there then updated and then in that same area other/actions i ran Update MariaDB configuration files, Rewrite WEB server configuration files, Secure PHP
I think thats all I did and mine finally upgraded. Someone have the exact steps needed but just make sure you database is showing the correct PHP version or you may still be running older versions.
 
You must log in or register to reply here.
Back
Top