Skip to content
Shantanu Sen Gupta
← All writing
NewsTechnologyUpdates

Security Update: PHP Patching and Server Hardening at Hereco

Shantanu

Most security work is unglamorous. It happens in update notices and maintenance windows, and when it goes well, nothing visible changes. On October 21, 2026, two critical PHP vulnerabilities were disclosed. As part of routine maintenance, Hereco applied a PHP security update addressing both. Here is what the vulnerabilities are, why they matter, and what site owners can do about them, in plain language and without exploit details.

The two vulnerabilities and what they mean

The first, CVE-2026-109618, involves improper handling of out-of-memory conditions. Every program occasionally runs short of memory, and well-written software responds by failing safely. When it doesn’t, it can be left in an unpredictable state, and unpredictable states are what attackers look for.

The second, CVE-2026-109619, involves stale internal request state. In simple terms, information left over from earlier work is not properly cleared and may be reused when it shouldn’t be. Software that mixes up what belongs to one request with what belongs to another can behave in ways its designers never intended.

Both vulnerabilities can potentially allow remote code execution, meaning an attacker might be able to run their own instructions on a vulnerable server from across the internet. That is why issues of this kind are rated critical. PHP sits underneath everything a PHP-based site does, so a flaw in the runtime can matter regardless of how carefully the application above it is maintained. “Can potentially allow” is not the same as “has been used against a given site,” and we make no claim that either issue was exploited against Hereco.

Fixed versions and why timely patching matters

The upstream fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Sites running earlier releases in these branches should treat updating as a priority, and the official advisories remain the authoritative source on exactly which versions are affected.

One caution applies to anyone reading this. Many servers receive PHP through a package system maintained by their provider rather than directly from the PHP project, and those maintainers often backport security fixes into their own builds. As a result, the installed version number may look different from the upstream releases above even though the fix is present, and a number that looks old is not automatically vulnerable. Upstream version numbers and distribution package versions are not interchangeable. The reliable way to confirm your status is to check the security advisory from your own provider against the exact package installed on your server.

Disclosure also starts a clock. Once a weakness is public, automated tools tend to begin looking for systems that haven’t been updated, which is why timely patching matters even for sites that nobody is deliberately targeting. The gap between a fix becoming available and a fix being applied is the period of greatest avoidable risk, and closing it quickly is the most direct way to reduce that risk. For that reason we treated this update as part of our routine maintenance rather than something to defer.

Hardening beyond the patch, and our commitment

Patching is necessary but not sufficient. An update does nothing about weak credentials, forgotten components, or sensitive files left in publicly reachable places, so hardening works best as a set of overlapping layers that cover each other’s gaps.

Start by knowing what you run. Keep a simple record of which PHP version or package your server uses and where its security advisories are published, so that a critical disclosure becomes a quick check rather than a scramble. Keep all software current, not only PHP, and remove components and accounts you no longer need, since anything unused is attack surface with no benefit. Limit access to what each person genuinely requires, use strong and unique passwords, and enable multi-factor authentication wherever it is available.

Make sure sensitive files and configuration data are never reachable from the public internet, and consider automated defenses that deny abusive traffic. Then pair them with regular human review. Logs and monitoring are only valuable if someone reads them, and knowing what normal activity looks like makes abnormal activity easier to recognize. When something is unclear, the sensible response is to document what is known, keep watching, and be honest about what remains uncertain.

No single step makes a system immune. Security is an ongoing practice rather than a finished state, and we do not claim otherwise about our own systems. Hereco is committed to proactive maintenance: applying updates in a timely way, investigating anomalies carefully, and communicating openly about what we find and what we do not. We will keep holding ourselves to responsible security practices.

References