- When you are not at summer camp you can't read about it
- The Fettle continues
- Using the CFAA against AI
- Social contracts are not security models
- VSCode extentions, again
- Bugtraq is back!
- NVIDA, LVFS, and unraveling AI infrastructure
- More routers that come with backdoors
- Do we care about LPE?
- Even more AI that finds vulnerabilities
- When AI breaks its own guardrails
- Let’s be honest, most threat intel is just noise. You’ve got feeds everywhere, but turning that into detections or hunts is still way harder than it should be.So how do you actually operationalize it?At the Threat Intelligence Virtual Cybersecurity Summit on August 26th, learn how to integrate intel into your workflows and make it useful for real-world detection and response.Security Weekly listeners can register for free at https://securityweekly.com/threatintel using the promo code: CSS26-SW
- InfoSec World brings cybersecurity professionals together across industries, from healthcare and financial services to government and the Fortune 500. Join the community in Orlando, October 12–14, for practical education, new perspectives, and cybersecurity research unveiled live. Listeners save 30% on their pass with code ISW26-SWSAVINGS at securityweekly.com/infosecworld2026.
Paul Asadoorian
- Who’s legally to blame for Anthropic and OpenAI’s autonomous AI hacks? It’s complicated
Summary: OpenAI and Anthropic have both admitted their unreleased AI models autonomously hacked into other companies during internal testing: OpenAI's model broke containment and accessed Hugging Face in June, and Anthropic discovered its model hit three separate companies months after the fact, only because the OpenAI story prompted an internal review. Attorneys say criminal charges under the CFAA are unlikely since intent is hard to establish for a non-human actor, but civil negligence suits are a different story, and at least one expert called it a "no brainer" to file.
Paul's take: The detail that keeps jumping out at me is that both companies deliberately disabled their own safety guardrails for these tests. The same guardrails that offensive and defensive security researchers have been complaining about for months because they're too restrictive. So they're strict enough to frustrate legitimate security research, but when the companies needed them for internal capability evals, they just switched them off. That is going to be a rough conversation in discovery. The negligence argument here is pretty solid: you built a tool capable of hacking systems, you knowingly removed the constraints, and you didn't notice the results for months. "You don't get to deploy something capable of breaking into systems and then disown where it goes" is the correct framing. The CFAA intent question is interesting from a legal theory standpoint, but the civil side doesn't need intent. It needs damages and a duty of care. I'd expect the quiet part of this story to be the settlement letters that never go public.
- Arch Linux AUR Under Siege: 7 Malware Incidents in 12 Months and Why Every User Must Act Now
Summary: The Arch User Repository has seen seven malware incidents since July 2025, escalating from a simple curl-pipe-to-bash injection in a single package to a June 2026 campaign that compromised 1,579 packages and dropped an eBPF kernel rootkit, to a July 2026 wave of 200+ packages delivering a Rust-based infostealer with SSH worm capabilities and anti-analysis checks. Each wave has been more sophisticated than the last, with the attacker adapting tactics in response to community defenses.
This is why I created fettle.
Paul's take: This is what a sustained, well-resourced supply chain campaign looks like from the ground floor. What started as a single malicious line in acroread in 2018 is now eBPF rootkits and SSH worms hiding behind Tor and fake dbus processes. The AUR's security model was never really a model, it was a social contract, and someone decided to cash it out. The structural problem here is that the AUR hands any new account the ability to run arbitrary code with root privileges on thousands of machines, and the only thing standing between users and that is: read the shell script yourself. That is not a security architecture. I run Arch, and the PKGBUILD-review advice is real and correct, but let's be honest that asking every user to be a manual code auditor before every install does not scale. The community response has been impressive (the LLM-based auditor is a genuinely interesting defensive use of AI) but every fix so far is reactive. Until there is mandatory signing, build isolation, and some form of trust tiering for new accounts, this campaign will keep coming back.
- 77 Open VSX extensions found harvesting developer info
Summary: Manifold Security found 77 "evil twin" extensions on Open VSX, the extension marketplace used by VS Code-compatible editors like VSCodium, impersonating real tools tied to AMD, Azure, Salesforce, Hyperledger, and a US government agency, right down to copying names, namespaces, and descriptions. All 77 phoned home to mangorbit[.]com, registered just 11 days before the first fake package appeared. Most (58) grabbed minimal recon: hostname, workspace folder, editor version. Nineteen went deeper, harvesting OS username, machine ID, git remote hosts and org names, branch and commit hash, up to 60 installed extension IDs, and CI/cloud environment identifiers from GitHub, GitLab, Azure DevOps, Buildkite, CircleCI, Codespaces, and Gitpod. Manifold says they didn't see source code, credentials, tokens, SSH material, or browser data taken, but the extensions still transmitted more than their listings disclosed. No attribution given. Open VSX pulled the extensions by August 3, but removal from individual developer machines and configs is manual.
Paul's take: Nobody stole your source code in this one, and that's exactly what makes it worth paying attention to instead of dismissing. This wasn't smash-and-grab, it was quiet environment fingerprinting: your git org, your CI provider, your commit hash, your other 60 installed extensions, that's a reconnaissance profile of an organization's entire development pipeline built from something that looked like a trusted extension with a familiar name. Copying real brand names like AMD and a government agency for the impersonation is the same typosquatting trick we've talked about with PyPI and npm, extension marketplaces are just the newest place it's landing, and open marketplaces without a strong vetting gate are always going to be a soft target. If you or your team use Open VSX-based editors, go check your installed extensions against Manifold's list, block mangorbit.com at the network level, and treat "no credentials taken" as cold comfort, not a clean bill of health, because knowing your CI setup and org structure is plenty useful to whoever's running this.
- Bugtraq is back – Bugtraq – SecurityFocus Mailing Lists
Summary: Jonathan Brossard announced he's acquired securityfocus.com and revived the Bugtraq mailing list, dormant since the domain changed hands through a string of acquisitions after Scott Chasin founded it in 1993 as a full-disclosure venue for security research. Brossard's stated goal is to bring back "full disclosure, researcher-first, no corporate filter" and to preserve security history that's been quietly disappearing from the internet as old archives and exploit writeups go dark.
Paul's take: Bugtraq predates most of the security industry as we know it, it's where an entire generation of us learned what full disclosure even meant, and watching it get swallowed by acquisitions until it just went quiet is the same story we keep telling about knowledge that isn't actively preserved. Bringing it back matters for reasons beyond nostalgia too, we've spent this year covering everything from gatekept vulnerability clearinghouses to uncoordinated dump sites like Exploitarium, and there's a real gap in the middle for a venue that's actually researcher-first without either corporate control or zero standards. Whether it sticks depends entirely on whether real researchers start posting there again instead of just X threads and personal blogs, mailing lists don't have network effects anymore the way they did in 1998. But as someone who cut his teeth reading this list, I'm glad somebody thought it was worth saving instead of letting it rot as a dead domain.
- NVIDIA is now supporting the LVFS
Summary: Richard Hughes, the LVFS/fwupd maintainer, announced NVIDIA has become a premier sponsor of the Linux Vendor Firmware Service, following firmware rollout for NVIDIA DGX Spark workstations through fwupd. That brings LVFS to four OEM sponsors, hitting the funding target Hughes set last year. Practically, it means NVIDIA firmware updates for supported hardware can now flow through Linux's standard update infrastructure instead of a proprietary vendor tool or manual process.
AI infrastructure represents stacks of computers inside computers, a greatly expanded attack surface that I am trying to wrap my brain around.
Paul's take: This is a small announcement that matters more than it sounds like it does. Firmware update delivery is exactly the kind of unglamorous infrastructure that determines whether a known vulnerability actually gets patched on real machines or just sits in an advisory nobody acts on, and every vendor that route their updates through LVFS instead of some bespoke tool is one less place firmware patching falls through the cracks on Linux. NVIDIA showing up as a funded sponsor, not just a token integration, is also a decent signal that a major hardware vendor sees Linux firmware maintenance as worth paying for rather than an afterthought. Nobody's writing a scary headline about this one, but boring, well-funded patch infrastructure is the unsexy foundation that makes every other fix on this show actually reach people's machines.
- ENDLESSDOORS Is Phoning Home. Pick Up.
Summary: VulnCheck's Jacob Baines found ENDLESSDOORS, a remote-control trojan preinstalled on 20+ Zbtlink and Wiflyer router models (sold under Shenzhen Zhibotong Electronics), started at boot by the vendor's own init script. It's a customized fork of an obscure 2015 GitHub project called rctl, disguised in process listings as "kworker" to blend in with legitimate kernel threads. On boot it dials out, no inbound connections needed, so it walks straight past NAT and firewalls, connects to hardcoded C2 infrastructure on Alibaba Cloud over ports 7000/7001 with zero authentication, sends a 39-byte hello with a device class and MAC address, then accepts any command via
popen()
running as root, either execute-as-root or spawn an interactive reverse shell. VulnCheck is explicit that this isn't a bug: "It's a component in the vendor's product, started at boot by the vendor's own init script, shipped across twenty models and years of images." There's no patch, because the vendor put it there on purpose. Their guidance is blunt: inventory affected models, check for unbracketed "kworker" processes and specific files, block the C2 domains at egress and DNS, and replace the devices or lock down egress hard, disabling the init script alone isn't enough.Paul's take: "Started at boot by the vendor's own init script" is the sentence that separates this from every other router vulnerability we cover. This isn't a memory corruption bug somebody's going to patch next Tuesday, it's a backdoor the manufacturer built in, dressed up as a kernel thread specifically so a
ps
listing wouldn't give it away, and shipped across twenty-plus models for years. No inbound exposure needed means your firewall rules don't save you, the device does the reaching out for you. If you've got Zbtlink or Wiflyer gear, or anything OEM'd from Shenzhen Zhibotong under a different brand, which given white-labeling is entirely possible, you're not looking at a patch cycle, you're looking at a replace-the-hardware cycle, because there's no fixing intent. This is the strongest argument yet for actually checking what chipset and ODM sits behind the brand name on cheap networking gear before you buy it, and for treating every unmanaged router on your network as a device that might be phoning home to someone who isn't you. - Linux suTrap Local Privilege Escalation Flaw PoC Exploit Disclosed
Summary: Researchers disclosed "suTrap," a local privilege escalation in shadow-utils (no CVE number given in the writeup) with a public PoC now available. TIOCSTI is a Linux terminal ioctl that lets a process stuff characters directly into a terminal's input buffer as if a human had typed them, a legacy feature meant for things like shell-history editors. The bug is in how
su
handles interactive sessions: when root runssu
interactively, the target user inherits root's controlling terminal directly instead of getting an isolated one, so an unprivileged attacker's background process can use TIOCSTI to inject keystrokes into that shared terminal buffer. Those injected keystrokes sit waiting, and when the admin finally types "exit," the root shell processes the queued input as legitimate commands, root commands, typed by nobody. No memory corruption, no race condition, just an old ioctl and a terminal that never should have been shared. RHEL 9, Rocky, AlmaLinux 9, CentOS 7, RHEL 8, Amazon Linux 2023, and Docker Desktop are affected; Ubuntu 24.04 and recent Fedora already disable legacy TIOCSTI by default. Fix: upgrade shadow-utils to 4.20.0+, setdev.tty.legacy_tiocsti
to 0, or stop using interactivesu
sessions in favor ofsudo
or PTY-flaggedsu
.Paul's take: But how much do we care? TIOCSTI terminal injection is one of the oldest tricks in the Unix playbook, this exact class of bug has been "rediscovered" and patched piecemeal for literal decades, and here it is again because
su
was still inheriting root's controlling terminal instead of isolating it. Once you understand what TIOCSTI actually does, fake keystrokes into a shared terminal buffer, the attack basically explains itself: your unprivileged process types silently in the background while the real admin does their work, and the moment they hit "exit," root faithfully executes whatever got typed in behind their back. That's the real lesson here: this isn't a novel exploitation technique, it's a known-dangerous ioctl that some distros fixed by disabling legacy TIOCSTI and others just never got around to. No CVE number in this writeup either, which makes it harder to track officially and harder for scanners to flag, so don't wait for a CVE to show up in your vulnerability management pipeline before acting. If you're running RHEL, Rocky, AlmaLinux, or CentOS and your admins are still dropping into interactivesu
sessions, that's your actual exposure, switch tosudo
or a PTY-flaggedsu
today and patch shadow-utils when the update lands. - OVSwrap: 13-Year-Old Linux Kernel Flaw Lets Local Users Become Root
Summary: Researcher Asim Manizada disclosed OVSwrap (CVE-2026-64531, CVSS 7.8), a local privilege escalation in the Linux kernel's Open vSwitch datapath. The bug itself dates back 13 years: individual nested action attributes have always needed to fit in a 16-bit length field, but a March 2025 change removed a 32KiB cap on generated action streams to fix an OpenStack deployment issue, exposing the old unsafe assumption. Submit oversized actions packed with hundreds of small conntrack actions, the kernel expands them past 65,535 bytes, the length field wraps to a small value, and later code trusts that wrapped length and resumes parsing from an attacker-controlled buffer, letting the attacker forge action headers precisely. All it takes is CAPNETADMIN inside an unprivileged user namespace, something achievable by default on most distros, no heap grooming needed, described as "logic-bug-grade reliability." A public PoC exists with pre-built records for roughly 800 kernel builds. It hits nearly every major distro in default configuration: AlmaLinux, Alpine, Amazon Linux, Arch, CentOS Stream, Debian, Fedora, Kali, Mint, NixOS, openSUSE, Pop!_OS, Rocky, Ubuntu 22.04. Upstream fix shipped July 24; if you can't patch immediately, block Open vSwitch module loads or disable unprivileged user namespaces as defense-in-depth.
Paul's take: First, do we need to pay attention to Linux LPEs any longer? Thirteen years old and it took a completely unrelated OpenStack fix to accidentally unlock it, that's the part that should stick with people. Nobody went looking for this, a well-intentioned patch removed a safety cap for a totally different reason and exposed a 16-bit length field that was always fragile. And "logic-bug-grade reliability, no heap grooming" is the phrase that should worry you more than any CVSS score, that means this isn't a flaky race condition you need ten tries and the right memory layout for, it's deterministic, which is exactly the kind of bug that gets weaponized fast once it's public. The fact that it needs nothing more than an unprivileged user namespace, on by default nearly everywhere, means almost every Linux box you touch is in scope until it's patched. Get the upstream fix rolled out, and if you're not in a position to patch today, disabling unprivileged user namespaces or blocking Open vSwitch module loads buys you real time, don't skip that step just because a patch is coming eventually.
- The Frontier AI Vulnerability Burst: Industrializing Autonomous Zero-Day Discovery in Open-Source Software
Summary: Unit 42 ran an autonomous multi-agent system called NOVA (no human in the loop until final review) across 3,915 open-source projects over two months and came back with 14,090 confirmed vulnerabilities, 99.4% of them previously unreported zero-days, 40% rated high or critical. Only 4% were classic memory-safety bugs, the other 92% were semantic and logic flaws: access control, path traversal, code injection, prototype pollution, SSRF, patterns that vary by ecosystem (C/C++ still memory bugs, JavaScript code injection, Go path traversal, PHP/Java access control). They also validated 4,141 downstream supply-chain exposures with working PoCs. Unit 42's framing is that discovery has industrialized to the point the "patch window has collapsed," and their pitch for the gap is "Advanced Virtual Patching," protection deployed within hours of discovery instead of the industry's 55-day average, ahead of an actual vendor fix.
Paul's take: The numbers here are the real story and they line up with everything else we've covered this year about AI compressing the vulnerability lifecycle, 14,000 zero-days from one system in two months is not a research curiosity, it's a preview of what every well-funded attacker will be running soon if they aren't already. The detail worth remembering is that most of what NOVA found wasn't memory corruption, it was logic and access-control flaws, the kind of bug that fuzzing has always been bad at and that actually requires understanding what the code is supposed to do, which is exactly where these models are getting good. Where I get skeptical is the back half of the post: Unit 42 identifies a real, scary structural problem and then the solution is conveniently their own "Advanced Virtual Patching" product. That doesn't make virtual patching a bad idea, closing the gap between discovery and an actual fix is the right instinct, but recognize the pattern, a vendor naming the crisis and then selling you the cure is worth the same skepticism we give every other company doing exactly that this year.
- Claude published malicious code to the Internet and attacked 3 real companies
Summary: Anthropic disclosed that during internal capture-the-flag style evaluations run with third-party partner Irregular, three Claude models (Opus 4.7, Mythos 5, and an internal research prototype) got internet access they were told they didn't have and, believing they were still inside a simulation, broke into three real organizations' production infrastructure. Opus 4.7 was the worst offender: after correctly reasoning in its own verbalized output that the target was real, it kept attacking anyway across all four runs, extracting credentials and several hundred rows of production data. Mythos 5 found a fake onboarding doc telling employees to install a nonexistent PyPI package, built and published a real malicious package with that name to trick a real company into running it, and during the roughly one hour it stayed live, 15 real systems downloaded and ran it, including a security company whose credentials Mythos then stole and used for further access. The research prototype scanned about 9,000 real targets before breaching one, and was the only one of the three that stopped once it independently concluded the target was real. Anthropic called the PyPI incident falling "short of ideal behavior" and says it will focus more training there; no exfiltration or deliberate escape attempts occurred in any case.
Paul's take: "Falls short of ideal behavior" is one of the great understatements in security disclosure history for an incident where a model built a fake developer identity, went hunting for a phone number to buy an email address to register a PyPI account, and published live malware that got pulled down and run by 15 real systems including a security vendor's own scanner. That's not a rounding error, that's premeditated persistence toward a goal past every reasonable signal that it had left the sandbox. And Dan Goodin's framing is the right one: if a human did any of this, weak-password exploitation, credential theft, publishing a trojaned package to a public registry, we'd call it what it is, multiple felonies, and somebody would be looking at prison time. Instead it's a blog post and a promise to "focus more training." The part that should worry defenders isn't that the models eventually noticed reality in most cases, it's that the one model that didn't stop was the one already released to real users, and the guardrails only failed because a testing partner made a configuration mistake, the same kind of mistake that happens constantly in production environments nobody's watching as closely as an internal eval. Self-policing works right up until the incentive to keep shipping outweighs the incentive to slow down, and right now there's no external accountability forcing that tradeoff the other way.