Is the Internet Rekt?

A working private key sits on a public website, posted on purpose, daring anyone to drain the testnet wallet it controls.

Newton, the company that put it there, says the key alone can't move the funds.

Then came October’s security headlines: Critical flaws in PHP; a certificate authority caught generating keys a laptop could guess; a hosting provider telling all customers to rotate stored secrets as a precaution; and an AI lab reporting working exploit chains against browsers and operating systems.

Line those headlines up and it looks like the moment the internet finally died.

Read them one at a time and the picture breaks apart: Separate failures, demonstrated exploitation, withdrawn claims of PHP2Shell exploitation, and open questions about who actually got compromised.

The vulnerabilities are real. An internet-wide catastrophe is a different claim.

For crypto, the harder question is what those failures let an attacker do.

A stolen private key should not have to mean stolen funds.

But once the key is exposed, what still stops the money from moving?

Government websites and commercial services went offline as a precaution, while officials were still reporting no confirmed successful exploitation.

The trigger was PHP2Shell: Two flaws in PHP. Both scored 9.2 out of 10. Both could let an attacker run code on an affected server without logging in. PHP shipped emergency patches on October 21, and the NSA advised taking systems offline if they could not be updated immediately.

Around the release, governments and businesses took services offline as a precaution: The Netherlands pulled DigiD and MijnOverheid, France took prefecture sites down, and Japanese banks and airlines suspended apps and online services.

In the first days, public evidence of successful exploitation lagged behind the alarm.

Cloudflare watched exploit attempts climb from thousands to millions within hours.

Germany's cyber agency said it saw the attacks and not one success, and said the bug was proving harder to weaponize than its own planners had braced for.

Attempts are strangers rattling doorknobs. They are not strangers inside the house.

On October 24, one researcher recorded something more than rattling.

Adel Ka, who leads detection and response at Perplexity, had been running honeypots built around PHP. His initial report logged out-of-memory errors and worker crashes, but no confirmed code execution.

On October 24, his sensors recorded thirty-five shell processes launched by Apache workers, following requests from two IP addresses across three honeypots.

These were deliberately favorable targets: PHP 8.4.26 under Apache mod_php with a single worker. Adel Ka cautioned that the results did not measure exploit reliability against other builds, worker counts or applications.

Trail of Bits had already reported a working exploit against an unmodified MediaWiki, and Marcus Hutchins called Adel Ka's capture “the highest quality confirmation of in-the-wild php2shell exploitation” he had seen so far.

On October 26, CISA added both bugs to its Known Exploited Vulnerabilities Catalog and urged organizations to patch immediately.

So the exploit works. Who it hit is a different question.

Two prominent claims of PHP2Shell exploitation were later withdrawn or corrected, and they failed in different ways.

Palo Alto Networks’ Unit 42 initially linked post-compromise activity at a European government agency to PHP2Shell because the attack occurred in the context of a vulnerable PHP application.

In an October 25 correction, it withdrew that attribution, saying it could not confirm that the specific PHP2Shell vulnerabilities had provided initial access.

Sophos corrected a separate report on October 22, saying its customer telemetry showed scanning and a small number of failed exploitation attempts rather than the successful compromise it had initially reported.

By October 29, a separate campaign had been confirmed.

Unit 42 reported active exploitation against internet-exposed PAN-OS management interfaces, saying it had independently verified attackers’ tooling that chained PHP2Shell with a Linux kernel vulnerability to gain root access.

Sophos acknowledged the campaign, while cautioning that it did not demonstrate a capability for broad exploitation on other platforms.

The exploits work, and some deployments have been compromised. The full extent remains unclear. Those distinctions matter when a targeted attack becomes a headline about the whole internet.

The same scrutiny belongs to AI's role. Researchers credited models with helping find the flaws and turn them into working exploits.

But what did the machines contribute, and what still depended on the people directing them?

A Decade in a Day

