If your business website runs on PHP, the useful response to this week's critical security disclosure is simple: identify who manages the server, ask them to confirm the installed PHP version, and get written confirmation that the appropriate security update has been applied.
You do not need to become a server administrator. You do need a named person who can answer those questions.
Last updated: October 22, 2026. This article summarizes public guidance available at that time. The situation may continue to change, so use the linked advisories as the source of truth.
The short version
The PHP project released emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Under the right conditions, they can allow an attacker who has not logged in to execute code on a vulnerable server.
The official PHP security advisory tells operators to update immediately to one of these fixed releases:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
PHP 8.1 and older no longer receive normal updates from the PHP project. Some operating-system or long-term-support vendors may provide backported fixes, but the vendor needs to confirm that explicitly. An old version number by itself is not proof that a vendor patch is absent, and a vague claim that a server is “protected” is not proof that it is fixed.
If your provider cannot update immediately, ask whether the affected service should be isolated or taken offline until a safe update is available. PHP's advisory lists temporary measures, but it is clear that only an update is a complete solution.
Does this affect WordPress websites?
WordPress runs on PHP, so a WordPress site may be affected depending on the PHP version and server environment underneath it. Updating WordPress, a theme or a plugin does not by itself update the PHP runtime on the server.
WordPress explains that the PHP version is controlled at the hosting level. Its documentation recommends checking Tools > Site Health in the WordPress dashboard and contacting the hosting provider when an update is required. See the official guides to WordPress Site Health and updating PHP for WordPress.
The same basic issue applies to other PHP applications. The business-facing website may look like one product, while the actual responsibility is divided among a host, an agency, a freelancer, a plugin vendor and someone inside the company. The first job is to find out who owns the server-level update.
What to ask your host or web agency today
Send one message to the person or company responsible for the website. Do not spread the request across several vendors and assume somebody else will handle it.
You can copy this:
Our website may run on PHP. Please confirm whether our production website or any connected web application is affected by CVE-2026-109618 or CVE-2026-109619. If PHP is in use, please tell us the exact version currently running, whether the relevant vendor security fix has been installed, when it was installed, and how you verified the updated version in production. Please also confirm whether staging sites, old subdomains or other internet-facing PHP systems are included.
A complete answer should identify:
- The company or person responsible for the hosting environment.
- The exact PHP version running in production after the update.
- Whether the provider applied an official PHP release or a documented vendor backport.
- The date and time the update was completed.
- Whether PHP workers or services were restarted where required.
- Whether staging sites, development sites, old portals and subdomains were checked.
- Whether logs and monitoring were reviewed for suspicious activity around the disclosure and before the update.
- Whether a tested backup and recovery path exists if the site becomes unstable.
“We use a firewall” or “the website software is current” does not answer the PHP-version question. A firewall may reduce exposure to some activity, but PHP's own guidance says temporary mitigations do not make an affected installation safe.
How to check without making the situation worse
Start with the people and systems you already trust:
- Check the hosting dashboard for the PHP version and recent security notices.
- For WordPress, review Tools > Site Health, then confirm the result with the host.
- Ask the web agency or developer who has server access.
- Check invoices, password-manager records and internal documentation to identify the hosting provider.
- Look for staging sites, old campaign sites, client portals and subdomains that may be hosted separately.
Avoid uploading credentials, configuration files or server details to an unfamiliar “free checker.” Do not make an untested PHP-version change on a production website if nobody has confirmed application compatibility, backups and a rollback path. The urgency is real, but an improvised change can still cause an outage.
If nobody can identify the host or access the account, treat that as an operational incident in its own right. Recover ownership through known billing records, domain records, password management and existing vendor contacts rather than sharing sensitive access information with a new party in a rush.
If your provider says the site has been patched
Ask for evidence that is specific enough to verify later:
- The production hostname or system that was checked.
- The version or vendor package installed.
- The completion time.
- The person or provider who performed the work.
- The verification step used after deployment.
- Any systems that remain pending or could not be checked.
Keep that response with the website's operating records. The purpose is not bureaucracy. It prevents the next urgent request from starting with the same question: “Who actually owns this?”
If compromise is suspected
Patching closes the known vulnerability; it does not prove that an already-compromised system is clean.
Unexpected administrator accounts, modified files, unfamiliar scheduled tasks, unusual outbound traffic, unexplained redirects or security alerts require qualified investigation. Avoid deleting logs or repeatedly changing the system before evidence is preserved. Contact the hosting provider, a cybersecurity incident-response professional and, where relevant, your cyber insurer or legal adviser.
Credential changes may be necessary, but they should be coordinated with containment and recovery. Changing passwords on a server that an attacker still controls may expose the new credentials too.
Mavryn does not provide emergency incident response, forensic investigation or server patching. Those jobs belong with your hosting provider and a qualified security professional.
What the AI part of the story actually means
AI-assisted security research contributed to finding and validating these vulnerabilities. The PHP Foundation's account says multiple research teams helped establish the impact and attack paths, while people in the PHP project made the decisions and developed the fixes. OpenAI's disclosure describes the broader coordination among maintainers, researchers, infrastructure providers and government agencies.
The practical lesson for a small business is not that AI will secure the website automatically. It is that important technical findings can move faster, and the business still needs a reliable human process for receiving an alert, finding the responsible vendor, approving urgent work and verifying completion.
Build a better ownership record after the emergency
Once the immediate update is handled, document the minimum operating information for every important website and portal:
- Business owner responsible for the system.
- Hosting provider and support contact.
- Web agency or developer contact.
- Domain registrar and renewal owner.
- Password-manager location for approved access.
- Backup owner, frequency and restoration process.
- Who receives security notices.
- Who can authorize urgent maintenance or downtime.
- Where completed changes and verification evidence are recorded.
This is a small workflow, but it matters. Security advisories do not become fixes until somebody receives the notice, recognizes the affected system, reaches the right provider and confirms the work was completed.
For the current PHP vulnerabilities, handle the technical remediation with your host or security provider first. If the incident exposes unclear ownership, missing records or unreliable vendor handoffs, those are operational workflows worth mapping after the immediate risk is under control.
Authoritative references
- PHP security advisory and update instructions
- PHP Foundation explanation of the vulnerabilities and response
- PHP supported-version policy
- WordPress Site Health documentation
- WordPress guidance for updating PHP
- OpenAI's coordinated-disclosure account
This article provides general operational information, not cybersecurity, legal or incident-response advice. Follow the current guidance from PHP, your software vendors and qualified security professionals for your specific environment.