Black October Broke the Internet's Social Contract. Now We Must Decide What Replaces It.

I have spent more than a quarter-century watching the Internet change the world. I believed in its original audacity: that someone with a computer and an idea should be able to reach anyone, publish something consequential, build a company, find a community, or ask for help without obtaining permission from a gatekeeper first.

That was not a design detail. It was the miracle.

This week, for the first time in a long time, I felt that miracle slipping out of our hands.

The cluster of events now called Black October is not one attack or one coordinated campaign. It is a compressed, frightening exposure of how fragile the institutions behind everyday digital trust have become. And it deserves more than another warning to patch faster. It deserves an argument about the future of the Internet itself. ^{1 2}

On October 21, the PHP project shipped emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which can allow unauthenticated remote code execution. Palo Alto Networks' Unit 42 subsequently counted more than 22.6 million Internet-exposed instances potentially vulnerable in its own telemetry. That is an exposure estimate, emphatically not 22.6 million confirmed compromised machines. PHP's much-quoted share of the web describes websites with identifiable server-side technologies. It is not proof that 70% of the Internet was breached. ^{3 4}

On October 17, a researcher reported eight eMudhra subordinate certificate-authority private keys generated with insufficient randomness—keys that could have been reconstructed to issue fraudulent trusted certificates. Google moved to block them quickly. Google also reported that it found no certificates chaining to the affected intermediates in Certificate Transparency logs before its block, an important limit on claims of observed mass exploitation. The trust mechanism failed, but that does not mean every feared abuse happened. ⁵

On October 21, a poisoned LiteLLM 1.107.0 release appeared in official Python and container distribution channels. Seven malicious Python wheels were available from 11:39 to 13:23 UTC—roughly 104 minutes. The company’s October 23 canonical incident review says attacker-controlled source made its way through a legitimate, signed release process using compromised developer credentials. In other words, the software was authentically signed by a compromised authority. That distinction should haunt every architect considering a signature-only Internet. ^{6 7 8}

Railway disclosed exposure of some customer environment-variable secrets and the temporary suspension of builds. Its October 22 preliminary report estimates that at most 1.85% of workspaces—approximately 100,000— had some variables potentially compromised. The number of customers affected by precautionary credential revocations was larger, and Railway says running deployments remained online. ⁹

Zeabur's October 19 report describes attacker access to 101 managed GCP servers and commands executed in 865 database services; its founder had already announced that the platform would wind down by December 31. An actual business disappeared from the cloud-provider landscape while its customers inherited an urgent migration. ^{10 11}

These incidents were disclosed in a tight window, although some underlying intrusions began earlier. They (especially) don’t prove that all encryption is broken, that every website is compromised, or that AI independently caused every event. They do prove something more useful, however, and perhaps more disturbing: the cost of discovering and exploiting weakness is collapsing much faster than the cost of rebuilding justified trust. ^{12 1}

I had previously warned about that structural collision, though not the specific incidents or their dates, in our October 9 research, When the Keys Fail. Our October 22 Black October Enterprise Survival Manual addresses the immediate recovery problem. I suggest this is the harder, longer question: what kind of Internet are we going to recover into? ^{13 1}

The original social contract is coming due

Imagine visiting someone's house.

Today, the Internet often allows you to walk up an unfamiliar street, find the address, and knock. The resident might welcome you, ignore you, ask who you are, or deny you entry. There are doors and locks, and the ability to reach a front porch was never supposed to mean permission to enter the living room.

But our digital neighborhood has made knocking extraordinarily cheap and infinitely repeatable. Anyone can try every door, rattle every lock, invent a new face, and send a thousand tireless agents to do it again. Some doors stand on software maintained by a tiny team. Some locks depend on authorities that issue keys at planetary scale. And when a legitimate delivery truck brings a malicious parcel, the signature on the manifest may be perfectly valid.

The tempting response is to put a guard at the end of every street and demand identification from everyone, forever.

That might protect the houses. But it might also destroy the neighborhood.

We must preserve the right to find an address and knock while ending the presumption that an unsolicited knock deserves access to the machinery inside. That is the difference between a safer open Internet and a collection of private, corporate or national networks. The Internet Architecture Board's principle remains a useful moral test: Internet standards should serve end users, not simply the convenience of those who control access. ¹⁴

Five possible futures—none free of consequence

