DEV Community: Simon Paxton

Rust Removed a Poisoned Arrayref Release After 86 Minutes Online

Simon Paxton — Thu, 20 Aug 2026 19:28:29 +0000

Rust removed a malicious arrayref@0.3.10 release on August 20, 2026, after it was available on crates.io for 86 minutes. The release made projects pull in a dependency whose build script downloaded a malicious payload, putting developer laptops and CI runners—not only shipped binaries—on the exposure path.

The incident was wider than one poisoned package. The Rust Security Response Team says a likely compromise of the arrayref author’s computer or credentials also led to malicious releases of append-only-vec@0.1.9 and internment@0.8.7, plus six newly created crates designed to look like ordinary dependencies. Existing projects with committed Cargo.lock files would not ordinarily have auto-upgraded into the malicious versions.

Rust said it received a report at 07:15 UTC from Nextron Systems GmbH, a German security vendor, that proc-macro1 was malicious. The team verified that the crate contained a build script that downloaded a payload, then deleted it alongside proc-macro-en, aovine, arone, aronenao, and tinymember.

“The Rust Security Response Team verified this to be the case: the crate had a build script that was downloading a malicious payload.”

The Rust team attributed that finding to its August 20 incident disclosure. That disclosure is also the only technical incident account cited here; it does not establish what the payload did, how many machines ran it, who controlled it, or whether any victim was compromised.

Cargo build scripts are executable code that runs during a build. When a package includes a build.rs file, Cargo compiles and executes it before compiling the rest of that package. In this case, a developer or CI job that fetched and built a poisoned dependency could have run the downloader simply by performing a normal dependency build.

That makes the immediate response an environment investigation: inspect Cargo.lock files and dependency graphs, review CI logs from the incident window, and search local Cargo caches for the exact three deleted versions or any version of the six malicious lookalike crates. Teams responding to the poisoned VS Code extension exposure faced a similar distinction between a compromised package being available and a particular machine actually installing it.

The three malicious crate releases were online for 86 to 107 minutes

The three established crates had short but meaningful availability windows:

Malicious release	Time online
`arrayref@0.3.10`	86 minutes
`internment@0.8.7`	90 minutes
`append-only-vec@0.1.9`	107 minutes

Rust also said the attacker had maliciously yanked earlier legitimate releases, which the response team restored. A yank removes a version from Cargo’s registry index for fresh dependency resolution, but it does not erase the downloadable package archive or copies already in local caches, as the Cargo documentation explains.

The yanks could therefore have made a fresh dependency solve more likely to choose a newer attacker-controlled version. Cargo generally prefers the highest compatible version available. But Rust’s disclosure does not establish that this was the attacker’s intent or identify a project whose resolution changed because of the yanks.

A committed lockfile is the practical dividing line. Cargo stores a dependency resolution in Cargo.lock, keeping selected versions fixed over time. Cargo’s own yank documentation says yanked releases are not selected for a new checkout without an existing lockfile, while existing lockfiles and direct downloads are unaffected.

So this was not an emergency for every Rust project using arrayref. It was an emergency for projects that generated or refreshed a lockfile, ran an unlocked build, or otherwise downloaded one of the affected releases between publication and removal. Claims that identify arrayref@0.6.7 as the poisoned release conflict with Rust’s official record, which names arrayref@0.3.10.

The incident also offers a reason to treat dependency age as a security control rather than an inconvenience. Cargo’s min-publish-age option could hold newly published packages out of fresh resolutions; the tracking issue says -Zmin-publish-age was available only on nightly as of June 21, 2026, with stabilization work unresolved. A delay can require exceptions when a security fix is urgent, but it would have excluded releases published minutes earlier.

Rust has locked the affected account as a precaution and said it did not believe the arrayref author acted maliciously. The containment work removed the malicious registry entries; the harder job for engineering teams is determining whether an 86-minute package release ever reached a machine that was allowed to build it.

Key Takeaways

Rust deleted arrayref@0.3.10 after the malicious release was online for 86 minutes.
The same account also published poisoned versions of append-only-vec and internment.
The malicious dependency used a Cargo build script to download a payload during package builds.
Existing builds with committed Cargo.lock files would not ordinarily select the new malicious versions.
Teams should inspect lockfiles, dependency graphs, CI logs, and local Cargo caches for the affected releases.

Israel’s $900,000 US PR Pilot Targets AI Citations, Not Proven Chatbots

Simon Paxton — Tue, 18 Aug 2026 19:25:57 +0000

Israel’s Government Advertising Agency funded a $900,000 U.S. digital-communications pilot that uses a firm to market content designed to earn citations from AI search tools. The public record supports an effort to shape what models retrieve and cite—not a claim that the Hanover Institute has poisoned model training data or changed ChatGPT’s answers.

The relevant organization is the Hanover Institute for Public Policy, a think-tank-styled research publisher focused on antisemitism in the United States. Hanover publicly says its material is distributed by Piro for Havas Media Germany, acting for Israel’s Government Advertising Agency, LaPam, under the Foreign Agents Registration Act registration number 7732.

That disclosure complicates the claim that Israel secretly created a fake think tank to manipulate chatbots. Hanover does not present itself as independent, nonpartisan, or neutral. But transparency about funding does not settle the more technical question: whether its articles have entered a training corpus, been retrieved by a chatbot, or altered a model’s answer. The available evidence does not show any of those things.

The $900,000 LaPam–Piro Digital Storytelling Pilot

Piro, Inc.’s June 2, 2026 FARA filing records an April 30 agreement with Havas Media Germany on behalf of LaPam, Israel’s government advertising agency. The stated job is strategic communications and media relations “in connection with LaPam’s engagement on behalf of the State of Israel,” with activities intended to influence the U.S. public.

The filing identifies a $900,000 pilot budget. It assigns $190,000 to strategy and content development, $80,000 to production oversight, $400,000 to production costs, $95,000 to distribution advisory and evaluation, $35,000 to media consultation, and $100,000 to measurement and analytics. Production therefore accounts for about 44% of the total budget, based on the filing’s $400,000 production allocation divided by its $900,000 total.

O’Dwyer’s, an independent PR trade publication, described the engagement as a U.S. program for digital content strategy, creative development, video-production oversight, distribution planning, performance analysis, and final evaluation. It reported that the content was intended for U.S. digital and social-media platforms.

The FARA document does not name the Hanover Institute. It also does not list chatbot manipulation, model training, or data poisoning as the work order’s objective. Its purpose is more conventional, if technologically updated: paid communications aimed at American public opinion.

Hanover’s own funding page says the Institute existed before the LaPam arrangement, and says the funder does not select research topics, see drafts, review findings, or approve publications. That is Hanover’s account of the funding arrangement, not an independent audit of its editorial process.

“That registration is why this site does not call itself independent, nonpartisan or neutral.”

— The Hanover Institute

The important distinction is not whether the site resembles an institution. It does. The question is whether it hides its sponsor or has demonstrably influenced AI systems. On the first point, the site supplies unusually direct disclosure. On the second, the evidence has not arrived.

Piro’s AI-citation pitch is real

Piro’s own AI Story Optimization marketing page describes the machinery that makes this more than an ordinary public-relations campaign. The company says it maps “every surface the models read,” including Reddit threads, YouTube transcripts, publisher pages, forums, reviews, and comparison sites.

It then says it authors content “engineered for how LLMs evaluate credibility,” deploys it on clients’ sites or third-party properties, and tracks whether the content remains “the answer.” Generative engine optimization, or GEO, is the emerging practice of making material more likely to appear in answers generated by AI search and chat systems.

“The engineering gets you cited. The story makes you chosen.”

— Piro’s AI Story Optimization page

That is a plain statement of commercial intent: Piro is selling ways to influence the sources an AI system finds credible enough to cite. Its page even claims that, in “neutral tests,” content it produced was cited by ChatGPT and Perplexity. But this is Piro’s marketing for its own service, not a Hanover-specific test, and it does not identify Hanover as a client for that product.

There is also a technical boundary worth keeping intact. Retrieval-based AI products may search the live web and cite pages at answer time. Training is a separate process in which model developers ingest large datasets before deployment. A page can be indexed without being in a model’s training data; it can also be in a web crawl without ever being retrieved for a particular answer.

The separate Clock Tower evidence

Reporting that Israel-linked websites have reached AI systems concerns a different operation: Clock Tower X, run by former Trump campaign manager Brad Parscale. That earlier contract explicitly described deploying websites and content to produce “GPT framing results on GPT conversations,” according to Responsible Statecraft.

