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)

Which Zones We Cover

We register domains in several hundred zones, including national ones (.ee, .fi, .lv, .is, .de, .uk and others), generic ones (.com, .net, .org, .eu, .info, .biz), and newer gTLDs (.online, .store, .tech, .shop and many more). The current list with pricing is always available on our domain search page.

How to Find an Available Domain

There are several ways to search.

On our website https://corehosting.eu/. Enter the name you want on the domain search page and the system will check availability across multiple zones at once. Useful if you have not yet decided on a zone.

Directly in the Customer Portal https://my.core.hosting/. If you already have an account, you can order a domain straight from the control panel without leaving it.

AI generator. If you have not settled on a name yet, describe your business or project and the system will suggest ideas. Useful when the obvious names are already taken.

Classic search. If you know exactly what you want, just type the name and check.

What to Consider When Choosing a Name

A domain is a long-term decision: the only way to change it is to register a new one. It is worth taking the choice seriously.

Length and readability. Shorter names are easier to remember. Avoid words that people often spell differently, and names that are hard to read aloud or easy to mistype.

Allowed characters. A domain may contain letters (a-z), digits (0-9), and hyphens. A hyphen cannot appear at the beginning or end of the name. Spaces, punctuation, and special characters are not allowed.

Reserved and prohibited names. Some names are blocked at the registry level: geographic names, well-known brand names, technical words. If a domain is unavailable for no obvious reason, it is most likely reserved or blocked by the registry.

Zone-specific rules. Each registry has its own requirements: registrant eligibility, local presence, mandatory identification. Before registering in an unfamiliar zone, it is worth checking the requirements.

Domain Contact Details: The Most Important Thing People Forget

When registering a domain, you provide contact information: name, address, phone number, and most importantly, an email address. This is where renewal notices, registry communications, data change confirmations, and other critical messages are sent.

A common mistake is providing a personal work email. The person leaves the company, the mailbox is closed or stops being read, and a year later the domain is not renewed because nobody is receiving the messages.

The right approach for businesses: create a dedicated shared address such as domains@, hostmaster@, or admin@, accessible to several responsible employees. This kind of mailbox is not tied to any one person and will not disappear if someone leaves.

For individuals: use an email address you actually read and plan to keep for a long time. A Gmail account or similar is a better choice than an address on the domain you are registering, which may itself expire.

One more thing: after registration, the registry typically requires you to confirm the contact email. Keep an eye on your inbox right after registering, or the domain may be suspended.

Keep Your Contact Details Up to Date

Contact information needs to be not only correct at the time of registration, but kept current over time. If your email, phone number, address, or company name changes, update the details in the control panel.

We recommend reviewing your contact details at least once a year. When a domain renewal reminder arrives, it is a good moment to also check that everything is still correct.

Do Not Leave Renewal to the Last Minute

An expired domain does not simply stop working. The freed name is instantly picked up by brokers and automated services that target expiring domains with a history. Popular names can be gone within minutes of being released. Buying your own domain back from a reseller costs significantly more than a regular renewal, if it is possible at all.

After the registration period ends, the domain is not deleted immediately: first comes a grace period during which it can still be renewed, then a redemption period at an additional cost. It is better not to let it get that far. Renew early, do not wait until the last day.

How We Notify You

We send reminders well in advance: the first notification goes out a month before expiration, then again at 14 days and 2 days before. Notifications are sent to the email in your domain contact record; invoices are issued to your billing account.

If you do not plan to renew, simply leave the invoice unpaid. If you do plan to renew, do not ignore the messages.

Have questions about registration or choosing a zone? Contact our support team, we will be happy to help.

Running an online store means writing constantly. Product descriptions, Instagram posts, review replies, About Us pages, email sequences — it never stops. And most store owners aren’t writers. They’re sellers.

That’s why we built AIShopStaff.

What is it?

AIShopStaff is an AI-powered assistant that handles content writing for online stores. You describe your store once — your niche, tone, audience, language — and every tool uses that context automatically. No prompting from scratch each time.

What it does:

• Generates product descriptions from a CSV upload — entire catalogues in minutes
• Writes Instagram and Facebook posts in your store’s voice
• Replies to customer reviews professionally
• Creates store pages and email templates: About Us, Delivery & Returns, FAQ, welcome and promo emails

Who is it for?

Small and mid-sized online store owners who spend hours on writing tasks that should take minutes. Shopify, WooCommerce, PrestaShop, Etsy — it doesn’t matter what platform you’re on. If you sell online and write content, AIShopStaff saves you time.

Content is generated in English, Estonian, Russian, Latvian, and Finnish.

Why did we build it?

We run hosting for hundreds of online stores. We kept hearing the same thing: setting up a store is manageable, but keeping up with the content is exhausting. Product pages stay thin, social media goes quiet, review replies get copy-pasted.

We wanted to fix that — not with another generic AI tool, but with something that actually understands what a store owner needs.

Launching a new store?

There’s a separate one-time product — the Store Launch Kit — that generates everything you need before going live: About Us, FAQ, Delivery policy, welcome emails, social media bio, and launch posts. One payment, no subscription.

Try it free

AIShopStaff comes with a 14-day free trial, no credit card required.

aishopstaff.com

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.

.EE domain transfer is free.
We can handle the transfer for you. All we need is your confirmation.

Renewal — €7 per year (excluding VAT).
A simple fixed price with no hidden fees.

Important:
If your domain has already been renewed for several years, that period remains unchanged.
When transferring a domain, the paid registration period does not disappear and no immediate renewal is required.

For example, if the domain is paid until 2029, it will remain valid until 2029 after the transfer.

Why move your domain to the same provider as your hosting

When the domain and hosting are managed by the same provider, many technical tasks become simpler and faster:

• DNS changes can be made immediately without accessing external control panels
• moving a website to another server can be done without additional actions from the client
• in most cases there is no need to request access or confirmations from another registrar

In the coming months we will continue upgrading our infrastructure and migrating client accounts to new servers. If the domain is managed by us, such work can usually be completed faster and without needing to involve the website owner.

How to transfer a domain

1. Request the EPP code from your current registrar
2. Fill in the transfer form and confirm the request:
https://my.core.hosting/cart.php?a=add&domain=transfer

Alternatively

If you prefer not to handle the transfer yourself, simply send us the name of your .EE domain. We will prepare the transfer and let you know what needs to be confirmed.