Update
PHP’s October updates: reconcile the supplier’s patch evidence
A retrospective of PHP’s October advisories and a practical way to distinguish runtime fixes, configuration checks and Windows package rebuilds.
Contrata editorial team · Published · Prepared on
Retrospective analysis of the October PHP advisories, originally drafted 22 October and refreshed 31 October 2026. This is not a new incident announcement or a finding that any particular supplier is exposed.
A supplier’s answer that it has “patched PHP” needs a date and a scope. During October, the PHP project published a critical runtime update, later configuration advice and a Windows package rebuild. Those are related assurance questions, but not interchangeable evidence.
For a lean Australian risk team, the useful job is to connect the applicable notice to the service your organisation buys. Ask the technical owner to establish applicability; do not ask a relationship manager to guess from a version string.
What changed during October
The PHP project’s dated notices distinguish three developments:
- 21 October: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 addressed two critical remote-code-execution vulnerabilities. The advisory covers installations serving web requests and explains vendor backports and limits of interim mitigations.
- 23 October: additional session-upload-progress advice addressed an unusual configuration and runtime-handler combination. Applicability needs technical assessment; it is not evidence that every patched service is affected.
- 26 October: Windows rebuilds with a
-1package suffix included a Brotli dependency fix. The PHP runtime version itself did not change. The relevant decoder path involves cURL response decompression when enabled.
These notices should be checked again at the time of a supplier decision. A statement about one does not automatically settle the others.
The NSW Government’s 22 October statement said some government websites had been taken down as a precaution while updates were applied. It reported no information breaches notified to Cyber Security NSW at that time. That dated statement is neither a current service-status report nor a guarantee that no breach occurred.
Build one service-scoped evidence record
Start with the customer-facing service, not the supplier’s entire technology estate. A hosted portal, document-transfer application and public website might use different stacks even when one supplier operates them.
Record the service owner and the person responsible for the technical assessment. Then ask for a concise response covering:
| Question | Useful evidence | What it does not establish |
|---|---|---|
| Does the purchased service use the relevant component? | A scoped component inventory or technical-owner statement identifying environment and service | That every other service has the same configuration |
| Which advisory applies? | Advisory reference and a documented applicability decision | That a generic “not affected” email answers later notices |
| What was deployed? | Package/build identifier, applicable vendor notice and deployment record | That a runtime version alone identifies bundled dependencies |
| What remains open? | Unresolved configuration question, change owner and review time | That a planned change has already happened |
| Does the service work after the change? | A proportionate test result tied to the changed environment | That every function and customer journey has been tested |
Do not request secrets, full production configuration dumps or customer records merely to complete this table. Ask the technical owner for the minimum evidence needed to support the decision, with sensitive detail held in the appropriate restricted system.
A version string is a starting point, not the conclusion
Consider a fictional supplier whose support email says its portal is running the fixed PHP runtime. Its hosting team later confirms that it uses Windows packages. The risk team should not conclude either “safe” or “unpatched” from those two sentences.
The next request is specific: identify the installed package build, the relevant vendor notice and the hosting team’s assessment of the later Windows advisory. Separately, ask whether the configuration advisory applies to the application. If the owner has not yet assessed that question, keep it open rather than carrying forward an earlier answer.
This is an illustrative review method, not a finding about a real supplier or a recommendation to make configuration changes without testing. The supplier’s authorised technical team should use the current project and distribution guidance within its change process.
Keep the operational consequence visible
A precautionary service pause, a failed deployment and confirmed compromise are different events. Record the one the evidence supports. If access to a supplier service is interrupted while changes are made, the business owner still needs to understand the affected work, temporary arrangements and recovery priority.
After restoration, check whether transactions or scheduled work accumulated during the interruption. The existing supplier recovery reconciliation guide helps separate a working connection from a cleared backlog.
Close the review when the applicable technical questions have evidence, service checks are complete and remaining exceptions have named owners. Use the remediation closure guide to distinguish a completed action from a promised one. Do not close every row because the supplier has answered only the first advisory.