home › Forums › Device, App & Web Security › Other Web, App Security › PHP2Shell Malaysia, WordPress sites urged to patch now

Viewing 1 post (of 1 total)
  • Posts
  • Millions of websites, including a large share run from Malaysia, are exposed to two critical flaws in PHP, the programming language that sits beneath WordPress, Drupal, Joomla and most online shops. PHP has released emergency updates that close the holes, and the project says only updating fully protects a server.

    The flaws, known together as PHP2Shell, let an attacker without an account run code on a web server. They carry the identifiers CVE-2026-109618 and CVE-2026-109619, and both are rated 9.2 on the CVSS v4.0 scale. PHP published the fixes around 14:00 UTC on 21 October 2026, a day after details leaked ahead of a planned 22 October disclosure.

    The scale is unusual. The Guardian and others report that PHP runs nearly 70 per cent of websites, and internet scanning firm Censys counted almost 55 million web properties running the language. Palo Alto Networks has estimated more than 22.6 million exposed instances.

    Why Malaysian WordPress sites are at risk

    The flaws sit in the PHP runtime, not in any application, so a site is exposed even when its own code is secure. Every PHP installation serving web requests is at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, according to the PHP security advisory. Even a basic page on a vulnerable PHP version can be attacked.

    The advisory singles out mod_php as the highest risk. In a demonstrated exploit, a single unauthenticated request triggers the attack before any application code runs. PHP-FPM behaves differently, because it shuts the worker down when a request fails early in setup.

    An attacker can also read memory from the PHP worker process, which may hold passwords, authentication tokens, API keys and certificates belonging to other visitors, without first gaining code execution. Researchers demonstrated this against applications they did not control.

    For most Malaysian site owners, the practical problem is simple. WordPress updates, plugin updates and security plugins cannot fix this, because the flaw sits below the application. The PHP runtime is updated by the hosting company, the server administrator or the container image, not from inside the WordPress dashboard. Site owners on shared or managed hosting should contact their provider and ask directly whether the 21 October PHP security release has been installed on the server holding their site.

    Malaysia urges patching of internet-facing systems

    Malaysia’s National Cyber Security Agency has urged local organisations to immediately patch internet-facing PHP systems, Lowyat.NET reported. The Malaysia Computer Emergency Response Team recommends temporarily taking internet-facing PHP systems offline where patches cannot be applied immediately.

    The advice mirrors warnings abroad. The US Cybersecurity and Infrastructure Security Agency publicly named the flaws and said they allow unauthenticated remote code execution affecting all installations serving web requests. The US National Security Agency told organisations running PHP to take systems offline if they cannot update immediately, and the UK’s National Cyber Security Centre issued its own alert.

    NC4 also advises organisations to monitor server logs for suspicious activity and to isolate affected systems if a compromise is suspected. Businesses relying on shared hosting or third-party managed services should confirm with their providers that the updates have been installed.

    Which PHP versions fix PHP2Shell

    Administrators should update the PHP runtime that serves web requests, then restart Apache, PHP-FPM and any long-running PHP workers. PHP 8.5 is fixed in version 8.5.12, PHP 8.4 in 8.4.27, PHP 8.3 in 8.3.36 and PHP 8.2 in 8.2.35. Any release below those numbers on each branch remains vulnerable.

    WordPress owners can check their version by opening Tools, then Site Health, then the Server section in their dashboard, and comparing the PHP version against the fixed releases.

    PHP 8.1 and older no longer receive updates from the PHP project. PHP 8.2 reaches end of life on 31 December 2026. For older branches, the PHP security team has published source backports for PHP 7.4, 8.0 and 8.1 for people building from source or waiting on a vendor.

    Linux distributions and long-term-support vendors received the patches in advance, so a distribution package can carry the fix under an old-looking version number. Administrators should check the package changelog for the CVE, as Debian advises, rather than the version string. A hosting provider’s answer should be held to the same standard.

    Workarounds are not a full fix

    Only updating is a complete fix. The settings below reduce exposure to specific attack paths and do not make a server safe, according to the advisory.

    For CVE-2026-109618, set memory_limit=-1 so applications cannot override it, keep post_max_size low and enforce request-size limits at the web server or proxy. For CVE-2026-109619, set session.upload_progress.enabled=0 and restart every worker, and on PHP 8.5 also set fatal_error_backtraces=0.

    The session setting circulated as a workaround before the patch, and the release confirms it was never a complete fix. “The only thing I can say is that the only mitigation is patching/upgrading PHP. I sadly know too much,” PHP core developer Gina Peter Banyard wrote before the release.

    Anyone who has patched but suspects an earlier break-in should watch for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, oddly large PHPSESSID response cookies, and unexplained restarts of PHP workers.

    Attacks under way but no confirmed breach

    Exploitation attempts are active. watchTowr reported at 14:19 UTC on 21 October that it was observing active exploitation attempts of both CVEs, having reported none earlier in the day. Amazon said its MadPot honeypot network recorded an exploitation attempt on 17 October, four days before public disclosure.

    “We are seeing early attacks emerging and are updating mitigations as new vectors show up,” Cloudflare CTO Dane Knecht said, calling the firewall rules Cloudflare deployed a stopgap and urging administrators to patch.

    No source has confirmed a successful break-in of a specific server. Some organisations took services offline as a precaution. The Wikimedia Foundation said it had taken down a number of systems as a precaution until they could be safely patched, and parts of Wikipedia were briefly unavailable. In the Netherlands, government identity services DigiD and MijnOverheid, the lower house of parliament’s site and several education systems went offline, the broadcaster NOS reported. BambooHR took its service offline across the United States, Canada and Ireland and warned that payroll would be interrupted.

    How the flaws came to light

    A leak pulled the release forward. On 20 October, a post on Hacker News said two PHP remote code execution flaws were set for disclosure on 22 October, based on a trusted tip. PHP posted an advance notice that evening and moved the release to 21 October. The leak’s claim of a CVSS 10.0 score was not PHP’s. PHP rates both flaws 9.2.

    The flaws were found by Wiz Research, Calif and OpenAI’s Codex Security team, working with the PHP security team and Google’s Gemini team on the fix. The researchers say AI models helped turn long-standing flaws into working exploits, letting one researcher do in about a week what would otherwise have taken a team months.

    The PHP Foundation said a core developer first found signs of the out-of-memory flaw during PHP’s 2024 external audit, but no concrete route to code execution was found then. Competing fixes risked breaking compatibility or opening denial-of-service paths, and work stalled for months. The Foundation called the delay “a structural failure” of its decision process and its resources, and said it has since changed how it makes security decisions and added staff and tooling.

    The coordinated disclosure also came apart before the release. Around 20:00 UTC on 20 October, Calif mistakenly posted a video of its working proof of concept, and at 07:41 UTC on 21 October, about six hours before the fix shipped, the vendor Chainguard published built images containing the patch, letting anyone study the fix while other users waited to update.

    0
Viewing 1 post (of 1 total)
  • You must be logged in to reply to this topic.