Who should check
This check is relevant for almost every site. PHP sites are the largest and most urgent group, because the PHP2Shell flaws attacked the interpreter itself. Next.js and Node.js sites follow, then sites using Python tooling, Java runtimes, and platforms such as GitLab or SAP. If you are unsure what technology your site uses, ask your developer or hosting provider. Uncertainty is a reason to check, not a reason to wait.
The PHP checklist, first
- PHP version: compare the running version against the fix lines 8.2.35, 8.3.36, 8.4.27, or 8.5.12, according to the release line in use.
- Restart workers: after updating, restart every PHP worker, because old workers still running keep serving the vulnerable code.
- Disable session.upload_progress: set session.upload_progress.enabled=0, because this legacy feature is one confirmed path into CVE-2026-109619, and switching it off closes that path even on a patched system.
- Older sites: PHP 8.1 and older received no official fix. Plan a version upgrade or a backport, and treat such a site as at risk until then.
- Signs of intrusion: check for admin users, plugins, and files you did not add, especially if the site was exposed before October 21, because early attacks were visible before a fix existed.
The JavaScript checklist: Next.js and Node.js
- Next.js version: compare against the fix lines 16.4.1 or 15.5.28, according to the release line in use.
- Node.js version: check the runtime actually running in production, not just on the developer's laptop, and compare against 26.12.1, 24.22.1, or 22.23.4.
- Hosting runtime: if the site runs on a managed platform, confirm which runtime is really running, because a platform can run a different version than you assume.
- After updating: rebuild and redeploy the site, then check the version again, because an update that never reaches production is the same as no update.
The Python and Java checklist
- Python: update pip to 26.2.2 or newer, together with certifi and trust stores, so the weak eMudhra keys are no longer trusted.
- SAP Cloud SDK for Python: if you use SAP BTP, make sure the SDK is on version 0.45.2 or newer, where the subdomain validation check exists.
- LiteLLM: if release 1.107.0 ever ran, reinstall version 1.106.2 and rotate every reachable credential, because that release stole credentials.
- Java: apply Oracle's October quarterly update, and update Java trust stores to stop trusting the eMudhra keys.
- SAP: apply the October security notes for NetWeaver and manufacturing components, including the authorisation flaw on the Java application server.
The supply chain and credentials checklist
- Self-managed GitLab: check against CVE-2026-110264 and apply the October 21 security fixes.
- npm packages: if tensorlake 0.5.144 ever ran, go back to 0.5.143 and rebuild the affected machine.
- OVHcloud CLI: delete binaries versions 0.11.0 through 0.15.0, install 0.16.0, and rotate cloud credentials and SSH keys.
- WordPress: check the Rank Math PRO 3.0.123 download window, and if you use UpdraftCentral, delete the UpdraftCentral keys, then check for plugins and admin users you did not add.
- Platforms: follow vendor notices for Railway, Zeabur, OpenCode, and ConnectWise, and rotate every environment variable, key, and credential named in those notices.
If updating cannot happen right away
Sometimes updates are delayed for legitimate reasons: incompatible dependencies, limited change windows, or approval processes. In that situation, the most important thing is honesty about the status: record that the site is still below the fix line, limit unnecessary exposure, and set a firm date for the update. For PHP, the UK's NCSC even advised considering taking the system offline until a full fix is possible.
What must not happen is treating the problem as solved because nothing has happened yet. A publicly disclosed vulnerability does not become safer just because it has not been exploited on your site.
After the checklist is done
Keep the result of this check. Note the versions before and after, the update date, and who verified it. This short documentation pays off twice: at the next audit, and when the next wave arrives, because the next wave will arrive.
If you do not have access to your site's project or hosting, pass this checklist to whoever does. The right question, asked to the right person, is often the entire fix that is needed.