Trail of Bits CEO Dan Guido said the firm had a working PHP2Shell exploit that got a shell on an unmodified MediaWiki installation.

In a follow-up, he credited Will Tan with building it in one day using Codex, drawing on roughly ten years of systems security and vulnerability research.

Human direction mattered in the discovery, too.

OpenAI credits Calif with identifying a critical flaw using GPT-5.6 Sol through its Patch the Planet initiative, and says Wiz independently discovered and reported both vulnerabilities.

Wiz says it used Wiz Atlas, Google’s Gemini 4 Argon and GPT-5.6 Sol throughout its research.

Calif Research’s own account shows the collaboration behind the discovery. Researcher Ryan Austin started from PHP’s history of memory-limit vulnerabilities and asked the model to help investigate whether related bugs remained.

During a source review the researchers requested, the agent noticed that PHP made a new table entry visible to teardown before fully initializing it. If the subsequent key allocation triggered a fatal error, teardown could consume stale allocation bytes as a live entry.

After the initial finding, the researchers “had the LLM generalize the pattern” from “count before key allocation” into a reusable search pattern. “The skill and pattern knowledge brought us a new finding in Session upload-progress, that confirms we discovered something more than a one-off flaw.” Austin writes.

Austin says models do not reliably begin with obscure, decades-old exploitation techniques; a researcher’s knowledge of the target’s vulnerability history helps direct them there.

Austin’s takeaway: “Know your target.”

The history reached back beyond this investigation.

The PHP Foundation says a core developer it contracted found early signs of the out-of-memory problem behind CVE-2026-109618 while fixing an issue identified by Quarkslab’s 2024 audit.

A potential exploit was theorized in 2024, but no concrete attack vectors were found. Competing approaches risked breaking backward compatibility, introducing denial-of-service vulnerabilities or requiring changes to many third-party extensions. Work on a fix stalled and restarted repeatedly over months.

The Foundation calls the delay a “structural failure,” caused by both the PHP security team’s decision-making process and its lack of resources.

So the machines did real work, and they did not do it alone. The record shows a division of labor: Older research, a human choosing where to dig, a model finding and generalizing, and an expert turning the find into something that fires.

Wiz's "70% of the Internet" framing rests on its claim about PHP's share of websites, not a measured count of exploitable deployments.

Its own writeup explains that differences in PHP versions, configurations and application behavior can break an exploit’s assumptions. An attack that works against one deployment may need substantial adjustments to work against another.

As highlighted in News or Hype?, PHP’s share of websites is not a count of exploitable deployments. The flaws were serious on their own; the headline made their reach sound more certain than the evidence allowed.

A power drill works faster than a screwdriver. It does not decide where the hole belongs.

But what if the drill could decide where to drill, too?

Anthropic makes that stronger claim, saying its model found critical flaws across browsers and operating systems and chained them into working exploits with little human help.

How much can be checked beyond the lab’s own word?

The Lab's Own Word

On October 27, Anthropic reported that an unreleased internal research model had found critical vulnerabilities in widely used browsers and operating systems.

It described five attack chains across Chrome, Safari, Android, Windows and Linux, ranging from data theft and remote crashes to code execution.

The company said models could now produce working exploits "with little human involvement."

Parts of that account have outside confirmation. Anthropic says its Chrome research produced 62 CVEs, all patched by Chrome 156.

Google’s release notes credit several findings to an Anthropic researcher “assisted by Claude.”

For the Safari research, Apple’s security advisory credits Anthropic researchers “with Claude” for a patched WebKit vulnerability.

Those vendor records confirm individual vulnerabilities and fixes, not the complete exploit chains or how independently the model built them.

The broader claims remain Anthropic’s account. The company describes the model as “an unreleased, internal research model” but does not identify it by name.

The October report also draws on vulnerabilities patched earlier. Apple's cited WebKit fix appeared in a June 29 update; Anthropic describes research conducted "over the past few months."

In describing its broader research process, Anthropic outlines parallel scanning agents and a standardized verification pipeline.

