Xinet Portal: Critical PHP Vulnerabilities - Action Required

October 21, 2026

AT A GLANCE

Two critical PHP vulnerabilities (CVSS 9.2) disclosed on 21 October 2026 allow unauthenticated remote code execution on PHP web servers, and exploitation attempts are already being observed in the wild. They are fixed in PHP 8.3.36. Update PHP and restart Apache on every Xinet Portal server as soon as you can.

These steps apply to Xinet 2025.11.14 and later. If you run an earlier release, read "Running an earlier Xinet release?" below before changing anything.

What happened

The two flaws, tracked publicly as "php2shell":

The root cause is internal PHP data that survives after its memory is released; a later request handled by the same worker can reuse it.

Are you affected?

Check your current version:

php -v
rpm -q php php-cli

These steps apply to Xinet 2025.11.14 and later, which run Xinet Portal on RHEL 9 with PHP 8.3. On these releases, your server is vulnerable if the version is below 8.3.36.

What to do now?

Run as root on each Xinet Portal server:

dnf clean metadata
dnf --refresh upgrade 'php*'
systemctl try-restart php-fpm
systemctl restart httpd

Restarting Apache is required, not optional. Until httpd restarts, it keeps serving requests with the old, vulnerable PHP it has already loaded in memory.

If dnf reports "Nothing to do" while you are still below 8.3.36, your Remi mirror has not received the package yet. Mirrors are still catching up; retry later. To see what your mirror currently offers:

dnf --refresh list --showduplicates php

Running an earlier Xinet release?

Releases before 2025.11.14 run Xinet Portal on PHP 8.1 (RHEL 9) or PHP 7.4 or 8.1 (RHEL 7). Do not switch your server to PHP 8.3 on its own: each Portal build only runs on the PHP version it was built for, so Portal will stop working.

On RHEL 9 with PHP 8.1, run the same commands from "What to do now?". A patched PHP 8.1 build is available. Because php -v still reports 8.1.34 after the update, confirm with rpm -q php php-cli instead: it must show 8.1.34-6 or later.

On RHEL 7 or CentOS 7, no patched PHP is available. Contact Customer Support to plan an upgrade to the latest Xinet release on RHEL 9.

What does not work

Scripts and one-line "mitigations" circulating online that disable session.upload_progress do not protect you. PHP's maintainers have confirmed that no php.ini or configuration change mitigates these vulnerabilities, and Session Upload Progress is only one of several ways to trigger them.

Verify the fix

php -v                        # must show PHP 8.3.36 or later
rpm -q php php-cli # must show 8.3.36-1 or later
systemctl status httpd        # active (running)

On PHP 8.1, rpm -q must show 8.1.34-6 or later instead (see "Running an earlier Xinet release?").

Then log in to Xinet Portal and confirm it loads as normal.

Support and references

Contact Customer Support if any step fails.