CVE-2026-109618 and CVE-2026-109619: Patched, With Zero Downtime

Short version: we are patched against both vulnerabilities. No action is needed from your district, and nobody saw a minute of downtime.

On October 21, 2026, the PHP project published fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both score 9.2 (Critical) on CVSS 4.0. Both allow unauthenticated remote code execution over the network, which is the worst category there is: no login, no phishing email, no user clicking anything.

Within minutes of the fixed releases going public, every node serving Manage1to1 was running them. We waited to post this until that was done, on purpose.

What the two vulnerabilities are

Both live in how PHP manages memory between requests. The PHP security team's advisories go into full detail, but the plain-English version is:

• CVE-2026-109618, "RCE via OOM corruption." When PHP runs out of memory partway through starting a request, it bails out in a way that can leave request memory uninitialized. The cleanup code then reads that memory. The advisory shows several ways an attacker can force the out-of-memory condition on purpose using crafted multipart (file upload style) requests, and the researchers validated full remote code execution against a default configuration. (GHSA-w8hw-w9fx-j79w)
• CVE-2026-109619, "RCE via stale global state." Some of PHP's global state points into request memory and is not always reset correctly. A later request can then read memory that has already been freed. Same outcome: remote code execution. (GHSA-6wmf-4rv5-p3rp)

They were reported by researchers at Wiz, Calif.io, and OpenAI, and fixed by the PHP core team. The fixed releases are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Every earlier release in those branches is affected.

The advisory is blunt about mitigation: updating is the only complete fix. Configuration changes reduce exposure but do not close it.

Why we waited to tell you

You might reasonably ask why a vendor would sit on news like this. The answer is that announcing a vulnerability before it is closed helps exactly one group of people, and it is not school districts.

So our rule is simple: close the hole first, then tell you about it. If you are reading this, the work is already done. You are not getting a "we're aware and investigating" email followed by a week of anxiety. You are getting a finished report.

This is the same principle behind our responsible disclosure policy, and it is one of the commitments we report on in our CISA Secure by Design progress report, which covers both timely security patches and CVE transparency. This post is that transparency in practice.

Minutes, not a maintenance window

Here is the part we are proud of.

Plenty of software vendors handle a critical patch the same way: schedule a maintenance window, post a banner, take the system down on a Saturday night, and hope nothing goes wrong. That is a bad trade for a K-12 district. Help desk tickets do not stop coming in because a vendor needs a quiet evening, and "down for maintenance" during a device rollout or the first week of school is a real problem for a real tech team.

We do not run Manage1to1 on a single server. It runs on a distributed set of nodes behind the scenes, built so that any one of them can be taken out of service while the rest carry the load. That design is usually invisible. On days like this, it is the whole story:

1. The fixed releases went public and the embargo lifted.
2. Within minutes, we were rolling the patch across every node.
3. Each node was updated while the others kept serving districts, then returned to service.
4. Zero downtime. No maintenance window, no banner, no lost tickets, no family stuck on an invoice page.

You can see the record for yourself on our public status page. We publish it so you do not have to take our word for any of this.

What we did not do

We are not going to dress this up as something it was not. These were flaws in a language runtime used by a large share of the web, not a flaw in our own code, and every vendor in the same position had the same disclosure on the same morning. What separates vendors on a day like this is not whether they were affected. It is how fast the fix reached production and what it cost their customers. For us: minutes, and nothing.

What your district should check

We are covered. Your own servers might not be.

PHP sits underneath a lot of what K-12 districts host themselves: WordPress school and district websites, Moodle, and plenty of open-source tools running on a server in the data closet. If your team hosts anything built on PHP, this is worth an hour today:

• Inventory it. List every PHP application your district runs, including the ones a building or department stood up years ago.
• Check the version. Anything older than 8.2.35, 8.3.36, 8.4.27, or 8.5.12 in its branch is exposed. If it is on an end-of-life branch older than 8.2, it will not get this fix at all, and that is a bigger conversation.
• Patch, do not just reconfigure. The interim measures in the advisory help, but the PHP team is explicit that only the update fully closes the hole.
• Ask your hosted vendors. For anything a vendor runs for you, ask directly whether they are patched and when they finished. A good vendor will have an answer ready. A great one will have told you already.

The bottom line

Your district's device, ticket, and family data sits on Manage1to1. That is a responsibility we take personally. Every one of us came from school district IT, and we have all been the person reading a vendor's vague security email and wondering what it actually means.

So here is ours, in plain terms: two critical vulnerabilities, patched across every node within minutes of the fix shipping, with zero downtime and nothing for you to do.

If you want to see how we handle security across the board, from encryption and hosting to breach notification and the agreements we sign, read our security overview. If you are a district evaluating vendors and want to talk about how we would handle the next one, book a demo and ask us anything.