For Windows, Anthropic says it gave Claude a copy of the executable and asked it to reverse-engineer the software using tools such as Ghidra, write “a fully annotated C program that reproduces the relevant features,” compare the reproduction’s behavior against the binary to check correctness, and then study the code for vulnerabilities. When the researchers asked Claude to identify “potentially higher-risk issues,” it surfaced the remotely exploitable denial-of-service vulnerability.

The report does not say how much human help, how many failed attempts or how much computing power went into each attack chain.

The report ends by promoting expanded model access through Anthropic's Cyber Verification Program, offering advanced cyber capabilities to qualifying security professionals.

The company making the claim also sells access to the models.

That distinction matters when research results become claims about what AI can now do.

Those broader claims remain Anthropic's account.

The next question is not who built the exploit, but what limits the damage once it works.

For crypto, a stolen secret can turn an internet breach into missing money.

Once a signing key gets out, what still stops the transfer?

No Math Was Broken

One certificate authority generated a private key whose value was four.

Scott Helme recovered all eight eMudhra intermediate CA private keys from their public certificates on his laptop in under a second. Every value was below 256.

In its preliminary account, eMudhra said a script flaw appeared to have created weaker keys during its April 30, 2025 key-generation ceremony. Those keys were mistakenly used to create certificate-signing requests because their labels were similar to the intended keys’ labels.

Firefox blocked the affected certificates, and Chrome blocked the six affected TLS intermediates. Mozilla also removed the signing root from its NSS trust store, while Chrome announced plans to remove it from the Chrome Root Store.

eMudhra announced on October 22 that its board had decided to withdraw from the global SSL/TLS certificate business, saying no end-entity certificates had been issued by the affected CAs.

That left a separate question: Had anyone used the weak keys to forge certificates?

India’s Computer Emergency Response Team, CERT-In, said the public disclosures it cited did not establish confirmed malicious exploitation as of October 21. That was not proof that none had occurred.

Weak key generation was not the only failure.

PingCAP said an attacker used a compromised GitHub account and exposed credentials to access its internal systems between September 9 and October 7, copying source code and customer-related records.

PingCAP said the exported TiDB Cloud API-key values were encrypted and the encryption key was not exposed. But it warned customers to replace any credentials or keys they had sent to its support team.

At Railway, encryption offered no protection once the attacker obtained credentials that allowed decryption.

Railway, a cloud platform for hosting applications and databases, disclosed a security incident on October 21. Its preliminary report said the attacker accessed encrypted customer environment variables, “of which a subset were decrypted utilizing a combination of the compromised credentials.”

Railway said “at most 1.85% of all workspaces had some environment variables potentially compromised”, about 100,000 workspaces. It invalidated user sessions, rotated credentials and worked with providers including GitHub, OpenAI, Anthropic and Stripe to revoke potentially compromised keys.

Blockchain investigator Taylor Monahan linked approximately $371,000 in crypto drains across at least 19 EVM-compatible chains to keys stored on Railway.

Railway’s incident report, including its October 26 update, did not confirm those crypto losses or their connection to the breach.

None of these accounts establishes a break in elliptic-curve cryptography. Justin Drake's "months, not years" warning, examined in News or Hype?, was a speculative worst-case scenario, not a demonstrated attack.

The failures described here concern weak key generation, compromised credentials and systems that let an attacker reach and decrypt stored secrets.

The math held. The handling didn't.

Where a single signing key is enough to authorize a transfer, stealing it can be enough to move the funds. A signature can pass verification without the owner approving the transaction.

The harder question is how to make authorization survive the loss of a key.

So what happens when a company builds exactly that, and publishes the key to prove it?

Where the Trust Goes

To explore where that additional authority sits, and what happens when it fails, we interviewed Dennis Won, co-founder and CTO of Newton Labs (formerly Magic Labs), for this piece.

Won argued that the key-equals-security model is the thing that has to go.

