Most websites in Bangladesh sit on shared cPanel hosting, where the owner cannot patch PHP even if they want to. That does not leave nothing to do. It leaves three things.
1. Find out what you are running
Log in to cPanel and open MultiPHP Manager (some hosts label it Select PHP Version). It shows the PHP version assigned to each domain. Compare it with the fixed releases: 8.5.12, 8.4.27, 8.3.36, 8.2.35.
If you are on 8.1, 8.0, 7.4 or anything older, those branches no longer receive security fixes at all — which is a larger problem than this one vulnerability, and this is the week to deal with it.

2. Ask your host the precise question
Open a support ticket and ask this, in these words: “Has PHP on my server been patched for CVE-2026-109618 and CVE-2026-109619? Please confirm the package version or changelog entry.”
Ask it that way because of a trap that catches experienced people. When PHP is installed through an operating system’s package manager, the version number often does not change when a security fix is backported. A host that replies “you are on 8.2.28, that is current for our stack” has not answered the question. The CVE identifiers in a changelog are the answer.
3. The second advisory, and the one setting it names
On 23 October PHP published a further advisory, CVE-2026-115560. It is informational rather than an emergency: it affects only web applications configured in an unusual way, the project considers exploitation unlikely, and no emergency fix is being issued. The fix will arrive in the next routine release.
Until then the recommendation is to turn off session upload progress. In cPanel this lives under MultiPHP INI Editor; the directive is session.upload_progress.enabled, set to Off. Almost no site built in Bangladesh uses this feature — it exists to show a progress bar during large uploads — so switching it off is close to free.
What not to do
Do not wait for your site to break. There is no visible symptom: a server that has been compromised through this flaw looks exactly like one that has not, which is why the UK’s NCSC advised that where immediate remediation is not feasible, organisations should consider taking the system offline until it can be mitigated. Several governments did exactly that.
Do not assume a web application firewall is enough. Cloudflare has deployed protections and they help, but the maintainers have been explicit that there is no complete mitigation. A WAF buys time; it does not replace the update.
And do not skip the sites you forgot about. The real exposure in Bangladesh is not the flagship portal that somebody checks daily. It is the five-year-old company site, the event microsite, the old WordPress install on a subdomain — the ones still serving PHP to the internet with nobody assigned to them.
If you build sites for clients
Agencies in Dhaka typically hand over a site and move on, with no maintenance contract and no agreement about who watches for this kind of advisory. This week is the argument for changing that, and it can be made commercially rather than morally: a maintenance retainer that covers security updates is easier to sell the week a 9.2 lands than it will be in six months.
In the meantime, the decent thing is a short email to every client whose site you built — naming the two CVEs, telling them which PHP version they are on if you know, and saying plainly whether you are checking it or they are. An unanswered question about who is responsible is how sites stay unpatched for a year.
Related: what PHP2Shell actually is.




