On a regular server the story is short: update the package and restart PHP. On hosting servers with ispmanager and CloudLinux it turned out to be more interesting. Over one night and morning we patched all our servers and stepped on almost every rake that neither the PHP advisory nor the panel documentation mentions.

This is not a retelling of the advisory but a list of what didn’t go by the book and how we solved it. If you run a server with ispmanager, especially on CloudLinux, check each point on your own system: some of these problems stay invisible until you look in the right place.

Temporary measures before the patches

Until packages are available you cannot fully close the vulnerabilities, only cut off the known attack paths. The public exploits that appeared before the release used the file upload progress handler, which runs on any multipart/form-data request, even if the site has no upload form at all.

We did two things:

1. Disabled session.upload_progress.enabled in all PHP versions. This is the PHP project’s own recommendation; almost nobody uses the feature, and sites are not affected. Important: the value must be set in php.ini or in the pool configuration, not via ini_set() or .user.ini, otherwise it applies too late.
2. Blocked multipart at the nginx level for all sites. In ispmanager every vhost includes /etc/nginx/vhosts-includes/*.conf, so a single file covers the whole server:

if ($http_content_type ~* "multipart") {
    return 403;
}

The price of the second measure: file uploads through forms, webmail attachments and imports in phpMyAdmin stop working. So this is a measure for hours, not days.

Two places that are easy to miss:

• The default server in /etc/nginx/nginx.conf. It catches requests by IP or with an unknown Host and, in ispmanager, proxies them to Apache, but it does not include vhosts-includes. Without a separate include there, an attack by IP bypasses the block.
• Apache on a public address. If Apache listens on a public IP rather than 127.0.0.1, a request can be sent straight to it, bypassing nginx. Check: ss -ltnp | grep httpd.

The CageFS trap: the panel setting never reaches the sites

During the day we disabled session.upload_progress.enabled the standard way: “Web server settings → PHP → version → settings”. The panel showed the value as saved. In the evening, a check from inside the CageFS cage showed it was still enabled for the sites.

The reason is how alt-php works on CloudLinux:

• ispmanager wrote the value into /opt/alt/phpXX/etc/php.d.all/session.ini, the ini file of the session extension;
• in alt-php the session extension is built in and is not loaded through PHP Selector, so nobody inside the cage reads that ini file;
• inside the cage PHP reads the main /opt/alt/phpXX/etc/php.ini and the user’s alt_php.ini from /opt/alt/phpXX/link/conf, which is a different directory from what root sees.

Hence the main lesson: check PHP settings as the user inside the cage, not as root:

su -s /bin/bash -c "/opt/alt/php83/usr/bin/php -r 'var_dump(ini_get(\"session.upload_progress.enabled\"));'" CLIENT_LOGIN

What worked:

1. Append the directive to the end of the php.ini each version actually loads (the path is shown by php --ini, line Loaded Configuration File).
2. Run cagefsctl --rebuild-alt-php-ini to rebuild the users’ alt_php.ini files.
3. Run cagefsctl --update: the native PHP inside the cage has its own copy of /etc/php.ini in the CageFS skeleton, and without updating the skeleton the change never reaches the sites.
4. Don’t forget the per-site php.ini files for CGI mode: ispmanager keeps them in /var/www/USER/data/php-bin*/php.ini.
5. Restart httpd and FPM.

One more detail: that same night at 03:37 something rebuilt the php.ini of every alt-php version from a template. If your change lives only in php.ini, back it up with a cron job that checks and restores the line until the patches arrive. We did exactly that, and cron did restore it several times, for example after the alt-php packages were updated.

The multipart block breaks the panel login

A couple of hours after the block went in, a client wrote that they could not log in to the panel: the login request got a 403 and the interface showed a loading spinner forever. Nobody had blocked the client’s IP.

The ispmanager panel runs on its own web server, ihttpd, on port 1500, and when you log in directly on that port nginx is indeed not involved. But if the nginx_proxy module is enabled, the panel is also reachable over 443 at https://HOST/ispmgr, and the login form is sent as multipart/form-data. Our block answered 403 in nginx, and the panel frontend cannot display that error.

