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?
 
Hey I just wanted to give Team DirectAdmin a shout for releasing the patched versions so quickly! Much appreciated 🙏
 
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.
 
You must log in or register to reply here.
Back
Top