PHP Security Update: Your Website Needs More Than a Relaunch
21 October 2026 · Website security and maintenance for Swiss businesses
Your website can look perfect, load quickly and still need an urgent security update.
That’s what the PHP security release on 21 October reminded us of.
If you built your app with AI, hired someone to build it, or have a PHP website running your business, this matters. Getting it online is one milestone. Keeping it reliable is an ongoing responsibility.
And no, asking your coding agent to “update Composer” doesn’t necessarily fix this one.
What happened? The PHP security update explained
PHP released fixes for two critical remote-code-execution vulnerabilities: CVE-2026-109618 and CVE-2026-109619. In plain language, these flaws can allow an attacker to run code on a vulnerable server.
The fixed releases are:
- PHP 8.2.35
- PHP 8.3.36
- PHP 8.4.27
- PHP 8.5.12
PHP’s advisory identifies installations serving web requests as at risk, including PHP-FPM. This is not just a problem for one framework or one hosting company.
Some vendors may provide verified backported fixes. Configuration mitigations can reduce particular attack paths, but they are not a substitute for a complete fix.
See the official PHP security advisory for the precise conditions and release details.
Built it with AI? You still need to know what runs it
I’m a big believer in using AI to build better software. We use it every day at TROPIKAL.
But there’s a difference between generating an app and taking responsibility for the system behind it.
Your project has several layers: your code, its dependencies, the PHP runtime, the server or container, and the deployment process.
Updating one layer does not automatically update the others.
Composer manages PHP dependencies. It does not upgrade the PHP runtime serving your website. A clean dependency audit is useful, but it is not a clean bill of health for the whole system. Composer’s audit documentation explains what it checks.
That’s why “the AI said everything looks good” needs a follow-up question:
What did it actually check?
What to do if you have a PHP website or app
1. Identify the runtime serving your live website
Don’t stop at the PHP version on your laptop or build server. Confirm the runtime handling real visitors.
Use your hosting dashboard, deployment configuration or an authorised server check. Avoid leaving a public diagnostic page online just to find out.
PHP has different execution interfaces, so a local command-line result is not enough to establish the web runtime’s status. PHP’s SAPI documentation explains that distinction.
2. Find out who owns the update
Managed hosting: ask your provider whether the runtime serving your specific site has received the fix, and how they confirm it. A general “we take security seriously” reply is not the same as patch confirmation.
Your own server: the person responsible for that server needs to check the installed packages, available fixes and running services.
Containers: check the PHP version inside the image. Updating the host machine alone does not establish that the application container is patched. Rebuild from a fixed base image, test and replace the running containers. Docker recommends regularly rebuilding images with updated dependencies. Docker build guidance
3. Prepare the update, not just the command
Our practical checklist is simple:
- Confirm the relevant fix and affected environment.
- Check backups and the rollback approach.
- Test the update where possible.
- Deploy through the appropriate, approved process.
- Verify the runtime that is actually running afterwards.
- Test the business-critical journeys: login, enquiries, bookings, payments and integrations.
A successful deployment message is not the finish line. Your customers still need to be able to use the product.
4. Make the next check someone’s responsibility
Who follows security advisories? Who checks your dependencies? Who contacts the host? Who verifies that the update worked?
If the answer is “probably someone,” that’s the gap to close.
A security-check prompt for Codex or Claude Code
Paste this into your coding agent with the relevant project open. It starts with analysis, not uncontrolled production changes.
Act as a security-maintenance assistant for this project.
Start read-only. Do not change production.
1. Inventory the application, PHP runtime, extensions,
Composer dependencies and lockfile, OS packages,
Docker/base images, hosting and deployment configuration.
Distinguish local CLI PHP from the runtime serving live
web requests. Record evidence and unknowns. Repository
files alone do not prove production is patched.
2. Check current official PHP, dependency, image and
OS/vendor security advisories. Include CVE-2026-109618
and CVE-2026-109619, but do not limit the review to them.
Verify any vendor backport claims. Run appropriate
read-only dependency audits safely. Do not treat a clean
Composer audit as proof that the runtime is secure.
3. Report findings, severity, evidence, uncertainty and
the smallest remediation plan. Identify what the hosting
provider must confirm. Include tests, runtime or image
updates, deployment verification and rollback planning.
Ask before edits. Require explicit approval before any
production change, merge or deployment.
4. Propose repeatable checks covering dependencies AND
runtime/image advisories. Ask me to approve the cadence,
timezone, notification destination, permissions and costs.
Use supported scheduled tasks or CI, not assumed memory.
Configure only after approval. Test the check and verify
its registration, next run, cancellation method and any
machine-availability requirements. Report failed or
incomplete checks clearly, never as “all clear.”
Do not expose secrets, create public diagnostic pages,
run exploit payloads or probe unrelated systems.
Finish with a concise checklist of findings, owners and
next actions. Separate verified facts from assumptions.
A prompt is not a monitoring service. The recurring job must actually exist, have access to the right information and deliver an alert someone will act on.
Scheduling capabilities differ between installations. Check the current Codex scheduling documentation and Claude Code scheduling documentation rather than assuming a chat stays running forever.
What this looked like at TROPIKAL
During this incident, we had zero outages. We warned clients and took preventive action.
That does not mean we can claim a specific attack would otherwise have succeeded. It means we treated the warning as something to act on, not something to leave until a customer reported a problem.
Security and customer data first. Not as a slogan added after launch, but as part of looking after the software a business depends on.
This is also why we keep talking about iteration. Sometimes the next useful improvement is a better booking flow. Sometimes it is an urgent runtime update nobody will notice because the website keeps working.
Both matter.
Website security in Switzerland: care beyond the launch
At TROPIKAL, we build websites, booking flows, customer portals, internal tools and practical AI solutions around your business.
You work directly with experienced engineering support, without having to build your own software department or keep up with every technical change yourself.
Our Website Care offer is CHF 200 per month, with the covered systems, responsibilities and any additional work agreed upfront. Hosting costs, AI services and larger development work should not be assumed to be included.
When everything works, ongoing care can feel like an optional expense.
When an urgent vulnerability appears, the value becomes easier to see: someone needs to understand the warning, establish what is affected and help get the right fix in place.
A breach or outage could cost far more than a monthly care plan in recovery work, lost business and customer trust. That is not a prediction that your site will be attacked, and no maintenance plan can promise zero risk.
It is a reason to have a plan before there is a problem.
Digital headaches? Let’s work through them
Whether you built it yourself with AI or have been running PHP applications for years, you don’t have to figure out every technical issue alone.
Bring us the website, the app or the problem. We’ll discuss what it needs, who is responsible for what and how ongoing care could work for you.
Premium expertise. Without the traditional agency overhead.
Book a free 20-minute fit call with TROPIKAL and let’s make your next step clear.
Sources and further reading
Technical details reflect the sources checked on 21 October 2026. For later use, check the latest security advisories and supported releases.