A fake take-home coding interview turns out to be a malware delivery operation hidden in a git pre-commit hook; a race condition in Linux's XFS filesystem gives root on an estimated 16.4 million systems; and PyPI now blocks new uploads to any release older than 14 days to close a supply-chain attack window

Qualys

RefluXFS: A Linux Kernel Local Privilege Escalation to Root in XFS (CVE-2026-64600)

Qualys researchers disclosed a race condition in the Linux kernel's XFS filesystem, present in every kernel since v4.11 (2017) on systems with the reflink feature enabled, that lets an unprivileged local user escalate straight to root. By Qualys's estimate the vulnerable configuration is running on roughly 16.4 million systems worldwide. The exploit is unusually clean as these things go: it's reliable rather than probabilistic, leaves no trace in kernel logs, bypasses SELinux enforcement entirely, and survives a reboot once triggered — which means kernel patching is the only dependable mitigation, since there's no reliable way to detect after the fact whether a given system was already compromised.

PyPI Blog

PyPI Releases Now Reject New Files After 14 Days

The Python Package Index now refuses new file uploads to any release more than 14 days old, closing off a specific supply-chain attack window: if a maintainer's publishing token or CI workflow is compromised months after a release has shipped, an attacker could previously still slip a malicious file into that old, trusted, long-stable version. 'As far as we are aware this has not yet been abused,' writes PyPI's Seth Larson, 'but there is no technical reason beyond that attackers weren't aware it was possible' — the fix closes a door before anyone's walked through it rather than in response to an incident. The change reached consensus at the Packaging Summit at PyCon US 2026 after PyPI's own historical analysis found the restriction would have had minimal impact on legitimate workflows, and a formal standard (PEP 694) is planned so other registries can adopt the same pattern.

Codeberg

Protecting Our FLOSS Commons From LLMs

Codeberg, the nonprofit, community-run alternative to GitHub, announced it will not use hosted user or project data to train AI models and will prohibit 'vibe-coded' submissions — contributions generated primarily by an LLM with minimal human understanding of the result. The reasoning is explicitly about protecting a commons rather than banning a technology outright: Codeberg argues that large-scale LLM crawling and AI-generated contributions impose real infrastructure costs on volunteer-run hosting, add unreviewable maintainer workload, and erode the norms of mutual understanding that open-source collaboration depends on, even before questions of environmental cost or training-data provenance enter the picture.

CrucibleBench

Can a MUD Evaluate LLMs? A $99 Proof of Concept

A small team built CrucibleBench, an LLM eval that drops 13 frontier models into persistent text-adventure worlds (MUDs) where NPCs remember prior interactions and trust has to be built over time, running 650 sessions total for about $99 in API spend (101 points, 70 comments on HN). The interesting result wasn't the leaderboard — it was what happened when they checked their own measurement instrument: two of the four behavioral dimensions leaned on an LLM-as-judge classifier, and removing those two dropped one frontier model six leaderboard positions. Checking that classifier against a second independent judge found per-model agreement ranging from 85% down to 22%, with an aggregate kappa of just 0.04 on one dimension — and the model most affected by the disagreement happened to share a model family with the judge itself. The authors are careful to call this an observation rather than proof of bias, and they're upfront about the study's limits (50 runs per model, no human raters, a tiny environment), but the finding they think actually generalizes is the judge-disagreement problem itself, not their pilot leaderboard.

Mitchell Hashimoto

Everyone Should Know SIMD

Mitchell Hashimoto makes the case that SIMD (processing multiple data elements with a single instruction) is a far more approachable optimization than its reputation suggests, walking through a real example pulled from the Ghostty terminal emulator to lay out a five-step framework for vectorizing a hot loop by hand. The payoff in his example is roughly a 5x throughput improvement on ordinary CPU hardware, but his broader argument is less about the speedup and more about control: modern compilers can auto-vectorize simple loops already, but that auto-vectorization is fragile and can silently regress with an unrelated code change, whereas explicit SIMD gives you a performance characteristic you can actually reason about and defend in review.