PHP security flaw: New concern over bank and website security worldwide

Banking, business, government services, news publishing and personal communication—almost every sphere of modern life depends on websites. Many of these websites are built with PHP, a widely used server-side programming language. But when a serious security flaw is discovered in the core engine of this technology, the impact is not limited to a single website; countless servers and online services can be put at risk.

On 21 October 2026, the PHP project released new versions with fixes for two critical security vulnerabilities, which security researchers have referred to as “PHP2Shell”. Later, on 23 October, an informational advisory from the project disclosed a related third vulnerability (CVE-2026-115560). If exploited, these flaws could, in certain situations, let an attacker run malicious code on a server without ever signing in to a user account.

Bangladesh has also issued warnings on the matter. For banks, government agencies, web hosting companies, software developers and ordinary website owners alike, the incident has become an important lesson.

What is PHP and why does it matter so much?

PHP is a server-side programming language. When a visitor opens a website, PHP code runs on the server to generate pages, data, search results or services connected to a database, as required.

Widely used content management systems such as WordPress, Joomla and Drupal, as well as many e-commerce platforms and web applications, are built on PHP. So when a security problem appears in PHP’s core engine, it is not only one particular piece of software at risk—many different kinds of websites can be affected.

That said, not every PHP-based website is equally exposed. The server’s configuration, the PHP version in use, the software installed, network protection and whether security patches have been applied all shape the level of risk.

What is PHP2Shell and why is it serious?

PHP2Shell is the name used for the serious PHP security vulnerabilities disclosed in October 2026. They include:

• CVE-2026-109618: a flaw in how PHP manages memory and handles out-of-memory situations.
• CVE-2026-109619: a flaw caused by internal state that keeps being used after the memory holding it has been freed.
• CVE-2026-115560: a flaw related to session upload progress, disclosed in the PHP project’s informational advisory of 23 October 2026; its full advisory is to be published with the next regular release.

The first problem can occur when PHP reaches its memory limit while processing a request and stops before the internal data has been fully prepared. If later clean-up routines use that incomplete data incorrectly, a security risk arises.

The second problem concerns internal state that can survive in a PHP worker even after the memory allocated for it has been freed. If that stale state is reused incorrectly while processing a later request, an attacker may get the chance to exploit the flaw.

The third flaw is related to the session upload progress feature. According to the PHP project’s advisory, it can come into play when an application sets the session.serialize_handler setting to php_binary or php_serialize in its configuration, then switches it back to php at runtime via ini_set() before session_start(), with upload progress enabled. This is a comparatively rare situation, but the PHP project has advised keeping session.upload_progress.enabled=0 on the server until the next regular bugfix release. The same setting is also listed as a partial mitigation for the earlier flaw CVE-2026-109619, which makes it the most important immediate step.

If these errors are exploited, an attacker may, in specific environments, gain the ability to run code of their own choosing on a server from a distance. In cyber-security terms this is called Remote Code Execution, or RCE.

According to the PHP project’s published information, the two vulnerabilities fixed on 21 October are both critical—each scores 9.2 on the CVSS v4.0 scale—and the corresponding security fixes need to be installed quickly. The risk applies to every serving environment, whether PHP-FPM, Apache’s mod_php, php-cgi or LiteSpeed. Extra caution is needed with mod_php, where an unauthenticated request has been demonstrated to trigger exploitation before application code even runs.

Why might a bank take its website offline?

When a bank temporarily takes its website offline, there can be several reasons behind it, such as:

1. Reducing the risk of a possible cyber attack.
2. Installing security updates on servers.
3. Testing the website and connected systems for weaknesses.
4. Security monitoring and identifying suspicious activity.
5. Limiting public access until the server’s security is confirmed.

After a high-level alert on PHP2Shell was issued in Bangladesh, news outlets reported that the websites of several banks had been temporarily offline. However, the fact that a bank kept its website offline does not in itself mean that a successful cyber attack took place there, that customer data was stolen, or that the bank suffered financial loss.

Taking a website offline can be a precautionary measure. At the same time, whether the same reason applied in every bank’s case needs to be verified individually.

There is another important distinction here: a bank’s public website being offline does not mean the bank’s core banking system, ATMs, card transactions or internet banking are down as well. The status of each service should be verified against the bank’s official announcements.

Which PHP versions were at risk?

On 21 October 2026 the PHP project released several versions carrying the security fixes.

