“Our servers are updated” is useful reassurance, but it does not identify the PHP build serving your Joomla domain. A practical verification records the domain, its active runtime, the applicable vendor fix and the time checked. It also leaves room for an honest result: sometimes the available evidence is insufficient.
What a patch check can establish
A patch check can establish that the recorded runtime includes a specified security fix, using an upstream release or vendor evidence. It cannot prove that every service on a server is patched, that an attacker never accessed the site, or that every Joomla extension is secure. Keep those questions separate in your report.
1. Record the domain’s web runtime
In Joomla administrator, open System → System Information and record PHP Version. Ask the host to identify the PHP handler and pool assigned to this exact domain. Check subdomains, staging and other applications separately if they are in scope. A screenshot or private export can support the record, but it should not expose environment secrets.
php -v in a terminal only identifies that command’s runtime. It may not match PHP-FPM or Apache, and a cron command may specify another executable. Avoid leaving a public phpinfo() page online; it exposes configuration details and still does not substitute for vendor patch evidence.
2. Match the fix to the right release or vendor package
For the 21 October 2026 PHP advisory, upstream fixes were released as PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 for their respective branches. The relevant issues are CVE-2026-109618 and CVE-2026-109619. Check the advisory again when using this guide: newer releases and vendor information can change the appropriate action.
Some distributions and long-term support providers backport security fixes while retaining an older upstream version string. An older-looking number is therefore a reason to investigate, not automatic proof of vulnerability. Ask for the complete package revision, repository or vendor, and the advisory or changelog confirming both fixes.
3. Ask a question the host can answer precisely
Please confirm the PHP runtime and handler currently serving [domain], the complete installed package/build revision, and whether that running build includes fixes for CVE-2026-109618 and CVE-2026-109619. If the fixes are backported, please link the vendor advisory or package changelog. Please also confirm when the relevant PHP workers were restarted or replaced and whether cron or other PHP runtimes require separate action.
Send this through the host’s authenticated support system. Include your account identifier there if needed. You do not need to include a password or SSH private key in the request.
4. Confirm deployment reached running workers
An installed package and a running process are different observations. Ask the host or server administrator to confirm the affected workers were restarted or replaced using the deployment method for that environment. Recheck the application-side runtime after the work. For a group of sites, retain a separate row per domain and handler rather than assuming one successful check covers the fleet.
5. Write down the result without overstating it
| Result | Evidence | Action |
|---|---|---|
| Fix verified | Runtime and release/vendor evidence match; deployment confirmed | Record time, scope and test results |
| Fix not yet applied | Host confirms affected build without the fix | Agree urgent remediation with the host |
| Not verified | Runtime hidden or vendor evidence missing | Request clarification; do not label it safe |
After an update, test admin login, a content save, a form and controlled email delivery. Add uploads, checkout or scheduled work according to the website. Preserve suspicious errors or file changes for investigation. Absence of obvious symptoms is not proof that no compromise occurred.
A reusable handover checklist
- Domain and environments included in the check.
- Web runtime, handler and complete package or build identifier.
- Applicable advisory and vendor-backport reference where used.
- Deployment/restart confirmation and timestamp.
- Acceptance tests, exceptions and unresolved questions.
- Named owner and deadline for each remaining action.
What if the host cannot patch?
Escalate through the host’s security channel and ask for an updated package, a supported alternative environment or an explicit remediation plan. The PHP advisory distinguishes temporary exposure reduction from a complete fix. If application compatibility blocks the move, plan a tested repair or migration rather than assuming a CMS update fixes PHP itself.
References
Need help with your site?
Send us the URL, hosting provider and the problem you need resolved. Our Joomla PHP upgrade and compatibility service starts with a scoped assessment and a written quote.