21 October 2026 | Updated 23 October 2026 | Website Security
Your website can look perfect, load quickly and still need an urgent security update.
The PHP security release on 21 October was a reminder that launching a website is only the beginning. Keeping it reliable requires ongoing attention to the software behind it.
Whether you built your application with AI or hired a development team, someone needs to follow security announcements, understand what is affected and act.
For this incident, asking a coding agent to “update Composer” would not have been enough.
What happened?
PHP released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can allow an attacker to execute code remotely without authentication.
The releases addressing these vulnerabilities were:
| PHP branch | Fixed release |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
PHP’s advisory identifies all installations serving web requests as at risk, including PHP-FPM and Apache with mod_php.
Some Linux distributions and long-term-support vendors provide backported fixes. An older-looking version number therefore needs to be checked against the vendor’s advisory and exact package release.
Temporary configuration changes may reduce particular attack paths, but they do not replace a complete fix.
Read the official PHP security advisory for affected configurations, update guidance and release details.
Why a Composer update does not fix everything
Your application depends on several layers: application code, frameworks, libraries, the PHP runtime, extensions, operating-system packages, container images and hosting configuration.
Composer manages PHP project dependencies. It does not upgrade the PHP runtime serving your website.
A successful composer audit checks for known issues within its dependency-audit scope. It does not establish that your server, runtime or container is patched.
Updating the host operating system also does not automatically replace PHP inside an application container.
The useful question is:
Which component is affected, and what evidence shows that the running system received the fix?
What website owners should check
1. Identify the PHP runtime serving visitors
The PHP version on a developer’s laptop or build server may differ from the one handling live web requests.
Confirm the production runtime through your hosting provider, deployment platform or an authorised technical check. Include every instance serving the application.
Avoid publishing diagnostic pages that expose server configuration.
2. Establish who owns the update
Managed hosting: Ask whether the runtime serving your specific website has received the fix. Request confirmation of the relevant version or vendor-patched package.
Your own server: The responsible engineer needs to check the package source, install the appropriate update and ensure the affected services are running the patched code.
Containers: Update the relevant base image or runtime packages, rebuild, test and replace the running containers. Rebuilding against the same vulnerable image digest will not resolve the issue.
A general assurance that “security updates are automatic” is not enough. Confirm that those updates cover the affected component.
3. Decide whether temporary isolation is needed
When immediate patching is not feasible, CERT-EU recommends considering isolation of internet-facing applications until the fix is applied and verified.
That decision should account for exposure, available mitigations and the consequences of interruption.
For this incident, an application-level maintenance page is insufficient if requests still reach vulnerable PHP. The advisory describes an exploit that can execute before application code runs.
Effective isolation needs to prevent public requests from reaching the affected runtime, including through direct access to the origin server.
4. Apply and verify the fix
A practical update checklist:
- Confirm the affected environment and the applicable fix.
- Check recovery options and relevant backups.
- Test compatibility where possible without unnecessarily delaying urgent remediation.
- Deploy the patched package or image.
- Restart or replace affected processes as required.
- Confirm that every production instance uses the fixed runtime.
- Test critical journeys such as login, enquiries, bookings, payments and integrations.
- Monitor application errors after deployment.
Rollback planning matters too. Do not restore public access on a vulnerable runtime simply because the patched deployment has a problem. Keep affected services isolated while resolving the failure or deploying a safe alternative.
5. Treat suspected compromise separately
Installing a patch closes the vulnerability. It does not remove an attacker who may already have gained access.
Signs of exploitation require a separate incident response: containment, evidence preservation, investigation and, where appropriate, rebuilding affected systems and rotating credentials.
A working website and zero downtime do not prove that no breach occurred.
What TROPIKAL did during this incident
During this incident, we had zero outages. We warned clients, took preventive action and applied the PHP security update as soon as the patch became available.
We did not take the websites offline.
These are statements about our response and service availability. They are not proof that exploitation was impossible or that no data breach occurred.
This is part of the responsibility that continues after launch. Sometimes the next improvement is a better booking flow. Sometimes it is an urgent runtime update.
Both need someone who understands the system and owns the next action.
Built your website with AI? Check the system behind it
AI can help build applications, explain security advisories and prepare fixes. We use it every day at TROPIKAL.
But “the AI says everything looks good” needs a follow-up:
What did it actually check, and what could it not verify?
Repository files can describe an intended deployment. They cannot, by themselves, prove what is running in production.
The same care applies to the information you give an AI tool.
Read-only does not mean data stays private
A coding agent may read files or command output and send that information to a cloud model, depending on how it is configured.
Projects can contain credentials, production logs, database exports, customer records and confidential source code.
An instruction such as “do not expose secrets” is not a substitute for access controls.
For a PHP patch-status check, start with the minimum technical information needed: a manually reviewed runtime version, exact vendor package release or container image identifier, checked against official advisories.
Do not give an unapproved AI service access to customer data, credentials or confidential project material.
Check the tool and the data arrangements first
Using AI is not automatically a violation of data-protection law. However, personal-data processing remains subject to applicable requirements, including Swiss data-protection law and, where applicable, GDPR.
Before using AI with client systems, confirm the permitted purpose, client arrangements, provider terms, relevant processing agreements, retention settings and any international data transfers.
A setting that prevents model training does not, by itself, resolve every data-protection obligation.
Restrict access through technical controls and approved workflows. Give the tool only the information it needs.
An AI-generated assessment cannot, by itself, prove that production is patched or that no compromise occurred.
Website Care for Swiss businesses
A website does not stop needing engineering attention when it goes live.
Security advisories, runtime updates, dependency changes and hosting responsibilities continue throughout its life.
TROPIKAL offers Website Care for CHF 195 per month, with the covered systems, responsibilities and scope agreed upfront.
We help you understand what needs attention and coordinate the appropriate next steps. The agreement defines who handles hosting, updates, monitoring and additional development work.
No maintenance plan can promise zero risk. Its practical value is having clear responsibility and a process for acting when something changes.
Digital headaches? Let’s work through them
Whether you built your application with AI or have been running a business website for years, you do not have to figure out every technical issue alone.
Bring us the website, application or problem. We will discuss what it needs and how ongoing care could work for your business.
Book a free 20-minute fit call with TROPIKAL.
Sources and further reading
- PHP: October 2026 security advisory
- PHP: CVE-2026-109618 advisory
- PHP: CVE-2026-109619 advisory
- CERT-EU: Critical Vulnerabilities in PHP
- Composer: audit command
- Docker: build best practices
- PHP: server API interfaces
- FDPIC: AI and data protection
- FDPIC: outsourcing of data processing
- EDPB: international data transfers
Technical guidance checked on 23 October 2026. The versions above identify the releases fixing this incident. For future maintenance, consult current vendor advisories and supported releases.