Ask your hosting provider or website maintainer today, 22 October 2026, to confirm that the PHP software running your website has received the PHP2Shell security fixes. Updating WordPress alone is not enough. As the PHP Foundation’s announcement explains, fixes released on 21 October address two critical vulnerabilities that, under certain conditions, can let an attacker run code on a server without logging in.
For Ghanaian businesses, online shops and organisations, the immediate task is to establish whether the right server software has been patched—not simply whether the website still loads. At Sobiaonline, we recommend requesting a clear answer now rather than waiting for the next routine maintenance visit.
What happened?
The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, are collectively known as PHP2Shell. They concern PHP’s handling of memory and internal request data. Successful exploitation could allow an unauthorised person to execute code with the permissions available to the affected PHP application.
The fixed upstream releases announced on 21 October are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP project’s consolidated security advisory explains that only an update provides a complete solution; temporary measures reduce exposure to specific attack paths but do not fully resolve the vulnerabilities.
The urgency is not based only on researchers’ demonstrations. AWS reports an exploitation attempt dated 17 October 2026 in telemetry from MadPot, its network of decoy systems used to observe threats. It also reports subsequent attempts and exploitation in the wild, while noting uncertainty about whether the early attempts would have succeeded against real-world systems.
Those observations justify prompt action. They do not establish that every targeted website was compromised or that Ghanaian websites have been hacked.
How is PHP different from WordPress?
PHP is a programming language used on servers to generate web pages and handle application functions. The software that executes PHP code is often called the PHP runtime. WordPress’s server requirements list PHP as a hosting dependency: WordPress needs it, but the two are not the same software.
Think of them as separate maintenance layers. WordPress core, themes and plugins belong to the website application; PHP belongs to the server environment that runs it. Keeping WordPress updated does not establish that the underlying PHP runtime has received these fixes.
This is not solely an Apache or old-WordPress problem. The PHP Foundation also confirms demonstrated remote code execution through application-level paths on PHP-FPM, another way of running PHP for websites. Ask your provider to assess the actual deployment rather than assuming a particular hosting arrangement is unaffected.
If you use a fully managed website platform, ask whether it uses affected PHP components and whether the relevant fixes are active. You do not need direct server access to request a clear answer.
Why a version number is not the whole answer
Linux and hosting vendors may backport security fixes: apply the correction to an older package while retaining its established version numbering. Ubuntu’s fixed-package list illustrates why an older-looking PHP version can still contain these fixes.
Ask for the full package revision and the vendor advisory covering both vulnerabilities, not just “you are on PHP 8”. The PHP advisory’s guidance for older branches notes that PHP 8.1 and older no longer receive ordinary PHP-project updates, although some vendors provide backported fixes. Where an older branch remains in use, request the applicable vendor fix or a migration plan.
Why might a website be taken offline?
Taking a system offline can be a precaution, not an admission that attackers have broken in. The UK National Cyber Security Centre’s alert recommends considering this when temporary mitigations cannot be applied, or applying them would take too long.
That is a decision to make with your technical provider. Ask what any temporary protection covers, what it may disrupt and when the complete update will follow. Temporary configuration measures are not equivalent to installing the fix.
What to ask your host or maintainer today
We recommend asking for a specific, recorded answer rather than a general assurance that “security is handled”. Use this checklist to guide the conversation:
- Identify every relevant PHP installation. Ask the provider to include your main website, subdomains, staging sites, old shops and other internet-facing applications. Confirm what is actually serving each site. The NCSC’s discovery advice covers PHP installations generally, not only outdated versions.
- Confirm the fix in writing. Request the fixed package or vendor backport covering both CVEs, confirmation that it is active, and a completion time for anything outstanding.
- Prepare for recovery. Ask your maintainer to back up the website files and database before changes and confirm how recovery would work. If compromise is suspected, request evidence preservation as well; do not treat a new backup as proof that its contents are clean.
- Activate the updated software. Ask whether the relevant applications and services have been restarted as required. Ubuntu’s restart guidance warns that corrected packages may still require application restarts or a reboot before the updated components are in use.
- Test the functions your business relies on. Request checks of enquiry forms, customer logins, checkout, payment confirmations, bookings and scheduled tasks—not just the homepage.
- Review suspicious activity. Ask for checks of web-server logs, unexpected file changes and unusual process execution. Seek incident-response help where compromise is suspected.
For an online shop, for example, a useful post-update check would follow a test order through checkout and confirmation rather than stopping at the product page.
Patching does not settle what happened before
Applying the fix and investigating a possible intrusion are separate tasks. Do not accept “we have patched it” as a substitute for investigating warning signs. The NCSC advises checking for evidence of compromise and attacker-installed backdoors, particularly where a system cannot immediately be updated or disabled. Separately, AWS recommends investigating activity from at least 17 October 2026, its earliest reported exploitation observation. Its recommended checks include web-server logs, unexpected process execution and file modifications.
Ask for two distinct answers: “Is the security fix active?” and “Have you assessed whether there is evidence of compromise?”
Your next step: send your host or maintainer this request today:
Please confirm whether every PHP application on our account is protected against CVE-2026-109618 and CVE-2026-109619. Identify the fixed package or vendor backport, confirm the running services have been updated, and tell us whether further testing, investigation or temporary downtime is needed.
Frequently asked questions
Is updating WordPress enough to address PHP2Shell?
No. WordPress and PHP are separate maintenance layers. Ask your host or maintainer to confirm that the PHP runtime serving your website has received the fixes, even if WordPress, themes and plugins are already updated.
Should I take my website offline immediately?
Not automatically. Ask your provider to assess exposure and apply the fix promptly. If temporary mitigation cannot be applied, or would take too long, discuss taking the affected system offline until it can be protected.
Can an older PHP version be patched?
Sometimes a vendor provides a backported fix under its support arrangements. Ask for the exact corrected package and applicable advisory; do not assume every old installation qualifies.
Does applying the patch guarantee my website is safe?
No. The update addresses these vulnerabilities; it does not establish that there was no earlier intrusion or guarantee overall website security. Continue normal maintenance and ask for investigation where there are warning signs.

Find more useful website guides from Sobiaonline.
Add Sobiaonline as a preferred source on Google