CTO: the run of 2026-10-22T1753Z

The review, in the reader's words

I got the severity, the fix, the side effects and the speed I need inside the first two pages, and with evidence I can check, but nothing gives me a paragraph I can put in front of my board, and the CTO briefing alone is a 20-minute read for an 8-minute question.

Got the answer partly · Severity, fixed versions and urgency came on the first screen of index.html (At a glance); fix order and side effects came in the thirty-second answer on briefings/cto/index.html (page 2); the board message never came: I had to piece it together myself from the front page and the claims table.

What works

• The At a glance block answers fix, severity, attackers, confirmed hacks, KEV status and agency advice in seven tiles: that is most of my first board slide. (index.html)
• The thirty-second answer is exactly the right shape for me: patch order by SAPI, restart and rebuild, test under load, EOL versions have no release, then the inventory lesson. (briefings/cto/index.html)
• Every claim carries a status (confirmed, reported, disputed, contradicted, unverified) and a primary-source count like 5/5 or 0/1, so I can see at a glance what I can repeat and what I must caveat. (briefings/cto/index.html)
• Severity is stated with its evidence and its tempering: 9.2 with the full CVSS vector, AC:H and AT:P explained, and the 10.0 figure explicitly marked contradicted. (flaws/index.html)
• The affected and fixed versions table, with the warning that scanners reading the CVE record will call 7.4 to 8.1 unaffected, is directly actionable for my vulnerability management. (flaws/index.html)
• The mitigations table pairs each setting with what it does not do, from the same source; that stops my team over-trusting a php.ini change. (flaws/index.html)
• What the fix changes (deferred OOM, memory_hard_limit_percent, max_multipart_body_parts, 389 files) is the side-effect list I need to plan regression testing, and it honestly says no regression has been reported yet. (patching/index.html)
• The process-tree signal (a PHP worker spawning a shell) and the plain statement that nginx default logs cannot answer 'were we hit' tell me what to ask my SRE lead today. (defence/index.html)
• The blast radius section frames the question as a property of our system, which is the right way to brief my architects on microservices. (flaws/index.html)

What does not

• high No board-ready summary anywhere on my path: the CTO briefing headline question drops 'what do I tell the board', and the Board member briefing is a separate path. (briefings/cto/index.html)
  Headline: 'What does this cost us in engineering time, what breaks when we patch, and what do we change so the next one is a non-event?' No section addresses board messaging; the board appears only as 'Board member or executive' in the Other readers list at the foot.
• medium The CTO path is far longer than my time: the briefing itself is 2,093 words and 6.5 screens, and the reading path is quoted as 20 minutes. (briefings/cto/index.html)
  'About 20 minutes in all.' and 'Your briefing 3 min', while the instruments measured 2,093 words on this page alone.
• medium The claims table is long and chronologically mixed: disclosure-timing disputes (pre-announcement at 19:30 vs 20:32 UTC, release time) sit alongside the facts I need to act on, with no grouping. (briefings/cto/index.html)
  'The pre-announcement was published at 19:30 UTC on 20 October' DISPUTED and 'The fixes were released at 14:00 UTC on 21 October' DISPUTED appear in the same table as patch and FPM claims, even though the briefing says I can skip 'the disclosure politics'.
• medium Containers are my estate, but the container guidance stops at 'Docker Official Image: php fixed' with no tags or digest, and 'rebuild every image' with no way to tell which base images carry the fix. (patching/index.html)
  'fixed Docker Official Images maintainers: Docker Official Image: php' with no version string, unlike the Ubuntu and Red Hat rows.
• low The top ~200px of every page is taken by the reading tracker and the research banner before any content, which pushes the answer below the fold on a 900px screen. (briefings/cto/index.html)
  fold.png: 'Your reading: on this page 24 new...', 'Mark this page read', 'Read items: fade hide show', 'RESEARCH collected from outside sources...' and a 'New to this story?' bar all precede the headline.
• low An unexplained price badge in the header ticks down as I read, which I cannot interpret and which makes me wonder whether I am being charged. (index.html)
  Header badge reads '£4.99' on index.html, '£4.98' on briefings/cto, then down to '£4.90' on the glossary; nothing on the pages explains it.
• low The briefing's 'Read the site as Avery' and persona names add a layer I do not need; I am the CTO, not Avery. (briefings/cto/index.html)
  'BRIEFING FOR AVERY, CTO' and 'Read the site as Avery →'.
• low How fast must we move is stated as agencies saying 'now', but there is no concrete risk framing for an FPM-and-containers estate beyond 'susceptible' and a disputed FPM claim. (flaws/index.html)
  'PHP-FPM susceptible ... the GitHub advisory says no complete FPM exploit has been demonstrated; the PHP Foundation blog says RCE was confirmed on FPM through application-level paths.'

