Recent PHP and Node.js security updates: what website owners need to know

Several security alerts issued this week concern software used to run websites and business applications. They need attention, but receiving an alert does not mean your website has been hacked.

There are three separate matters: emergency PHP fixes, a subsequent PHP configuration precaution, and security updates for Node.js. Datasouth has applied the relevant PHP fixes and precaution across the hosting systems covered by our maintenance work, and updated the Node.js services identified in that work. Here is what the alerts mean and what to do if you receive one.

What happened with PHP?

PHP runs behind the scenes on many websites. On 21 October, the PHP project released emergency fixes for two critical vulnerabilities that could allow an attacker without an account to run unauthorised code on an affected server.[1]

These were problems in PHP itself. Updating a content management system or plugin alone would not fix them: the underlying PHP installation needed the appropriate security update.[1]

On 23 October, PHP published a further warning about an unusual combination of session settings and application behaviour. It recommended disabling “session upload progress” until a fix arrives in a routine release. The emergency updates issued two days earlier do not, by themselves, resolve this separate issue.[1]

That feature lets applications track file-upload progress through PHP sessions. Disabling it is not the same as disabling file uploads, although an application relying on it may lose its progress display.[6] PHP describes the vulnerable configuration as unlikely in practice; we have applied the recommended precaution rather than assuming it cannot occur.[1]

Where does Node.js fit in?

Node.js is different software, used by some applications and background services. Its security release on 21 October addressed separate vulnerabilities, including problems with checking secure connections, resolving internet addresses and handling compressed data. The highest-rated issues were classified as high severity.[3]

This is not another name for the PHP issue, and updating PHP does not update Node.js. Equally, a website does not necessarily use both. The relevant checks depend on what actually runs that website or service.

Application dependencies—the additional software libraries an application uses—also need separate attention. A runtime update and a dependency update are different jobs; completing one does not establish that the other is up to date.

What has Datasouth done?

We checked installed PHP packages and their security-fix records, applied the required updates, and verified the earlier emergency fixes in current releases or provider-supplied backports. We have also disabled session upload progress in the startup configuration of the PHP installations covered by this work and refreshed the affected web workers so the setting takes effect.

Checks included the settings used by running PHP services and actual web requests, alongside representative HTTPS website checks. Those website checks returned successful responses. They were service and configuration checks, not a test of every customer login, transaction or application workflow.

For the Node.js services identified during maintenance, we updated running application runtimes and checked service operation afterwards. We also carried out separate dependency remediation for one application.

Why might a scanner still show an older version?

Hosting-package providers can apply a security fix to an existing software branch without changing its headline version to match the latest upstream release. This is called a backport; PHP explicitly recognises that distributions and long-term-support providers may supply these fixes.[1]

An older-looking number therefore needs investigation, not an automatic conclusion that the fix is missing. The useful evidence is the exact installed package, its provider’s security record, and confirmation that the running service uses it. That does not make every old version safe: a backport must be confirmed for the particular vulnerability.

What should website owners do?

If you receive an alert about a site whose hosting Datasouth manages, forward the original message with the website address and any vulnerability reference. We can check it against the actual hosting configuration and the scope of your maintenance arrangement. Hosting maintenance, application maintenance and third-party services are not necessarily the same responsibility.

If another provider manages your hosting, ask them to confirm whether the specific issue applies and what patch or mitigation they have put in place. Avoid changing unfamiliar server settings solely to clear a generic scanner warning.

An advisory identifies a software weakness; it does not establish whether anyone has exploited it on your website. Equally, a successful update or homepage check is not forensic proof that compromise has never occurred. Report unexpected behaviour alongside the alert so it can be investigated on its own evidence.

For the earlier PHP response, see PHP security update: how Datasouth responded.[5]

Sources

[1] https://www.php.net/archive/2026.php
[3] https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
[5] https://www.datasouth.co.uk/blog/php-security-update-how-datasouth-responded
[6] https://www.php.net/manual/en/session.upload-progress.php