CoDMON Shut Everything Down Before the PHP Patch Landed

At lunchtime on 21 October 2026, nurseries across Japan went back to paper. CoDMON, the management platform used by more than 25,000 childcare facilities, began taking every service it runs for facilities and parents offline at around 1 p.m. Nothing had broken. The PHP project had announced that patches for two critical vulnerabilities would ship at 11 p.m. that night. Most Japanese services waited for the night. CoDMON didn't.

What happened that day

CoDMON published its own account. The company's head of product development posted a detailed post-mortem on the engineering blog two days later, and that is my main source here.

At 4:33 a.m. Japan time, the PHP team announced two critical flaws (CVE-2026-109618 and 109619, severity 9.2 out of 10) and said fixes would be released at 11 p.m., details withheld. Japan's Information-technology Promotion Agency issued a prepare-now alert the same day.

Inside CoDMON, an engineer flagged the issue on Slack at 9:01. At 10:32 it reached the executive team. The position then: don't stop, wait for 11 p.m. At 11:18 the product security team proposed a precautionary shutdown. At 11:37 the executives agreed on a plan. Announce in advance, stop at night to coincide with the release, and stop immediately if the release moved earlier.

Up to here, this is what most companies decided. The turn came at 12:03. The location of the bug and the way to fix it began circulating on social media and in developer communities, which meant an attack could work before 11 p.m. (the report notes not all of it had been verified). At 12:37 the executives met again and decided to stop now. Shutdown began around 1 p.m. The parents' app went dark at 1:46, the staff console at 2:02, and the last of the targeted services at 2:49. About 30 minutes from new information to decision.

Thirty minutes after the facts changed, the company decided to stop its own revenue

CoDMON's response to the PHP vulnerability (PHP2Shell), 21 to 22 October 2026, Japan time. From the post-mortem by the company's head of product development (23 October 2026)

1. 4:33PHP team gives noticeTwo critical flaws, fixes at 11 p.m. the same day, details withheld
2. 10:32Executives briefedPosition at this point: don't stop, wait for 11 p.m.
3. 11:37Night shutdown agreedAnnounce first, stop at 11 p.m.; stop at once if the release moves earlier. Approved by the CEO, the head of product and the executive officer for sales
4. 12:03The facts changeBug location and fix spread on social media; an attack could work before 11 p.m.
5. 12:37Daytime shutdown decidedEmergency executive meeting applies the morning's approval to the new information
6. 14:49Shutdown completeServices taken down in sequence from about 1 p.m.
7. 22:38Patch releasedSlightly early. Distributors would take hours to days to ship it
8. 3:22 next dayCore services backOn a self-built PHP. The rest returned on the 22nd; the child location alert at 9 a.m. on the 23rd

The decision changed every time the information did. What never changed was what came first.

The patch came out at 10:38 p.m., slightly early. But by 5 p.m. the team had realized that distributors (the official Docker image, Ubuntu packages and so on) could take hours or days to ship it. Engineers prepared their own PHP build in parallel. A night crew of 13 assembled at 10:30 p.m. At 3:22 a.m. on 22 October the staff console, the parents' app and the core services came back on the self-built version. The rest returned during the day, and the last feature, an alert for a child's whereabouts, at 9 a.m. on the 23rd. No unauthorized access or data leak was found, the company says.

What it cost

CoDMON's own site listed 25,696 facilities as of 1 October 2026. By the company's own March 2026 press release, paid facilities passed 25,000 in February, and about 4.16 million parents use the app, roughly one in three of all parents of children aged 0 to 14 in Japan. A weekday afternoon is the busiest time in a nursery. Attendance records, messages to parents, the check on where each child is at pickup: all of it went back to paper and phone calls for more than half a day.

The post-mortem doesn't dress this up. It lists as failures: advance notice to users was insufficient, the fact that the stop was precautionary didn't get through, and nobody had mapped in advance what a shutdown would break (attendance, messaging, payments, deadline-bound paperwork). Read that part before you turn this into a heroic story.

Nikkei's headline quoted the CEO as saying the call was made "on our code of conduct." The post-mortem says the deciding axis was "protecting children's information comes first," and that having it fixed in advance is what made a 30-minute decision possible.

Values are only tested on the day they cost revenue

Here is my point. Almost every company has "safety first" or "customers first" on a wall. In normal times you can't tell whether it means anything. You find out on the day that following it loses you revenue, a customer or your reputation. Every other day, the value asks nothing of you.

The detail I keep coming back to is who approved what, and when. According to the post-mortem, the rule that services would be suspended to avoid attack if the release moved earlier had been approved before noon by the CEO, the head of product, and the executive officer in charge of sales. The 12:37 decision was the executive team applying that approval to new facts; the report doesn't name titles again at that point. So the person responsible for revenue had signed off on a rule that could take 25,000 of their own customers offline, while nothing had happened yet. That, I think, is the line between a value that has become an institution and a value that is framed in the lobby.

One more thing. The decision wasn't stubborn. At 10:32 it was "wait." At 11:37 it was "stop tonight." At 12:37 it was "stop now." Each time the information changed, the decision changed. Deciding by values doesn't mean fixing the answer in advance. It means fixing the criterion you will switch on, so that when the facts move you don't spend an hour arguing.

Who in your company can hit stop?

Turn the question on a foreign company's Japan subsidiary. Can the country manager take the production service down without head office approval? Who in the entity can halt a shipment, or a delivery to a customer? Is it written anywhere?

In many subsidiaries the honest answer is "ask HQ." If HQ is in a time zone that wakes up eight hours later, the 12:03 information moves nobody's decision until the next morning. That company's "customers first" has business hours.

I wrote earlier about who decides in the Japan entity when the boss is away. This sits one level above that. The routine approval chain is one thing. Who holds the authority to stop revenue, and under what conditions, has to be settled in advance. In an organization where bad news stops traveling up, the 12:03 information never reaches the executives at all. At CoDMON an engineer wrote it in Slack at 9:01, and the executive team knew within ninety minutes.

What to write down comes to three things. The names of the people who can stop the service, because titles alone won't tell you who picks up the phone that night. The conditions. And who gets told what afterwards. CoDMON listed the third as its own failure. Put that much in writing, and the values part takes 30 minutes.

One line in the post-mortem reads to me as the real organizational story. The self-built PHP was never in the plan; engineers started looking into it on their own. In a company where management stopped revenue at noon, engineers start doing unplanned work at night. It doesn't happen in the other order.

---