Versions before the fixed releases listed above may be vulnerable to these flaws. For older PHP branches, it is necessary to check whether the relevant operating system or hosting provider has supplied a separate security patch. The project’s advisory notes that minimal source-level backports have been provided for PHP 7.4, 8.0 and 8.1 on GitHub.

Note that the permanent fix for the third vulnerability (CVE-2026-115560) announced on 23 October is not yet included in the versions above; it will arrive with the next regular release. Until then, the safe step is to set session.upload_progress.enabled=0 in php.ini or the PHP-FPM configuration. It is also worth remembering that analysis by hosting providers and security researchers suggests exploit code had circulated publicly before the fix was released—so delaying the update is risky.

One point deserves special emphasis: knowing only the major PHP version is not enough. For example, if someone says their website runs PHP 8.3, it matters whether that is 8.3.20 or 8.3.36. The security posture of the two is not the same.

Similarly, the PHP version shown in phpMyAdmin and the version actually used to process requests for the main website can differ. The site’s real runtime therefore needs to be verified.

Keep in mind too that the PHP 8.2 branch stops receiving security support on 31 December 2026, and PHP 8.1 and older branches are already unsupported. Planning a move to a supported PHP branch is advisable for the long term.

What Joomla and WordPress users should do

Staying safe from PHP security flaws is not just about updating the CMS—the PHP runtime on the server has to be kept secure too.

1. Verify the exact PHP version

Check the version from your hosting account’s cPanel, MultiPHP Manager or the relevant PHP Selector. If necessary, ask hosting support which PHP runtime your website is using and whether the security patch has been installed on it.

2. Install the security patches

Use supported, patched PHP versions. Before changing the PHP version, however, make sure your Joomla or WordPress installation, themes, plugins and other extensions are compatible with it.

3. Keep backups

Take a full backup of files and the database before updating PHP. If possible, test on a staging environment before making the change on the live site.

4. Keep extensions and templates updated

Old or abandoned extensions can weaken a website’s security. Remove unnecessary extensions and install security updates for the software you use regularly.

5. Check server logs

Examine suspicious requests, unusual file changes, unknown admin accounts or abnormal server activity with care. Installing a security patch does not automatically reveal whether an intrusion happened in the past.

6. Contact your hosting company

Shared-hosting users often cannot control every server-level security measure themselves. In that case, confirm the patch status with the hosting company and ask about any additional measures they recommend.

Why can updating PHP cause problems for a website?

Even though security updates are important, moving to a newer PHP version can produce errors on some older websites. The reason is that some themes, plugins or custom code may not be compatible with the new version. Differences in PHP extensions or server configuration can also cause trouble.

For example, if a Joomla site shows an Internal Server Error or a Fatal Error after moving from PHP 8.3 to 8.4, that does not automatically mean the PHP security update itself is faulty. The extensions, templates, custom code and the server’s error log all need to be examined.

In such a situation, the site can be kept running by temporarily rolling back to the previous version. But it is essential to make sure that previous version is itself a security-fixed release. Alongside resolving the compatibility problem, there must also be a plan to install the security patch.

Website security does not rest on PHP alone

A website’s security depends on several layers. Alongside PHP, the operating system, web server, database, CMS, extensions, admin accounts and network configuration all matter.

Strong passwords, two-factor authentication, regular backups, limited access, safe file permissions and log monitoring are all part of a security setup. A web application firewall and other defensive measures can reduce risk, but they are no substitute for installing the fixed version that addresses PHP’s core weakness.

That is why website security should be treated not as a one-time task but as part of ongoing maintenance and monitoring.

Conclusion

Flaws as serious as PHP2Shell remind us that an error in one small part of the internet’s infrastructure can spread across many websites and online services. For banks and critical institutions, precautionary measures are necessary—just as ordinary website owners must also take server and software security seriously.

Rather than panicking, the emphasis should be on verifying accurate information, using fixed PHP versions, taking regular backups and monitoring servers. Keeping a website online matters, but keeping it secure is an even greater responsibility.

Building a safe web infrastructure requires coordinated effort from developers, hosting providers, institutions and website owners alike.

Sources

1. PHP Official Security Advisory (21 October 2026) — Critical remote code execution vulnerabilities, update now
2. PHP Project Informational Advisory (23 October 2026) — Session upload progress
3. BGD e-GOV CIRT — PHP2Shell: Critical Unauthenticated Remote Code Execution Vulnerabilities in PHP
4. CERT-EU — Critical Vulnerabilities in PHP
5. Hostinger — Protecting PHP from PHP2Shell
6. Reports on the PHP security alert and bank website outages published in The Daily Star and other Bangladeshi news outlets.