Drop Site News reported in July 2026 that 10 Clock Tower sites were crawled 912 times by Common Crawl between January and June 2026. It also reported tests in which some Clock Tower material appeared in citations from systems including Perplexity and Microsoft Copilot.

Those findings concern Clock Tower’s distinct network, not Hanover. Common Crawl inclusion is not proof that any particular model trained on the material, and a chatbot citation in one query is not proof of a persistent model-level political change. The Clock Tower reporting may be evidence that state-backed content can reach AI-adjacent infrastructure. It is not evidence that Hanover has done so.

The broader security concern is still legitimate. In 2025, researchers from Anthropic, the UK AI Security Institute, and the Alan Turing Institute found that 250 malicious documents could backdoor models ranging from 600 million to 13 billion parameters. Their experiment inserted a trigger that made a model produce gibberish—a narrow denial-of-service behavior.

That result does not demonstrate political persuasion, favorable retrieval ranking, or a real-world advocacy campaign changing an AI answer. It does show why provenance controls matter: training and retrieval systems cannot treat every polished institutional-looking page as equally trustworthy.

The Hanover episode is therefore not a demonstrated chatbot-poisoning case. It is a disclosed foreign-government communications pilot paired with a vendor explicitly selling AI-citation optimization—and that is enough reason to inspect how AI systems decide which web sources deserve a voice.

Key Takeaways

Israel’s Government Advertising Agency, LaPam, funded a $900,000 U.S. communications pilot through Havas Media Germany and Piro.
Piro’s FARA filing describes communications intended to influence the U.S. public, not chatbot manipulation.
The Hanover Institute publicly identifies Piro, Havas Media Germany, LaPam, and FARA registration 7732 as part of its distribution arrangement.
Piro markets a service designed to improve how content is retrieved and cited by AI systems.
Evidence of chatbot citations and Common Crawl activity concerns Clock Tower X’s separate network, not Hanover.

Thames Water’s Drought Plant Had Water to Treat. Not Membranes.

Simon Paxton — Mon, 17 Aug 2026 19:24:47 +0000

London entered official drought on 29 July 2026, but Thames Water’s Beckton desalination plant was out of service. The plant’s headline 150-megalitre-a-day design capacity was not a usable drought reserve: regulators had written its formal deployable output down to 25 Ml/d because approved replacement reverse-osmosis membranes were unavailable.

That turns the apparent puzzle into a more troubling one. Beckton, formally the Thames Gateway desalination plant in east London, was built to turn brackish Thames water into drinking water during severe drought. But it could not simply be switched on when the drought declaration and low river flows met its operating trigger.

The Environment Agency declared drought across seven English regions, including London and the Thames Valley, after record-low rainfall, high temperatures, low river flows and water-use restrictions affecting 23 million customers. At Teddington, flows were reported at about 220 Ml/d—below the 300 Ml/d drought target and far below the plant’s 3,000 Ml/d trigger.

Beckton’s deployable output was written down to 25 Ml/d

The three Beckton numbers describe different things, and only one represented its drought contribution in recent planning.

Beckton figure	What it means
150 Ml/d	The plant’s original design capacity
100 Ml/d	Capability assumed in Thames Water’s 2024 plan for the 2021/22 baseline
25 Ml/d	Deployable output counted in 2024/25 planning and regulators’ December 2025 assessment
75 Ml/d	Reliable drought output Thames Water planned to restore by 2030/31

The joint December 2025 review by Defra, the Environment Agency and Ofwat says Gateway’s long-term outage led Thames Water to reduce its assumed output to 25 Ml/d, half the 50 Ml/d planned for 2024/25. The stated reason was the unavailability of approved membranes.

Those membranes are the working core of a reverse-osmosis plant. High pressure pushes brackish water against semi-permeable barriers that admit water molecules while rejecting salts and other dissolved material. They are not an interchangeable consumable: drinking-water operations require approved equipment and a validated process. Without compliant replacement membranes, a nominal 150 Ml/d plant is an engineering specification, not a dependable source of potable water.

The 25 Ml/d planning value should not be read as proof the plant could have delivered exactly that volume on any day in August 2026. It was the number used to calculate drought resilience, reflecting a source under prolonged outage. Thames Water’s own 2024 water-resources plan had previously used a 100 Ml/d capability assumption, already below the original 150 Ml/d design figure.

This is why “idle” is an incomplete description. A working standby plant can be idle by choice; Beckton was offline because of asset condition and unresolved restoration work. Thames Water said it was replacing damaged equipment, including the membranes, and preparing the site to return later in 2026 if needed. New Scientist reported that even in service, the plant’s ramp-up to full capacity takes four to six weeks. Drought infrastructure that needs more than a month to ramp up cannot rescue the first weeks of a fast-moving drought.

“The hot and dry weather means we are currently using water faster than nature can replenish it.”

— Helen Wakeham, Director of Water at the Environment Agency and chair of the National Drought Group

Beckton’s record during the 2022 drought makes the 2026 outage harder to dismiss as a one-off. Thames Water’s WRMP24 supply assessment records repeated outages and says the plant was unavailable through that drought as well. Its separate review describes 2022 as a stress test for London’s drought plans; river flows at Teddington dropped below the 3,000 Ml/d awareness level in mid-June, and London reservoir storage began to fall.

The regulators’ response was not merely to request an update. They instructed Thames Water to restore Gateway’s planned 75 Ml/d deployable output as soon as possible, address the membrane-availability problem and expedite alternative London supply options. They said the outage was reducing London’s surplus and leaving customers with lower resilience. Thames Water’s 2024/25 annual review also recorded leakage of 575 Ml/d, while regulators calculated that this was 40.84 Ml/d above the company’s WRMP24 forecast.

The evidence supports an asset-condition and resilience-planning failure, not claims of shareholder, contractor or lobbying influence. The operational explanation for Beckton’s condition largely comes from Thames Water’s own planning documents; the crucial 25 Ml/d write-down and the demand for corrective action come from the independent regulator review.

London’s target is now not a return to 150 Ml/d, but 75 Ml/d of reliable drought output by the end of AMP8, or 2030/31. Until that work is complete, the capital’s only mainland large-scale desalination plant remains less a reserve tap than a reminder that capacity on paper is not water in the network.

Key Takeaways

Beckton was offline when drought was declared in London and the Thames Valley on 29 July 2026.
The plant was designed for 150 Ml/d, but regulators counted only 25 Ml/d as deployable output in 2024/25 planning.
Approved replacement reverse-osmosis membranes were unavailable during the plant’s long-term outage.
Beckton was also unavailable during the 2022 drought after repeated outages.
Thames Water plans to restore 75 Ml/d of reliable drought output by 2030/31.

Claude Mythos Finds Bugs Faster Than Teams Can Patch Them

Simon Paxton — Sun, 16 Aug 2026 19:17:57 +0000

Matthew Green’s August 14, 2026 “going dark” warning is not about encryption blocking network inspection, compliance tools, or parental controls. The Johns Hopkins cryptographer is predicting that AI-assisted software assurance could make remotely exploitable bugs scarce enough to deprive U.S. intelligence and law-enforcement agencies of a major hacking route.

The immediate evidence points somewhere messier: Anthropic says Claude Mythos Preview and its Project Glasswing partners have found more than 10,000 high- or critical-severity vulnerabilities across roughly 50 organizations. That is not a world without bugs. It is a world where defenders may find them faster than they can verify, disclose, and patch them.

Matthew Green, an associate professor at the Johns Hopkins Information Security Institute, made the claim in his August 14 post, “Everything is about to ‘go dark’”. He uses “going dark” in the old law-enforcement sense: authorities losing access to useful investigative evidence—not network operators losing visibility into encrypted traffic.

“I’m concerned that AI is going to make software much too secure.”

That is Green’s deliberately perverse formulation. His concern is that agencies have increasingly relied on targeted device access and remote exploitation as conventional wiretaps became less useful in an encrypted, smartphone-heavy world. If remotely exploitable flaws dry up, he argues, those agencies could return to their familiar demand for legally compelled exceptional access—backdoors, by a more bureaucratic name.

Green’s Two-Year Prediction Concerns Remote Exploits

Green’s post does discuss encryption, but not as a warning that encryption will blind corporate network monitoring or content-filtering systems. Its argument is narrower and more consequential: end-to-end encryption reduced the value of intercepting communications in transit, which made device hacking and remote exploits more important to investigators seeking access to messages and stored data.

His forecast is that well-maintained software could become nearly free of remotely exploitable vulnerabilities within about two years as AI systems become better at finding and repairing flaws. He does not say that all software bugs will vanish, nor that crime will become uninvestigable. The relevant category is the remote bug that lets an attacker compromise a target device without physical access or the target’s cooperation.