Path	What changes	Principal advantage	Failure mode / what we lose	Relative transition burden
1. Fully permissioned Internet	Defined and approved paths between hosts, services or trust domains; default deny	Shrinks reachable attack surface and limits lateral movement	Unknown partners, newcomers, discovery, emergencies and independent publishers become exceptions; gatekeepers acquire immense power	Extreme at Internet scale; high inside bounded enterprises
2. Fully signed interactions	Every caller presents cryptographic identity or a verifiable signature before access	Better authentication, attribution and revocation where keys are well governed	Stolen or improperly issued keys authenticate attackers; universal real-name rules threaten anonymity and dissent	Extreme for global identity; moderate for enterprise workloads
3. Hardware-rooted zero-trust network	Device/workload attestation and continuous policy govern connection and execution	Makes spoofing and some classes of compromise harder; can contain untrusted endpoints	Legacy devices, supply-chain trust, attestation gaps, recovery and hardware-vendor concentration	Very high across legacy fleets; selective deployments feasible
4. Privacy-preserving capabilities	Short-lived, narrowly scoped invitations prove authorization without necessarily revealing legal identity	Lets open discovery coexist with minimal privilege and anonymity	First-contact and invitation UX; issuance, expiry, replay and delegation are hard at scale	High for platforms; can grow incrementally
5. Open Internet, hardened foundations	Keep public reachability; strengthen routing, software provenance, certificates, patching and admission at services	Preserves interoperability, permissionless publishing and existing Internet reach	Exposed services still need defending; compromised authorized software and identities remain risks	Large but incremental, distributed across the ecosystem

These are architectural scenarios and relative assessments only. They’re not yet products, official standards proposals, or measured global cost forecasts. Also, they are not mutually exclusive.

1. A permissioned Internet: safer streets, fewer strangers

In the strict version, paths must be named before traffic can flow. The enterprise form is already familiar: application allowlists, private overlays, identity-aware proxies, segmented service meshes, egress control, default-deny ingress, and tightly defined partner connections. For hospital systems, financial settlements, industrial controls and confidential enterprise services, much of this is overdue. NIST's zero-trust architecture explicitly avoids granting trust merely because a system sits on an approved network. ¹⁵

But make this the universal Internet and the failure becomes social as much as technical. Who approves a first visit? A whistleblower contacting a newsroom? A new company finding its first customer? A teenager launching a website? A disaster volunteer whose organization was never added to a routing policy? Search crawlers, federated communities, webhooks, independent software, emergency response and countless machine-to-machine integrations become a permissions backlog. The approval machinery itself becomes a spectacular target and a potent instrument of censorship.

A universal allowlist is not merely a security design. It is an allocation of the power to decide who may encounter whom. We should use it wherever the consequences justify it, not make it the price of being online.

2. A fully signed Internet: stronger evidence, not guaranteed truth

There is real appeal in demanding cryptographic evidence that a connection came from an identified person, device or workload. SPIFFE/SPIRE already gives services short-lived, verifiable workload identities; FIDO/WebAuthn and certificate technologies can authenticate devices and users. Modern PKI can be federated, automated and rotated rather than administered by hand. ^{16 17}

But here is Black October's warning: a signature proves possession or authorized use of a key, not good intentions or untampered provenance. eMudhra exposed weakly generated CA keys. LiteLLM's compromised pipeline released malicious software through its own trusted distribution mechanisms. A universally signed Internet without independent authority checks, scoped permissions, provenance, transparency and fast revocation would create an even larger stage for perfectly authenticated attacks. ^{5 6}

And “identify yourself” must never automatically mean “show a government ID.” A journalist, abuse survivor, activist or ordinary citizen needs to be able to prove permission without surrendering a permanent identity graph. W3C's Verifiable Credentials work explicitly recognizes correlation risk and selective disclosure. A signature can assert a role, a bounded right or a pseudonym. Done well, that distinction protects both security and liberty. Done badly, and this is one of my real concerns, it builds the most comprehensive surveillance infrastructure in human history. ¹⁸

3. Hardware-rooted zero trust: trust the machine less, measure it more

My analysis is that we now need very different networking assumptions: establish strong evidence about the boot state, software provenance, workload and device health before giving a connection meaningful authority; reevaluate that authority throughout the session; make revocation and containment routine. TPMs, secure elements, trusted execution environments, measured boot, remote attestation and identity-aware transport could make parts of that viable.

Yet hardware is neither necessary for every zero-trust deployment nor sufficient to guarantee safety. Devices can attest that they ran the firmware the vendor signed, while the vendor's signing infrastructure is compromised or the authorized firmware contains a serious flaw. Hardware roots fail when keys are mishandled, update paths are poisoned, silicon has defects, devices are orphaned or administrators cannot safely recover them. Crucially, eMudhra says the weak keys at issue were generated during a ceremony using FIPS 140-2 Level 3 certified hardware security modules: a flawed wrap/unwrap procedure reportedly produced and published weak keys anyway. Certified silicon did not substitute for a sound ceremony and independent verification. ¹⁹ NIST zero trust is fundamentally a policy and resource-access architecture—not a requirement to replace every router. ^{15 5}

Path-aware systems such as SCION, pursued by an open engineering community and already deployed in specialized networks, offer another possibility: cryptographically validated route selection and stronger isolation across administrative domains. But SCION's own documentation is clear that it does not itself supply end-to-end payload encryption or application identity. A secure path is not automatically a secure service. ²⁰

