November 9th Research Briefing

Contents

1. Metis: 137 new bugs in edk2 boot firmware, found with LLM-built harnesses
2. Proving the Wrong Program: compiler bugs that make zkVMs prove wrong results
3. ModelShield: 41 malicious models on Hugging Face, caught by what they do

Metis: 137 new bugs in edk2 boot firmware, found with LLM-built harnesses

Metis fuzzed 60 drivers of edk2, the reference UEFI firmware that vendors such as Intel, AMD, ARM, and Microsoft build on, and found 137 previously unknown bugs. The researchers have reported 26 so far, including 12 that are remotely triggerable, and the vendors acknowledged every reported vulnerability.

This matters because edk2 code runs before the operating system, so a bug there can enable bootkits that survive an OS reinstall, and boot firmware lacks mitigations such as ASLR. Earlier fuzzers mostly targeted post-boot SMI handlers, or ran the whole firmware in a simulator with harnesses that miss many input paths.

Metis rehosts each boot-time protocol as a normal Linux program. It writes mocks for the protocol's direct dependencies, so data that another protocol returns becomes a second input channel for the fuzzer. An LLM (Claude Sonnet 5.5 by default) generates the harnesses and mocks from templates, the UEFI specification, and the edk2 sources, and a compile check rejects broken code. AFL++ then runs each target for 24 hours with AddressSanitizer and UndefinedBehaviorSanitizer.

Mean line coverage reached 73.1%. On the 54 drivers that both tools could test, Metis averaged 72.5% against 42.1% for FuzzUEr, the previous state of the art. An LLM-only baseline with the same sources produced a running harness for only 25 of the 60 drivers. Metis also has limits: it rediscovered only 4 of 14 known CVEs that the researchers ported back into the tree, partly because some of those bugs need semantic oracles, not crash checks.

Authors: Datta Manikanta Sri Hari Danduri, Connor Everett Glosner, and Aravind Machiry (paper, pdf). Aravind Machiry: X, GitHub.

Proving the Wrong Program: compiler bugs that make zkVMs prove wrong results

Proving the Wrong Program showed that known Rust and LLVM miscompilations carry over to production zero-knowledge virtual machines (zkVMs). Of 88 known bugs, 48 made a guest program commit a wrong output on SP1 and 46 on Jolt, and the zkVM proves it as readily as a correct one. An LLM agent then wrote ordinary-looking patches that trigger such bugs in 12 of 366 project and bug pairs, across 11 of 20 SP1 projects, for about $40 per project.

This matters because a zkVM proof covers the compiled binary, not the source. A patch whose source is correct passes code review and even formal verification, while the buggy compiler builds a guest that computes something else. The attacker only needs a bug that the project's toolchain still contains, and toolchains update slowly.

Each reproducer was built with the buggy compiler and with the same compiler plus the upstream fix, and the two runs were compared. An LLM agent recovered Rust triggers for 60 of 124 LLVM bugs reported only as LLVM IR. Accidental impact is rare: across 13 guests of 10 popular SP1 projects, the two compilers produced byte-identical binaries in 447 of 552 guest and bug pairs.

In 4 of the 12 agent successes, the guest commits a wrong output. In ethrex, an Ethereum client, a patch to trie prefix counting made the buggy build report that a valid block from Ethereum's test suite failed validation. A bridge committed a validator bitmap with 8 bytes set to zero. In the other 8, the guest fails on a valid input, which can stall a rollup or bridge.

Authors: Hui Xuan Tan, Stefanos Chaliasos, and Alastair F. Donaldson (paper, pdf). Stefanos Chaliasos: X, LinkedIn, GitHub. Alastair F. Donaldson: X, LinkedIn, GitHub.

ModelShield: 41 malicious models on Hugging Face, caught by what they do

ModelShield scanned 145,000 models uploaded to Hugging Face, ModelScope, and Kaggle between March 25 and May 5, 2026, and found 41 malicious models, all on Hugging Face. One opened a reverse shell and had 108 downloads over three days without detection by the platform's scanners. Another ran reconnaissance commands, read /etc/passwd, and sent the results out over HTTPS. The researchers reported the malware to the Hugging Face Security Team, and Hugging Face removed the reverse-shell model within two days.

This matters because a model file can run code while it loads or runs inference, and current scanners mostly match function denylists on a few serialization formats. On the 41 models, ModelScan caught 29%, PickleScan 56%, Fickling 80%, and ModelAudit 93%.

ModelShield loads and runs each model and watches what happens. Wrappers on ML framework APIs tag each load or inference call with a correlation ID, and eBPF probes record the system calls that follow, including those in spawned threads and child processes. That link separates model-triggered activity from framework noise. The tool then matches the attributed syscall sequences against 195 patterns mapped to MITRE ATT&CK techniques. It supports 17 frameworks and 36 formats.

On the PickleBall evaluation dataset, it was the only evaluated tool with zero false positives, and it detected all 29 published evasion variants. The reverse shell used PyTorch's legacy tar-based loading path, which the paper calls the first documented in-the-wild use of that evasion. Median analysis time was 12.3 seconds per model. The code and advisories for the malware samples are public.

Authors: Hala Ali and Andrew Case (paper, pdf, code). Hala Ali: LinkedIn, GitHub.