At 9:55 p.m. Tokyo time on October 21, Japanese Prime Minister Sanae Takaichi posted on X with an urgent request for that night. She asked website operators to check whether they were using PHP and be ready to update immediately after a patch came out at 11:00 p.m.; if they could not update right away, she added, “temporarily suspending websites and other services is also an effective measure.” According to a zakzak headline, the post drew more than 20 million views within two hours. Organizations including BASE, Cygames, pixiv, NicoNico, Shizuoka Bank, and Hankyu Railway took their services offline as a precaution that night.
This did not come out of nowhere. The underlying flaw had been filed as an ordinary software bug as early as 2020, and a 2024 security audit flagged the same issue again, but because no working exploit was demonstrated, a fix was shelved for another two years. That changed in 2026: with AI assistance, Calif began auditing PHP on July 30, reported the vulnerability on August 11, and delivered a working proof-of-concept for remote code execution on August 14.
Two other stories broke in the same week: Claroc queried a commercial passive DNS history database and found more than 6,800 denoised Muse share hostnames, prompting Meta to say it had paused the sharing feature while reviewing the report; and Anthropic released experimental results for scorpion-toxin-binding proteins designed with Claude, where 17 out of 211 tested designs bound to toxins and 0 were shown to neutralize toxicity. Let’s look at each of the three in turn.
What prompted the Japanese Prime Minister’s late-night post was a
pair of remote code execution vulnerabilities patched in the PHP core
that same day. The root cause lies in how PHP manages memory when
handling an individual request. PHP sets aside a separate memory arena
for each incoming web request and reclaims it all at once when the
request ends. The memory_limit configuration setting caps
the maximum memory a single request is allowed to use. Once a request
exceeds that cap during memory allocation, the engine abruptly aborts
the current flow, leaving part of the shutdown cleanup code unfinished.
In production environments, the worker handling requests is
a long-lived background process that loops through incoming jobs rather
than exiting after each request. When the same worker
immediately picks up the next request, it may treat partially
initialized structures or already-freed memory from the previous request
as valid state and continue reading from or writing to them. The two
patched vulnerabilities share this root cause and differ only slightly
in where they are triggered. CVE-2026-109618 occurs during request
startup, when the engine aborts over the memory limit while parsing
multipart form data and initializing internal tables, and the shutdown
logic treats half-built structures as valid state. CVE-2026-109619
occurs when global state fails to reset after a fatal error in a
previous request, causing the subsequent request to read leftover
dangling state before initialization completes. An attacker only needs
to send specially crafted multipart requests to trigger this process.
Under the default configuration of Apache mod_php (an older
deployment model that embeds PHP directly inside Apache), the attack can
succeed before any application code runs; under the more common
PHP-FPM architecture (where PHP runs as an independent
process pool behind a web server), exploitation needs to be paired with
session handling or deserialization paths during application execution.
In its technical report, the
security firm Calif used this mechanism to demonstrate unauthenticated
remote code execution across 11 popular applications, including
WordPress, Drupal, and Joomla.
Remote vulnerabilities around PHP’s memory_limit were
studied publicly as early as 2004, and the same class of hazard behind
this incident had surfaced years ago as well. In 2020, someone filed bug
report #78876 in the PHP bug tracker pointing out that oversized
multipart variables could exhaust memory while leaving behind temporary
files that could not be cleaned up. At the time, maintainers treated it
as an ordinary software bug rather than a security issue. In 2024, the
Open Source Technology Improvement Fund (OSTIF) and Quarkslab conducted
a systematic security audit of the PHP core, identifying 27 issues in
total, of which 17 were security-related and 3 were rated high severity.
The audit report flagged the same memory-exhaustion hazard once again.
Because no one had produced reliable exploit code, however, and
refactoring the memory bailout path would affect compatibility and
runtime performance across many extensions, the fix was left on the
shelf. In its October 21 security
release announcement, the PHP Foundation acknowledged this as a
structural failure rooted in a past reliance on full consensus for
security decisions and a shortage of maintenance resources. The team has
since shifted security decisions to a majority vote and expanded its
ecosystem security team.
What changed the equation was a sharp drop in the cost of exploit development. Responding to an invitation from Patch the Planet, an initiative launched jointly by OpenAI and Trail of Bits on June 22, 2026, the security firm Calif began auditing PHP’s source code on July 30 and found its first path from memory exhaustion to remote code execution just two days later, on August 1. The Calif team reported the first vulnerability on August 11 and delivered working proof-of-concept code on August 14, which the PHP team confirmed on August 15; on August 21, the Calif team reported the second vulnerability. According to the PHP Foundation, OpenAI also independently reported the same root cause on August 11 and followed up with additional trigger vectors on September 18. Cloud security company Wiz disclosed in a research blog post that its team used Gemini 4 Argon and GPT-5.6 Sol to independently find the first vulnerability on August 19 and reported both flaws together on August 24. Explaining how they pieced together the initial exploit path, the Calif team noted that the original discovery used neither a specialized testing framework nor models unavailable to the public; instead, they used two decades of PHP vulnerability history as prompting direction to work out usable primitives from past records. Because the underlying flaw had already been documented in 2020 and 2024, this does not mean AI autonomously discovered an unknown vulnerability; what AI actually shortened was the engineering cycle required to turn an old, known hazard into a reliable exploit.
At 14:00 UTC on October 21, 2026, PHP officially released four
versions: 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Acting as the CVE
Numbering Authority (CNA), the official PHP project scored both
vulnerabilities at 9.2 under CVSS 4.0, marking them with high attack
complexity (AC:H) and attack requirements present (AT:P). The U.S.
National Vulnerability Database (NVD) separately assigned a 9.8 score
under CVSS 3.1 with low attack complexity (AC:L), while Red Hat rated
them 8.1 under CVSS 3.1 with a severity of Important for RHEL; the 10.0
score circulating in earlier forum leaks was untrue. The core fix commit
31c0ea7 modified 423 files, adding 11,556 lines and
deleting 1,017 lines of code. The change removed the forced jump on
memory exhaustion: a soft limit breach now records a pending error and
runs until a virtual machine safe point before exiting, while a hard
limit breach terminates the process immediately, accompanied by a new
memory_hard_limit_percent configuration option that
defaults to 200% and is capped at 1G. Although official upstream
releases only cover 8.2 through 8.5 (with 8.2 reaching end of life on
December 31, 2026), php.net provided minimal source backport patches for
the end-of-life 7.4, 8.0, and 8.1 branches, and Debian and Ubuntu also
backported fixes to older branches. According to W3Techs, PHP accounts
for 69.3% of websites whose server-side language is known, and the
roughly 70% figure cited by Wiz is a rounded version of that metric.
Scanning the global network by IP address rather than by website,
VirusTotal found roughly 5.1 million PHP IP addresses, of which 3.8
million had at least one open port; among IPs disclosing a version in
their banners, 758,000 were still running end-of-life branches such as
5.4 through 8.1, and 85,000 were running the latest pre-patch version
released on September 24. Based on open-source intelligence, Talos
initially estimated that roughly half of all PHP systems may never
receive the patch.
Before the patch actually landed, the disclosure process itself took several twists. At 15:00 UTC on October 20, the two reserved CVE numbers began circulating on forums along with an incorrect release time and an erroneous 10.0 score; at 19:30 UTC, the PHP team published a pre-announcement moving the release time forward from October 22 to 14:00 UTC on October 21. Around 20:00 UTC that evening, Calif accidentally posted a demo video, and copies continued to spread after it was deleted. At 02:29 UTC on October 21, VirusTotal received the first leaked exploit archive; at 03:02 UTC, Cloudflare enabled blocking rules by default for both free and paid Web Application Firewall (WAF) tiers; and at 07:41 UTC, Chainguard released patched container images 6 hours and 19 minutes early, a move CEO Dan Lorenc told The Record was a judgment call made after weighing the risks. Even so, as of October 21, the U.S. CISA Known Exploited Vulnerabilities (KEV) catalog had not included either CVE number and listed their exploitation status as none; in-the-wild exploitation attempts observed by watchTowr all failed, CISA and Talos saw no successful intrusions, and only Hadrian unilaterally claimed to have seen exploitation at scale. Tracing this long arc from public research in 2004, the bug filing in 2020, and the shelved audit in 2024 to going from the start of an audit to a working PoC in about two weeks in 2026 suggests that assessing real-world exploitation risk should also account for changes in the cost of attack development. Once models compress exploit development into roughly two weeks, what determines the outcome is the logistics layer of backporting patches, upgrading the long tail, and coordinating disclosure.
The second surprise happened on Muse, Meta’s personal AI assistant.
Muse launched in the United States on September 8, 2026, with support
for iOS, Android, and the muse.ai web interface. Its
sharing feature lets users publish a conversation or generated output as
a standalone web page; by design, anyone with the link can view it
directly. In theory, as long as a user has not posted the link on a
public web page or social media, no one else can see it. Under Meta’s
domain construction scheme, however, when the system generates a share
link of the form muse.ai/s/<title-slug>-<id>,
the page content is loaded not from the single host
muse.ai, but from a separate subdomain:
<title-slug>-<id>.cf.metaaiusercontent.com.
Every shared item has its own subdomain whose leftmost label is the
conversation title plus a random ID, such as
home-sale-budget-9f21c8a3.cf.metaaiusercontent.com. All of
these subdomains share the cf.metaaiusercontent.com suffix,
but each full hostname is distinct. As soon as a link holder visits the
link once in a browser, the browser must send a resolution request to
DNS to look up the IP address for that subdomain before loading the
page. As the resolution request passes through recursive resolvers (DNS
servers that query domain names step by step on a user’s behalf),
commercial passive DNS services running alongside them
record the domain lookup history, results, and timestamps. Such
databases do not record who made the request or store the body of the
web page, keeping only the hostname itself; yet because the leftmost
part of each hostname carries a human-readable conversation title, the
historical resolution database turns into a list searchable by
title.
Although the random ID at the end of the link uses base36 encoding—a
sample of 76 slugs showed lengths between 12 and 21 characters (mostly
13 to 17 characters), making brute-force enumeration infeasible—an
outside querier never needs to try, because the full hostnames are
already exposed in passive DNS databases. Likewise, a site’s root
robots.txt only governs crawling protocols for search
engine bots and cannot affect underlying domain resolution records, nor
did Claroc’s discovery rely on search engines. In its GhostShares
research report, the security research firm Claroc noted that it ran
a single passive DNS query against the content domain and, after
filtering out wildcard resolution noise (wildcard DNS causes any random
subdomain to resolve successfully, so such noise must be removed first),
obtained more than 6,800 share hostnames. Each hostname represents a
share link that was resolved at least once and observed by that
provider—not all shares ever created by users, and not 6,800 sensitive
documents. Claroc opened several hundred of the pages and found six
categories of sensitive content, including a candidate’s notes preparing
for an executive interview at an AI lab (with internal contacts and
meeting times), a marketing agency’s revenue review, loan applications,
bank fraud alerts, real-estate return-on-investment calculations, and an
all-hands vacation schedule. The public platform urlscan held 83 records
of shared pages, and the Wayback Machine had stored 40 hostnames.
Claroc reported the vulnerability through Meta’s bug bounty program
on October 8 and published its research on October 18; in an October 20
article, Ars Technica quoted a Meta statement saying that it had paused
the sharing feature and was evaluating how to adjust the way links are
discovered. When Claroc retested 40 share links on October 20 that had
opened earlier in the month, none of the pages would load; another check
on October 21 showed the content host returning 503, while the Meta AI
help page still stated that links do not expire and can continue to be
forwarded, though that help page is not specific to Muse. Compare this
with two similar incidents in 2025: ChatGPT had more than 4,500 share
links indexed on Google because sharing included an extra toggle to
allow search engine indexing, while Grok had more than 370,000
conversations indexed on Google because clicking share made them public
by default without warning. In both of those cases, the discovery
channel was at the search engine index level, where noindex
directives or de-indexing requests can restrict subsequent discovery,
even though they cannot retract copies that have already spread. Muse
had no search toggle and its pages were originally visible only to link
holders, yet by putting titles into subdomains that inevitably triggered
DNS resolution, it wrote records into third-party DNS history
databases—and taking down the pages is not the same as clearing those
historical records.
Whether an identifier goes into a URL path or a subdomain is not just
a routing choice; it also determines whether that name enters public
resolution logs. A high-entropy random string prevents blind guessing,
but it cannot stop public logging by the channel itself; once a
human-readable title is mixed in, traffic logs become a searchable
directory. Not being able to guess a link, not being able to find a link
via search engines, and unauthorized users not being able to see the
content are three completely separate things. Being
unlisted (not publicly listed, accessible only to link
holders) is only a distribution policy and cannot replace access
control, because what users consented to was visibility for link
holders, not public indexing. Fixing this requires first stopping link
creation, then revoking old links, changing subdomain naming, and
finally adding access controls and auditing—for instance, setting a
48-hour expiration like Duck.ai and hiding the key in the URL fragment
(the part of a URL after #, which browsers generally do not
send to the server).
The third thread comes from computational biology: Anthropic published its scorpion-toxin binder research page, technical report, and open Hugging Face dataset. Traditional antivenom has to be produced by extracting antibodies from the blood of immunized horses, a process measured in months that offers narrow coverage and is prone to allergic reactions. Neurotoxins in scorpion venom bind to sodium channels on the surface of human cells, disrupting electrical signals in nerves and muscles; instead of using large traditional antibodies, this study designed minibinder proteins aimed at blocking the sites where toxins contact sodium channels. The research question, the five toxin targets, the design cohorts, and the safety rules were all set in advance by humans; within that framework, Claude called protein-design and folding tools, choosing binding hotspots, setting filtering thresholds, and combining tools on its own. Within 64 hours, the system generated 318,484 designs and filtered out 180; the team and Claude then added 31 more, sending a total of 211 designs to two laboratories by day 9.
Roughly two months later, the two laboratories used SPR (an optical method that immobilizes molecules on a chip to see whether they bind) to test whether the designs stuck to the toxins. In the end, 17 designs met the authors’ four composite criteria, with 15 passing tests across both laboratories and 2 LqhIII binders tested only by Adaptyv; 0 were confirmed to neutralize scorpion venom. Out of the total sent for testing, the overall hit rate was 8.1% (17/211), but there was a wide gap between that overall average and the hardest subset: subsets targeting a single toxin had an 18% hit rate, whereas in the high-difficulty subset aimed at binding all five toxins simultaneously, only 1/91 became a binder, and it bound only to AaH I. Sticking to a toxin is also not the same as neutralizing venom. Binding is molecular adhesion on a chip, whereas neutralization requires actually stopping the toxin from disrupting living cells. This round of experiments did not include cell, animal, stability, immunogenicity, or manufacturing tests, and Anthropic explicitly stated that it had not produced an antivenom.
Even looking only at those 17 binding results, the four composite binding criteria used to judge hits were defined after the experimental data came back rather than pre-registered; the technical report was not peer-reviewed, and as of October 21, 2026, no independent public replication had been found. The project was jointly designed and funded by Anthropic and the investment research firm Citrini, whose article also recommended related stocks. The most solid part of the entire study is that it published the data openly on Hugging Face for outside verification. Putting the time and cost of the two stages side by side, generating 318,484 candidate designs and filtering out 180 took just 64 hours, whereas wet-lab experiments took roughly two months to identify 17 binding starting points; by Citrini’s own account, design and screening compute cost about $50,000 and wet-lab testing cost about $150,000, suggesting that in this project, wet-lab validation took longer and cost more than the initial design screening.
Put the three stories side by side: a PHP flaw sat shelved for two years before going from the start of an audit to a working PoC in about two weeks, shifting the pressure onto patching and disclosure coordination; Muse’s share pages put conversation titles into subdomains, leaving records in third-party DNS history that may persist indefinitely; and Anthropic generated 318,000 designs in 64 hours, while two months of wet-lab experiments yielded 17 binders and 0 antivenoms—whether on the front end a model is compressing the cost of generating exploits and candidate proteins, or an AI product is turning conversations into one-click shared web pages, what determines the outcome is not the generation step itself, but the downstream systems that receive the output.
The three threads ran into three different boundaries: PHP’s boundary is the logistics of patching and disclosure, Muse’s boundary is identifiers and access control, and protein design’s boundary is wet-lab validation and druggability. Models have compressed the generation end, but they have not changed the shape of those three downstream ends; verification, distribution, and control still determine where the results stop.