That distinction matters. A typo in a web dashboard, a local privilege-escalation bug, and a remotely exploitable browser vulnerability do not carry the same operational value. The last category can be a route into a device that its owner has locked down and whose communications are encrypted.

Green’s two-year timeline is explicitly a prediction, not an observed result. His larger warning is political: if government agencies lose this capability abruptly, the pressure to mandate access mechanisms in encrypted services could return under a new rationale.

It also puts a different light on the struggle between AI companies and the U.S. security establishment. Anthropic has already had a visible conflict with U.S. national-security power; a future argument over whether AI hardening has obstructed lawful hacking would not be a purely technical dispute.

Green’s position is plausible as a direction of travel, but it leaps over the operational problem exposed by current AI security testing: discovery is only the first stage. A model can produce a plausible bug report in minutes; a software supplier still has to determine whether the report is real, assess its severity, develop a safe fix, test it across versions and dependencies, coordinate disclosure, and persuade users to install the patch. Each of those steps can fail independently.

Glasswing’s 10,000-Finding Remediation Backlog

Anthropic launched Project Glasswing as a collaborative defensive program around Claude Mythos Preview, a general-purpose model the company says is unusually capable at cybersecurity work. In its April 7 technical assessment, Anthropic said the model could identify and exploit zero-day vulnerabilities in its tests involving major operating systems and web browsers.

Those are Anthropic’s own results, and the company has a strong incentive to frame an alarming capability assessment as evidence of a frontier model’s power. The company also says more than 99% of the vulnerabilities described in that April assessment remained unpatched and undisclosed, which prevents outsiders from independently examining most individual reports.

By May 22, Anthropic said Glasswing and about 50 partner organizations had found more than 10,000 high- or critical-severity findings. Dividing those two company-reported figures produces a crude but revealing floor of at least 200 serious findings per partner, using 10,000 findings and roughly 50 partners. The actual distribution is surely uneven; the point is the queue.

Anthropic says the limiting factor has moved from discovery to verification, disclosure, and patching. That is a more immediate security risk than Green’s clean two-year endpoint. An organization receiving hundreds of possible high-severity reports is not automatically safer. Until it sorts true positives from false positives and ships fixes, it may simply possess a much more detailed map of its own exposed surfaces.

The project follows coordinated vulnerability disclosure norms: the company describes a roughly 90-day disclosure window, or around 45 days after a patch becomes available. Those delays exist because publishing a flaw before users have upgraded can hand attackers the instructions they need.

Anthropic’s May estimate also began with model-assigned severity ratings. At that point, only 1,752 initially high- or critical-rated findings had been assessed by six independent security firms or Anthropic. That is enough to demonstrate a serious validation workload; it is not enough to treat the raw 10,000 figure as 10,000 confirmed, independently adjudicated vulnerabilities.

Mozilla offers the clearest public example of what the workload looks like when findings can be acted upon. In an April 21 account of its Mythos Preview evaluation, Mozilla said Firefox 150 fixed 271 vulnerabilities identified during the exercise. It also described the strain of processing so many reports at once.

That is the useful correction to both AI doom language and AI security triumphalism. Faster bug-finding can lower risk only if maintainers can convert model output into deployed fixes at approximately the same speed. Otherwise, the model has improved reconnaissance faster than repair.

This is also why evaluations of agentic systems should not be confused with finished autonomous security operations. The same gap appears in agentic sandbox escape and AI security limits: a capable model operating in a constrained test setup is not equivalent to an operator reliably navigating production infrastructure.

Independent Tests Show Both Capability Gains and Validation Limits

There is outside evidence that Mythos Preview represents a genuine jump in some cyber tasks. The UK AI Security Institute, an independent government-backed evaluator, reported that a newer Mythos Preview checkpoint was the first model to complete both of its cyber ranges. That supports the narrow claim that models are improving at multi-step offensive-security exercises.

But the institute also says its cyber ranges and time-horizon benchmarks are imperfect proxies for real-world impact. They run in constrained environments and cannot establish whether the latest performance jump is a durable trend rather than a one-off result. A model completing a range has cleared a designed test; it has not demonstrated a dependable ability to compromise arbitrary production targets.

XBOW, a security company that evaluated the model, reached a similarly mixed verdict in its May assessment. It found Mythos Preview especially strong for source-code auditing—where the model can inspect a defined codebase and search systematically for dangerous patterns—but less self-sufficient at validating vulnerabilities against live systems.

That limitation is not a footnote. Live validation depends on configuration, deployed versions, hidden dependencies, network controls, permissions, rate limits, and the human judgment needed to distinguish an exploitable flaw from a theoretically suspicious line of code. Source review is a search problem. Exploiting a real service is a systems problem.

The emerging picture is therefore sharper than either extreme. Green is not warning that encryption will make enterprise traffic opaque to ordinary inspection tools. He is warning that AI may eventually reduce the supply of remote exploits relied upon by government hackers, potentially reigniting backdoor politics.

For now, though, Mythos Preview’s clearest demonstrated effect is more prosaic and more urgent: it can generate a security triage queue at industrial scale. A shortage of zero-days remains a forecast. A pile of vulnerability reports waiting for humans to confirm and fix is already here.

Key Takeaways

Matthew Green’s “going dark” post concerns intelligence and law-enforcement access through remote hacking, not network traffic inspection.
Green predicts that well-maintained software could lose most remotely exploitable bugs within about two years, but calls this a forecast rather than an observed outcome.
Anthropic says Project Glasswing found more than 10,000 high- or critical-severity findings across roughly 50 partners.
More than 99% of the vulnerabilities in Anthropic’s April 2026 assessment had not yet been patched or publicly described.
Mozilla fixed 271 Mythos-identified vulnerabilities in Firefox 150, illustrating both the model’s utility and the remediation burden.

Firefox Keeps Full UBlock Origin. Brave Has a Side Door.

Simon Paxton — Sat, 15 Aug 2026 19:17:28 +0000

Firefox is not the only major browser where users can still run full uBlock Origin. Firefox retains broad, ordinary Manifest V2 support for the extension, while Brave separately hosts its own Manifest V2 build of uBlock Origin as a curated exception.

That distinction became sharper after Microsoft began Edge’s staged Manifest V2 transition on August 7, 2026. Edge has started warning users and will gradually disable old extensions through the end of 2026; enterprise deprecation is planned for early 2027.

Firefox publicly reaffirmed its position on August 10. As reported by PCWorld, Firefox said:

“Our support for uBlock Origin isn’t going anywhere.”

— Firefox, August 10, 2026

That makes Firefox the clearest mainstream home for the full blocker: users install it normally, rather than relying on a browser-specific carve-out. But calling it the sole major-browser option leaves out Brave.

The split comes down to extension architecture. Manifest V2 is the older extension format that gave blockers broad control over web requests. Manifest V3 is its successor, promoted by browser makers as a more secure and performant foundation, but it has pushed content blockers toward more constrained designs.

The full uBlock Origin project blocks ads, trackers, popups, malware sites, coin miners, and anti-blocker scripts, with extra filter lists, host-file support, and custom filtering rules. Its own documentation says that uBlock Origin works best on Firefox. The Manifest V3 alternative, uBlock Origin Lite, remains available on Chromium browsers but has fewer features and less successful ad blocking, PCWorld noted.

Brave’s hosted uBlock Origin exception

Brave has kept a narrow escape hatch. Since version 1.81, Brave has hosted four Manifest V2 extensions on its own backend: uBlock Origin, AdGuard, NoScript, and uMatrix. They are separate from Chrome Web Store versions, and users must enable them through brave://settings/extensions/v2.

Browser	Full Manifest V2 uBlock Origin status
Firefox	Broad, normal extension support
Brave	Brave-hosted exception, enabled separately
Chrome	Disabled for Chrome 139+ users
Microsoft Edge	Staged shutdown began in August 2026

Brave’s system is not normal compatibility preserved indefinitely. The company describes it as limited, best-effort support, contingent on continued cooperation from each extension’s authors. It covers only those four curated extensions, not arbitrary old Manifest V2 add-ons.

Brave also argues that its built-in Shields protection does not depend on either Manifest V2 or Manifest V3 because it is patched directly into the Chromium codebase. Shields block ads and trackers without an extension, Brave says, but the available sources do not provide an independent, current measurement comparing Shields, uBlock Origin Lite, and full uBlock Origin for blocking coverage, tracker protection, or site breakage.

Chrome’s cutoff is already further along. Google says Manifest V2 was disabled for all Chrome 139-and-newer users on July 24, 2025. Its remaining Manifest V2 listings are due to leave the Chrome Web Store on August 31, 2026—the same removal date listed on uBlock Origin’s project page.