The module is included only in the vhost of the panel host (/etc/nginx/modules-includes/nginx_proxy/), and all its paths go to ihttpd, not to PHP. So it is safe to make an exception for the combination of host and path:

set $cve_mp 0;
if ($http_content_type ~* "multipart") { set $cve_mp 1; }
set $cve_hu "$host:$uri";
if ($cve_hu ~* "^panel\.example\.com:/(ispmgr|mancgi|manimg|long|shell|notify)(/|$)") { set $cve_mp 0; }
if ($cve_mp = 1) { return 403; }

An exception by path alone, without the host, would be a mistake: a request to client-site/ispmgr would go to Apache, WordPress would rewrite it to index.php, and PHP would parse the multipart body. On the panel host this path is guaranteed to go to ihttpd.

Take the list of paths from the module itself (grep location /etc/nginx/modules-includes/nginx_proxy/*.conf), not from memory. And don’t test right after reloading nginx: the first requests may still be served by an old worker with the old configuration.

The forgotten Roundcube and phpMyAdmin

When the alt-php patches came out, we updated the packages and removed the block. Only then did we remember that webmail and phpMyAdmin in ispmanager run not on the PHP version you selected for the sites. Updating alt-php does not touch them.

Both applications are included through vhosts-includes, which means they are reachable on every domain on the server (/roundcube, /webmail, /phpmyadmin or a path with a random prefix). Which PHP runs them is shown by fastcgi_pass in these files:

grep -E 'location|fastcgi_pass' /etc/nginx/vhosts-includes/*roundcube*.conf /etc/nginx/vhosts-includes/*phpmyadmin*.conf

We found several variants across our servers:

The second column matters as much as the first. Apache receives these requests in two cases:

• a request by IP or with an unknown Host goes through the nginx default server straight to Apache, where Alias /webmail and /phpmyadmin are global;
• the nginx configuration for /webmail and /phpmyadmin has error_page 404 @apache and error_page 502 = @apache. A URL with PATH_INFO such as /webmail/index.php/x does not match location ~ \.php$, gets a 404 and goes to Apache, where mod_php executes it.

On one of the servers the native PHP was 5.4 from CentOS 7, which will never receive fixes. While we were moving these applications to alt-php, the multipart block stayed only on their paths, and the sites already worked without restrictions:

if ($uri !~* "^/(roundcube|webmail|phpmyadmin)(/|$)") { set $cve_mp 0; }

During that time clients could not attach files in webmail, and they noticed almost immediately.

Why the version number doesn’t change on CloudLinux

CloudLinux released fixes for all alt-php branches at once, from 5.4 to 8.5, but not as 8.3.36 or 8.4.27. They are new builds of the existing versions: alt-php83-8.3.35-6, alt-php84-8.4.26-5, alt-php85-8.5.11-5 and so on. The patch is applied to the installed version, and only the package release number goes up.

So check scripts that compare PHP_VERSION with 8.3.36 will keep reporting “vulnerable” after the update. And clients who look at the panel will see the same numbers and ask why nothing was updated. There are two reliable indicators.

The package changelog. For the old branches CloudLinux additionally removed the upload progress handler entirely:

for p in $(rpm -qa --qf '%{NAME}\n' 'alt-php[0-9]*' | grep -E '^alt-php(5[4-9]|[78][0-9])$' | sort -V); do
  printf '%-10s %-16s ' $p "$(rpm -q --qf '%{VERSION}-%{RELEASE}' $p)"
  rpm -q --changelog $p | head -10 | grep -c 'CVE-2026-10961[89]'
done

Build Date in phpinfo(). The fixed builds show 21 October 2026, the previous ones earlier dates. This is what you can tell clients: anyone can check it without server access.

Native PHP has the same story from the other side. On RHEL 9 and its rebuilds the fixed 8.0 version is php-8.0.30-8.el9_8.1 (Red Hat advisory RHSA-2026:87151), and in the changelog the CVE numbers ended up attached to the last item of the list, which has a completely different description. Without the advisory it is easy to mistake this for a routine update.

The ispmanager packages (isp-phpXX) have a template changelog with a single 2019 entry. The indicators there are indirect: the build number (for us 1781 for 8.2-8.5, 1782 for 7.4, 1786 for 7.1) and a Build Date of 22 October.

Pitfalls of the update itself

dnf --best --allowerasing on an ispmanager server. On CloudLinux 9, dnf update printed a long list of conflicts: the repository contains native PHP 8.3.36 from a module stream, and dnf considers it the best candidate for the installed 8.0. But the ispmanager Apache module (isp-httpd-mod_php) strictly requires PHP 8.0.x, and coremanager-pkg-php and ispmanager-pkg-php, that is the panel itself, depend on it. The dnf hint to add --best --allowerasing is dangerous here: it would remove the panel packages. The conflict is harmless, and dnf ends with Nothing to do. To silence it until the 8.0 build arrives: dnf update --exclude='php,php-*'.

ispmanager has its own Apache PHP module. It is loaded from modules/isp-libphp8.so and belongs to the isp-httpd-mod_php package, not to the system php package. The fixes for these CVEs live in the PHP core, that is inside the module itself, and updating the php package does not change it. Check:

grep -rhE 'LoadModule\s+php' /etc/httpd/conf.modules.d/ /etc/httpd/conf.d/
rpm -qf /etc/httpd/modules/isp-libphp8.so
strings /etc/httpd/modules/isp-libphp8.so | grep -m1 -E '[A-Z][a-z]{2} [ 0-9][0-9] 20[0-9]{2}'

If the module was built before 21 October, every site in “Apache module” mode stays vulnerable. To find them: grep -lE 'SetHandler\s+application/x-httpd-php\s*$' /etc/httpd/conf/vhosts/*/*. We moved such sites to alt-php, and where that was impossible (an interface that needs access outside CageFS), we restricted access by IP.

Disabled PHP is worse than enabled PHP. Some former mod_php sites turned out to be static, so we disabled PHP for them. On one of them, next to the placeholder page, there were 61 files of an old site, and with PHP disabled their source code, including a config with the database password, was served as plain text. Before disabling PHP, check: find DOCROOT -name '*.php*' | wc -l.

SSH dropping in the middle of a transaction. Updating 160 alt-php packages took several minutes, and the connection dropped. Luckily the transaction completed, but you have to verify: dnf history list, dnf check (on CentOS 7: package-cleanup --problems, package-cleanup --dupes). Run long updates inside tmux.

Quiet ispmanager rebuilds. The fixed isp-php packages arrived one at a time over a day: first 8.2-8.5, then 7.4, then 7.1. For CentOS 7 the 7.4 build had not appeared at the time of writing. It makes sense to check dnf check-update 'isp-php*' several times a day.

How to move Roundcube and phpMyAdmin to alt-php

On the server with native PHP 5.4 we moved the service FPM pool apache to alt-php56 while keeping the same socket. That way the nginx configuration does not change, and rolling back means simply starting the old service. Choosing 5.6 over 7.4 was simple: Roundcube 1.4 and the old phpMyAdmin ran on 5.4, 5.6 is the closest, and CloudLinux released a backport for it.

Steps:

1. A dedicated ini directory. Outside CageFS, alt-php run by root loads only a minimal set of extensions; the rest live in php.d.all. We built a single extensions.ini from the required modules (session, json, dom, xml*, mbstring, intl, gd, mcrypt, zip, pdo, nd_mysql*). The CloudLinux ini files pull in their own dependencies, so duplicate extension= lines have to be removed.
2. An FPM config with an apache pool on /var/run/php-fpm.apache.sock, the same user, group and listen.owner, and an explicit session.save_path, because it was not set in the native php.ini.
3. A check before switching: PHP_INI_SCAN_DIR=… php -m without errors and php-fpm -t -y … reporting test is successful.
4. A systemd unit with Environment=PHP_INI_SCAN_DIR=… and ExecStart=… php-fpm --nodaemonize -y ….
5. The switch: rename /etc/php-fpm.d/apache.conf, restart the native FPM (it keeps the www pool), start the new one. A few seconds of downtime.
6. Point Apache to the same socket. In roundcube-webmail.conf and phpmyadmin-httpd.conf replace SetHandler application/x-httpd-php with SetHandler "proxy:unix:/var/run/php-fpm.apache.sock|fcgi://localhost/", and in roundcube-isp.conf replace the isp-php74 socket. Make sure SetHandler is inside <FilesMatch "\.php$">, otherwise static files will go to FPM too.

Removing duplicate extensions from step 1:

awk '/^[[:space:]]*(zend_)?extension[[:space:]]*=/ { k=$0; gsub(/[[:space:]]/,"",k); if (seen[k]++) next } { print }' $FILES > conf.d/extensions.ini

Checking which PHP actually runs on each path, including a direct request to Apache and PATH_INFO:

echo '<?php echo PHP_VERSION, " ", php_sapi_name();' > /usr/share/roundcubemail/_v.php
curl -s -H 'Host: nonexistent.invalid' http://127.0.0.1:8080/webmail/_v.php
curl -sk https://DOMAIN/webmail/_v.php/x
rm -f /usr/share/roundcubemail/_v.php

Every line should say 5.6.40 fpm-fcgi. After that the nginx block can be removed.

Two downsides of this approach: on the Apache path the open_basedir restrictions from the mod_php configs are lost, and roundcube-isp.conf is marked by ispmanager as overwritten on package updates. After panel updates, check that the sockets have not reverted and that /etc/php-fpm.d/apache.conf has not reappeared.

Checklist for an ispmanager server

If you run a server with ispmanager and are not yet sure you have fully closed PHP2Shell, go through this list:

• All alt-php branches in use are updated, and the changelog mentions CVE-2026-109618/109619 or the Build Date is 21 October 2026 or later.
• The isp-php* packages are updated and the php-fpm* services restarted (after a unit file change, run systemctl daemon-reload first).
• The OS native PHP is updated or serves nothing (check the pools in /etc/php-fpm.d/ and who connects to their sockets).
• The Apache module isp-libphp8.so was built after 21 October, or no site runs in “Apache module” mode.
• Roundcube and phpMyAdmin run on patched PHP both via nginx and via Apache.
• PHP settings were checked as the user inside CageFS, not as root.
• The CageFS skeleton is updated (cagefsctl --update).
• Temporary nginx blocks are removed, including the line in the default server in nginx.conf.
• Sites with PHP disabled contain no .php files.
• Clients know why the version number in the panel did not change.

The main takeaway from that night is simple: on a hosting server with a control panel, “update PHP” means not one package but five or six different PHP builds from three vendors (upstream via CloudLinux, ispmanager, the distribution), and some of them serve not the sites but the panel’s own applications. It pays to know in advance which PHP sits behind which path, before you need to find out at night.

Sources

• PHP: Security advisory, 21 Oct 2026
• CloudLinux KB: updated package availability
• CloudLinux blog: Imunify360 Ruleset 8.83
• Red Hat RHSA-2026:87151 (PHP 8.0, RHEL 9)
• ispmanager: PHP settings on CloudLinux
• OpenNet: PHP vulnerability (in Russian)

Protect your WordPress admin from logins outside your country

We built a free plugin that blocks access to the admin panel for IP addresses from countries not on your allowed list.

What the plugin does

The plugin blocks access to wp-admin and wp-login.php for IP addresses from countries not in the allowed list. Frontend visitors, online store customers, and members area users are not affected — only the admin panel is restricted.

Download

block-access-to-admin-by-country.zip

Installation

1. Download the zip archive using the link above
2. In your WordPress dashboard, go to Plugins → Add New → Upload Plugin
3. Select the downloaded archive and click Install Now, then Activate
4. Go to Settings → Admin Country Block and set your allowed countries

Settings

• Allowed countries — country codes, one per line (e.g. EE, FI, LV). Only IPs from these countries will have access to the admin panel.
• Exception IPs — IP addresses that always have access regardless of country. Add your own IP here to avoid locking yourself out.
• Cache TTL — how long the lookup result is cached per IP address (default: 24 hours).

For Core Hosting customers

On Core Hosting servers, the plugin automatically uses a local MaxMind GeoLite2 database — no external requests, fast and reliable. The database is updated weekly. No additional configuration is needed.

For sites on other hosting providers

he plugin uses a free geolocation API (freeipapi.com). You can also specify any other compatible API in the API URL field. Results are cached, so the number of API requests stays minimal.

The plugin supports automatic updates — new versions will appear in the standard WordPress updates section.

The plugin is free and open to everyone. If you run into any issues during installation or have questions, feel free to contact our support team.

The changes were approved by the CA/Browser Forum, an industry organization that defines security standards for certificate authorities and browser developers.

In practice, this means that the validity period of SSL certificates will gradually become shorter and certificates will need to be renewed more frequently.

Let’s look at what exactly is changing and whether website owners need to take any action.

If your website does not yet use SSL, you can use a free Let’s Encrypt certificate or a commercial certificate with extended validation. More information about available options can be found on the SSL certificates page.

What will change?

The main change concerns the maximum validity period of SSL certificates.

The transition will happen gradually:

As a result, the industry will gradually move from annual certificates to certificates that are valid only for a few weeks.

The reuse period for domain validation will also be shortened. This means certificate authorities will verify domain ownership more frequently.

Why is the SSL validity period being reduced?

The main reason is improving internet security.

The longer a certificate remains valid, the more time attackers have if a private key is compromised or a configuration error occurs. Shorter validity periods allow potentially vulnerable certificates to be replaced faster.

There are also other reasons:

• faster transition to new cryptographic algorithms
• more frequent domain ownership verification
• preparing infrastructure for future security standards

Will SSL certificates need to be purchased more often?

No. Shorter certificate lifetimes do not mean higher costs.

Commercial certificate authorities already use a subscription model. This means a certificate can be purchased for 1 or 2 years, while it may be reissued several times during that period at no additional cost.

For example:

• a certificate is purchased for one year
• the first certificate is valid for about 200 days
• a new certificate is then issued for the remaining period

This process is called reissue and is a standard practice.

What does this mean for website owners?

The main practical change is that certificates will need to be renewed more often.

Approximate renewal frequency:

• in 2026 — about two renewals per year
• in 2027 — three or four renewals
• after 2029 — renewals may happen every few weeks

If SSL certificates are installed manually, the risk of forgetting to renew them will increase.

Why automatic SSL renewal is becoming the standard

Modern web infrastructure increasingly relies on automation.

If a certificate expires, browsers begin displaying security warnings. This can lead to loss of visitors and reduced trust in the website.

For this reason, most hosting platforms now use automated SSL management.

For example, free Let’s Encrypt certificates can automatically:

• be issued
• be installed on the server
• be renewed before expiration

On web hosting plans, these certificates are usually enabled through the control panel and renewed automatically.

Do hosting clients need to do anything?

In most cases, no.

If you are using a free Let’s Encrypt SSL certificate through the hosting control panel, it will be issued and renewed automatically without any action from the website owner.

Commercial SSL certificates (for example, OV or EV) usually require manual installation and periodic reissuance. Their validity period will also be shortened according to the new industry rules.

When should you pay attention?

You should check your SSL configuration if:

• the certificate is installed manually on the server
• commercial OV or EV certificates are used
• certificates are managed within corporate infrastructure

In these cases it is recommended to configure automatic certificate renewal in advance.

Frequently asked questions

Why is the SSL validity period being shortened?

The goal is to improve security. Shorter certificates reduce risks if a key is compromised or cryptographic algorithms become outdated.

Will I need to pay for SSL more often?

No. Commercial certificates are usually purchased for one or two years and may be reissued multiple times within that period without additional cost.

What happens if an SSL certificate expires?

Browsers will display a security warning. Visitors may not open the website and search engines may reduce trust in the site.

Do hosting users need to take any action?

If you are using a free Let’s Encrypt SSL certificate through the hosting control panel, it is renewed automatically and requires no action.

Summary

Starting in March 2026, the maximum validity period of SSL certificates will be reduced to 200 days. In the future the validity period will become even shorter.

This is part of a global shift toward more frequent certificate renewal and automated security management.

For most website owners these changes will be almost invisible, especially if SSL certificates are managed through the hosting control panel.

Need an SSL certificate for your website?

Our hosting allows you to use free Let’s Encrypt certificates with automatic renewal as well as commercial certificates for projects that require extended validation.

View available SSL certificates

Update immediately if you’re running OpenSSL version 3.0.0 through 3.0.6.

Version update information: https://www.openssl.org/source/.