The hardware route will be essential for high-consequence systems. Imposing it as a prerequisite to reading a blog, publishing anonymously or connecting a low-cost device would be a terrible bargain.

4. Capabilities: prove you were invited, not who you are

This is the additional path I find especially promising. A public destination remains discoverable; an untrusted visitor can reach a minimal, rate-limited introduction surface. Before doing anything important, it obtains a short-lived, signed, tightly scoped capability—permission for this action, to this resource, for this interval, potentially without disclosing a globally stable identity. A person, a trusted intermediary or a protocol can issue the invitation. A service can revoke it without blacklisting an entire human being.

This brings us closer to how a civilized neighborhood actually works: the house is findable, the doorbell works, the rooms are not public. Privacy-preserving credentials and selective disclosure offer important building blocks. But discovery, anonymous abuse resistance, delegation, account recovery, offline use and interoperability remain hard problems. A capability stolen from a device still needs binding, expiry, proof of possession or other protections. ¹⁸

The challenge is not merely cryptography. It is designing first contact so a six-billion-person Internet can stay welcoming. It must also be usable, performant, and effective.

5. Keep the Internet open—and finally finish securing its foundations

The least glamorous path is also indispensable. RPKI and route-origin validation can reduce certain routing-hijack risks; certificate transparency and independent root-store governance make CA failures more discoverable and containable; secure DNS, TLS, automated short-lived credentials, software bills of materials, verifiable builds, signed provenance, reproducible artifacts and rapid patch distribution can reduce systemic exposure. Sigstore, OpenSSF, Let's Encrypt/ISRG, browser root programs, package registries and network operators matter as much as security vendors. ^{21 17 5}

This is not enough by itself: an open PHP endpoint still needs patching, a compromised developer still holds apparently valid privileges, and malicious code signed by an authorized release system remains malicious. But it preserves the democratic, economic and creative upside of the Internet while we change where trust is required.

The most plausible future is probably not one of these five alone. It is an open discovery layer with verified, increasingly granular admission; strongly authenticated services where appropriate; hardware-attested critical paths; privacy-preserving access for humans; and heavily repaired Internet foundations underneath them all.

What must be rebuilt—and who will pay?

This is a generational infrastructure program, and not a new procurement category.

The network layer needs a thorough overhaul for today’s security realities: better route validation, secure resolver behavior, anti-spoofing, DDoS resistance, path options and safe fallback. The transport and application layers need interoperable identity negotiation, continuous risk checks, machine-readable capabilities, robust revocation and strict separation of public discovery from privileged execution. Developer infrastructure needs trustworthy build provenance and distribution, constrained CI identities, hardened secrets handling and emergency revocation. Organizations need application-dependency inventories, independent recovery planes, survivable key ceremonies, cross-provider restore paths and actual tests of what happens when a trusted issuer becomes untrusted. ^{21 16 6 9}

The most brutal hidden cost is not equipment. It is mapping relationships that were never documented. Consider a large enterprise with 10,000 applications averaging ten explicitly governed outbound dependencies: 100,000 directed relationships. At an illustrative 30 minutes to classify, approve and test each relationship, that's 50,000 engineering hours—about 25 full-time engineering years, or $7.5 million at an assumed fully loaded $150/hour, before tooling, migrations, exceptions, hardware or ongoing maintenance. That is a transparent scenario calculation, not a survey result or a global cost prediction. Actual topology, automation and labor cost will vary enormously.

Universal signed identity will add credential issuance, account and device enrollment, lost-key recovery, revocation distribution plus a big risk of concentrating power in a few global identity authorities. Hardware attestation adds fleet renewal and lifecycle support, adding in the unglamorous challenge of keeping hospitals, factories, schools and old industrial systems operating. The permissioned model imposes a permanent tax on new relationships. The open-hardening model spreads spending across package ecosystems, operators, maintainers and browser vendors—and may be less costly in absolute replacement, but demands relentless upkeep.

Scale matters: the ITU estimated six billion people online in 2025, with 2.2 billion still offline. A new global authentication tollbooth would not merely redesign enterprise security; it would determine who can participate in the modern economy. That cannot be decided solely by the vendors capable of selling the tollbooths. ²²

We have also been financing essential infrastructure as though it were optional. The PHP Foundation has acknowledged that the long road to repairing the underlying memory-handling issue reflected both limited engineering capacity and a security decision process that stalled. In this very week, OpenJS and the Sovereign Tech Agency announced research into managing the flood of vulnerability disclosures more sustainably. Maintainer funding and disclosure capacity are Internet infrastructure now. ^{12 23}

This is who must step up

