On October 21, 2026, the PHP project published a critical security advisory and released fixes for two vulnerabilities that can allow unauthenticated remote code execution. If your publication uses PHP, make confirming the security update an immediate operating task.
This checklist helps website owners coordinate with their host, review the deployed site after maintenance, and keep a clear record of what has been completed.
What the PHP security announcement says
The official PHP 8.4.27 announcement identifies CVE-2026-109618 and CVE-2026-109619 and urges users to upgrade. It states that configuration mitigations do not provide a complete solution.
The PHP security advisory covers PHP installations serving web requests. It lists these fixed upstream releases for the October 21 advisory:
| PHP branch | Fixed release announced October 21 |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
The advisory also directs distribution and long-term-support users to check their vendor's updated packages. PHP 8.1 and older do not receive regular updates from the PHP project; consult the advisory and your vendor about fixes or a supported upgrade path. Check the current PHP support schedule when planning that migration.
Use the announcement and your package vendor's guidance for the technical update. The steps below organize the publisher's follow-up work.
Ask your host for a specific confirmation
For a managed website, open a support request that identifies the domain and asks about the PHP runtime handling its web requests. An application update and a hosting runtime update are different maintenance items, so make the request specific.
A useful request can ask:
- Which PHP version or vendor package serves web requests for this domain?
- Has the fix for the October 21 advisory been deployed to that runtime?
- Is the confirmation based on the listed upstream release or a documented vendor package containing the fix?
- Who owns the change, and when will the deployed result be confirmed?
Keep the response with your maintenance record. A notice that an update is scheduled is different from confirmation that it is deployed.
Coordinate the change if you manage the server
Follow the PHP project's advisory and your operating system or hosting vendor's instructions for the actual update. Identify the person responsible for applying it and the person who will check the publication afterward.
Before the change, note the important reader journeys you need to review: the homepage, a representative article, navigation, and any functions central to the publication. Keep the applicable backup and recovery procedures available while prioritizing the security fix.
After the operator confirms deployment, use the same short list to review the result. If a compatibility problem appears, work with the operator on a supported, patched configuration and record the remaining issue.
Check the website readers actually reach
Review the public production site in a signed-out browser session. Include both the homepage and an article that represents your normal publishing format.
Check that:
- The intended homepage opens and displays the publication's content.
- A representative article renders with its normal navigation and links.
- Important reader journeys still work as expected.
- A maintenance screen or access restriction has not been left in the public path.
- Any issue has a named owner and a clear next action.
These checks establish what you observed about availability and functionality. The operator's confirmation of the security update remains a separate part of the record.
Review Congrid publisher requirements after maintenance
For a Congrid publisher, include the member badge in the homepage review. The current publisher onboarding guide requires the homepage badge to match the registered domain and public owner wallet, with its surrounding link's href set exactly to https://congrid.net.
Compare the deployed homepage with the registration details your team maintains. A template change during maintenance may need its own review, even when the PHP update is complete.
For example, if a homepage template change removes the member badge, restore the required embed and review the deployed result. If the owner wallet has changed, follow the onboarding guide's re-registration process; editing the homepage alone does not complete the ownership update.
Congrid's publisher and verifier guides describe participation checks. Those checks are not a PHP vulnerability scan or a confirmation that a runtime is patched. Keep security-update evidence and publisher-status evidence distinct.
Close the maintenance task with evidence
Record the domain, the advisory being addressed, the operator's package or runtime confirmation, and the date of deployment. Add the public-page checks you completed and any unresolved issue.
Give each part its own status: security update confirmed, public website reviewed, and publisher requirements reviewed. This makes it easier for the next person to see what is finished without assuming that one successful check proves everything else.
For the security details, start with the official PHP advisory. For the website participation requirements, use the Congrid publisher guide.