Skip to main content
  • Home
  • >
  • News
  • >
  • PHP2Shell: nearly half of listed companies on the Main Market run their websites on WordPress
Article by Gustav Nyberg Gustav Nyberg

PHP2Shell: nearly half of listed companies on the Main Market run their websites on WordPress

On 21 October, the developers behind PHP, the programming language that powers WordPress among others, released urgent security updates for two critical vulnerabilities that let an attacker take over a web server without logging in. The flaws, known as PHP2Shell, affect every website running on PHP that has not been updated, which includes many Swedish listed companies. According to the PHP Foundation, one of the flaws was already known in 2024. Of the 343 companies on Nasdaq Stockholm's main list whose websites we studied, four in ten build their site in WordPress.

What has happened?

OpenAI, whose AI models were used to find the flaws, describes PHP2Shell as one of the most far-reaching vulnerabilities in recent times. Authorities have urged immediate updating, and several organisations, including public authorities, took their websites offline while waiting to update.

PHP2Shell consists of two security flaws in the PHP programming language (CVE-2026-109618 and CVE-2026-109619). The flaws lie in how PHP handles a request to the site that is interrupted halfway, for example when the server runs out of memory. PHP rates both as critical, the highest severity level, and the security updates are available in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Because WordPress is written in PHP, all WordPress sites may be affected, and the same applies to other publishing systems such as Drupal and Joomla.

Details of the flaws leaked on 20 October, before the update was ready. The same evening, the security firm Calif, which helped find the flaws, accidentally published a video showing the company's test attack working against several different targets. The video was taken down, but copies spread quickly on social media. It also revealed some details of the vulnerabilities, making it easier for others to develop their own attack code. Repositories (repos) appeared on the code platform GitHub claiming to contain ready-made attack code, and Cloudflare saw attack traffic aimed at its customers. All of this happened before PHP had time to release the update, which was brought forward from the planned date of 22 October to 21 October.

Known since 2024

This type of flaw is not new. Security researcher Stefan Esser described as early as 2004 how PHP could leave the server in an unsafe state when memory ran out in the middle of a request. The vulnerable part of PHP has been present since version 5.4, released in 2012.

In 2024, something remarkable happened. During PHP's first external security audit in several years, carried out by the French cybersecurity firm Quarkslab, a developer found the first signs of the memory flaw. No one could show at the time how the flaw could be used to take over a server. The security team developed several possible fixes, but each one risked breaking existing sites or creating new problems, and the work stalled for months. The PHP Foundation itself calls the delay a structural failure, caused by both the decision-making process and a lack of resources.

Only when researchers in 2026 demonstrated a working attack using AI tools did the flaw rise to the top of the priority list. For anyone responsible for a website, the lesson is uncomfortable. A flaw can be known for years without a security update available, and by the time one arrives, the attacks may already have happened.

Why it is serious

The flaws can be exploited before WordPress has even started. PHP has shown that in a standard server setup, a single request to the site, with no login, is enough to get in. A WordPress site with an updated core and updated plugins can therefore still be vulnerable.

Attackers can also use the flaws to read the server's memory, where passwords and keys to connected systems may be stored. A server that was updated late may therefore have leaked keys that still work.

PHP states that complete mitigations are not available and that updating is the only safe option. For version 8.1 and older, PHP no longer releases new versions. Given the seriousness, PHP's security team has nevertheless produced simple security patches in the source code for PHP 7.4, 8.0 and 8.1, but on most sites it is the provider that has to implement them. Anyone running an older version therefore needs to ask their provider how it is protected.

What we saw on the Main Market

We reviewed the websites of 343 companies on Large, Mid and Small Cap. The review was carried out between 21 and 23 October and is based on what the sites themselves show externally.

138 of the companies use WordPress, or 40 per cent. In Mid Cap and Small Cap, it is more than half:

Segment Companies Of which WordPress Share
Large Cap 128 22 17 %
Mid Cap 121 62 51 %
Small Cap 94 54 57 %

Not all sites reveal which PHP version they run. Among those that do, the distribution on 23 October was as follows:

Status Share
Updated (PHP2Shell fixed) 36 %
Not updated (security update available) 48 %
PHP 8.1 or older (no new version from PHP) 17 %

Nearly two in three had thus not updated, and one in eight was running PHP 7.

