I was reading through the fix for a package manager CVE last week and ran into a git flag I’d somehow never noticed: --end-of-options. My first reaction was that some LLM had hallucinated it, but it’s documented in gitcli(7), it was added in git 2.24.0 in November 2019, and it exists because git had already used -- for something else.

In most Unix tools -- marks the end of option parsing, so rm -- -f removes a file called -f rather than passing the force flag. Git had repurposed -- early on to separate revisions from pathspecs, because git log foo on its own is ambiguous between a branch named foo and a file named foo and one of the two readings needed a marker: git log main -- README.md means commits on main touching that file. That left the revision position with no terminator, so if a script runs git log "$rev" and $rev starts with a dash, git parses it as an option.

From the commit that introduced --end-of-options:

But that doesn’t work for the revision parser, because -- is already meaningful there: it separates revisions from pathspecs. So we need some other marker to separate options from revisions.

-- and --end-of-options are different things in git, and treating them as interchangeable is a mistake I’ve now seen in several places. Putting -- before a URL in git clone -- "$url" works, because clone follows the POSIX convention. A trailing -- after a ref, as in git checkout "$ref" --, marks $ref as a revision rather than a filename but still lets it be read as an option first. Passing an untrusted revision safely means writing git log --end-of-options "$rev" -- "$path", with both markers doing separate jobs.

Support for the new flag arrived per subcommand rather than all at once: git rev-parse only got it in 2.30.0, a year after the initial release, because it has its own hand-rolled argument parser, and git checkout and git reset rejected it until 2.43.1 in February 2024 because they parse -- themselves and the initial implementation left --end-of-options in the argument list where their parsers rejected it.

Argument injection

Git, hg, and ssh all ship options whose documented purpose is to run a command the caller names. git clone accepts --upload-pack=<cmd> to specify the server-side binary, and any git invocation accepts -c core.sshCommand=<cmd> to override how it connects. Mercurial accepts --config=alias.<subcmd>=!<shell> on any subcommand, which redefines the subcommand you’re running as an arbitrary shell script. ssh accepts -oProxyCommand=<cmd>. These are documented features that become attack primitives when a wrapping program passes an untrusted string into the argument list.

The failure mode has its own CWE, CWE-88, argument injection, and it’s distinct from command injection because there’s no shell involved: the wrapping program builds an argv array and calls exec directly, exactly as every “don’t use system()” guide recommends, the array reaches git intact, and git then parses one of the arguments as an option because it starts with a dash. CVE-2019-13139 in docker build is a clean example: Go’s os/exec package, an argv array, no shell, and a git-context URL whose #ref:dir fragment reached git fetch origin <ref> as --upload-pack=<cmd>.

The pattern was demonstrated across four version control systems on the same day in August 2017, when CVE-2017-1000117 (git), CVE-2017-1000116 (Mercurial), CVE-2017-9800 (Subversion), and CVE-2017-12836 (CVS) were disclosed together. Each passed a URL’s hostname to ssh as an argument, and a hostname starting with -oProxyCommand= became an ssh option. Phabricator’s post-mortem on the disclosure noted that of the three actively maintained tools, only Subversion actually added -- before the hostname in its fix; git and Mercurial validated the hostname format instead, partly because -- isn’t supported by every ssh implementation. The same write-up called the -- mechanism itself “unsafe by default”, since code without it looks correct and works fine right up until an argument starts with a dash.

Package managers

Package managers routinely take a git URL or ref as data and pass it to a subprocess: gem 'foo', git: '...' in a Gemfile, github:user/repo#ref in a package.json, and equivalents in pyproject.toml, Cargo.toml, mix.exs, Package.swift, pubspec.yaml, conanfile.py, and go.mod. The URL and ref arrive in a manifest, a lockfile, or a transitive dependency’s metadata.

Of nineteen package managers I checked¹, seventeen fork the git binary as their default or only path. The two that default to a library are Cargo, which uses libgit2 with an opt-in net.git-fetch-with-cli setting to fork instead, and Poetry, which switched to dulwich in 1.2.0 with a system-git-client setting to fall back. Nix uses libgit2 for reading local repositories but forks git for fetches, because libgit2 lacks git-credential helper support.

