The PHP alert is real.
Your next step
can be clear.

Notice updated through October 22, 2026 · Checked October 23

GoDaddy reports its Managed Hosting for WordPress was patched by October 21, 19:30 UTC, and Web Hosting with cPanel by October 22, 13:30 UTC. Its notice treats VPS separately. [8]

1. Identify your exact product. Owning a domain at GoDaddy does not mean your site is hosted there.
2. Managed WordPress: the incident notice says its PHP versions were patched and no customer-side PHP update was needed. Ask support to confirm your specific site if its status is unclear, including today's follow-up.
3. Web Hosting / cPanel: GoDaddy's CloudLinux fix may keep an older-looking PHP version number. Its incident instructions use a PHP build date of October 21 or later as evidence for that product. Follow its check or ask support for proof; don't apply that date rule to unrelated vendors.
4. VPS: your administrator must update the correct PHP packages, restart serving workers and verify them. With cPanel/WHM, check EasyApache as well as the panel itself. See the cPanel path ↗
5. Dedicated server: the notice reviewed did not establish fleet-wide patch status. Confirm whether the server is managed and who owns the runtime update; don't assume either safety or inaction.

Bulletin published October 21, updated October 22, 2026

AWS says its services are not impacted, but customer PHP workloads may be. It has updated Beanstalk platforms, Lightsail blueprints and Amazon Linux packages. That does not automatically patch your running application. [9]

1. EC2: inventory and update the OS/vendor PHP installed inside each instance. Verify the relevant security package, reload the runtime and cover every instance and FPM pool.
2. Elastic Beanstalk: move to the updated PHP platform. AWS says managed platform updates apply at the next maintenance window; confirm the fixed version actually deployed instead of waiting on a checkbox.
3. Lightsail: new blueprints are available, but AWS cannot patch existing instances in place for you. Snapshot and follow the blueprint-specific procedure. OS-packaged PHP and Bitnami-bundled PHP differ: apt upgrade does not update Bitnami's bundled PHP. AWS recommends a migration path to a Lightsail blueprint. [10]
4. Containers / custom PHP runtimes: rebuild from fixed packages, redeploy and replace all old replicas. Updating a host OS or downloading a new image is not enough if old containers are still serving.
5. AWS WAF: the bulletin describes rule updates, including action for pinned rule-group versions. Treat them as interim risk reduction. Test application impact and block direct origin bypass where appropriate—not as proof PHP is fixed.

Ubuntu / Debian advisories checked October 23, 2026

On a self-managed Linux or Windows server, your team owns the runtime update. Apache, Nginx with PHP-FPM, LiteSpeed, CGI and alternative PHP workers have different package and restart paths. Changing your web-server brand is not a fix. [1]

1. Inventory what's actually serving. Record the OS, PHP package source, active handlers and every pool/container. php -v only identifies that CLI binary; it may not match the web runtime.
2. Use the correct vendor fix. Ubuntu publishes release-specific packages and coverage requirements; older releases may need Pro/ESM. Debian tracks PHP by release and package, including bookworm's PHP 8.2 and trixie's PHP 8.4. Vendor backports can retain older-looking version strings. [11] [12]
3. Restart the code that serves requests. After the update, replace or restart the relevant PHP workers and services according to your deployment procedure. Verify all serving nodes loaded the fixed runtime and check site health.
4. For older branches: PHP 8.1 and earlier are upstream end-of-life. Verify a vendor-supported backport or migrate to a supported branch. PHP's emergency source backports for 7.4–8.1 are not a renewed support lifecycle.
5. Source builds / Windows / custom stacks: follow PHP's official downloads and your build vendor's instructions. Don't paste a Linux package command into an unrelated environment or install an unverified “hotfix” from social media.

October 21–22 releases · Checked October 23, 2026

cPanel's advisory distinguishes two layers: PHP used internally by the control panel, and EasyApache 4 PHP used by your websites. Updating just one does not prove the other is fixed. [13]

1. No WHM/root access? Ask your host to confirm both layers and every PHP handler assigned to your domains.
2. Server administrator? Update cPanel/WHM to its patched release and update EasyApache PHP through the supported package process. Check the official advisory for the exact release applicable to your panel branch.
3. Don't rely on major/minor version labels. The EA4 advisory lists original-CVE backports for PHP 7.4–8.1, plus the new upstream versions for 8.2–8.5. Verify the full installed package, not merely “PHP 8.1.”
4. Include nonstandard handlers. LiteSpeed / lsphp, custom PHP builds and older ELS packages need their applicable provider checks. A panel's rollout announcement is not evidence your server installed it.
5. Verify the serving process. Ask whether a controlled worker restart is needed and confirm the website loaded the fixed runtime. The cPanel notice reviewed does not prescribe a universal restart command.

Advisory dated October 21, 2026

Plesk's notice covers PHP shipped with Plesk and separately identifies fixed control-panel engines. It announces available fixes—not that every hosted server installed them. [14]

1. Check the domain's handler. Under Websites & Domains → your domain → PHP, identify the active PHP version and handler. If subscription permissions prevent it, ask your host.
2. Update both relevant layers. The panel engine fixes are listed for Obsidian 18.0.80 Update 11 or 18.0.81 Update 4. Website-facing PHP 8.2–8.5 has the October 21 fixed upstream releases.
3. Older Plesk Linux PHP builds need date verification. Its notice lists PHP 7.4.33, 8.0.30 and 8.1.34 builds dated October 21, 2026 for the original fixes. Version number alone is insufficient.
4. Use the right maintainer. OS-provided PHP, third-party builds and containers are not automatically covered by a Plesk-shipped PHP update. Ask for their own patch evidence.
5. Confirm rollout and service health. Coordinate any worker restart with the operator; the incident bulletin reviewed gives no blanket restart command. Check today's upstream session follow-up separately.

Official materials checked October 23, 2026

No public, incident-specific Cloudways remediation statement was located in the official materials checked. That proves neither that it patched nor that it failed to patch. Its general PHP upgrade documentation is not an incident-status attestation. [15]

1. Identify the product and application. Cloudways Flexible and Autonomous have different PHP controls and supported versions. Check each application's actual runtime, not one account-wide assumption.
2. Ask for explicit confirmation. Request the fixed build or vendor backport for both original CVEs, the rollout time, restart requirements, and an assessment of the October 23 follow-up.
3. Don't switch versions blindly. A major/minor version offered in a dropdown may not establish patch status. Use the provider-supported remediation path; take a backup and test app/plugin compatibility before a customer-initiated change.
4. Apply the same standard to any managed host. “We manage security” is not a patch receipt. Request account-specific evidence and a responsible contact if remediation is unclear.