Is the Open Internet Ending? PHP2Shell, Broken Certificates, and AI Agent Risks

On October 24, 2026, Platzi’s video “Why the PHP hack is the end of the open internet” connected a series of troubling stories: two critical PHP vulnerabilities, certificate authorities using weak private keys, concerns over AI agents accessing sensitive services, and the prospect of businesses and governments pulling critical infrastructure away from public networks.

It asks a worthwhile question: are we leaving behind an internet where almost everything can connect to everything else? But the answer cannot be obtained simply by stacking headlines. The incidents have different causes, some claims lack sufficient public evidence, and—most importantly—a private network is not automatically a secure one.

Our argument is less apocalyptic: AI is putting additional pressure on an already imperfect system of trust. The sustainable answer is stronger control over identities, permissions, and connections—not a declaration that the internet is dead.

We have previously explored PHP2Shell’s technical mechanics, affected versions, and disclosure history in our dedicated article. This is about the bigger picture.

1. Two confirmed incidents, two different failure modes

PHP2Shell: a shared dependency beneath many applications

On October 21, 2026, the PHP Foundation released patched versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Two memory-handling defects, CVE-2026-109618 and CVE-2026-109619, could allow unauthenticated remote code execution under certain conditions. Researchers demonstrated exploitation paths, and operators were urged to upgrade.

The structural issue matters more than the headline: a vulnerability in a shared runtime can affect numerous applications built upon it. A shop or government service may have perfectly adequate application logic and still be exposed through a common dependency. Cloudflare deployed WAF protections before disclosure, but an edge defense is not a substitute for patching the vulnerable runtime.

A frequently quoted statistic about PHP adoption does not measure how many servers were exploitable, still less how many were compromised. Attack attempts, exposed installations, and successful compromises are different measurements.

eMudhra: when a trust issuer fails

On October 17, a researcher reported insufficient entropy in private keys belonging to eight eMudhra intermediate certificate authorities. Google confirmed that the weakness could allow forged HTTPS certificates to appear trusted to clients that had not removed trust in those authorities. Apple began blocking affected trust paths on October 19.

This does not mean HTTPS was universally decrypted or that all encrypted traffic became readable. The failure involved the ability to issue fraudulently trusted certificates through specific chains of trust—quite different from breaking the underlying cryptographic algorithms.

In its own incident statement, eMudhra says seven intermediates were never used in production and the eighth had issued no end-entity certificates. That statement is part of the investigation, not evidence that every device has received remediation. Google and Apple documented their blocks; devices and applications with stale trust stores deserve particular attention.

Both stories expose shared dependencies: runtimes and certificate issuers concentrate risk across otherwise unrelated systems.

2. Did AI cause this wave of vulnerabilities?

The video suggests a temporal link with recent open-weight models, particularly a DeepSeek release, and modified models with weaker refusal safeguards (abliteration).

It is plausible—and increasingly observable—that AI tools accelerate code inspection, bug discovery, and proof-of-concept development. But that capability does not establish that one particular model caused unrelated incidents during the same week.

PHP2Shell offers a more thoroughly documented chronology. The PHP Foundation says clues to the problem existed in 2024; Calif and OpenAI independently reported significant findings on August 11, 2026, and Wiz submitted additional findings on August 24. October’s disclosure followed months of difficult coordination and remediation. A model release in mid-October cannot retroactively account for that discovery.

Nor do the official sources reviewed here establish a common actor, model, or tool connecting the PHP, eMudhra, and other incidents mentioned in the video.

Timing is not proof of causation. Establishing that hypothesis would require verifiable traces, technical attribution, evidence of the tools involved, and a consistent timeline. A hypothesis can guide investigation; it should not be reported as a conclusion.

The operational lesson still stands: if finding vulnerabilities becomes cheaper, maintainer triage, patch engineering, and deployment must speed up too. The PHP Foundation explicitly credits sustained funding and human expertise alongside AI-assisted research.

3. AI agents expand the attack surface

A model does not need to have its safeguards removed to create serious risk. Connecting a capable agent to email, code repositories, terminals, password managers, or financial systems—and giving it excessively broad permissions—can be enough.

A chatbot that drafts advice has a different potential impact from an agent allowed to read secrets, send network requests, execute commands, or modify records. The threat shifts from the generated sentence to the authorized action.