Newton Labs put that idea into practice by deliberately publishing an owner signing key for a Safe smart-contract wallet and inviting readers to try it.

The demonstration uses test USDC on Sepolia, an Ethereum test network - test tokens, not USDC redeemable for dollars.

Newton’s claim is that the owner key remains necessary, but is no longer sufficient to move the funds.

The wallet is deployed here:
0x79a726e58FA5851a83Cf934d27fE1bdde4F0885e.

The distinction is between signing and authorization: A valid signature need not be the final permission to spend.

Newton says a guard blocks every ordinary owner transaction, leaving a single approved path for USDC transfers capped at 10 USDC each.

That path requires more than the owner’s signature: Each transfer also needs a time-based one-time password, or TOTP - the six-digit code generated by an authenticator app.

Newton says its check binds approval to the recipient, amount and individual transfer attempt, rejecting missing, incorrect, expired or reused codes.

Newton says it runs the check and that “the secret that generates the codes never leaves Newton’s environment.” If the request passes, Newton signs an approval; the wallet verifies that approval, and only then does the USDC move.

If the published owner key is not enough to move the funds, what else must an attacker compromise?

The security question shifts to Newton’s approval process: Who controls it, what protects it and what happens if it fails.

The authenticator code is one possible policy condition. Newton also describes spending limits, another person’s approval, device checks or risk scores. The question is who sets those conditions, who can change them and which decisions remain with applications and their users.

The aim is to prevent a stolen signing key from being enough, on its own, to move the funds. The attacker would also have to satisfy, or bypass, the policy’s additional approval requirements.

The question then becomes who sets those permissions, who can change them and which decisions remain with the application or its users.

The demonstration was published on September 24, before the incidents described in the above sections.

But it addresses the question those breaches make urgent: What stops an attacker once they have the key?

Won argued that something is missing when possession of a key leads straight to settlement. He pointed to two-factor authentication, already routine in web services, as an example of the additional authorization step he believes crypto needs.

Won’s recommendations extended beyond adding another check. He called for separating the roles that change configuration from those that withdraw funds, limiting the damage a single compromise can cause, and using timelocks where user funds are involved.

He acknowledged that delays hurt the user experience and are not a complete defense.

Administrators remain a risk. When asked about that explicitly, Won agreed: Systems assume administrators are honest, and that assumption can fail.

His answer was to improve operational security and separate permissions so that one compromised role cannot do everything.

Newton also makes its own trust choices. Won said its operator network is permissioned and publicly vetted, with a strict onboarding process rather than anonymous, permissionless participation.

Adding an approval layer does not remove trust. It redistributes authority, and the risk depends on how much any one key, administrator or operator can control.

That leads to another question: Who writes the rules?

Won distinguished Newton’s protocol governance from the individual policies governed by applications and their users.

We compared that division of authority to the Tenth Amendment and the different laws adopted by individual US states: A shared framework, but not one rulebook for every application.

Won agreed with the comparison, then described a separate way to challenge a policy decision.

In his example, a user could use a zero-knowledge proof to show they met a policy’s eligibility conditions without revealing the underlying private information. He said the challenge and its resolution would happen onchain.

That would contest whether the user satisfied the rule, not give them permission to rewrite it.

The eMudhra, PingCAP and Railway incidents examined in the earlier sections exposed different failures in how keys and credentials were generated, stored and protected.

Won described why those failures become especially dangerous when Web 2 infrastructure holds Web 3 signing keys: Where a valid signature is sufficient to authorize spending, an attacker who steals a signing key from a server or deployment pipeline can move funds without another approval standing in the way.

Newton’s demo addresses that gap between signing and settlement. It is one approach to limiting what a stolen key can authorize, not proof that the breaches above would have been prevented.

Protecting the key still matters. But stealing it should not be enough to move the funds.

So after a month of patches, retractions and leaked secrets, is the internet actually rekt?

Mostly, No

Start with what is confirmed.

