South Korea starts emergency response to PHP security flaws
SBS reports government guidance as vulnerable websites face an urgent security response.
South Korea has begun an emergency response to critical PHP vulnerabilities as the programming language’s developers urge website operators to install security updates.
SBS reported Thursday that the government was directing companies and organisations to take protective action. The PHP project’s own advisory, published October 21, identifies two vulnerabilities that can allow unauthenticated remote code execution.
Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP team is urging users to update rather than rely on temporary configuration changes.
The vulnerabilities sit below application logic
The issues, tracked as CVE-2026-109618 and CVE-2026-109619, involve memory handling and stale internal state. The project says installations serving web requests are at risk and identifies Apache’s mod_php as the highest-risk configuration in its demonstrated case.
That does not make other listed deployments safe without checking the advisory. It also means a website’s own login page or application-level checks are not enough to establish that its server is unaffected.
A vulnerable installation and a confirmed compromise are different things. The discovery does not prove that every PHP website has been attacked successfully.
Operators should check vendor packages
Administrators need to identify the PHP packages actually running and consult their hosting provider or distribution vendor about patched versions. Some vendors backport security fixes, so an upstream version number alone may not describe the status of a maintained package.
The PHP team says distributions and long-term-support vendors received patches in advance. Its support guidance also distinguishes actively maintained branches from older releases that no longer receive routine upstream updates.
Older branches need special attention
PHP’s support policy gives a release branch an initial period of active maintenance, followed by a period focused on critical security fixes. A branch reaching the end of that lifecycle no longer receives routine support from the PHP project. Administrators therefore need to consider both the immediate patches and the longer-term status of the software they depend on.
The official guidance says PHP 8.1 and earlier no longer receive normal upstream updates. Some distributions and long-term-support vendors may still provide backported fixes, so organisations using those packages should establish what their vendor actually maintains rather than assume either that every older package is safe or that its visible version number tells the whole story.
For this incident, the PHP team also supplied minimal source backports for certain older branches to assist people building from source or without an LTS vendor. Those exceptional materials do not turn an obsolete branch into a generally supported platform. The immediate task is to obtain an applicable fix; the continuing task is to keep the deployment within a maintained update path. Both matter when deciding whether a server is ready to remain in service.
A patch does not replace a compromise review
The official advisory says temporary measures reduce only particular attack paths and do not make an installation safe. Operators should follow the complete advisory and environment-specific vendor guidance rather than copy isolated settings from a general news story.
After updating, they should confirm that the running service is using the patched software. Reviewing whether a server was previously compromised is a separate task that may require logs and other evidence.
SBS’s bulletin also described European restrictions on access to government websites during the response. The available account does not identify the security status of any particular reader’s site; that requires checking the actual deployment.
