PHP – Mosravo Endless Solutions Publications

Critical PHP Flaws Get Urgent Fix Today: What Site Owners Must Do

admin — Wed, 21 Oct 2026 12:33:15 +0000

If your business website, online shop or customer portal runs on PHP, today matters. The PHP security team has scheduled an urgent release for Wednesday, 21 October 2026, at 14:00 UTC (3:00 p.m. in Lagos) to fix two critical remote code execution flaws in PHP core. This article is for website owners, small business IT leads, developers and anyone who manages a WordPress, Laravel or other PHP-based site, whether on shared hosting, a VPS or in containers.

Key takeaways

PHP will ship fixes for two critical vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, on 21 October 2026 at 14:00 UTC.
The PHP security team rated both flaws 9.2 on the CVSS v4.0 scale. Early online claims of a perfect 10.0 score were not confirmed by PHP.
Details of the bugs leaked before the planned disclosure, which is why the release was announced at short notice.
Fixes are expected only for supported PHP 8 branches. Sites still on PHP 5 or PHP 7 will not receive an official patch.
No public exploit code or in-the-wild attacks had been reported at the time of the announcement, but that can change quickly once technical details become public.

Photo: “Programmer’s Laptop” by Wallboat, CC CC0 1.0, via Openverse

What happened

On the evening of Tuesday, 20 October 2026, Jakub Zelenka posted an advance notice from the PHP security team on the official php.announce mailing list. It warned of an upcoming critical security release fixing two vulnerabilities, each scored 9.2 under CVSS version 4.0, and set the release for 14:00 UTC on Wednesday, 21 October. The notice also said the team could publish earlier if details of either flaw became public or if there was evidence of active exploitation, and it urged users to prepare so they can update as soon as the new versions are available.

The timing was not ideal. Earlier the same day, a post on the Hacker News forum claimed that a source had revealed two PHP remote code execution bugs, with an announcement expected on 22 October. That post was later removed, but screenshots spread across X and Mastodon, and some posts listed the reserved CVE numbers. Security firm watchTowr publicly confirmed that the leak related to real, embargoed PHP vulnerabilities, while making clear it had not discovered them and would not share technical details. PHP’s official schedule effectively brought the fix forward by about a day.

What we know about the flaws

Very little technical information has been published, and that is deliberate. According to security advisories from Beazley Security Labs and Threat Landscape, both CVE records are still marked as reserved. PHP has not said which function or extension is affected, which configurations are vulnerable, or whether an attacker needs to be logged in. Some advisories note that a critical rating like this could point to unauthenticated remote code execution, but PHP has not confirmed that.

Remote code execution is the most serious class of web bug because it can let an attacker run their own commands on your server. In practice that can mean defaced pages, stolen customer data, hidden malware that redirects visitors, or a foothold for wider attacks on your network.

Which versions are affected

PHP has not yet published official affected or fixed version ranges; these will come with the release. Public reporting suggests the current releases of the 8.2, 8.3, 8.4 and 8.5 branches are affected. Claims that every version back to PHP 5 is affected came from social media and have not been confirmed. What is clear is that PHP 5 and PHP 7 are end-of-life, so they will not receive official fixes regardless.

Who is affected

PHP powers a very large share of the web, including popular content management systems such as WordPress, Joomla and Drupal and many custom business applications. That makes this release relevant to:

Small businesses and NGOs with a website on shared hosting, where the host controls the PHP installation.
Developers and agencies managing client sites on VPS or cloud servers, where you are responsible for updates.
Teams using containers, where old PHP base images can linger in production long after newer builds exist.
Organisations running appliances or third-party products that bundle their own copy of PHP.

Across Nigeria and the wider continent, many SMEs rely on low-cost shared hosting and on developers who built a site years ago and have since moved on. Those sites are often running older PHP versions that nobody has checked recently. If that sounds like your organisation, treat this as the prompt to find out.

Why the leak raises the stakes

Coordinated disclosure normally gives defenders a head start: the fix and the details arrive together, and attackers have to work backwards from the patch. When details leak early, that head start shrinks. Advisories note that researchers have largely respected the remaining embargo, and at least one researcher has said they will publish a technical lab only after the embargo lifts. Even so, once patched versions are public, attackers can compare old and new code to find the bug. Sites that update within days are in a far stronger position than those that wait weeks.

What you can do before the release

1. Build an inventory

List every server, hosting account, container image and appliance that runs PHP. Record the version for each. On a server you can run php -v; on WordPress you can check under Tools > Site Health > Info > Server; in cPanel, the MultiPHP Manager shows the version for each domain.

2. Talk to your host or distribution

If you use shared or managed hosting, ask your provider when they will roll out patched PHP builds and whether you need to do anything. If you run Linux servers, watch your distribution’s security advisories, because many teams install PHP from distribution packages rather than directly from php.net.

3. Reduce exposure

Advisories recommend restricting non-public PHP applications, such as internal admin panels and staff portals, to trusted networks or VPN access. Internet-facing applications that cannot be patched quickly should be isolated where possible.

4. Plan your upgrade path off old PHP

If you find PHP 5, 7, 8.0 or 8.1 anywhere, prioritise moving it to a supported PHP 8 branch. According to php.net, the supported branches are 8.2, 8.3, 8.4 and 8.5, and PHP 8.2 itself only receives security fixes until 31 December 2026, so moving to 8.3 or newer buys more time.

What you should do

Today: confirm which PHP versions you run and who is responsible for updating each one.
After 14:00 UTC: check php.net and your host or distribution for the patched versions, then apply them as soon as they are available. Test critical functions such as checkout, contact forms and logins afterwards.
This week: watch for exploit reports. If public exploit code appears, treat any unpatched internet-facing site as urgent.
This quarter: retire any PHP version that no longer receives security updates and make PHP version checks part of your regular maintenance routine.