The published CVEs against package managers in this class include CVE-2021-43809 (Bundler), CVE-2021-29472 and CVE-2022-24828 (Composer), CVE-2022-36069 (Poetry), CVE-2023-5752 (pip), CVE-2022-21223 and CVE-2022-24440 (CocoaPods), and CVE-2025-68119 (Go). The Snyk research that produced several of the 2022 entries is written up here, and Sonar maintains a catalogue of the dangerous options per binary.

Of the seventeen that fork git, exactly one uses --end-of-options: Go’s cmd/go. It added -- before repository URLs in June 2019 as a general hardening pass. In January 2026 that turned out to be insufficient and --end-of-options was added across the board as the fix for CVE-2025-68119, along with HGPLAIN=+strictflags, which has restricted Mercurial’s early-option parsing since hg 4.4.2 in 2017. The commit message ends: “We should probably follow up with a more structured change to make it harder to accidentally re-introduce these issues in the future, but for now this addresses the issue at hand.”

Minimum git versions

The other package managers that guard the argument list at all use -- or a leading-dash check on the input, and looking at when each guard was added, most arrived as the fix for a reported vulnerability rather than in the original implementation. The -- before the URL in Bundler’s git clone is the CVE-2021-43809 patch. The leading-dash rejection in cocoapods-downloader landed in three commits over ten days in March 2022, matching the CVE-2022-21223 disclosure. Poetry’s guard arrived in September 2021 with a CVE assigned a year later, and the switch to dulwich followed six months after that. vcpkg is the exception I found where -- was present from the day git registry support was written.

Composer’s advisory for CVE-2022-24828 explains why almost none of these tools use --end-of-options: it names the flag as the correct fix and then says Composer supports git versions that predate it, so the patch rejects leading-dash branch names instead. vcpkg’s git integration has a comment stating a floor of git 2.7.4. Homebrew’s HOMEBREW_MINIMUM_GIT_VERSION is 2.7.0 on Linux, set in 2018.

Amazon Linux 2, which packaged git 2.14.3, reached end of life last month, so the distributions those floors track are only now ageing out. Ubuntu 18.04 with git 2.17.0 is in extended support until 2028. Ubuntu 20.04, in extended support until 2030, packages 2.25.1, which is new enough to accept --end-of-options on git fetch but old enough to reject it on git rev-parse. Relying on the flag means raising the minimum git to 2.24.0 for most subcommands, 2.30.0 for rev-parse, or 2.43.1 for checkout and reset, and losing anyone still on the distribution-packaged git.

Git libraries

libgit2, gitoxide, go-git, JGit, and dulwich all implement enough of the git wire protocol to clone and fetch in-process, with no argv boundary and so no argument list to inject into. Jujutsu uses gitoxide for its git interop and has no published CVEs in the argument-injection class; its two advisories to date are a path traversal and a missing SHA-1 collision check inherited from the library. go-git has one, CVE-2025-21613, and it’s specifically on the file:// transport, the one code path in go-git that spawns the git binary.

I noted in the package manager CWEs post that this trades one problem for another, since a bundled git implementation has to track every checkout-safety fix upstream git ships, and libgit2 and JGit have both had rounds of those. That’s a real cost, but it’s a stream of specific patches to apply rather than a check that has to be remembered at every call site forever.

Writing this prompted me to open a PR against Homebrew raising its minimum git to 2.30.0 and adding --end-of-options before URLs in clone, remote set-url, and ls-remote, and before refs in rev-parse. The checkout and reset calls are left alone, since covering those would need a floor of 2.43.1, released February 2024, and that’s recent enough to still be ahead of several supported distributions.

Adblock test (Why?)

This story is wild. The short version: OpenAI were running a cybersecurity test against an unreleased model, with the model's guardrail features turned off. Rather than solve the test, the model broke its way out of OpenAI's sandbox, then found exploits to break in to Hugging Face, all so it could cheat on the test by stealing the answers.

Along the way it helped make the strongest case yet for how the imbalance of model availability is hurting our ability to secure our software.

Here's what happened

We currently have three documents to help us understand what happened here.

1. ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks? is a paper published on 11th May 2026 describing ExploitGym, a new eval suite for LLM-powered agent systems.
2. Security incident disclosure — July 2026 by Hugging Face on 16th July 2026 describes how they detected an attack from an "agentic security-research harness - used LLM still not known" that breached some of their systems.
3. OpenAI and Hugging Face partner to address security incident during model evaluation from OpenAI on 21st July 2026 confesses that it was their agent harness that did this, and that they're working with Hugging Face to clean up the mess.

