PHP, Laravel, Node.js and Your Server: Why One Security Update Is Not Enough

A security update can protect your website against a serious vulnerability. But updating one component does not automatically secure everything your application depends on.

On 21 October 2026, PHP published emergency security fixes for two critical vulnerabilities known as PHP2Shell. Node.js also released security updates, and NGINX vendors issued warnings about critical vulnerabilities. GitLab published a critical patch release, while the eMudhra certificate incident raised a separate concern about the trust behind encrypted website connections.

Ruby on Rails also has a previously disclosed critical vulnerability that developers should check if their applications use the affected functionality.

The lesson is straightforward: website security requires maintaining the entire technology stack, not just the programming language.

1. PHP: Two critical PHP2Shell vulnerabilities

The PHP security team disclosed two critical vulnerabilities:

• CVE-2026-109618

• CVE-2026-109619

Both received a CVSS v4.0 score of 9.2. Under affected conditions, an attacker could exploit them to execute code remotely without authenticating first.

Fixed releases include:

• PHP 8.5.12

• PHP 8.4.27

• PHP 8.3.36

• PHP 8.2.35

If you operate a PHP website, identify the runtime serving your application and apply the appropriate security update. Older, unsupported PHP versions may require a vendor backport or an upgrade to a supported release.

Updating Laravel, WordPress or another application does not necessarily update the PHP runtime underneath it.

Source: PHP2Shell security advisory

2. Laravel: Check the framework and its dependencies

Laravel applications depend on PHP, but they also depend on the Laravel framework, Composer packages, authentication logic and application-specific code.

A PHP runtime update will not automatically patch a vulnerability in a Laravel package or your own application.

Developers should review the official Laravel security announcements, confirm which framework and package versions they run, and apply relevant updates. Also review dependency advisories and remove packages that are no longer maintained.

Do not assume every Laravel application is affected by every security announcement. Verify the affected versions and conditions before deciding on the required update.

Source: Laravel security and release announcements

3. Node.js: Update the runtime and dependencies

On 21 October, Node.js published security releases for its 22.x, 24.x and 26.x release lines.

The releases addressed multiple issues, including vulnerabilities involving TLS certificate validation and a high-severity flaw in the Brotli decoder that could permit remote code execution.

The corresponding release versions are:

• Node.js 22.23.4

• Node.js 24.22.1

• Node.js 26.12.1

If your production application uses Node.js, check its deployed version and follow the official release guidance. Updating only your local development environment is not enough if production still runs an affected release.

Source: Node.js security releases, 21 October 2026

4. NGINX and your server infrastructure

NGINX is commonly used as a web server or reverse proxy. On 21 October, F5-related security guidance covered three critical vulnerabilities affecting NGINX products, with CVSS v4.0 scores of 9.2. Depending on the vulnerability and configuration, impacts could include denial of service or remote code execution.

This is why checking the server matters alongside checking application code.

Review:

• Your NGINX or Apache version and configuration.

• Operating-system security updates.

• PHP-FPM and other application services.

• Exposed ports and unnecessary services.

• System and application logs.

Not every server runs an affected NGINX product, and not every configuration is vulnerable. Follow the advisory that matches your actual software.

Source: Singapore Cyber Security Agency — NGINX security alert

5. Go: Certificate validation matters

A Go vulnerability entry published on 21 October addressed handling of compromised intermediate certificate authorities. This is connected to the wider eMudhra certificate incident.

If your systems use Go applications or Go's certificate-handling functionality, review the relevant Go security guidance and update affected components.

Source: Go vulnerability database

6. GitLab: Apply the critical patch release

GitLab published a critical patch release on 21 October 2026, including fixes for security issues.

The release included versions such as 19.5.1, 19.4.3, 19.3.6 and corresponding patches for additional maintained release lines. GitLab strongly recommended that self-managed installations upgrade to an appropriate fixed version.

If you host GitLab yourself, check your release line and follow its upgrade instructions. Users of GitLab's managed service should follow the provider's guidance rather than assuming they need to perform a manual server upgrade.

Source: GitLab critical patch release

7. eMudhra: A certificate trust incident

The eMudhra incident is different from a conventional application vulnerability.

Certain intermediate certificate private keys were found to have been generated with insufficient randomness, making them recoverable. An attacker possessing those keys could potentially create fraudulent certificates and impersonate websites to systems that still trusted the affected certificates.

This is why certificate revocation and updates to certificate trust stores matter. Encrypted connections are only as trustworthy as the certificates and authorities your systems accept.

Administrators should apply relevant operating-system and trust-store updates, following their distribution's guidance.

Source: Google's explanation of the eMudhra certificate incident

8. Ruby on Rails: Check Active Storage

Ruby on Rails has a critical vulnerability tracked as CVE-2026-66066, disclosed on 29 July 2026.

The flaw concerns Active Storage variant processing. In affected configurations, a malicious upload could lead to arbitrary file reads and potentially expose application secrets, creating a path to further compromise.

The Rails security release included these fixed versions:

• Rails 7.2.3.2

• Rails 8.0.5.1

• Rails 8.1.3.1

This is an earlier disclosure, not a new vulnerability from the 21 October PHP announcement. Nevertheless, developers operating Rails applications should confirm that they are running a fixed release and review whether their configuration is affected.

Source: Official Rails security release

Your practical security checklist

You do not need every technology mentioned here. You need to know which components your applications actually use.

• Identify the PHP runtime serving each production application.

• Patch PHP to an appropriate fixed release.

• Review Laravel, Rails and other framework security advisories where relevant.

• Update Node.js and production dependencies where used.

• Check NGINX, Apache and operating-system security updates.

• Update certificate trust stores according to vendor guidance.

• Check self-hosted GitLab installations and other exposed services.

• Review logs and investigate suspicious activity if a vulnerable service may have been exposed.

• Confirm that updates were successfully installed and that applications still work correctly.

If you suspect a server was compromised, patching alone may not be enough. Investigate the incident, rotate potentially exposed credentials and secrets, and restore from a known-good state where necessary.

The takeaway

Security is not a one-time task. It is an ongoing part of building and operating technology.

A website can use a patched PHP runtime and still depend on an outdated framework, vulnerable package, misconfigured web server or untrusted certificate authority.

Don't just ask, “Is my website working?” Ask, “Are the components behind it secure and maintained?”

At Querytech, we believe building technology also means understanding the responsibility that comes with operating it.

Security note: Advisories, affected configurations and fixed versions can change. Always consult the official vendor advisory for your exact deployment before applying production changes.