The figures should be read with caution. A site that hides its version is not necessarily secure. Conversely, a provider may have applied the security update without the version number changing, which is common among providers that backport updates to older versions. One thing can still be concluded. A site that today shows it is running PHP 7 has not been upgraded to a version that PHP itself has supported for several years, and that says more about management than about the individual flaw.

The problem lies in plugins rather than WordPress

WordPress itself, the so-called core, has few security flaws. Of the 7,966 vulnerabilities found in the WordPress ecosystem in 2024, only seven were in the core. The rest were in plugins and themes, and the number increases every year. Patchstack counted 5,948 new vulnerabilities in 2023, 24 per cent more than the year before. In 2025, 11,334 were found, an increase of 42 per cent, and 91 per cent of them were in plugins.

Many of the flaws are minor. Of the 2024 vulnerabilities, Patchstack assessed that 70 per cent are unlikely ever to be exploited. At the same time, 43 per cent could be exploited without logging in. Paying for a plugin is no guarantee either. According to Patchstack, 59 per cent of the flaws in paid plugins and themes were of the most severe type, those that can be used in automated mass attacks. Such an attack does not single out a specific company but targets every site running the vulnerable plugin. In addition, plugins abandoned by their developers never receive security updates.

This shifts the question to management. A WordPress site consists of core, theme, plugins and PHP. These are often updated by different parties, such as the web agency, the hosting provider and each plugin's own developer. PHP2Shell lay in the layer that the editor never sees and that no one at the company usually has responsibility for.

The website is part of the MAR chain

For a listed company, the website is more than a marketing surface. Inside information is disseminated first via the news distributor, but under Article 17.1 of MAR, the company must also post the information on its website and keep it there for at least five years. The article also requires the issuer to ensure that inside information is kept confidential until it is made public.

That makes the time between upload and publication a risk. How much it can be worth was shown by a US case in 2015. Over five years, hackers broke into press release distributors and accessed more than 100,000 releases before publication. According to the SEC, trading on the information generated over USD 100 million in illegal profits. That case concerned distributors, but the same window arises when confidential files are uploaded to the website's media archive awaiting publication. The window is at its widest during reporting periods, and right now we are in the middle of third-quarter reporting.

What listed companies should do now

  1. Ask the web provider which PHP version is running, whether the security update is installed and whether the server has been restarted afterwards.

  2. Replace keys and passwords that have been on the server if the update was delayed by more than a day or so.

  3. Go through the plugins, remove those that are not in use and check that the rest are still maintained.

  4. Ensure that responsibilities are clearly divided for core, theme, plugins, PHP and server, and that this is stated in the contract.

  5. Ask the provider to show how the site is protected if it runs PHP 8.1 or older, since PHP no longer releases new versions for them.

  6. Keep inside information off the public server until publication, even when publication is scheduled.

  7. Have a plan for reporting day that defines what applies to the website if it goes down. Press releases still go out because they are distributed via the distributor and not via the website.

Listed companies devote substantial resources to getting their reporting right, with audits, controls and clear accountability for every figure. The website where the same report is published, however, is often handled as a marketing project, spread across a web agency, possibly a hosting provider and a number of plugins that no one at the company has an overview of. Yet the website is the hub of a listed company's disclosure. Ask yourself how many people read your financial reports compared with how many visit your website. For most companies, the answer gives pause for thought, and yet the website often receives a far smaller share of the budget.

PHP2Shell was known for two years before a security update was available. In the days after the update was released, nearly two in three of the listed-company sites that show their PHP version were still running a version where the flaw had not been fixed. This says less about the technology than about ownership, and it raises the question of whether a platform built on third-party plugins is the right choice for a website that handles sensitive information.

AVA Corporate Communications is a communications agency in Stockholm and Gothenburg that works with over 30 listed companies on Nasdaq. We offer financial communication, investor relations, sustainability, digital solutions, brand and public relations, and we build and manage IR websites and corporate sites as part of companies' disclosure and reporting. Contact us for a review of your website or for more information.

Get in touch

Our strategic advisors and consultants help our clients manage complex challenges and create lasting value over time.

Contact

Contact us

*
*
*
By clicking "Submit" you accept our terms and conditions and confirm that you have read our privacy policy, including our cookie policy.