PHP shipped fixes for CVE-2026-109618 and CVE-2026-109619 on 21 October 2026. Most organisations treated that as a patching exercise, and by the end of the week most will be on a fixed version.
The second of those two flaws deserves a second conversation. Alongside remote code execution, PHP's advisory confirms memory disclosure — an unauthenticated attacker reading heap memory out of a PHP worker process. Imperva measured roughly 67 KB of process memory recoverable through one of the demonstrated techniques.
A PHP worker handles many requests over its lifetime. Whatever passed through it recently is in that memory: session identifiers, authentication tokens, database credentials read from configuration, API keys for whatever the application calls, parts of other users' requests and responses. A read of that memory is not a read of your application's data model. It is a read of whatever happened to be in flight.
So the question after patching is not only "are we fixed". It is "what might have left, and can we replace it".
What the advisory actually confirms
Precision matters here, because overstating this is as unhelpful as ignoring it.
PHP confirms, for CVE-2026-109619, "unauthenticated heap use-after-free, memory disclosure and remote code execution with the web worker's privileges". Code execution was validated against mod_php and, through the session lifecycle path, against PHP-FPM.
What is not established is whether any of that happened to you. There are no indicators of compromise published for a successful memory read, and a disclosure of this kind leaves no artefact in an application log, because the application never ran. As of today neither CVE is in CISA's Known Exploited Vulnerabilities catalogue, and CISA stated on 21 October that it had not observed exploitation. Vendor telemetry disagrees sharply — Hadrian reported exploitation "at scale", Imperva saw no matching traffic at all in the same window, and watchTowr saw attempts but no successes.
That combination — confirmed capability, absent evidence either way — is the uncomfortable middle ground where most of the real decisions get made.
Why this lands on the inventory, not on the incident
An organisation that can answer "which secrets did that application hold, who issued them, and how do we replace each one" treats this as a week of scheduled work. An organisation that cannot answer it has a much worse problem, and the problem is not PHP.
In practice the gap shows up like this. The database password is known, because somebody changes it occasionally. The API key for the payment provider is known, because it is in a runbook. Then there is a long tail: the SMTP credential set up in 2021, the token for the internal reporting service, the webhook signing secret, the key for the mapping provider, the OAuth client secret for the single sign-on integration, the certificate used for mutual TLS to a partner. Each of those was created by somebody who has moved on, and none of them has ever been rotated, because nothing ever forced the question.
This is squarely within Article 21 of NIS 2, transposed in Romania by OUG nr. 155/2024: policies on the use of cryptography, access control, and incident handling. A credential inventory is not a separate compliance artefact — it is the thing that makes incident handling executable.
The inventory that makes rotation possible
Four columns, filled in for the applications that matter. Not a project.
- What the secret is, and where it lives. Environment variable, configuration file, secrets manager, or hard-coded in a repository — and if the last one, that is its own finding.
- Who issued it and how it is replaced. A vendor portal, an internal CA, a cloud IAM console, a partner's onboarding team. Include who has access to do the replacing.
- What breaks when it changes. This is the column people skip, and it is the one that decides whether rotation happens at 10:00 on a Tuesday or never. If nobody knows what a credential is used by, nobody will risk rotating it.
- Whether it can be rotated without downtime. Some systems support two valid credentials during a changeover. Some do not. Knowing which is which in advance converts a crisis into a sequence.
The useful test is not whether the document exists. It is whether somebody could execute it this week, without the one person who knows how being available.
Deciding what to rotate
A proportionate response rather than a panicked one. Rotate, in roughly this order:
- Anything the affected application held in configuration — database credentials, cache and queue credentials, service account passwords. These were resident in process memory by definition.
- Tokens and API keys the application used outbound, especially long-lived ones. Where the provider supports short-lived credentials and you are not using them, this is the moment to change that.
- Session signing and encryption keys, which invalidates existing sessions. Plan the user impact deliberately rather than discovering it.
- Certificates and private keys loaded by the web worker, including client certificates for partner integrations. Reissue rather than merely re-deploy.
- Any credential that cannot be rotated without a maintenance window — schedule it now rather than carrying it as a known exception for another two years.
What you can reasonably deprioritise: credentials that were never held by the affected hosts, and anything already short-lived enough that the window has passed.
Is a possible disclosure a reportable incident?
This is where organisations tend to want a yes or a no, and the honest answer is that it depends on what you can establish.
Under NIS 2 as transposed by OUG nr. 155/2024, the reporting duty attaches to a significant incident, with the 24-hour early warning and 72-hour notification clock. A theoretical capability, with your systems patched and no evidence of exploitation, is generally not that. Evidence that the vulnerable path was exercised against your estate is a different matter, and that is what makes log review worth doing properly rather than as a formality.
Under GDPR Article 33, the question is whether a personal data breach occurred, notifiable within 72 hours unless unlikely to result in a risk. Memory disclosure from a worker that handled authenticated sessions could involve personal data — but "could have" is not "did", and the regulation asks about an actual breach, not a vulnerability.
The defensible position in both regimes is the same: document what you checked, what you found, when you patched, what you rotated, and the reasoning behind the classification decision. A decision recorded with its basis is a functioning process even where the conclusion is "not reportable". A decision nobody wrote down is indistinguishable from not having looked.
If you did find evidence of exploitation, that changes both analyses, and the clocks start from when you became aware — not from when the CVE was published.
What the logs can and cannot tell you
PHP's advisory includes an audit procedure, and its caveat is the important part: "absence of an error in logs is not proof of safety."
The procedure, for an isolated audit window: set log_errors=On with a functional error_log and error_reporting=E_ALL, then review web server, PHP-FPM and proxy logs for warnings, deprecations and core errors appearing repeatedly before target scripts run; diagnostics raised during extension or server cleanup; fatal, parse and uncaught errors; "Maximum execution time exceeded"; and failures confined to attacker-controlled routes or content types.
CISA adds the behavioural signal worth alerting on regardless: PHP worker processes launching shells or downloading tools.
Corelight published Zeek notices and Suricata rules for detection, and CERT-EU points to a community-maintained list of third-party software that embeds PHP — useful for the appliances and vendor products nobody counts as a PHP estate.
The part that generalises
Every few months something produces the same question: a vulnerability that may have exposed credentials rather than definitely having done so. The Atlassian file-read flaw earlier this month was a cleaner version of it — read one configuration file, obtain the credentials inside, and the only honest response is to rotate them.
What distinguishes organisations in that moment is not detection and not tooling. It is whether somebody can say what secrets exist, who issues them, and what breaks when they change. That answer is built on an ordinary week or not at all.
Where the inventory itself is the gap, an audit and compliance review under NIS 2 covers what an assessor expects to see and what evidence satisfies it. Where the question is what an attacker reaches once they hold one recovered credential, an internal penetration test answers it directly. And where you are unsure what PHP you publish at all, an external attack surface review builds that list from the outside, the way an attacker does.
Sources: PHP 21 October 2026 release announcement · CVE-2026-109619 record · NVD entry for CVE-2026-109619 · watchTowr analysis · Corelight detection content
The memory disclosure capability is confirmed in PHP's own advisory; whether it was exercised against any given organisation is not established, and no indicators of compromise exist for a successful read. Vendor exploitation reports contradict one another and none has published counts. Neither CVE was in CISA's Known Exploited Vulnerabilities catalogue at the time of writing. The ~67 KB figure is Imperva's measurement of one demonstrated technique.
This article is general information, not legal or regulatory advice.