Millions of PHP attack attempts: what Swiss website owners need to do now

Two critical vulnerabilities in the widely used programming language PHP prompted precautionary website shutdowns worldwide on Wednesday, 21 October. In Switzerland, those affected included the canton of Basel-Stadt, the University of Geneva and EPFL, the Swiss Federal Institute of Technology Lausanne. Security updates have been available since Wednesday afternoon, but server operators face an urgent task: attempts to exploit the flaws already run into the millions.

Several websites belonging to educational institutions, businesses and public authorities remained unavailable on Thursday morning. Most of the Swiss services named above were back online. A precautionary shutdown does not mean a website has been successfully attacked: its immediate purpose is to stop an unprotected server remaining accessible online.

Why these vulnerabilities are so dangerous

PHP runs behind the scenes on web servers, powering dynamic websites. It underpins applications including WordPress, Drupal and MediaWiki, the software behind Wikipedia. Estimates suggest more than 60 per cent of websites use PHP in some form. That reach explains the scale of the warnings, but does not mean that a similar proportion of websites have been attacked or taken over.

Both flaws allow attackers to execute malicious code remotely on affected servers without logging in. In the worst case, they can take control of a server and the websites it hosts. The consequences could extend beyond outages: customer data could be stolen, or data encrypted to demand a ransom.

The flaws had gone undetected for years. The PHP project had known about them since August and was preparing security updates. Their existence was meant to remain confidential until the fixes were released, denying attackers a head start. Yet details of the vulnerabilities and ways to exploit them began circulating several hours beforehand.

Cloud services company Cloudflare recorded thousands of attack attempts during roughly the ten hours before public disclosure. In the first 45 minutes afterwards, the figure rose to tens of thousands, reaching hundreds of thousands within two hours and subsequently millions. These figures count attempts, not confirmed successful breaches.

What Swiss operators need to check

The Federal Office for Cybersecurity, Switzerland’s federal cybersecurity authority, has urged operators of websites, online shops and digital business platforms to act immediately. The first step is to establish where PHP is running, which versions are in use, which systems are accessible from the internet and who operates them. Integrated components and externally operated applications must also be included.

The security updates available since 4pm on Wednesday must be installed without delay. But installation alone does not necessarily finish the job. Affected PHP services and continuously running processes must then be restarted. Applications running in containers may need to be rebuilt and redeployed.

Administrators must then check that the application actually running uses the corrected PHP version, or a software package whose provider has confirmed the fix. Downloading an update offers no protection to a service still running the old software.

Older PHP versions that are no longer officially supported present a particular problem: corresponding updates are not available for them. These systems should be isolated or taken offline until they have been moved to a current, supported and patched version. Websites left unchanged for years may therefore need considerably more work than a single update.

Hosting provider or private server: who is responsible?

For Swiss clubs, individuals and businesses, the immediate workload depends heavily on how their website is operated. Many rent hosting space for WordPress sites or other applications. In that arrangement, updating the underlying server environment is generally the hosting provider’s responsibility. Anyone unsure should check the provider’s service status information or obtain explicit confirmation that the flaws have been fixed.

Those operating their own server must arrange the PHP update themselves. Managing content in WordPress and securing the server environment beneath it are separate tasks. What matters is not simply which content management system a website uses, but who maintains its technical infrastructure.

Whatever the hosting arrangement, an update closes the vulnerability but does not undo an intrusion that has already occurred. Administrators should examine logs and systems for unusual requests, crashes, changed files and unexpected processes. Those checks also matter before a website is brought back online. A temporarily disconnected server is not automatically free of malicious software if attackers had already compromised it.

The distinction is important for organisations restoring services: installing the fix and checking for an earlier breach address different risks. Both need attention before a shutdown can be treated as having resolved the problem.

What internet users will notice — and what comes next

People simply browsing on a smartphone or computer do not need to update their own device because of these PHP flaws. The vulnerabilities are on providers’ servers, not visitors’ devices. Users can nevertheless be affected indirectly, through unavailable online services or potential data leaks from inadequately protected websites.

Further attacks and outages are expected over the coming days because not every operator can secure its systems at the same time. The immediate priorities are to install updates, verify that they are effective and investigate possible earlier intrusions.

For Swiss organisations with a website, the central question is whether the responsible operator has completed all three tasks. A service being back online is not, by itself, confirmation that its server has been patched and checked for signs of compromise.