OWASP’s guidance on excessive agency emphasizes three common root causes: too much functionality, excessive permissions, and autonomy without sufficient boundaries. OWASP also documents prompt injection: material found in a webpage, file, or tool output attempts to become instructions for the assistant.

Consider a security-analysis agent reading what looks like vendor documentation. The page contains an embedded request to upload environment variables to an external address. If the agent mistakes untrusted source content for a user instruction and can access those secrets, ordinary text can become a privileged action.

Defenses must therefore exist outside the model:

Service-specific, least-privilege credentials, preferably short-lived.
A strict separation between read-only tools and those that can write, delete, or transfer funds.
Explicit approval for consequential actions, spending caps, and auditable logs.
Destination and parameter validation before external requests are allowed.
Isolated execution environments and protection from instructions embedded in untrusted sources.

An agent’s ability to perform an operation does not establish permission to do so. Likewise, cutting off internet access cannot solve insider abuse, stolen credentials, or malicious files.

4. Are we entering an era of intranets?

The video’s central forecast is that heightened security concerns will push organizations to isolate services and favor private networks. There is a sound kernel: keeping administrative dashboards, databases, and industrial control systems off the public internet can materially reduce attack opportunities.

But consider three distinct approaches:

Architecture	Main advantage	Important limitation
Everything exposed online	Simple access and connectivity	Large attack surface
Private or segmented network	Fewer entry points and movement paths	Insider misuse remains possible
Zero Trust plus segmentation	Authorizes each user, device, and resource	Requires policy operations and monitoring

NIST SP 800-207 is explicit: being inside a local network grants no implicit trust. Zero Trust moves authorization away from physical network location and toward verified identities, devices, assets, and permissions.

For physical infrastructure, CISA issued guidance in April 2026 on applying Zero Trust concepts to operational technology, where safety, availability, and older device constraints complicate the design.

A more plausible future than “the end of the internet” is therefore an internet that remains connected while sensitive functions move behind verified identities, restrictive gateways, separated networks, and human approval. This is an architectural shift—not an inevitable shutdown of the global network.

5. A practical design for small teams

Imagine a small organization running a website, a support bot, scheduled automations, and a database. It does not need to build a private internet. It does need boundaries between components.

A defensible baseline would look like this:

Expose only the necessary entry point: a public website or authenticated API, not an unrestricted database, admin dashboard, or SSH port.
Keep data behind a private service layer: the public component uses a narrowly scoped API rather than administrative database credentials.
Give agents distinct identities: a read-only credential for research and a separate, tightly governed pathway for authorized writes.
Separate environments: development, CI, and production have different permissions and secrets; external tool outputs never become security policy.
Maintain dependencies and certificates: inventories, vendor advisories, regression tests, prompt rollout, and rollback capability.
Measure suspicious activity: alerts for privilege changes, failed logins, unusual outbound traffic, secret access, and configuration drift.

These principles apply whether the stack runs on a hyperscale cloud platform or a modest Linux VM. The aim is not to eliminate connections but to limit how far a single failure can propagate.

6. Which parts of the video are supported?

Claim	What the evidence supports
”PHP suffered two critical vulnerabilities”	Confirmed, with CVEs, patched releases, and maintainer analysis.
”A certificate authority used weak keys”	Confirmed for specific intermediates; browser and operating-system blocks began.
”A specific DeepSeek release caused the wave”	Not established by sufficient public technical attribution.
”Tool-using AI agents introduce new risks”	Documented risk, with severity depending on granted permissions and connections.
”The open internet is ending”	A forecast, not an observed fact about global connectivity.

Platzi’s video performs a useful service by bringing scattered security headlines together. Its weakness is the leap from documented incidents to one causal story and a sweeping prediction without matching evidence.

The question that matters

Will the open internet survive? As of October 24, 2026, the evidence does not warrant declaring its end. It does justify abandoning the assumption that a hidden IP, a corporate network, or a well-instructed chatbot is sufficient security.

Security in this era turns on four questions: who gets in, what they can read, what they can change, and how we detect abuse.

The future need not be an archipelago of isolated intranets. It can be a connected internet with far better-defined trust boundaries.