ExploitGym

I hadn't seen the ExploitGym paper before and it's a really interesting one. Authors from UC Berkeley, the Max Planck Institute, UC Santa Barbara, and Arizona State designed a new benchmark for evaluating models on their ability to turn a reported vulnerability into a concrete exploit. OpenAI, Anthropic, and Google provided feedback and helped run the benchmark against their models.

The benchmark "comprises 898 instances derived from real-world vulnerabilities that affected popular software projects" - including the Linux kernel and V8 JavaScript engine.

Here's the paragraph that best represents their benchmark results:

Among all configurations, Claude Mythos Preview and GPT-5.5 achieve the highest success counts (157 and 120 successes, respectively), demonstrating that current frontier agents can exploit a substantial subset of real-world vulnerabilities under controlled conditions. GPT-5.4 also solves a notable 54 tasks, placing it in an intermediate tier. The remaining model–agent pairings solve fewer than 15 tasks each, underscoring that end-to-end exploitation remains challenging and sharply differentiates today’s frontier systems. Notably, Claude Opus 4.7 achieves fewer successes than Claude Opus 4.6 despite being a newer checkpoint, and does so at substantially lower cost on the full set. Trace inspection reveals that Claude Opus 4.7 and Gemini 3.1 Pro frequently conclude early after judging the target vulnerability non-exploitable.

The paper also describes the approach they took to preventing the agents from cheating by going outside the parameters of the test. This becomes relevant in a moment!

Outbound connections are restricted to a curated allowlist that permits routine package installation (Ubuntu apt repositories and PyPI) and fetching the toolchains required for building V8. All other external endpoints are blocked.

The paper concludes with this (emphasis mine):

Our results show that autonomous exploit development by frontier AI agents is no longer a hypothetical capability. While current agents are not yet reliable across all targets, they already exploit a non-trivial fraction of real-world vulnerabilities, including complex targets such as kernel components. This rapid emergence is itself a central finding, showing that capabilities that would have seemed implausible are now present in deployed frontier models.

An important detail here: this paper isn't about discovering vulnerabilities; it's about being able to take those vulnerabilities and turn them into working exploits.

When Anthropic first restricted access to Mythos back in April they talked about this capability as well. A model that can act on vulnerabilities is a lot more dangerous than one that can just discover them.

One of the ways Fable differs from Mythos is that it's more likely to refuse to weaponize vulnerabilities in this way. I get the impression the US government did not understand that distinction when they banned Fable last month.

The Hugging Face incident

The first hint we got of the attack was in this blog post by Hugging Face on 16th July 2026:

A malicious dataset abused two code-execution paths in our dataset processing (a remote-code dataset loader and a template-injection in a dataset configuration) to run code on a processing worker. From there, the actor escalated to node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a weekend.

I hope they release more details about the code that pulled this off. I'm assuming this means packages using the datasets library, a Hugging Face project for bundling up and sharing datasets on their platform. That library used to execute arbitrary code but has been steadily locked down over time, with the 4.0.0 release in July 2025 removing the trust_remote_code=True flag entirely.

Assuming the attack used that library it must have either abused pickle serialization in some way, found some other non-obvious code execution path, or (most likely) specified datasets<4.0.0 as the dependency.

The campaign was run by an autonomous agent framework (appearing to be built on an agentic security-research harness - used LLM still not known) executing many thousands of individual actions across a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services.

This was a sophisticated attack!

Then Hugging Face hit a wall: they tried to use "frontier models behind commercial APIs" - I'm guessing from Anthropic and OpenAI - to help analyze the attack, and were blocked:

When we started the log analysis, we first used frontier models behind commercial APIs. This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker.

They switched to their own self-hosted instance of MIT licensed GLM-5.2 and it helped them figure out what was going on.

This indicated a fundamental asymmetry between the defending team and the (so-far unknown) attacker:

We do not know which model powered the attacker's agents, whether a jailbroken hosted model or an unrestricted open-weight one; either way, the attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried.

As a useful indicator of how seriously they took the attack:

[...] Finally, we have also reported this incident to law enforcement agencies.

So who was responsible for this "autonomous agent framework"? It turned out to be OpenAI themselves.

The OpenAI confession

