The NHS retreats behind closed doors as AI-powered vulnerability scanners change the threat calculus, a single git push could have compromised all of GitHub, and MiniMax discovers that you can’t call something MIT-licensed if it isn’t. Here’s what matters today.
In a guidance note distributed April 29, NHS England told its development teams that all source code repositories must be made private by default, with a hard deadline of May 11. The stated rationale: “rapid advancements in AI models capable of large-scale code ingestion, inference, and reasoning” — a direct reference to Anthropic’s Mythos, the offensive cybersecurity model deemed too dangerous for public release. Teams that need exemptions must request them by May 6. The decision has drawn sharp criticism from the open source community. Critics note that neither the AI Safety Institute nor the NCSC recommend this action, and that making already-public code private doesn’t undo the fact that it’s been publicly accessible (and likely already ingested) for years. The deeper tension here is one the entire industry will have to grapple with: if AI tools can find exploitable vulnerabilities in any codebase faster than humans can fix them, is “security through obscurity” a rational interim response — or does it just eliminate the community review that finds and patches those bugs? For taxpayer-funded public health infrastructure, the stakes of getting this wrong in either direction are unusually high.
Critical GitHub RCE flaw (CVE-2026-3854) exposed millions of repositories through a single git push
Wiz researchers disclosed a command injection vulnerability on March 4 that allowed anyone with push access to a repository — including one they created themselves — to achieve remote code execution on GitHub’s servers via a crafted push option with an unsanitized character. The attack was trivial: a single git push command. On GitHub.com, the flaw gave access to shared storage nodes where millions of public and private repositories from other users and organizations were accessible. On GitHub Enterprise Server, it could lead to full system compromise. GitHub patched github.com within two hours of the report and found no evidence of prior exploitation. The bad news: GHES instances need version 3.19.3 or later, and data indicates 88% remain unpatched. For a platform that hosts the vast majority of the world’s open source code, this is exactly the kind of infrastructure-level vulnerability that should have every enterprise GitHub admin checking their version this week.
MiniMax dropped M2.7 with impressive benchmark numbers — competitive with Claude Opus on coding tasks — and initially released weights under what the community understood to be an open license. Then the LICENSE file on Hugging Face changed. The new “Modified MIT” license prohibits commercial use without prior written authorization and requires prominent “Built with MiniMax M2.7” attribution for any approved commercial deployment. The community response was immediate and scathing: MIT’s defining feature is its permissive commercial terms, so calling a non-commercial license “Modified MIT” is, as one attorney put it, “far more restrictive, as written, than what many are assuming.” MiniMax’s Head of Developer Relations explained that bad-faith hosting providers had been deploying degraded versions of earlier models, damaging MiniMax’s reputation — a real problem, but one that doesn’t require reinventing license taxonomy. This follows MiniMax’s January 2026 Hong Kong IPO, which raised roughly $620 million, and fits a pattern we’ve seen before: companies use open-weight releases to build developer mindshare during growth phases, then tighten the terms once public market investors start asking about monetization. Call it what you want, but don’t call it MIT.
PyCon US 2026 Packaging Summit to chart the future of Python packaging governance
The Packaging Summit at PyCon US 2026 is scheduled for May 15 in Long Beach, and it arrives at a pivotal moment for the Python ecosystem. PEP 772, which proposes a formal Packaging Council with broad authority over packaging standards, tools, and implementations, has been working through multiple rounds of community review since 2025. The PSF Board authorized the council’s creation last August, and elections for the five-member body are expected in June. If you’ve ever been confused by the overlapping jurisdictions of pip, setuptools, Poetry, PDM, uv, and the PyPA — or wondered who actually gets to make binding decisions about Python packaging — this is the governance structure intended to resolve that ambiguity. Coming just weeks after pip 26.1 shipped the ecosystem’s first standardized lockfile format, the timing suggests Python’s packaging story is finally getting both the tooling and the governance it has needed for years.
The Linux Foundation’s flagship event is two weeks out, with a schedule focused on AI infrastructure, software supply chain security, and the sustainability of open source at scale. Speakers from AWS, Google, Microsoft, Netflix, OpenAI, and others will address the rise of AI agents, embedded Linux innovation, and what it actually takes to sustain the open source projects that underpin modern infrastructure. The co-located events tell their own story about where the energy is: OpenSSF Community Day (May 21) will feature deep dives on SBOMs, digital signatures, post-quantum cryptography, and AI-driven remediation, while CNCF’s Observability Summit (May 21-22) covers how AI and MCP are reshaping observability. If the NHS repo closure story above is any indication, the conversations about AI’s impact on open source security are going to be especially pointed this year.
PyTorch Docathon kicks off May 5 — a two-week sprint to improve ML’s most critical documentation
The 2026 PyTorch Docathon runs May 5-19 under the PyTorch Foundation, starting with a live kick-off and Q&A tomorrow at 10 AM PT. Participants will refine technical documentation, test tutorials in CI environments, and help accelerate the transition from research to production. The event is explicitly designed to be accessible to all expertise levels, from newcomers to experienced ML practitioners. Documentation is one of those unglamorous contributions that disproportionately determines whether an open source project is actually usable — and for a framework as central to ML research and production as PyTorch, good docs are a force multiplier that benefits the entire ecosystem. If you’ve ever struggled with a PyTorch tutorial that didn’t quite work, here’s your chance to fix it for everyone who comes after you.