TL;DR: On 17 October 2026 an external audit report went to a public university: 445 findings, consolidated into 9 standalone top risks, every claim backed by a hashed artefact. For five days there was no acknowledgement. On 21 October the German BSI published an emergency advisory on two RCE flaws in the PHP engine; on 22 October the university's online services were offline — publicly explained as "IT problems". This article claims no causal link. It documents a chronology and what is structural about it: a report nobody receives is not risk management, and "IT problems" is not a category an organisation can learn from.
What this is about
The target was the publicly reachable infrastructure of a university — the primary domain and the legacy domain from before its rename: external, non-intrusive, unauthenticated, no exploitation, no write access. A fleet of 48 agent units ran in four waves against 83-plus resolving hostnames on 27 IPs across six networks. 5,312 evidence files were hashed and recorded in a SHA-256 manifest.
The result: 445 findings — 28 high, 90 medium, 186 low, 141 informational — consolidated into 9 standalone top risks. Wave four re-ran every high and medium finding against fresh artefacts: 15 of 15 reproduced. Reproducibility is what separates a suspicion from a finding.
And then the sentence that carries this whole text: a report is not a state. It is an offer.
The chronology
17 October: handover
The complete audit report went to the university's responsible teams — with all technical evidence, risk ratings and the hash manifest, so that every statement stays verifiable. The report describes exposure and impact, not remediation: it says what is open, who can reach it, and what a patient attacker can do with it. What follows from it is the operator's decision.
17 to 21 October: silence
The disclosure log shows no acknowledgement for this window, no follow-up question, no named contact. Five days is not a long deadline for a fix. It is a long deadline for an acknowledgement — and that is the decisive difference: "not patched" is a state, "not received" is a process failure. An automated ticket reply would have been enough to tell the two apart.
21 October: someone else's clock
While the report sat unanswered, the PHP project published emergency patches for two remote code execution flaws in the PHP engine itself: CVE-2026-109618 (out-of-memory corruption) and CVE-2026-109619 (stale global state, use-after-free), both rated CVSS v4.0 9.2, both exploitable without authentication. Fixed releases: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35; older branches receive no official fix. The BSI advisory is BITS-H no. 2026-297981-1132 (version 1.1, criticality 3/Orange, TLP:CLEAR).
Two properties make this more than a patch note. First, it triggers before application code runs: in the demonstrated path — Apache with mod_php — the vulnerable sequence occurs during request start, ahead of any validation, any rate limit and any logging of a malicious body. Second, it was exploited before it was public: an attempt was observed four days before disclosure, and attempts rose sharply after the release.
For this estate that was not a side note. The inventory was clean per application — mail platform, list host, document portal, monitoring, learning platform. But not per runtime: nobody asked which interpreter serves which host, in which version, and who owns it.
22 October: shutdown
On 22 October the university reported an outage of its online services — publicly explained as "technical or IT problems". The reported findings and the disclosure notice did not appear in that statement.
What is established — and what is not
This separation is the core of a serious disclosure account, so it is explicit here.
Established: the handover date, the contents of the report, the reproducibility of the findings, the BSI advisory of 21 October with its CVE identifiers and CVSS rating, the outage on 22 October and the official explanation for it.
Not established: that the outage was caused by the reported flaws. Equally, that the report was read, or that the shutdown was a response to it. Anyone claiming that has more evidence than I do.
So why write this? Because the question of whether the two are connected can only be answered by one party: the university. Transparency makes it answerable. If the outage had nothing to do with the report, the answer is one sentence. If it did, the same answer is the start of a learning curve — for the university, for other institutions, and for everyone who writes these reports.
Why runtime is the actual subject
An application inventory answers "what software do we run?". A runtime inventory answers "what executes our code?". The second question is the one that suddenly mattered on 21 October — and it was absent from every document I was given.
The pattern is not specific to universities. It is the normal consequence of applications growing for years while runtimes drift along with nobody owning them. A list host that has "just worked" since 2010 is not a security problem as long as nobody looks. It becomes one the moment a flaw is published for an interpreter that no longer receives patches. Then the question is no longer "how fast do we patch?" but "how fast can we even find what is affected?".
What 445 findings mean
The nine top risks are not nine bugs. They are four patterns.
| Pattern | What was exposed | Why it matters |
|---|---|---|
| Mail and identity core | Exchange farm two security updates behind, EWS and Autodiscover answering anonymous Basic/NTLM requests outside SSO and MFA, DMARC at p=none | Any password harvested anywhere reaches a mailbox without an identity gateway and without MFA; branded phishing is delivered instead of rejected |
| The forgotten list host | Mailman 2.1.14 from 2010 on an Apache 2.0.63 origin, 16 version-applicable CVEs, no CSRF token in any web form | A crafted link against a logged-in list administrator means list takeover and bulk mail under the university's real brand |
| Data endpoints | Filr appliance in the 9.8 auth-bypass range, Grafana /metrics unauthenticated, end-of-life eLabFTW | A megabyte of metrics including usernames, routes and counters; an auth bypass in front of the document portal |
| Flat substrate | DNS, identity, VPN and CMS in one /24, 103 internal names in valid CT certificates, zero rate limiting and no WAF across two full waves | The map is public and renews every 60 to 90 days; nothing would have slowed an attacker down |
The full CVE mapping — including CVE-2026-70571 and CVE-2026-70279 for the Exchange farm — is in the audit profile (password-protected).
What was not the problem
An honest audit also names what is good — otherwise it is a sales pitch. The main surfaces had zero third-party origins and zero pre-consent trackers; the learning platform ran the current security release and closed exactly the RCE that would have chained through the reachable endpoints; the Exchange edge was hard except at its two by-design surfaces; backup hygiene and baseline hygiene of the main site were clean. The estate was not negligent. It was undefended precisely where nobody was looking any more.
Responsible disclosure is a process, not a courtesy
The term is often used as scenery: the researcher is generous, the operator is grateful. In reality it is a division of labour with obligations on both sides.
What the research side owes: no exploitation beyond proof, no data exfiltration, no publication of exploit code, data minimisation in the report, verifiable evidence instead of claims — and the willingness to accept a deadline longer than its own impatience.
What the operator side owes: an acknowledgement within a few working days, a named owner for the case, a documented triage decision — even "we will not fix this" with a reason is an answer —, a reachable channel (security.txt, a PGP key, an address that does not lead nowhere) and a statement about whether the reporter is treated as an ally or as a risk.
The 90 days common in the industry are not law. They are an expectation measured by whether anything happens within them. A deadline does not pass because nobody answers.
The silent week is the finding
An unanswered report is not an open finding. It is an unassessed risk — the worse category, because nobody measures it.
Three metrics are enough to know whether an organisation has a disclosure process or just an email address:
- Time to acknowledge — how long until the first human reply?
- Time to triage — how long until a decision, with severity and owner?
- Time to patch — how long until the fix, measured from triage, not from report?
Anyone who cannot state these three numbers does not have a process. And anyone who says only "IT problems" during an outage robs the public and other institutions of the chance to learn from it. Regulation is heading toward reporting duties and traceable communication anyway — NIS2, the Cyber Resilience Act. Public institutions will have to say more than "technical problems". Those who do it voluntarily, before they must, keep control of the narrative.
Frequently asked questions
What is responsible disclosure?
A procedure in which a security flaw is reported confidentially to the operator before it becomes public — with the goal of it being fixed before anyone exploits it. The core is the order: report first, fix second, tell the story third. Reversing the order is not responsible disclosure, it is a show.
How long may an organisation take?
A few working days for the acknowledgement, one to two weeks for triage, and for remediation as long as the severity justifies. The number matters less than the visibility: an operator who says "we have seen it, we assess by Friday, the patch lands in the next cycle" is in control. Silence has no schedule.
Why does the audit profile name the target while this article does not?
Because they are two different kinds of text. The essay The Door Beside the Front Door describes the same engagement without naming the target so the pattern stays reusable — it is a lesson, not a report. The audit profile is password-gated and does name the target, because it has to evidence the findings against the concrete system. This article stays with the pattern: it separates what is established from what is open.
The technical deep dive
- Audit profile (password-protected) — every finding, severity, evidence path, the nine top risks and the addendum on the PHP emergency advisory.
- The Door Beside the Front Door — the detailed analysis of the pattern: why the SSO exception was the real perimeter, how a list host from 2010 leads to takeover, and what certificates reveal about an estate.
Conclusion
- A report only becomes a risk once someone assesses it. Handover is the start of the procedure, not its end.
- Five days of silence is not a patch problem. It is a process problem — and process problems are cheaper to fix than any CVE.
- Inventory runtimes, not just applications. The component that executes every request is the one nobody inventories.
- "IT problems" is not a category. Whoever uses it loses the learning effect — and the narrative — to whoever writes about it later.
- Transparency is not weakness. A university that says "we had a security incident, here is where we stand" loses less trust than one that stays silent and later has to explain why.
Sources
- Audit profile of a public university, assessment date 17 Oct 2026 (5,312 evidence files, SHA-256 manifest)
- BSI, security advisory BITS-H no. 2026-297981-1132, version 1.1 of 21 Oct 2026, criticality 3/Orange, TLP:CLEAR
- PHP security advisory of 21 Oct 2026 (GHSA-w8hw-w9fx-j79w) for CVE-2026-109618 and CVE-2026-109619, CVSS v4.0 9.2