Five days later, on July 21st, OpenAI revealed the culprit. They had been running the ExploitGym benchmark against a new, as-yet undisclosed model, and that model had been operating way outside its intended parameters (emphasis mine):

After investigating, we now know that this particular incident was driven by a combination of OpenAI models — including GPT‑5.6 Sol and an even more capable pre-release model, all with reduced cyber refusals for evaluation purposes — while being internally tested on a benchmark⁠ [ExploitGym] of cyber capabilities. [...]

We estimate maximal cyber capabilities by running this evaluation without production classifiers used to prevent models from pursuing high-risk cyber activity. Our benchmarks run in a highly isolated environment, with network access constrained to the ability to install packages through an internally hosted third-party software that acts as a proxy and cache for package registries.

The models identified and chained vulnerabilities across OpenAI’s research environment and Hugging Face’s production infrastructure to obtain test solutions directly from Hugging Face’s production database. All evidence suggests that the models were hyperfocused on finding a solution for ExploitGym, going to extreme lengths to achieve a rather narrow testing goal.

It's pretty clear what happened here. OpenAI removed safety filters for an in-progress model, locked it up in a sandbox and told it to solve the ExploitGym problems. Given the absence of guardrails there was nothing to prevent the model from attempting to break out of that sandbox, break into Hugging Face, and read the answers from there instead.

OpenAI's sandbox used the now common pattern of allowing access to an allow-list of sites related to installing additional packages via a controlled proxy. In OpenAI's words:

While operating in our sandboxed testing environment, our models spent a substantial amount of inference compute finding a way to obtain open Internet access, in pursuit of solving the evaluation problem. To gain access, the models identified and exploited a zero-day vulnerability (which we’ve now responsibly disclosed to the vendor) in the package registry cache proxy. With this access, our models performed a series of privilege escalation and lateral movement actions in our research testing environment until the models reached a node with Internet access.

So step one was to break out onto the public internet. The model then broke into Hugging Face to find the answers:

After gaining Internet access, the models inferred that Hugging Face potentially hosted models, datasets and solutions for ExploitGym. Knowing this, the model searched for and successfully found ways to gain access to secret information that it could use to cheat the evaluation. In one example, the model chained together multiple attack vectors, including using stolen credentials and zero-day vulnerabilities to find a remote code execution path on the Hugging Face servers.

Chaining together multiple attack vectors is exactly the kind of thing these new models can do, where previous generations of models might have failed.

I wrote last month about how Claude Fable is relentlessly proactive, when I noticed it spinning up custom web servers and deploying CORS tricks on my own laptop just to help debug a WebKit CSS issue. It turns out relentless proactivity is the defining trait of this new generation of Mythos-class models. If you set them a goal and give them a way to get there, even inadvertently, they will figure it out.

Resist the temptation to write this off as a stunt

There will inevitably be some people who dismiss this story as a dishonest marketing trick by OpenAI to make their models sound terrifyingly effective. I found 81 instances of the term "marketing" in the Hacker News discussion of the incident.

To those people I say pull your heads out of the sand - you're now including Hugging Face in your conspiracy theories, just so you can deny the crescendo of evidence here!

The best models we have today have the ability to both find and exploit new vulnerabilities. The ExploitGym paper itself concludes that "autonomous exploit development by frontier AI agents is no longer a hypothetical capability", and this incident is a perfect example of exactly that.

The asymmetry is increasingly frustrating

One of the most infuriating details of this story is how Hugging Face, faced with an accidental and aggressive attack from one of OpenAI's models, were unable to then turn to OpenAI's models to help them fend off the attack.

The frontier models we have access to are increasingly being constrained in how much they can help us protect our software, heavily influenced by the US government's ongoing threat of export controls. Claude Fable 5 wouldn't even proofread this article for me! It insisted on downgrading me to a less capable model.

Meanwhile open weight models from China such as GLM-5.2, Kimi 3 and the new Qwen 3.8 Max appear to have none of these restrictions - and any restrictions that do exist can likely be fine-tuned out of them by modifying the weights

These constraints are meant to make us safer. I think there's a risk that the effect they are having is the opposite.

Tags: sandboxing, security, ai, openai, generative-ai, llms, hugging-face, anthropic, paper-review, ai-security-research

I’m announcing two new global feeds: a redesigned Global Shared Stories and a new feed called Good Reads.

Redesigned Global Shared Stories