Microsoft is catching up, but its rollout is not complete. The Microsoft Edge team says 95% of the top Manifest V2 extensions in Edge Add-ons have moved to Manifest V3. It identified 58 MV2 extensions with meaningful use and said only three lack a publicly available MV3 counterpart.

Microsoft’s claim that most extensions moved without lost customer functionality is Microsoft’s own assessment. It does not establish feature parity for uBlock Origin, whose value is precisely in functions that its Lite version does not fully reproduce.

For now, Edge users may still have time before their installed extension is switched off: notices began with a subset of users in August, first in Canary, Dev, and Beta channels, then gradually in Stable. Firefox users do not need that timetable; Brave users need a special settings page. That is the practical difference between a browser that still supports Manifest V2 and one that has preserved four artifacts from it.

Key Takeaways

Firefox remains the only major browser with broad, ordinary Manifest V2 extension compatibility.
Brave still distributes a Brave-hosted Manifest V2 version of full uBlock Origin as a limited exception.
Brave’s exception covers uBlock Origin, AdGuard, NoScript, and uMatrix, enabled through a separate settings page.
Microsoft Edge began its staged Manifest V2 shutdown in August 2026 and targets consumer completion by the end of 2026.
Chrome disabled Manifest V2 for Chrome 139-and-newer users in July 2025.

AMD’s Old DRAM Swizzle Is Real. the Universal Break Is Not

Simon Paxton — Fri, 14 Aug 2026 19:45:52 +0000

Skitter Creek Bath Salts is a credible proof of concept for AMD Family 16h processors: with privileged access, it can alter a DRAM controller’s address mapping and calculate an ordinary physical-address alias for data in protected memory. That is a serious result on the hardware it tested—but it is not yet a demonstrated defeat of memory protections across modern AMD, Intel, ARM, or RISC-V systems.

The unusually named project, published on GitHub by xoreaxeaxeax, claims to reach Platform Security Processor (PSP) private DRAM, System Management Mode (SMM) memory, C6 save-state DRAM, and microcode-related paths by changing how the memory controller translates an address into the row, column, bank, rank, and channel signals sent to DRAM. Its developers say it was developed and tested on AMD Family 16h CPUs, an older generation whose controller registers were documented in public AMD manuals.

“Poke the DRAM controller and an address can be made to land wherever you want in memory.”
— Skitter Creek Bath Salts repository

That wording is deliberately maximalist. The evidence beneath it is narrower and more useful: a root-level actor on a tested Family 16h machine can tamper with a documented controller setting below the physical-address fences that normally separate privileged memory regions. The project’s broader claims about AMD Family 17h and newer, ARM, and RISC-V are extrapolations; the repository does not show reproductions on those platforms.

AMD’s documented BankSwizzleMode register enables the tested remap

The crucial mechanism is not a mysterious DRAM flaw. AMD’s 2015 Family 16h BIOS and Kernel Developer’s Guide documents D18F2x94’s BankSwizzleMode as a read-write DRAM-controller field. AMD describes the setting as an XOR-based transformation of bank-address bits using other physical-address bits—a performance-oriented remapping intended to distribute memory traffic more effectively.

Skitter Creek Bath Salts changes that final translation step. A CPU instruction starts with a virtual address, which the operating system translates into a physical address. Hardware protections can then forbid software from issuing requests to physical ranges reserved for SMM or the PSP. But after that check, the memory controller still converts the physical address into DRAM coordinates. Change the conversion, and an address permitted by the fence can end up at the same DRAM cell as an address behind it.

That is physical-address aliasing: two physical addresses that software treats as different locations resolve to one underlying DRAM location after the controller mapping changes. The project’s collection tooling experimentally maps those aliases, then uses an accessible alias to read or write a protected target where one exists.

The repository frames the security consequence bluntly:

“The fences guard physical addresses, not DRAM coordinates; rearrange the coordinates and the barriers above never notice.”
— Skitter Creek Bath Salts repository

That reasoning fits the documented hardware behavior on the tested generation. AMD’s manual establishes that the bank-swizzle control exists, is writable, and changes address-bit relationships; the project supplies the attack workflow that treats the altered mapping as a solvable aliasing problem.

The attack is also much less turnkey than “change one bit, own the CPU” suggests. The supplied userspace tools run as root and rely on a kernel module to manipulate DCT/MCT controller state. This is not an unprivileged operating-system escape, and it is not presented as a remote exploit.

Keeping a machine alive while its memory map changes beneath it is the project’s operational challenge. Its usage guide describes calibrating the system, collecting an alias map for the particular machine, and matching that map against a firmware fingerprint of the live controller state. The tool refuses a mismatched map by default, because a solved mapping is specific to the hardware and firmware configuration that produced it.

Nor is every calculated alias usable. The guide says some aliases land in a protected carveout themselves; those locations remain inaccessible and are reported as “holes” in the collected map. Its collection workflow also includes remotely power-cycling a target if alias collection hangs, a practical admission that the experiments can destabilize the platform.

The project’s headline targets are specific:

PSP private DRAM, which the AMD security coprocessor uses outside normal OS control.
SMRAM, the memory used by SMM firmware handlers.
C6 save-state DRAM, used when CPU cores enter a deep idle state.
Microcode-related memory paths, another class of privileged state the project says its method can approach.

Those demonstrations matter because they test the boundary below the kernel, where ordinary page permissions and reserved-memory maps assume a physical address continues to mean what the CPU thinks it means. But the account remains the project authors’ account: the supplied material contains no independent reproduction, vendor advisory, CVE, or evidence of exploitation on AMD Family 17h or newer, Intel, ARM, or RISC-V hardware.

AMD stopped publicly documenting the relevant translation registers after Family 16h, according to the project repository. That absence is not evidence that newer platforms retain a writable equivalent—or that they do not. The next meaningful result is not a broader claim about “everything”; it is a reproduced alias map on a newer controller, with the register path and access controls shown.

Key Takeaways

Skitter Creek Bath Salts demonstrates DRAM-controller aliasing on AMD Family 16h systems.
AMD’s 2015 documentation lists the Family 16h BankSwizzleMode control as read-write.
The technique changes the final physical-address-to-DRAM mapping beneath higher-level memory fences.
The supplied tooling requires root access, a kernel module, and machine-specific calibration.
The project has not demonstrated the technique on current AMD, Intel, ARM, or RISC-V hardware.

Reasoning Logs Hid 704 Secrets. the Old Envelopes May Still Open

Simon Paxton — Thu, 13 Aug 2026 19:56:11 +0000

Publicly shared LLM API logs can still expose customer data hidden inside encrypted reasoning blocks—at least unless providers have also invalidated the old cryptographic envelopes. An August 10, 2026 preprint reports recovering 704 distinct non-benchmark artifacts from public agent trajectories, including API keys, passwords, access tokens, and private keys.

The live cross-session replay attack described in the paper was no longer reproducible after private disclosure and provider mitigations, the researchers say. But the same paper’s mitigation appendix says old, already-published envelopes require pre-fix keys to be retired and legacy envelopes to be rejected. The reviewed record does not publicly confirm that OpenAI, Anthropic, or Google took that retroactive step.

Reasoning APIs often return an opaque block alongside a model response, then expect the application to include it in the next request. That lets a provider preserve multi-turn context without storing every conversation server-side. It also means a raw agent transcript can contain data its publisher cannot read, search, or reliably remove.

“[T]hese encrypted blocks are fully compatible and interchangeable across different sessions, users, and models within a provider’s ecosystem.” — the researchers’ preprint

The attack used that portability as a decryption route: replay an encrypted reasoning block into a weaker model from the same provider family, then instruct that model to transcribe its hidden content. The researchers reported this worked across Anthropic, OpenAI, and Google before mitigations. It is a different failure mode from the Claude prompt-injection data-exfiltration path: here, the sensitive material can already be sitting in a public log, wrapped in what looks like harmless API bookkeeping.

The 704 artifacts recovered from genuine public sessions

Alexander Panfilov of MATS Research and the ELLIS Institute Tübingen, David Schmotz of the ELLIS Institute Tübingen, and their co-authors decoded 315,320 encrypted reasoning blocks from 6,708 public trajectories. Their target was public repositories containing agent rollouts and session logs, not a provider’s internal systems.

From genuine, non-benchmark sessions, the paper’s Appendix D lists 62 API keys, 33 passwords, 24 access tokens, and seven private keys. The total was 704 distinct artifacts, including credentials and personally identifiable information.

Recovered non-benchmark artifact	Distinct count
API keys	62
Passwords	33
Access tokens	24
Private keys	7