The IETF and Internet Architecture Board must bring operators, browser vendors and protocol designers together on a clear divide between discoverability and privilege: the future of transport, DNS, routing validation, path-aware research, privacy and resilience. NIST, W3C, FIDO Alliance and the CA/Browser Forum must drive interoperable, revocable, privacy-respecting identity and attestation profiles rather than competing universal ID silos. ^{14 15 18}

ICANN, the regional Internet registries, MANRS, ISPs and backbone operators must make routing hygiene a baseline rather than a voluntary improvement. Microsoft, Google, Apple, Mozilla, Cloudflare, Cisco, AWS, Akamai and other infrastructure vendors must ship safer defaults that work across competitive boundaries, with open recovery interfaces and published interoperability tests. Their opportunity is to compete above the trust layer—not own it.

The unexpected heroes could be the most important: the PHP Foundation, OpenJS, OpenSSF, CNCF projects such as SPIFFE/SPIRE, Sigstore, open-source package registries, public-interest certificate authorities, libraries, archives, humanitarian networks, accessibility advocates and the Tor Project. They understand threats that an enterprise purchasing committee may never see: exclusion, surveillance, unpaid maintainers, abandoned devices and the quiet disappearance of the small independent website. They deserve funding and a seat at the design table. ^{12 23 16 17}

Perhaps most important of all, as calls for change reach national levels: Governments must absolutely resist the temptation to equate safety with compulsory legal identity. The open Internet has been a tremendous civilizational advance. It can’t be lost. Security agencies can help with this by providing coordinated disclosure and infrastructure defense; legislators can fund digital public goods, re-establish basic interoperability and accountability rules, and critically, protect anonymity for legitimate speech. The insurance and audit industries can create incentives for provable recoverability rather than demanding yet another annual checkbox.

The decision not to decide

We can do nothing. It is still a choice. It means accepting an expanding cycle of mass scanning, reactive patching, compromised credentials, platform shutdowns and increasingly expensive recovery. The speed of attacker discovery and deployment will keep outpacing institutions that cannot patch, revoke, reconstruct and verify trust quickly enough. This week's disclosures give no reliable basis for predicting a date for a total Internet collapse. They give more than enough reason to reject complacency. ^{4 12 9}

I do not want my children to inherit an Internet where every stranger is a suspect, every publisher needs a license, and every conversation begins with a demand for identification. I also refuse to accept one where ordinary people, hospitals, schools and small businesses must gamble their safety on invisible chains of keys, code and vendors they cannot inspect.

What I want is almost embarrassingly simple: a safe Internet again. Not a nostalgic restoration of its early innocence. We cannot go back, and pretending we can is part of the problem. I want the old freedom with better boundaries; the old possibility with stronger proof; the old openness with the ability to say no, and to recover when no has failed.

We should still be able to find someone's house and knock unexpectedly. That is how friendships begin, discoveries happen, and an open world remains open. But the door should be real, its locks should be trustworthy, and nobody should have to let the entire street into the kitchen to answer it.

Black October must not become the week we accepted the end of the open Internet. Let it be the week we decided openness deserved an architecture capable of keeping it.

---

Sources

1. The PHP Project — Security advisory and October 21 releases ³
2. Palo Alto Networks Unit 42 — PHP2Shell exposure and attack telemetry, updated October 23 ⁴
3. Google Chrome and Android Security Teams — eMudhra intermediate CAs, October 20 ⁵
4. LiteLLM — October 21 compromised release and October 23 investigation update ⁶
5. Microsoft Security — LiteLLM package analysis, October 23 ⁸
6. Railway — Preliminary incident report, October 22 ⁹
7. Zeabur — Preliminary security incident report, October 19 ¹⁰
8. Zeabur — Wind-down announcement, October 17 ¹¹
9. 404 Media — Reporting on Black October and AI discovery, October 22 ²
10. Frontier Research — Black October: The Enterprise Survival Manual, October 22 ¹
11. Frontier Research — When the Keys Fail, October 9 ¹³
12. The PHP Foundation — Security response and resourcing, October 21 ¹²
13. NIST — Zero Trust Architecture, SP 800-207 ¹⁵
14. Internet Architecture Board — The Internet Is for End Users, RFC 8890 ¹⁴
15. SPIFFE — Workload identity and verifiable identity documents ¹⁶
16. Sigstore — Identity-based software signatures and transparency ¹⁷
17. W3C — Verifiable Credentials Data Model 2.0 ¹⁸
18. SCION — Secure path-aware inter-domain networking ²⁰
19. MANRS — Global validation and RPKI ²¹
20. International Telecommunication Union — Global 2025 Internet user estimates ²²
21. OpenJS Foundation — Funding alternative disclosure workflows, October 22 ²³
22. eMudhra — Technical incident statement on certified HSM use, October 22 ¹⁹
23. LiteLLM — Canonical October 23 investigation of the malicious release pipeline ⁷