Global Shared Stories has been in the sidebar for years, and for years it worked in a way I never liked. It was not the shares of everybody on NewsBlur. It was the shares of the accounts that the @popular account happened to follow, a list I put together by hand a long time ago and rarely touched. If you were on that list and you shared a lot, you decided what everybody else saw. If you shared one story a month and wrote a paragraph about why it mattered, you were drowned out by someone who shared thirty without a word.

So I rebuilt it. Every hour, NewsBlur now gathers every story shared across the whole site in the last few hours, caps each person at three so nobody can flood the pool, drops private blurblogs, and then picks a few worth reading. The picks accumulate, so the river stays deep enough to scroll back through.

The picking is done by Claude Haiku, once an hour, and it is worth being precise about what it does and does not do. It does not go looking for stories. It does not write anything. It only ranks stories that NewsBlur readers already chose to share, and the thing it weighs most heavily is the comment the sharer wrote, because a share with a few sentences attached is a share somebody thought about. It is allowed to pick nothing at all in a quiet hour, and in testing it regularly passes on half of what it is offered. If the API is ever unreachable, a plain heuristic takes over and the river keeps flowing.

Good Reads

The new feed in the sidebar is Good Reads, and it asks a question the other feeds do not: which stories did somebody finish and then do something about?

A story lands in Good Reads when at least two people read it closely, thirty seconds or more, and at least one of them then saved it, shared it, or trained it up. Finishing is not enough. Somebody has to have bothered to act. On top of that, the score is tilted toward feeds with few subscribers, so a story from a site with forty readers can beat a story from a site with forty thousand. That tilt is the whole point. The big sites do not need help getting seen.

Four feeds, four questions

There are now four curated rivers sitting together in the sidebar, and the reason there are four and not one is that they each answer a different question.

Global Shared Stories asks what people chose to hand to someone else. It runs on sharing, a deliberate human act.

Widely Read Stories asks what held the most attention across NewsBlur. It runs on reading time, not clicks, so a headline nobody read cannot buy its way in.

Long Reads asks what was worth an afternoon. Features and essays that readers gave real time to, rather than skimmed.

Good Reads asks what somebody finished and then kept, and leans toward the small sites you have probably never heard of.

Widely Read Stories and Long Reads have been around since April, and I wrote about how they work when they launched. None of the four ranks by clicks, and none of them is trying to keep you scrolling. They are all built out of what NewsBlur readers actually did with their time.

Because it was never obvious from looking at them which was which, each of the four now explains itself in a line at the top of its story list. It scrolls away with the stories, so it is there when you arrive and gone once you are reading.

Your classifiers still apply to all four. If you have trained a tag, an author, or a site, those green and red scores carry through, including on stories from feeds you do not subscribe to. And all four work as dashboard rivers, so you can park any of them next to your regular feeds.

Good Reads and the rebuilt Global Shared Stories are available now on the web. If a story shows up in one of these feeds that clearly should not have, I want to hear about it on the NewsBlur forum.

Adblock test (Why?)

How do you speed up computational Python code? A common, and useful, starting point is:

1. Pick a good algorithm.
2. Use a compiled language to write a Python extension.
3. Maybe add parallelism so you can use multiple CPU cores.

But what if you need more speed? Consider the following real problem, one of the steps in scikit-learn’s gradient histogram boosting algorithm:

• You have a large array of floating point numbers.
• You want to assign them to the integer range 0-254, spread out evenly.

scikit-learn implements this by splitting up the full range of float values into 255 buckets, creating a sorted array of bucket boundaries, and then using binary search to choose the appropriate bucket for each value. The binary search is implemented in a compiled language, and it can run in parallel on multiple cores.

Recently, as part of my work at Quansight, and inspired by two posts by Paul Khuong, I sped up this implementation significantly. How? By making sure the code wasn’t fighting against the CPU.

In this article I’m going to walk you through that speed-up, demonstrated on a simplified example. Then I’m going to demonstrate a series of additional optimizations, with the final version running 6× faster than the original one.

It’s worth knowing that I will be speeding through mentions of many different low-level hardware topics: instruction-level parallelism, branch (mis)prediction, memory caches, SIMD, and more. This is only one article, it can only briefly introduce you to what’s possible, it can’t function as an in-depth tutorial. So I’ll talk about how you can learn more about these topics at the end of the article.