Sources

Featured image: Photo: “First Web Server” by User:Coolcaesar at en.wikipedia, CC BY-SA 3.0, via Openverse — source

How to Check and Update Your Website’s PHP Version Safely

admin — Wed, 21 Oct 2026 11:00:14 +0000

Most small business websites run on PHP, the programming language behind WordPress and many other platforms. Yet few owners know which PHP version their site uses, or that old versions stop receiving security fixes. With PHP shipping an urgent security release on 21 October 2026 and PHP 8.2 reaching the end of its security support on 31 December 2026, now is a good time to check. This step-by-step guide is for business owners, office managers and junior web admins using shared hosting with cPanel, or a WordPress site. You do not need to be a developer to follow it.

Key takeaways

You can see your PHP version in WordPress under Tools > Site Health > Info > Server, or in cPanel’s MultiPHP Manager.
As of October 2026, php.net lists PHP 8.2, 8.3, 8.4 and 8.5 as supported. Anything older gets no security fixes.
Always back up your files and database before changing PHP versions.
Test on a staging copy first if your host provides one, then switch the live site.
If something breaks, switch back temporarily, but only to a version that still receives security updates.

Why your PHP version matters

Each PHP branch gets a period of active support, followed by a period where it receives only security fixes, and then nothing at all. According to php.net’s supported versions page, as of 21 October 2026:

PHP 8.5: active support until 31 December 2027, security fixes until 31 December 2029.
PHP 8.4: active support until 31 December 2026, security fixes until 31 December 2028.
PHP 8.3: security fixes only, until 31 December 2027.
PHP 8.2: security fixes only, ending 31 December 2026.

A site on PHP 7.4, 8.0 or 8.1 will not get patches for newly discovered flaws, including critical ones.

Before you start: prerequisites

Your hosting control panel login (often cPanel) or your WordPress administrator login.
A recent, complete backup that includes both the site files and the database.
A list of the plugins and theme your site uses.
About an hour at a quiet time for your business, such as late evening or a weekend morning.
Your host’s support contact, in case your plan does not let you change PHP yourself.

Step-by-step: check your current PHP version

Option A: inside WordPress

Log in to your WordPress dashboard as an administrator.
Go to Tools > Site Health. On the Status tab, look for a recommended improvement about PHP; WordPress flags outdated versions here.
Click the Info tab, then expand the Server section. The PHP version is listed there.
Write the version down.

Option B: in cPanel

Log in to cPanel.
In the Software section, open MultiPHP Manager. If you cannot see it, your host may have disabled it, so contact support.
Find your domain in the list. The PHP version assigned to it is shown alongside. If it says inherit, the site uses the server’s default PHP version.

Step-by-step: update PHP safely

Step 1: Back up everything

Copy all of your site files and export your database. A backup is only useful if it includes both. Many hosts offer a one-click backup tool in cPanel, and WordPress users can use a backup plugin such as Duplicator. Download a copy to your computer or cloud storage, not just to the same server.

Step 2: Check plugin and theme compatibility

Visit each plugin’s page in the WordPress plugin directory and check the PHP version it supports. Update all plugins, themes and WordPress itself to their latest versions before changing PHP, because updates often add support for newer PHP releases. Plugins that have not been updated in years are a warning sign; plan to replace them.

Step 3: Test on a staging copy

If your host offers a staging site, create one so it matches your live site, then change PHP on the staging copy only. If no staging option exists, choose a quiet time and be ready to switch back.

Step 4: Change the PHP version in cPanel

Open MultiPHP Manager.
Tick the checkbox next to the domain you want to change.
Choose the new version from the PHP Version drop-down menu. Versions your host recommends are labelled Recommended.
Click Apply. If PHP-FPM is enabled for the domain, it updates to match automatically.

A good target for most sites today is PHP 8.3 or 8.4. If a version is missing from the list, it is not installed on your server or not available on your plan; ask your host.

Step 5: Test the important things

Open your site in a private browser window and test what matters to your business: the home page, navigation, contact and enquiry forms, newsletter sign-up, comments, logins and, for online shops, the full checkout process.

Step 6: Apply to the live site

Once staging works, make the same change on the live site, then repeat your tests.

Troubleshooting

The site shows a blank page or “critical error”

Switch back in MultiPHP Manager to the previous version so customers are not affected, then investigate on staging. Only roll back to a version that still receives security updates.

Finding which plugin is the problem

On a staging site, set WP_DEBUG to true in the wp-config.php file to display PHP errors and deprecated function warnings. Error messages usually name the plugin or theme folder causing trouble. Update it, replace it with a maintained alternative, or ask its developer for a fix. Turn debugging off again afterwards.

You cannot change the version yourself

Some shared hosting plans restrict PHP changes. Open a support ticket and ask the host to move your domain to a supported version, or ask about moving to a plan that allows it.

Checklist

Current PHP version noted.
Full backup of files and database saved off the server.
WordPress core, plugins and theme updated.
Plugin compatibility checked; abandoned plugins listed for replacement.
PHP changed on staging and tested.
PHP changed on the live site and key functions tested.
Debug mode switched off.
Calendar reminder set to check PHP and plugin updates every month.

Next steps

Keeping PHP current is not a one-time task. Ask your host to confirm how quickly they apply PHP security releases, such as the critical update scheduled for 21 October 2026, and add a monthly website health check to your routine. If you rely on an outside developer, ask them to confirm the PHP version in writing and to plan upgrades well before each branch reaches its end of support.