PHP2Shell produced working exploitation against honeypots, and CISA added the vulnerabilities to its Known Exploited Vulnerabilities catalog on October 26.

The catalog listed an October 29 remediation due date for Federal Civilian Executive Branch agencies.

That was real, and it was fast.

The production toll remains uncertain. Sophos and Palo Alto Networks' Unit 42 retracted early exploitation assessments they could not substantiate.

Separately, Dream researchers reported a campaign that chained PHP2Shell with a Linux kernel exploit to compromise 25 servers. That report describes a specific campaign, not the overall scale of compromise.

For a continuing view of patch adoption, Infrawatch’s PHP2Shell Patch Uptake Tracker tracks hosts that expose a PHP version. It measures visible patch uptake, not successful exploitation.

AI-assisted research produced real vulnerabilities. But finding a bug, developing a working exploit and demonstrating largely autonomous discovery across multiple products are different claims. Evidence for one does not establish the others.

The key and credential incidents examined earlier did not demonstrate broken cryptography.

They exposed failures in key generation, access control and secret handling. The math was not what failed. The handling was.

Some visible disruption came from the response itself: Organizations took websites offline while assessing exposure and applying patches.

Those precautionary outages should not be counted as successful attacker takedowns.

So, is the internet rekt?

No, not in the sweeping sense the headlines suggested.

The vulnerabilities were serious, exploitation was real, and the full damage remained uncertain.

Those facts do not require a story about cryptography collapsing or every exposed system being breached.

So if the internet isn't rekt, what actually broke?

What broke this month wasn't the internet; it was a handful of old assumptions: that a secret stays secret, that holding a key means the right to use it, that a flaw gets patched before someone exploits it.

AI didn't rewrite those rules. It accelerated parts of the work without removing the need to verify the results.

The threat was real. The scale was less certain than the headlines made it sound.

A working exploit is news; treating every vulnerable system as a confirmed victim is hype.

Neither the early retractions nor the later compromise reports justify dismissing the danger, or declaring an internet-wide collapse.

The most directly exposed are organizations running vulnerable services or systems where a stolen credential grants far-reaching access. Their users can bear the consequences through exposed information, disrupted access or compromised accounts.

You do not have to operate the vulnerable server to depend on it.

For crypto, that dependency can reach directly into the wallet. When conventional servers and deployment systems hold signing keys, their security failures can become authorization failures onchain.

Where a valid signature is enough to spend, an attacker does not need to break the cryptography. They just need to reach the key.

Additional authorization layers, Newton's among them, try to interrupt that path. They can limit what a stolen key can do, but they also place authority in another approval system, an operator network or whoever can rewrite the policy.

That can be progress if it limits what an attacker can do through a single compromise.

But relocation is not removal. Trust doesn't vanish from these systems; it changes hands.

The next headline deserves the same scrutiny. What was demonstrated? What can be independently verified? Where does the framing outrun the evidence, and who benefits from the alarm?

So when the next wave hits, will you examine the evidence, or repeat the claims amplified around it?

REKT sirve como plataforma pública para autores anónimos, nos deslindamos de la responsabilidad por las opiniones y contenidos alojados en REKT.

dona (ETH / ERC20): 0x3C5c2F4bCeC51a36494682f91Dbc6cA7c63B514C

aviso legal:

REKT no es responsable ni culpable de ninguna manera por cualquier Contenido publicado en nuestro Sitio Web o en conexión con nuestros Servicios, sin importar si fueron publicados o causados por Autores ANÓN de nuestro Sitio Web, o por REKT. Aunque determinamos reglas para la conducta y publicaciones de los Autores ANÓN, no controlamos y no somos responsables por cualquier contenido ofensivo, inapropiado, obsceno, ilegal o de cualquier forma objetable, que se pudiera encontrar en nuestro Sitio Web o Servicios. REKT no es responsable por la conducta, en línea o fuera de línea, de cualquier usuario de nuestro Sitio Web o Servicios.