Sixty-four of the 704 artifacts were absent from visible chat history, according to the paper. That is the part most likely to surprise teams that sanitize a transcript before publishing it: redacting user and assistant text does not remove material sealed inside the reasoning envelope.

The researchers do not establish where those 64 values originated. They could have come from prompts, tool output, model memory, or another source. But their absence from visible text is enough to make ordinary transcript scrubbing an incomplete defense.

The count also needs reading carefully. The paper’s main text refers to “833 passwords” from genuine sessions, while Appendix D’s category table lists 33 distinct non-benchmark passwords. The authors used a two-stage LLM-assisted labeling and deduplication pipeline, rather than a human forensic review of every recovered item. The appendix’s distinct-artifact count is the cleaner number for assessing exposed unique secrets.

Matthew Green, a cryptography professor at Johns Hopkins University, had already described the basic replay behavior in a May 29 post: encrypted reasoning blobs could travel across sessions and accounts, and for OpenAI, across models. Green initially downplayed it as not “a particularly exciting vulnerability”; in an August 11 update, he wrote that the later research group had turned the observation into a working attack.

The providers’ fixes may have shut the door on a new replay attack. They do not automatically shred copies that have already escaped.

The proposed remedy is unusually concrete: rotate the signing keys used before the fix and reject envelopes made under those legacy keys. Without both steps, a public archive may still hold a valid, replayable object even when today’s API rejects newly created malicious requests.

Google has said its systems recognized reasoning-trace coercion and reduced the associated risk. That is Google’s account of its own remediation, not independent evidence that old public reasoning envelopes were invalidated. The cited material contains no comparable public confirmation of retroactive invalidation from any of the three providers.

For developers, the immediate lesson is blunt: a published raw API trajectory should be treated as a potential secret-bearing artifact, not as a sanitized conversation record. That risk sits beside other documented operational failures, including Anthropic data-leak operational failures and research into Claude web-fetch profile-data theft.

A patch that stops tomorrow’s replay is useful. A rotated legacy key is what decides whether yesterday’s public logs remain openable.

Key Takeaways

Researchers reported recovering 704 distinct non-benchmark artifacts from public LLM API trajectories.
The recovered artifacts included 62 API keys, 33 passwords, 24 access tokens, and seven private keys.
The paper says its replay-and-decoding attacks stopped reproducing after providers received private disclosure.
Sixty-four recovered artifacts were absent from the visible chat history of the relevant sessions.
The paper recommends retiring pre-fix keys and refusing legacy envelopes to protect already-published logs.

Anthropic, OpenAI and Google Reasoning Locks Met Their Own Spare Keys

Simon Paxton — Wed, 12 Aug 2026 20:00:47 +0000

Researchers reported on August 10, 2026, that they could extract supposedly hidden reasoning traces from Anthropic, OpenAI, and Google API ecosystems by replaying encrypted reasoning blocks into weaker compatible models. The attack turned those models into decryption oracles: a stronger model’s opaque trace could return as readable plaintext.

The August 10 arXiv preprint also decoded 315,320 reasoning blocks collected from 6,708 public agent trajectories, finding 367 personal-information artifacts and 182 credentials. The work is not peer reviewed, and the authors say providers changed their systems after disclosure, preventing reproduction of the same attacks.

The Cross-Model Decryption-Oracle Attack

Reasoning APIs increasingly return opaque fields alongside a model response. Anthropic calls them signed thinking blocks; its documentation says the encrypted full thinking is carried in a signature field to preserve multi-turn continuity. OpenAI tells applications managing their own state to replay encrypted reasoning items, while Google’s Gemini API describes thought signatures as encrypted representations of internal reasoning.

Those fields were designed to be passed around, not read. The paper’s central finding is that portability can defeat opacity when a provider’s weaker sibling model accepts a block created by a stronger one and is willing to transcribe what it contains.

The researchers tested cross-session, cross-user, and cross-model replay paths in the three providers’ API families. Their technique supplied an encrypted block from one interaction to a compatible lower-capability model, then prompted that model to reveal the content it had evidently decoded to continue the conversation. In effect, the encryption protected the trace from the customer directly but not from another model endpoint willing to interpret it.

The paper calls this a cross-model decryption-oracle attack. It is less like breaking modern encryption and more like finding a service desk that will open a sealed envelope if the request is phrased correctly. The practical security boundary was the API’s acceptance rules, not the unreadability of the returned blob.

The authors evaluated extraction fidelity over 120 Codeforces programming problems, comparing extracted-token counts with each provider’s reported thinking-token counts. Those measures tracked closely, the authors report, though they could not compare results with ground-truth plaintext reasoning traces because the providers do not expose them.

That limitation matters: token counts are evidence that something substantial was recovered, not a full independent verification of every recovered sentence. But the reported cross-provider design flaw is concrete enough that CTOs should stop treating encrypted reasoning output as harmless logging material.

This is a different route from the Claude Code leak and its harness-level attack surface, where the problem sat in the surrounding agent environment. Here, the risky artifact is the reasoning-continuity data the API itself asks customers to preserve and replay.

Public Trace Scan Recovered Credentials and Personal Data

To see what such extraction could expose outside a lab, the researchers scanned 6,708 public trajectories from GitHub and Hugging Face. They decoded 315,320 encrypted blocks—about 47 blocks per trajectory, calculated from those two reported totals.

The scan found:

367 PII artifacts and 182 credentials across the decoded material.
1,028 blocks, or 0.3%, containing at least one privacy leak.
328 sessions, or 4.9%, containing at least one real sensitive item.
62 API keys, 33 passwords, and 30 personal email addresses from genuine user sessions.

The larger 367-artifact headline includes benchmark material, which contributed substantially to the personal-information count. That does not erase the real-user findings; it does mean the headline total should not be casually read as 367 live customer-data incidents.

The review was targeted rather than exhaustive. Public agent logs are also not a representative sample of all API traffic: they are disproportionately likely to include demos, benchmarks, debugging sessions, and people who published their workflow without expecting an opaque field to become legible later.

Still, that is precisely the operational lesson. A trace does not need to be deliberately published as plaintext to leak. It only needs to be retained in a broad-access observability system, copied into a benchmark repository, or handed to a vendor whose compatible endpoint can reinterpret it.

The exposure overlaps with the risk behind Claude’s prompt-injection exfiltration path: agent systems often move sensitive context through components that engineers assume are merely internal plumbing. “Encrypted” output is still output, and output tends to end up in logs.

The public-scan findings and attack demonstrations are reported by the paper’s authors; the brief provides no independent replication of their original vulnerable API behavior.

Provider Patches and Context-Bound Trace Design

The researchers said the providers acknowledged the responsible-disclosure report and that they could no longer reproduce the same extraction paths after fixes. The tests covered particular API versions and reasoning models in early July 2026, while providers can alter proprietary implementations without notice.

That is good news for the specific exploit. It is not a reason to resume dumping signed thinking blocks into every analytics store. A vendor-side patch can close one cross-model compatibility path; it cannot retract copies that customers already placed in logs, evaluation corpora, support tickets, or public repositories.

The paper proposes binding a reasoning block to its intended context: the relevant model, user, session, and conversation state should be part of what the API validates before accepting a block. A trace replayed into a different model or account should fail rather than silently become interpretable context.

For CTOs, the immediate policy is simpler than the cryptography:

Classify encrypted reasoning fields and raw API transcripts as sensitive data.
Limit retention and access as aggressively as for prompts and tool outputs.
Keep such traces out of public benchmarks, debug bundles, and broad telemetry by default.
Recheck integrations when an API provider changes its reasoning-continuity format.

The attack did not prove that every encrypted reasoning trace remains extractable today. It did show why “our engineers cannot read this field” is not a security classification. If a model can read it, the system has to assume somebody may eventually make it talk.

Key Takeaways

Researchers reported replay attacks that extracted hidden reasoning traces from Anthropic, OpenAI, and Google API ecosystems.
The technique used weaker compatible models as decryption oracles for opaque reasoning blocks.
A public scan of 315,320 blocks found 367 PII artifacts and 182 credentials.
The headline PII count includes benchmark material, while genuine user sessions contained API keys, passwords, and personal email addresses.
The researchers said provider changes after disclosure stopped reproduction of the reported attacks.

Noreply.net Became a Mail Sink: and Nobody Checked the Drain

Simon Paxton — Tue, 11 Aug 2026 19:58:48 +0000

Security researcher Cory Solovewicz says noreply.net received 401,796 messages after he acquired it in December 2024, including notifications that reportedly carried private customer and organizational data. The volume works out to almost exactly 700 messages a day—mail sent by systems that apparently treated a real, externally owned domain as a harmless no-reply address.