What this reader would change, in order

1. Add a 'What to tell the board' box of four or five sentences (severity and evidence, our likely exposure class, the fix and its risk, the timeline, what is still unknown) just under the thirty-second answer. (briefings/cto/index.html, small)
   It is a quarter of my question and the one I have to answer in person, and right now I have to assemble it myself.
2. Split the claims table into 'Decide on these' (severity, fix, FPM, EOL, WAF, side effects) and 'Background' (timing and attribution disputes), collapsing the second. (briefings/cto/index.html, small)
   The briefing tells me to skip the disclosure politics, then makes me read them to find the FPM and EOL rows.
3. Give the Docker Official Image row the fixed tags or the date the images were rebuilt, and add one line on how to verify the PHP version inside a running container. (patching/index.html, small)
   We run a dozen microservices on containers and 'rebuild every image' is only useful if I know which base image is safe.
4. Add a one-line exposure guide by SAPI for planning (mod_php: demonstrated, today; FPM: susceptible and disputed, this week at latest) to the thirty-second answer. (briefings/cto/index.html, small)
   It turns 'how fast' into a schedule I can commit to and defend.
5. Collapse the reading tracker and research banner into a single thin line on desktop, or show them below the page headline. (briefings/cto/index.html, medium)
   On a 900px screen they cost me the first third of every page before I see the answer.
6. Explain or remove the '£4.99' header badge. (index.html, small)
   An unexplained, falling price next to a security briefing makes me doubt what I am looking at.
7. Offer a printable or forwardable one-page version of the At a glance block plus the core facts with their status labels. (index.html, medium)
   That block is the closest thing to something I can send to the board, but the page around it is not forwardable.
8. State honestly that the CTO path is 20 minutes and offer an 8-minute route (briefing top, flaws versions table, patching 'What the fix changes'). (briefings/cto/index.html, small)
   I have eight minutes and need to know which sections are the minimum.

Lines this reader reacted to

• briefings/cto/index.html: Patch internet-facing mod_php first, then FPM, then the rest; restart every worker and rebuild every image. The fix changes how PHP behaves when memory runs out, so test under load.
  This is the answer I came for, in two sentences. I can hand this to my platform lead as is.
• briefings/cto/index.html: 7.4, 8.0 and 8.1 have a source backport and no release: that is a migration you are now doing, not a patch.
  Blunt and correct framing for budgeting; this is the line that changes engineering time.
• briefings/cto/index.html: a system that used to survive on the edge of memory_limit may now _exit instead.
  Concrete side effect, phrased so I know what to load-test. Good.
• flaws/index.html: The CVE records carry defaultStatus 'unaffected' and list only 8.2 to 8.5, so an automated scanner reading the CVE will call 7.4 to 8.1 unaffected.
  This is the most useful single warning on the site for my security team: our scanner dashboard would have lied to us.
• flaws/index.html: Remote code execution as the web worker is the floor, not the ceiling, and not yet a breach.
  Good line for the board, and the right mental model for blast radius.
• defence/index.html: An organisation whose only telemetry is the access log cannot answer "were we hit" from it
  Uncomfortable and useful: this tells me what to say if the board asks whether we were compromised.
• playbook/index.html: a system that cannot is one you take offline early, because you will not be able to later.
  A sharp decision rule I can actually apply to our services list.
• patching/index.html: The downstream rows are the NCSC-NL inventory's own rows at commit cca173c64ec5 (22 October, 08:40 UTC), each named exactly so the gate can check it is there and has the status quoted.
  Lost me: 'the gate' is the site's internal plumbing, not something I need in the opening paragraph.
• briefings/cto/index.html: About 20 minutes in all.
  More than double my time; I need to know what to skip, not just how long the whole thing is.

Since the last run

First run: no previous review to compare against.

Reviewer: agent-session.

The journey

The pages in the order read: the start, the reader's path, then the links that matched its interests.

What the instruments flagged

Measurements, not verdicts: the review says which of them mattered to this reader.

Everything this run saw

Vault wlhgl8pk · read key sgit_public_read_c20a2e6e91f6aa161ab7f6abb20dc0e27ade846a94ce149d0fd11996daaade3f:wlhgl8pk (read-only, published on purpose)

Open the vault read-only in a new tab ↗ · sgit clone sgit_public_read_c20a2e6e91f6aa161ab7f6abb20dc0e27ade846a94ce149d0fd11996daaade3f:wlhgl8pk

This run is in the folder runs/2026-10-22T1753Z/: the served and rendered HTML, the text and the screenshots of every page, every request and console message, and what the reviewer was given.