Two critical vulnerabilities discovered in PHP are prompting governments and technology providers around the world to patch affected systems and, in some cases, temporarily take services offline. Granicus took precautionary action to address the vulnerabilities and safely restored all services within 24 hours, with no known breach of Granicus systems and currently no indication of malicious activity or exploitation affecting Granicus products.
The remediation is complete and all Granicus solutions are back online. Check the status of your solutions any time at status.granicus.com.
Here is what government organisations and Granicus customers need to know about the vulnerabilities, the measures taken in response, and the steps they can take while remediation continues.
What are the PHP vulnerabilities?
PHP is a widely used programming language designed in part for web development. On October 20, 2026, the PHP security team announced two critical vulnerabilities, each with a CVSS v4.0 severity score of 9.2, and urged users to prepare to upgrade as soon as fixes became available.
The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, could allow an attacker to make a vulnerable server run malicious code without needing a username, password, or other credentials. In cybersecurity terms, this is known as “unauthenticated remote code execution.” CERT-EU says PHP installations serving web requests are at risk across several common configurations.
The two vulnerabilities create this risk in different ways.
CVE-2026-109618 involves how PHP handles memory when a request exceeds its configured memory limit. Under certain conditions, an interruption can occur while PHP is still initialising request data. During cleanup, PHP may then use memory that was not initialised properly, creating an opportunity for an attacker to influence what happens next.
CVE-2026-109619 involves internal information from one request remaining after the memory supporting it has been freed. A later request handled by the same worker can encounter that older information before PHP resets its normal state. The result can again be remote code execution.
The vulnerabilities exist in the underlying PHP technology. Commercial and open-source applications can also use PHP behind the scenes, giving organisations another set of systems to assess.
Why were websites and services taken offline?
Organisations running affected PHP systems need to reduce their exposure while fixes are applied.
The UK National Cyber Security Centre (NCSC) has advised organisations that cannot immediately update PHP to take affected systems offline until they can be fully mitigated. The agency warns that vulnerabilities of this kind can provide a direct path to a server’s file system or database. The US Cybersecurity and Infrastructure Security Agency (CISA) has also issued an alert calling for immediate patching of the critical PHP vulnerabilities.
That guidance explains why people may find websites and other services temporarily unavailable.
It also makes the distinction between a vulnerability and a compromise especially important. A vulnerability creates an avenue an attacker may be able to exploit; a system is not compromised or breached unless there is a successful attack. Taking an affected service offline can remove that avenue while teams patch and verify the underlying environment.
The PHP project has released fixes in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and earlier branches have reached end of life and no longer receive standard updates from the PHP project, although some distributions and long-term support vendors may provide backported fixes.
How did Granicus respond?
The immediate technical work centres on applying the appropriate fixes, verifying affected environments, safely restoring services, and continuing to monitor for potential threats. Government cybersecurity agencies across the globe, including NCSC, CISA, the Canadian Centre for Cyber Security, Australian Cyber Security Centre, and CERT-EU recommended keeping internet-facing resources isolated when immediate patching is not feasible until fixes have been applied and verified.
Granicus temporarily took affected PHP-based services offline while our Security, Engineering, and Product teams investigated and addressed the vulnerabilities before safely restoring access.
At this time, there is no known breach of Granicus systems and no indication of malicious activity or exploitation affecting Granicus products. Our Security Operations Centre continues to monitor for unusual activity and potential security incidents.
What should governments do to mitigate the PHP vulnerabilities?
Customers who rely on affected PHP-based services should develop contingency plans for those services and continue monitoring the Granicus Status Page for the latest availability information and guidance.
For government teams, contingency planning should focus first on the functions that cannot wait for service to return. Identify time-sensitive public communications, transactions, meetings, or government services that depend on an affected solution, then determine how your organisation will handle those functions while the service remains unavailable.
Service availability alone should not be interpreted as evidence of a security incident. Granicus took affected PHP-based services offline as a precaution while teams addressed the vulnerabilities, and there is currently no indication that Granicus products have been compromised or exploited.
As of 2 p.m. BST October 22, all Granicus services have been fully restored.