The incident is reported solely through Solovewicz’s account to Ars Technica in August 2026. But the available historical record points to a more durable failure than the story’s surface-level “expired domain” framing: noreply.net had long looked generic enough for people, templates, and even a Postfix tutorial to use as a placeholder.

Solovewicz, a security researcher and consultant, told Ars that he bought noreply.us in 2020 and noreply.net in 2024. He said the .us purchase began as a catch-all mailbox project, before mail intended for other people and organizations started arriving.

“I did not realize that this was going to be as big of a problem as it is,” Solovewicz said, according to Ars Technica.

He reportedly received injury reports from a city government, pizza-order confirmations, repair-service orders, school-platform account setup emails, and test-platform credentials. Ars reported that Solovewicz was notifying affected organizations but was not publicly naming them.

The raw totals make this more than a handful of stray password resets:

Domain	Reported incoming mail
`noreply.net`	401,796 messages since December 2024
`noreply.net` attachments	28,365 attachments
`noreply.us`	37,255 messages over 2,345 days
Both domains, recent month	More than 11,000 messages

Ars also reported that more than 14,000 From addresses sent mail to the two domains. That is consistent with a distributed configuration problem: copied deployment instructions, address-rewriting rules, old test settings, and services that substitute a generic domain when an employee or customer address disappears.

Generic noreply.net configurations created a durable mail sink

The clearest evidence for that mechanism is a 2012 Postfix setup guide that explicitly recommended setting myorigin=noreply.net. Its rationale was straightforward: use a valid-looking domain name to signal that a recipient should not reply.

That advice is exactly the sort of configuration that can outlive its author. In Postfix, myorigin helps determine the domain appended to locally posted mail that lacks one. Put noreply.net in a tutorial, deploy the tutorial unchanged, and a system can begin generating addresses at a domain its operator never owned. The mail server does not know it is a placeholder; it resolves and delivers mail as instructed.

The name had been used this way long before Solovewicz’s reported purchase. A 1998 Usenet post appeared from an address at noreply.net, with the poster saying the address had been forged to deter spam. A 2004 forum notification record used no@noreply.net.

Those examples do not prove that a particular company’s 2025 or 2026 messages came from the old Postfix advice, or from any other copied configuration. They demonstrate something narrower and important: for decades, noreply.net could plausibly be mistaken for a generic label rather than recognized as somebody else’s property.

That distinction changes the remediation job. Organizations should not limit abandoned-domain monitoring to domains that once belonged to them. They also need an outbound-email inventory that searches application settings, mail-transfer-agent configuration, templates, test fixtures, address transformations, and vendor integrations for domains they do not control—especially deceptively generic ones.

A useful audit should identify:

domains used in sender and reply-to addresses;
domains inserted by mail-server settings such as myorigin;
fallback addresses used after account deletion or employee departure;
no-reply values embedded in application templates; and
external domains receiving attachments or account-setup messages.

The expiration story is not established

The “abandoned domain” label may be directionally useful, but it is not proven by the available evidence. A public domain-index listing shows a July 2011 registration date for noreply.net, yet that alone cannot establish whether the domain expired, dropped from registration, was re-registered, or changed hands in a private transaction before the reported 2024 acquisition.

Likewise, the available record does not independently verify Solovewicz’s purchase, the provenance of the messages, the number of affected organizations, or the validity of the credentials he said he received. The reported message counts, content, and notification campaign all come from Ars Technica’s account of Solovewicz’s findings, not from public incident disclosures by the senders.

That limitation does not rescue the configurations. If a production system emits sensitive messages to a domain it does not own, the error exists whether the domain was dropped, sold, inherited, or simply mistaken for an imaginary no-reply namespace. noreply.net is a reminder that “no reply” is a mailbox convention—not a reserved destination.

Key Takeaways

Cory Solovewicz told Ars Technica that noreply.net received 401,796 messages after his reported December 2024 acquisition.
The reported noreply.net mail included 28,365 attachments.
A 2012 Postfix guide explicitly recommended myorigin=noreply.net as a generic-looking no-reply configuration.
Public records show noreply.net-style addresses in use as early as 1998.
Available evidence does not establish that noreply.net expired before its reported 2024 acquisition.

SQLite’s Six Critical CVEs Were Bugs in a Database of Bugs

Simon Paxton — Sun, 09 Aug 2026 19:28:42 +0000

Six purported SQLite vulnerabilities, initially rated from 7.5 High to 9.8 Critical, were not reproducible bugs at all. JFrog’s July 30, 2026 investigation found that the advisories cited nonexistent code, impossible source locations, and proof-of-concept inputs that either failed to parse or did not crash SQLite under memory-error detection.

The six records—CVE-2026-51296, CVE-2026-51297, CVE-2026-51300, CVE-2026-51302, CVE-2026-51303 and CVE-2026-51304—reached the National Vulnerability Database before their CNA withdrew them on July 31. SQLite now labels each one “Not a bug in SQLite” and describes them as unreproducible, apparent AI hallucinations. That is an attribution, not a proven account of who authored the reports.

Six SQLite CVEs Reached NVD Before Rejection

The records originated in the public programmervuln/cveadvisory- GitHub repository, which published the SQLite advisories amid a larger collection of CVE-named submissions. JFrog security researcher Afek Berger reported that the six SQLite entries were assigned CVEs, entered NVD workflows and received enrichment from CISA’s Authorized Data Publisher program before the withdrawal. NVD’s preserved record for CVE-2026-51302 shows prior CISA ADP scoring and CPE product metadata despite its current rejected status.

That sequence matters operationally because a CVE is not just a web page. Once a record arrives in vulnerability feeds, scanners can flag it, ticket systems can open remediation work and security teams can spend time chasing a patch for a bug that does not exist. The supplied sources do not quantify how many of those downstream systems retained alerts from these six records.

JFrog tested the claims the less glamorous way: against the source code and actual binaries. Researchers checked out the SQLite versions named in the advisories, compiled them in isolated Docker containers, then ran each supplied SQL proof of concept under AddressSanitizer, a runtime tool designed to catch memory-safety failures. The investigation says several payloads were invalid SQL or JSON, while others completed without an ASan-detected crash.

One record illustrates the gap between the label and the evidence. CVE-2026-51302 was presented as a 9.8 Critical heap use-after-free, alleging that sqlite3ReleaseTempReg() left a dangling pointer later read by exprComputeOperands(). JFrog found that exprComputeOperands() did not exist in the SQLite 3.41 release named by the advisory; it was added only in mid-2025. The alleged first function also recycles register indexes rather than freeing heap memory, undercutting the proposed use-after-free mechanism.

“Not a bug in SQLite.”

SQLite’s maintained CVE page applies that verdict to all six records and calls them “apparent AI hallucinations.” The maintainers also note that they generally regard CVE counts as an unreliable indicator of bugs affecting typical SQLite deployments. That broader position does not automatically invalidate every future SQLite CVE; here, the decisive evidence is the failed source review and failed reproduction attempts.

The technical defects varied, but they shared a pattern that should have stopped the reports before severity scoring: functions absent from the cited version, wrong function signatures, fabricated fixes, references to unrelated code and line numbers that did not fit the release. JFrog says it found those failures across the six reports, including claims rated severe enough to prompt immediate remediation in many organizations.

CVE-2026-51302’s severity also shifted before rejection. JFrog observed that Red Hat initially assigned it a 10.0 Critical score, then reduced it to 7.6 High. The original advisory’s own framing was 9.8 Critical. Precision is not the same as verification: a decimal score can make an invented failure mode look strangely official.

NVD does not erase rejected records. Its page for CVE-2026-51296 preserves the previous SQLite vulnerability description while marking the entry rejected because the CNA determined it was not a security issue. That archival choice is useful for audit trails, but it means teams cannot assume an old scanner finding remains valid merely because its CVE page still exists.

This account is principally based on JFrog’s audit and SQLite’s status page; JFrog’s broader claim that 54 of 55 advisories in the originating repository were fabricated has not been independently quantified by the other supplied sources. But the six SQLite records have a clear final status: no patch to deploy, no bug to reproduce, and six false positives that security teams should close rather than keep escalating.

Key Takeaways

Six purported SQLite CVEs were withdrawn on July 31, 2026 after their CNA determined they were not security issues.
The affected records were CVE-2026-51296, -51297, -51300, -51302, -51303 and -51304.
The advisories initially carried reported severity scores ranging from 7.5 High to 9.8 Critical.
JFrog found that the reports cited absent code, incorrect logic and non-working proof-of-concept payloads.
Rejected CVE records remain available in NVD, so teams should close prior scanner findings and remediation tickets tied to them.

