Türkiye’s official PHP warning: A practical response for organizations
The Turkish Cybersecurity Presidency’s PHP security bulletin TR-26-1372, dated 21 October 2026, calls on organizations to review their PHP systems. My previous post covered the technical vulnerabilities; here I want to translate the official warning into practical work for the teams responsible for those services.
The bulletin warns that successful exploitation could execute code with the application’s permissions. The possible impact goes beyond a defaced website: files, data, and services accessible to the application could also be exposed. The scope depends on the permissions granted to the application and the details of its deployment.
Separate the bulletin’s publication date from the current situation
When the bulletin was written, the PHP team’s detailed security announcement and update were still expected. As of 22 October 2026, that waiting period is over: the fixes have been released. Repeating the earlier expectation as though patches were still unavailable would give readers an outdated picture.
The corrected releases identified in the official PHP security announcement are:
| Installed branch | Release fixing these two vulnerabilities |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
This table gives the fix thresholds for the two issues discussed here. Distribution vendors may backport the patches into their own packages, so their package advisories also need checking; the upstream version number alone may not settle the question.
What are the two technical problems?
CVE-2026-109618 involves invalid internal request data left behind when out-of-memory handling interrupts processing. CVE-2026-109619 concerns stale internal state associated with freed memory being reused by subsequent requests. Under suitable conditions, either problem can lead to remote code execution.
That does not mean every deployment can be compromised through exactly the same route. The way PHP is hosted and the application’s behavior affect susceptibility. However, using a particular server configuration is not sufficient justification for delaying the update.
How I would organize the response
I would start with a short inventory mapping applications to the servers that run them. Which service is exposed to the internet, which PHP package does it use, who owns it, and when will the update be installed? Without answers to those questions, a statement that “the servers have been updated” is difficult to verify.
Next I would update the running service and restart the processes that need it. I would check the PHP service handling actual web requests and any separate workers, rather than relying on the version printed in a terminal. In a container deployment, the fix also needs to be represented in the image or persistent configuration so it survives the next recreation.
The Presidency’s access restrictions should be applied according to the service’s needs: restrict administrative interfaces and critical services to authorized addresses, and block international traffic where the system has no requirement for it. These measures reduce the routes through which an attacker can reach the service; they are not a permanent substitute for updating PHP.
My final check would be evidence that an owner can use to close the work: the installed package, the active version, the restarted services, and successful application checks. This post does not report an inspection of a particular organization’s infrastructure or claim that an attack has been detected; it describes the practical response I draw from the official warning.
The cover is an AI-generated illustrative scene. The Turkish edition includes an AI-presented studio bulletin, not a recording of a human newsreader or a real live broadcast.