PHP after the latest warnings: evidence from Kazakhstan education websites

What changed in the past day

On 23 October PHP published an additional notice about session upload progress. It describes CVE-2026-115560 as an unlikely remote-code-execution path requiring an unusual combination of configuration and application behaviour. Pending a routine fix, PHP recommends disabling session.upload_progress.enabled; administrators who already disabled it should keep that setting. This is not an announcement that every PHP website has been compromised. PHP notice.

The earlier critical CVE-2026-109618 and CVE-2026-109619 were fixed on 21 October in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Those releases address those two flaws; the 23 October notice must be considered separately. Linux and commercial LTS vendors may backport a fix without changing the upstream-looking version. Their bulletin and complete package revision matter. PHP, Red Hat bulletin updated on 23 October.

Scope and method

On 24 October Shanraq made one ordinary HTTPS homepage request to each of 60 selected public endpoints. We examined public response headers and HTML technology signals. We did not log in, request diagnostic files, perform load tests or attempt exploitation. No student personal records were collected.

This is a purposive, non-representative sample, not a census of Kazakhstan’s websites or a security audit. University selection drew on the ENIC directory, colleges on public lists and their own pages; the school portion is predominantly associated with Kostanay. Returned pages were checked for institutional identity. Internal learning platforms, branch subdomains and contractors’ servers are outside scope. Institutions of differing ownership should not be treated as a verified exclusively state-owned population.

Of 60 endpoints, 45 returned HTTP 200 but only 36 provided usable substantive pages. Fifteen requests ended in network/TLS errors or timeouts; seven returned access restrictions or technical shells; two were excluded from technology statistics because the response did not establish the intended institutional identity. This does not establish compromise. Six education-authority endpoints share GOV.KZ and must not be counted as six independent technology platforms.

Reading the results

Seven of 36 usable pages explicitly declared PHP and a version in a response header. Eleven other pages exposed WordPress, Joomla or Bitrix signals: indirect evidence of a PHP-associated CMS, not verification of the current origin runtime. PHP was undetermined on 18 pages. The education subset has 31 usable pages: seven explicit banners, ten indirect CMS signals and fourteen undetermined results. These are not national education-sector prevalence estimates.

The seven banners declared 5.3.29 once, 5.6.40 twice, 7.4.33 three times and 8.3.36 once. Six refer to branches without routine PHP Project support. This means six of seven disclosed banners, not “86% of schools are unsafe”. A banner can be stale, altered or describe a vendor-backported package. Administrators must verify installed packages and the web workers actually serving requests.

PHP: Supported Versions

Languages, frameworks and versions are different layers

All 36 usable pages load external JavaScript scripts. That describes browser-side code, not proof of a Node.js backend. Two pages return Nuxt headers and two return Next.js headers. These frameworks can serve pregenerated pages and do not disclose the source language or server-runtime version. Compiled scripts do not reliably distinguish TypeScript from JavaScript.

Java, Python, Go, C#, Node.js and operating-system versions were not verified in this review. “Undetermined” does not mean zero adoption. WordPress 7.1.3, 6.8.8 and 6.0.17 occur in individual pages’ HTML metadata: these are CMS versions, not PHP versions. CMS support status requires its own assessment; a version number is not presented as a vulnerability finding. Observed public markers appear in the detailed table.

How obsolete or secure is the situation?

Old PHP banners justify prioritising lifecycle, maintenance-owner and support-contract checks. Neither an old nor a new number alone answers whether personal data is safe. Access controls, uploads, dependencies, configuration, backups, logs and incident response also matter. PHP 5.3.29 cannot automatically be assigned a particular CVE affecting a different version range: lack of routine support and confirmed applicability of a specific flaw are distinct findings.

All 36 usable pages were retrieved over certificate-verified HTTPS. HSTS appeared on 15 responses, CSP on four, and X-Content-Type-Options and X-Frame-Options on sixteen each. A missing header in one response does not establish that equivalent safeguards are absent. HTTPS protects transport but cannot repair the interpreter. These indicators are not combined into a “security score”.

Observations for each usable page

Versions are server declarations, not verified code execution results. CMS assets may be cached; updating a plugin does not establish a PHP update. A missing marker does not establish that a technology is absent.

Have state education organisations acted?

KZ-CERT has issued a national PHP2Shell warning. That establishes public notification, not successful patch installation on every education server. A limited search of official education domains and GOV.KZ did not yield individual organisations’ patch-installation records, worker-restart logs or independent verification reports. Their absence from search is not proof of inaction; internal maintenance is often unpublished. KZ-CERT warning.

One school response declares 8.3.36, matching an upstream release fixed on 21 October. This is a positive external observation, not proof that every school server is current, the latest configuration advice is applied, or student databases are secure. Only the system owner can confirm package revisions, SAPI, installation time, restarted workers and verification responsibility. The editorial team has not contacted contractors on institutions’ behalf or accessed their internal infrastructure.

What a verifiable protection plan should contain

1. Inventory public and internal PHP applications, including learning systems and contractors’ components, with maintenance owners and support expiry.
2. Install a vendor-confirmed fixed package; update base images and replace deployed builds where containers are used.
3. Fully restart affected web workers and verify the environment actually serving HTTP. A CLI version alone is insufficient; publishing phpinfo() is unnecessary.
4. Assess the 23 October notice, test applications with the recommended upload-progress setting disabled, and control the configuration administratively. A temporary setting does not replace patches for the previous two critical flaws.
5. Review logs, access rights, recovery tests and dependencies; record findings and an accountable owner. Coordinate suspected incidents with KZ-CERT.

A public progress report can list system counts, remediation coverage, exceptions and deadlines without exposing secrets, internal addresses or student personal data.

Our G-TON Astana Hub proposal

Shanraq and Qazna Technologies propose a unified platform for regional education departments on an existing modular Go foundation. The live product already has publishing, accounts, roles and three-language content; its stack includes Go, PostgreSQL and the chi HTTP framework. This is our developer proposal, not an independent certification of superiority or a claim to have won the programme. Shanraq framework.

G-TON’s education-organisation portal challenge describes approximately 600 schools and kindergartens repeatedly buying websites and calls for a platform hosted on a regional server, free for organisations to use. We propose a separate regional build, organisation spaces, shared templates and central maintenance. Tenant/data isolation, migration, recovery, capacity and update procedures require pilot verification. Our presentation proposes three to five organisations over two months, a plan for agreement rather than an approved customer timetable. Astana Hub challenge, our presentation.

Go does not provide automatic immunity: dependency maintenance, access controls and external assessment remain necessary. The practical opportunity is a named lifecycle owner, repeatable updates and effective separation between organisations. Choosing a programming language cannot substitute for those processes.

CSV observations for all 60 requests. Public-page snapshot: 24 October 2026.

ENIC · GOV.KZ

Primary source: https://www.php.net/archive/2026.php#2026-10-23-1.

Charts and cover: Shanraq, original observations collected on 24 October 2026.