Texas Just Made Grid Approval the Choke Point

Simon Paxton — Tue, 04 Aug 2026 20:22:08 +0000

Texas has effectively halted progress on new queued data center grid connections as of August 3, 2026 by ordering the Public Utility Commission of Texas and ERCOT to verify and audit every proposed data center in the interconnection pipeline before any project moves forward. The state said the audit must determine whether each project is a real load request, what power and water it would consume, who would bear infrastructure costs, and what community impacts it would create, in a queue dominated by data center demand.

That matters because ERCOT had already tightened large-load entry through its new Batch Zero process, approved on June 18, 2026, which replaced first-come, first-served handling with a batch screening system for very large new power users. In practice, Texas has turned grid access into a hard development gate for AI infrastructure, including the kind of rapid buildouts behind projects such as OpenAI and Oracle’s data center expansion.

Texas has not published, in the cited materials here, a project-by-project list of paused applications or an audit timeline. But Governor Greg Abbott’s August 3 directive was explicit that a “comprehensive verification and audit” must happen before any new data center project can move forward toward connecting to the grid.

“Before any new data center project can move forward toward connecting to the grid, there must be a comprehensive verification and audit process to ensure that the proposed project is a valid, viable project—not merely an effort to reserve grid capacity that may never be used.” — Governor Greg Abbott

Abbott’s August 3 order follows a broader June 10 directive to PUCT Chair Thomas Gleeson and ERCOT CEO Pablo Vegas that told regulators to shield Texans from paying for infrastructure built for data centers, to scrutinize water use, and to require projects to add dispatchable generation or storage rather than only new demand. The state’s framing comes from the governor’s own press operation, but the policy direction is clear: Texas wants developers to prove they are serious, fund more of the physical buildout, and stop treating grid queue positions like cheap options.

Abbott’s August 3 audit freezes progress on queued data center connections

The direct answer to whether Texas has halted new data center connections is yes, for projects still trying to advance through the queued approval pipeline. Abbott’s August 3 announcement says every proposed data center in the interconnection queue must be audited before it can move forward.

The queue Texas is reacting to is enormous. In an April 9, 2026 presentation to the Texas House State Affairs Committee, ERCOT said about 410 gigawatts of large-load requests were seeking interconnection in Texas, and about 87% of that demand was from data centers. Abbott’s August 3 release used a later and larger figure, saying more than 474 gigawatts of requests were in play and about 90% of new power requests were tied to data centers. Those are request figures, not built load, and ERCOT has said not all requests become operating projects.

A simple way to read the April figure: 87% of 410 gigawatts is roughly 357 gigawatts of data center demand in the pipeline. That is several times larger than the current peak demand on the Texas grid, which helps explain why regulators stopped waving projects through.

The August 3 audit order says regulators must verify:

That is a much broader screen than a narrow electrical study. It treats a new hyperscale campus less like a passive customer and more like an industrial megaproject that has to show its financing, utilities plan, and local footprint before it gets a place in line.

ERCOT’s Batch Zero process was already turning large-load interconnection into a screening gate

The August audit did not appear out of nowhere. PUCT approved ERCOT’s Batch Zero process on June 18, 2026, creating a new study system for large flexible loads such as data centers, crypto mines, hydrogen facilities, and large industrial users.

Under ERCOT’s description of Batch Zero, applicants had to provide more detailed information up front so ERCOT could sort serious projects from speculative ones and study them in groups rather than one by one. The Texas Tribune reported on June 17 that the process required developers to submit details including location, expected load profile, operations, and readiness so ERCOT could better judge grid impacts before moving requests deeper into the pipeline.

The timing change matters. ERCOT said Batch Zero submissions would be reviewed on a set schedule, with applicants expected to learn whether they were accepted into the new study track after that screening step rather than simply progressing by filing early. In other words, large-load interconnection in Texas stopped being a simple queue and became a qualification round.

The Texas Tribune’s reporting captured the point of the redesign clearly: ERCOT and state regulators did not think the old process worked when hundreds of gigawatts of speculative and real demand were piled together. If too many projects reserve transmission capacity they never use, everyone else plans against a distorted map.

Texas had already shown it was willing to use that leverage. In a July 23, 2026 press release, Abbott’s office said an East Texas data center proposal withdrew after falling short of the governor’s standards. The release is the governor’s framing, but it is still evidence that the state’s tougher posture was affecting projects even before the August freeze.

Texas is trying to shift power, water, and community costs back onto data center developers

The policy goal is not subtle. In his June 10 directive letter, Abbott told PUCT and ERCOT to ensure data centers do not socialize the cost of their required transmission and generation upgrades onto ordinary ratepayers. He also told regulators to consider on-site generation, backup generation, energy storage, and broader planning rules that would make large loads contribute capacity, not just consume it.

“Data centers must bear the cost of the infrastructure they require and should add generation to the grid, not just demand from it.” — paraphrased from Abbott’s June 10, 2026 directive letter

That combination of cost recovery, water scrutiny, and queue vetting is the real 2026 shift. Texas is no longer treating data center growth as an automatic good once land and capital are lined up; it is treating grid access as a permit that must be earned. For AI companies, that means compute expansion in Texas now depends not just on financing and chips, but on whether a project can survive a state review of its load realism, infrastructure plan, and local impacts.

The next milestone is the completion of the PUCT-ERCOT audit ordered on August 3, 2026. Texas has not yet published, in the cited materials here, either the audit timeline or a project-by-project list of which queued data center applications are paused.

Key Takeaways

Texas ordered PUCT and ERCOT on August 3, 2026 to audit every proposed data center in the interconnection queue before any project can move forward toward grid connection.
ERCOT said in April 2026 that about 410 GW of large-load requests were seeking interconnection and about 87% of that demand came from data centers.
Abbott said in August 2026 that more than 474 GW of requests were in play and about 90% of new power requests were tied to data centers.
ERCOT’s Batch Zero process, approved June 18, 2026, had already turned large-load interconnection into a screening step that required more detailed project information up front.
Abbott’s June 10 directive told regulators to push infrastructure, generation, water, and community costs back onto data center developers rather than Texas ratepayers.

Gemma 4’s 2 GB Mac Story Is Really SSD Streaming

Simon Paxton — Sun, 02 Aug 2026 20:09:35 +0000

Gemma 4 26B-A4B does not, on the best citable evidence here, run as a true all-in-RAM 2 GB model on Macs. The strongest published figures from the project behind the claim put Gemma-only resident memory at about 3 GB with SSD-streamed expert loading, compared with about 6 GB using memory-mapped llama.cpp workflows and about 13 GB for vanilla 4-bit MLX on Apple Silicon, according to the project's Hugging Face page and an independent setup guide.

That makes the real story narrower, but still interesting. The project is showing disk-backed Mixture-of-Experts inference on Macs, not a full end-to-end local workflow with the whole model sitting in 2 GB of memory. The project's own published setup guidance also asks for 16 GB or more of RAM and about 30 GB of free disk, which is a more grounded statement than “any M-series Mac.”

Gemma 4 26B-A4B is one of Google's Mixture-of-Experts models. The Gemma 4 technical report describes Gemma 4 as spanning MoE architectures from 2.3B to 31B parameters, and an MLX Swift issue discussing Gemma 4 support describes the 26B variant as having about 3.8 billion active parameters per token. That “26B” label is about total model size, not the amount of compute or memory touched at once. In MoE systems, only some experts fire for each token. That is what makes this kind of trick possible.

What the 2 GB claim is actually measuring

The closest citable documentation from the project does not publish a plain “2 GB full workflow” number. Its Hugging Face deployment page says Gemma 4 26B 4-bit plus Sniper uses about 3 GB resident RAM, while Gemma plus Falcon vision uses about 5 GB resident RAM. The same page contrasts that with vanilla MLX at about 13 GB for Gemma 4 26B 4-bit.

That is a resident-memory claim, not a claim that the whole model file has shrunk to 2 or 3 GB. The same page recommends about 30 GB of free disk space, and the project's GitHub repository says it works by flash streaming experts on Apple Silicon rather than pinning the full model in memory.

“Only the hot experts plus a small DRAM cache stay resident; cold experts are streamed from flash on demand.” — Walter Grace, mac-code repository

That is the key distinction. Low resident RAM here means the runtime is keeping a small working set in memory while using the SSD as an extension of the model store. It does not mean a Mac is somehow running a 10 GB to 16 GB class model file as a literal 2 GB in-memory artifact.

