The reply from your website supplier says “updated.” That is useful, but it leaves two questions unanswered: which PHP runtime is actually serving customers, and what happened before the update?
For a Malaysian SME running an order portal, customer website or internal application, those questions now deserve a named owner. The PHP project’s 21 October 2026 advisory identifies CVE-2026-109618 and CVE-2026-109619, two flaws that can permit remote code execution without authentication. The patched releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Updating a CMS or its plugins does not, by itself, establish that the underlying PHP runtime has been fixed.
Start with the application behind the domain
Ask for an inventory organised by business service, rather than a screenshot of a hosting account. Record the application, public address, hosting arrangement, technical owner and runtime evidence. Include forgotten campaign sites, supplier portals and staging environments that are still reachable from the internet.
Do not assume that the version reported by a command-line tool is the one handling web requests. Ask the administrator to verify the relevant web-serving process and its deployment configuration. For shared hosting, request confirmation from the provider identifying the affected account and its assigned runtime. Avoid publishing a diagnostic page containing server details just to obtain this evidence.
Hypothetical example: a distributor’s main website and quotation portal share one hosting account but use different PHP handlers. The provider upgrades the website’s handler; the portal remains on an older one. A single “hosting updated” email would miss the business-critical exception.
Containers and cloud platforms still need a deployment check
Docker’s 22 October notice confirms that its PHP Official Images and Hardened Images were updated. That makes corrected images available; it does not demonstrate that your running application has changed. Have the team identify the image used by each live workload, rebuild where appropriate, redeploy and verify the replacement instances. Keep the deployment record with the service inventory.
Cloud responsibility also depends on the service. AWS’s bulletin, updated 23 October, provides product-specific instructions: for example, customers using PHP custom runtimes or container images on Lambda are responsible for updating and redeploying them. Existing Lightsail instances need customer action; availability of a new blueprint does not update a running instance. “It is hosted in the cloud” is therefore not a closure criterion.
Read the follow-up advisory, too
PHP published an additional session upload progress advisory on 23 October. It recommends disabling session.upload_progress.enabled pending the next regular bugfix release for an unusual configuration involving a runtime change of session serializer. Applications that never make that change can retain the feature. Ask the application maintainer to assess applicability and document the decision; do not label every patched installation compromised.
Configuration advice needs an accountable administrator. Copying isolated settings into production without checking how they apply to the serving process can create an unreliable sense of completion. Where an application cannot be updated promptly, agree temporary exposure restrictions and a business continuity route. Record when those measures will be reviewed.
Patching and investigating are separate jobs
Amazon Threat Intelligence reported a PHP2Shell exploitation attempt in its MadPot telemetry dated 17 October 2026, before public disclosure. This is a confirmed observation in Amazon’s monitoring environment. It is not evidence that your organisation, any Malaysian business or every vulnerable server was breached.
It does explain why “we patched yesterday” cannot answer the historical question. Ask whoever handles security monitoring to preserve relevant web, application and host logs before retention windows expire. Review unexplained changes, unexpected processes and suspicious access using the current vendor guidance. Treat findings as leads to investigate, rather than proof based solely on an unusual request.
If compromise is suspected, bring the application owner and incident responder together before making destructive changes. They need to consider evidence preservation, containment and any credentials the affected application could access. A routine restart and an incident investigation have different objectives.
What an SME owner should receive
A useful closure note is short enough to read and specific enough to challenge. Request four items: the services checked; the fixed runtime or vendor-backported package evidence for each; the deployment and business-function test results; and the outcome or status of the compromise review. Any unresolved item needs an owner, deadline and temporary control.
Test a real business journey after the change: submitting an enquiry, placing a test order or generating a quotation. Use approved test data and confirm that the result reaches its intended destination. A homepage loading successfully is not the same as an application working correctly.
For your next supplier review, link this evidence to your patch exception register. The objective is a defensible answer for every exposed application, with unfinished work visible. To discuss your application and infrastructure priorities, contact AXO Technologies.
Sources and dates
Published 26 October 2026. Official sources checked on 26 October 2026; this is the access date, not a claim that each advisory was published today. Guidance may change.
- PHP: critical remote code execution advisory — 21 October 2026.
- PHP: session upload progress advisory — 23 October 2026.
- Docker: impact for Docker customers — 22 October 2026.
- AWS bulletin 2026-143-AWS — published 21 October; updated 23 October 2026.
- Amazon Threat Intelligence: pre-disclosure exploitation attempt — 21 October 2026.