Subscribe Share Full episode and show notes Vulnerability Management , AI/ML , AI benefits/risks 1999 Called and It Wants It’s Exploits Back – PSW #935 This week, our technical segment covers a new open-source tool written by Paul (and Claude) that helps you keep your Linux systems up to date and assess supply chain risks. It’s called “fettle” and is a pure Python implementation that gives you even more features than previously discussed! Then in the security news: The GodDamn Ransomware , CMMC suspended, Holy Microsoft Tuesday!, Lessons learned, Without the Internet, do we still get water?, The forgotten shims, More than two BIOS passwords, Cracking firmware encryption with Claude, 1999 called, and it wants its “Exploits” back, Prompt injection for defenders, Grok has your repo, You’re not going to outpatch AI. July 16, 2026 Full Segment Notes This week, our technical segment covers a new open-source tool written by Paul (and Claude) that helps you keep your Linux systems up to date and assess supply chain risks. It's called "fettle" and is a pure Python implementation that gives you even more features than previously discussed! Then in the security news: The GodDamn Ransomware CMMC suspended Holy Microsoft Tuesday! Lessons learned Without the Internet, do we still get water? The forgotten shims More than two BIOS passwords Cracking firmware encryption with Claude 1999 called, and it wants its "Exploits" back Prompt injection for defenders Grok has your repo You're not going to outpatch AI Hosts Paul Asadoorian @0offset https://securitypodcaster.com Larry Pesce @haxorthematrix https://www.finitestate.io/ https://breakstuffforfun.com/ Lee Neely Announcements Let’s be real. Your scanners are dumping thousands of vulns, half of them noise, and you still don’t know what’s actually exploitable in your environment. Patching everything isn’t possible, and chasing CVSS isn’t working. At the Vulnerability Management Virtual Cybersecurity Summit, learn how to prioritize based on exploitability, reduce false positives, and actually fix what matters. Security Weekly listeners can register for free at https://securityweekly.com/vulnmanagement using the promo code: CSS26-SW CyberRisk TV is proud to be an official media partner of Black Hat USA 2026! We'll be broadcasting live from the Black Hat LIVEWIRE Studio with technical interviews covering offensive security, detection, response, infrastructure, and the tools practitioners use every day. Our Executive Interviews and Event Momentum Packages keep your message in front of the security community long after Black Hat wraps up. Fewer than 10 interview opportunities remain, so visit https://securityweekly.com/exec today and secure your spot before they're gone. List of Articles Paul Asadoorian Claude Flaw Automatically Sends Malicious Prompts to AI Agents Vulnerabilities of Realtek SD card reader driver, part2 AI Compresses the Vulnerability Lifecycle to Hours Summary: Past the "AI finds bugs fast now" setup, Deepak Gupta gets into why patching can't keep up: testing bottlenecks, change management built for weekly, not daily patch volume, combinatorial dependency conflicts when shared libraries like OpenSSL or glibc need simultaneous updates, and security teams already short by an estimated 4 million people globally. His fix is a three-tier speed-first architecture. Tier 1 auto-patches low-risk systems (dev, staging, containers) the same day with no human in the loop. Tier 2 targets 72 hours for standard production systems using pre-approved emergency change windows, automated regression testing, and canary rollouts with automated rollback; human review happens after deployment, not before. Tier 3 caps even crown-jewel critical systems at 7 days, using pre-built playbooks and pre-authorized decisions instead of case-by-case approval. He backs all of it with compensating controls for the gap that always remains: RASP, WAF virtual patching, network segmentation, and behavioral detection that catches post-exploitation behavior instead of trying to fingerprint the exploit itself. Paul's take: The tiering is the right idea; not every system deserves the same ceremony, but the part everyone's going to gloss over is "human review happens after deployment, not before." That's a real cultural fight in most orgs, because it means trusting automated regression gates enough to let a patch go to production unattended, and most change management processes exist precisely because somebody got burned trusting automation once. He's also honest that 7 days is a ceiling now even for critical systems, which is a brutal number for a team that's already short-staffed by millions industry-wide; tiering doesn't fix a headcount problem; it just triages it. The part I actually buy without reservation is the shift toward behavioral detection and network segmentation as the real safety net. You're never going to out-patch an AI that finds exploits in hours, so the honest answer is stop betting everything on the patch race and put more weight on catching what a compromised system does after the fact; that's a strategy that survives even when the patch window keeps shrinking. The serpent’s tongue: Luring the Python out of its den Summary: Talos put together a field guide to how malicious Python packages actually execute code on your machine, ten-plus techniques split between build-hook abuse (setup.py tricks, .pth files, sitecustomize.py, PYTHONPATH manipulation, all of which fire automatically on install) and package-content abuse (payloads in __init__.py or __main__.py , entry-point hijacking, name-collision squatting). They cite GitHub's numbers: malware advisories up 69% year over year, 17% of all advisories now tied to the pip ecosystem, and call out TeamPCP running 20 waves of supply chain attacks including a litellm compromise. No user interaction needed; payloads can run within minutes of pip install , and even packages pulled within hours still leave a real exploitation window. Paul's take: This is a genuinely useful reference, not just a scare piece, because it maps the actual mechanics instead of just saying "supply chain attacks bad." The part that should stick with people is how many of these fire before you ever import anything on purpose; a .pth file or a sitecustomize.py hook runs just because the package got installed, no import evil_thing required. And the target list has quietly expanded: it's not just developers anymore, it's CI/CD pipelines, cloud infra, and now AI tooling that pulls in packages on an agent's behalf without a human even reading the dependency tree first. Talos's own conclusion is the right one: no single control saves you, pin your dependencies with hashes, scan before install, isolate your build environments, and stop treating "it's on PyPI" as a trust signal. xAI Grok CLI Exposed Developer Code Through Automatic Whole-Repository Uploads Summary: Researcher cereblab found that xAI's Grok CLI coding agent (version 0.2.93) was silently uploading entire Git repositories, full commit history, unread files, and all, to xAI's infrastructure regardless of what the agent actually needed for the task. That included test .env files with credentials, transmitted unredacted, and a 12GB test repo pushed over 5GB before testing stopped. Disabling the "improve the model" telemetry toggle didn't stop it, because a server-side setting kept upload enabled anyway. xAI has since flipped disable_codebase_upload: true server-side and added an opt-out, though it's described as a data-retention setting rather than something that actually blocks the upload, and Musk's public promise to delete previously uploaded data hasn't been independently verified. Paul's take: "Turning off the privacy toggle doesn't turn off the upload" is the whole story right there. That's not a bug; that's a design decision somebody made: ship the whole repo to the mothership by default and let the opt-out control what happens to it after the fact rather than whether it happens at all. Full commit history plus unredacted .env files means every secret that was ever committed and later "removed" is potentially sitting on xAI's servers now, and a promise to delete it isn't the same as proof it's gone. If you're running any AI coding agent against a real codebase, assume by default it's phoning home more than the task requires until you've verified otherwise, and never let a live credential anywhere near a repo an agent touches, test or not. Now, defenders are embracing the prompt injection, too Summary: Tracebit built a defense called "context bombs," short pieces of text planted inside decoy secrets (like a fake AWS credential in Secrets Manager) that don't exhaust tokens or crash anything; they just trigger the attacking AI agent's own safety guardrails when it reads the honeypot during recon. Tested against five leading models including Opus 4.8, Gemini 3.1 Pro, DeepSeek, GLM, and Kimi, a single context bomb dropped admin-access success from 93% to 0% for Opus 4.8, and cut full-compromise rates from 36% to 1% on average across models. Different content triggers different models (Western models balk at sensitive biological content; Chinese models via Chinese providers balk at politically sensitive Chinese-language content), and every successful bypass still tripped the canary alert. Paul's take: This is a genuinely clever idea: instead of trying to detect an AI attacker after the fact, plant something in its own path that makes its own safety training refuse to continue. The line that stands out is "the strongest agents fall the hardest," meaning the most capable models were also the most reliably stopped, because they're the ones with the strongest guardrails to trip. That's a nice inversion of the usual AI security story where more capability means more risk. But don't mistake this for a permanent fix; the researchers say so themselves: this is round one of an arms race, and it only works because current models st