A quick file-size reality check makes that plain. The Unsloth GGUF listing includes quantized Gemma 4 26B-A4B files such as UD-IQ2_M at 9.97 GB and MXFP4_MOE at 16.6 GB, while a Bartowski IQ4_XS GGUF page lists a 14.2 GB file used in llama.cpp testing. The storage footprint never disappeared. It moved off resident memory and onto disk-backed access.

How Gemma 4 26B-A4B normally fits on Macs

Against standard local setups, the SSD-streamed result is real. It is just not magic.

The MLX Expert Sniper page lays out the cleanest side-by-side numbers in this source set:

Setup	Published memory figure
Sniper + Gemma 4 26B 4-bit	about 3 GB resident RAM
`llama.cpp` with mmap	about 6 GB RAM
Vanilla 4-bit MLX	about 13 GB RAM

An independent Unsloth setup guide reports the same middle ground from a different angle: Gemma 4 26B MoE can run at about 6 GB RAM with memory-mapped files on Apple Silicon. Another independent data point is higher: an issue in mlx-swift-lm says the downstream 4-bit MLX model required about 26 GB of RAM in that context. Different runtimes and packaging choices matter a lot.

That spread is the useful answer for Mac users. “Gemma 4 26B on a Mac” is not one memory number; it is a stack choice. If you are comparing local LLM stack choices, the question is not just “can it load,” but how it loads: full MLX residency, mmap-heavy access, or expert streaming from SSD.

The project's own numbers also narrow the “any M-series Mac” framing. The Hugging Face page recommends 16 GB+ unified memory, and the GitHub repository reports measured performance on specific machines, especially a 16 GB Mac mini M4. That is a useful demo target. It is not the same as a broad hardware guarantee across the entire M-series line.

The speed and quality tradeoffs of SSD-streamed MoE inference

The upside is obvious: resident memory drops hard enough to make a 26B-class MoE model practical on Macs that would struggle with a more conventional load path. The downside is just as obvious: you are paying for that with storage traffic, caching behavior, and workflow constraints.

The mac-code repository describes an architecture that predicts and prefetches experts so the SSD is not hit blindly for every token. That matters because random storage fetches are slower than RAM by a wide margin. The trick is to behave less like a naive pager and more like a tiny specialist librarian: keep the experts you are likely to need next close at hand, and fetch the cold ones before the model stalls.

The project publishes speed figures, but they are benchmarks from particular Macs, not universal promises. Its GitHub page includes measured results on Apple Silicon and presents the method as a way to stay usable despite the streaming overhead. That is plausible. It also means readers should resist the usual local-AI demo error: treating one tightly scoped benchmark as a general hardware law. That is how AI claim verification failures happen in the first place.

Quality is a separate axis. The Gemma 4 technical report and the broader Gemma 4 developer shift story are about model design and capability, not this particular Mac runtime. Expert streaming changes deployment economics, not the underlying model weights. In practice, though, the workflow can still feel different if slower token generation, cache misses, or storage pressure make longer contexts and interactive use less smooth than a more RAM-heavy setup.

One more tradeoff sits in the background: disk wear and disk dependency. The method depends on SSD access as part of normal inference, so free space, storage speed, and sustained I/O matter more than they do in a simple all-in-memory run. The Hugging Face page explicitly asks for about 30 GB of free disk, which is the kind of requirement that gets lost when a demo collapses everything into one RAM number.

So is “2 GB RAM” meaningful? Only in the narrow sense of resident-memory measurement, and even then the best citable figure here is closer to 3 GB for Gemma-only than 2 GB. As a real-world Mac buying or setup claim, it is incomplete without the other half of the sentence: with SSD-streamed MoE experts, enough free disk, and published testing centered on specific Apple Silicon machines.

The next useful milestone would be a reproducible benchmark set across several M-series Macs using the same prompts, context lengths, and storage configurations. Right now, the project's best published grounding remains its Hugging Face deployment page and GitHub repository.

Key Takeaways

Gemma 4 26B-A4B is not best supported as a true 2 GB all-in-memory Mac model; the strongest citable project figure is about 3 GB resident RAM for Gemma-only with SSD-streamed experts.
The low-memory result depends on SSD offload, so the full model is not loaded into RAM at once.
Standard local Apple Silicon setups are materially heavier, at about 6 GB with llama.cpp memory mapping and about 13 GB for vanilla 4-bit MLX in the project's own comparison.
The model files themselves remain large, with cited quantized files ranging from about 9.97 GB to 16.6 GB and a 14.2 GB IQ4_XS example.
The project's own published guidance recommends 16 GB+ RAM and about 30 GB of free disk, which is narrower than “any M-series Mac.”

Frequently Asked Questions

Can Gemma 4 26B really run in 2 GB RAM on a Mac?

Not on the best citable evidence here as a full in-memory setup. The closest published figures from the project behind the claim put Gemma-only resident memory at about 3 GB, and that result depends on SSD-streamed experts rather than loading the whole model into RAM.

What stays in memory and what stays on disk?

The project's GitHub repository says hot experts and a small cache stay resident in DRAM, while cold experts are streamed from flash storage on demand. That is why resident RAM can stay low even when the actual model files are far larger.

How much RAM does Gemma 4 26B usually need on Apple Silicon?

In this source set, the range runs from about 3 GB resident RAM with Expert Sniper, to about 6 GB with llama.cpp memory mapping, to about 13 GB for vanilla 4-bit MLX on the project's own comparison page, with one downstream MLX report at about 26 GB. The runtime matters as much as the model.

Is the 2 GB claim useful for real Mac buyers?

Only partly. A resident-memory number is useful if you are debugging whether a runtime will fit, but it is not a full workflow spec. The same deployment page also recommends 16 GB+ RAM and about 30 GB of free disk, which is the more practical guidance.

References

Last reviewed: 2026-08

Originally published on novaknown.com

DEV Community: Simon Paxton

Rust Removed a Poisoned Arrayref Release After 86 Minutes Online

The three malicious crate releases were online for 86 to 107 minutes

Key Takeaways

Further Reading

Israel’s $900,000 US PR Pilot Targets AI Citations, Not Proven Chatbots

The $900,000 LaPam–Piro Digital Storytelling Pilot

Piro’s AI-citation pitch is real

The separate Clock Tower evidence

Key Takeaways

Further Reading

Thames Water’s Drought Plant Had Water to Treat. Not Membranes.

Beckton’s deployable output was written down to 25 Ml/d

Key Takeaways

Further Reading

Claude Mythos Finds Bugs Faster Than Teams Can Patch Them

Green’s Two-Year Prediction Concerns Remote Exploits

Glasswing’s 10,000-Finding Remediation Backlog

Independent Tests Show Both Capability Gains and Validation Limits

Key Takeaways

Further Reading

Firefox Keeps Full UBlock Origin. Brave Has a Side Door.

Brave’s hosted uBlock Origin exception

Key Takeaways

Further Reading

AMD’s Old DRAM Swizzle Is Real. the Universal Break Is Not

AMD’s documented BankSwizzleMode register enables the tested remap

Key Takeaways

Further Reading

Reasoning Logs Hid 704 Secrets. the Old Envelopes May Still Open

The 704 artifacts recovered from genuine public sessions

Key Takeaways

Further Reading

Anthropic, OpenAI and Google Reasoning Locks Met Their Own Spare Keys

The Cross-Model Decryption-Oracle Attack

Public Trace Scan Recovered Credentials and Personal Data

Provider Patches and Context-Bound Trace Design

Key Takeaways

Further Reading

Noreply.net Became a Mail Sink: and Nobody Checked the Drain

Generic noreply.net configurations created a durable mail sink

The expiration story is not established

Key Takeaways

Further Reading

SQLite’s Six Critical CVEs Were Bugs in a Database of Bugs

Six SQLite CVEs Reached NVD Before Rejection

Key Takeaways

Further Reading

Texas Just Made Grid Approval the Choke Point

Abbott’s August 3 audit freezes progress on queued data center connections

ERCOT’s Batch Zero process was already turning large-load interconnection into a screening gate

Texas is trying to shift power, water, and community costs back onto data center developers

Key Takeaways

Further Reading

Gemma 4’s 2 GB Mac Story Is Really SSD Streaming

What the 2 GB claim is actually measuring

How Gemma 4 26B-A4B normally fits on Macs

The speed and quality tradeoffs of SSD-streamed MoE inference

Key Takeaways

Further Reading

Frequently Asked Questions

Can Gemma 4 26B really run in 2 GB RAM on a Mac?

What stays in memory and what stays on disk?

How much RAM does Gemma 4 26B usually need on Apple Silicon?

Is the 2 GB claim useful for real Mac buyers?

References