1999 Called and It Wants It’s Exploits Back – PSW #935

Paul Asadoorian

1. Claude Flaw Automatically Sends Malicious Prompts to AI Agents
2. Vulnerabilities of Realtek SD card reader driver, part2
3. 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.

4. 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.

5. 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.

6. 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 still have refusal behavior baked in that hasn't been stripped out by whoever's running the attack. If you're building canaries into cloud environments, this is a cheap, clever addition to the toolbox, but treat it as a tripwire that also alerts you, not a wall that stops the attacker.

7. How Linux Teams Spot Vulnerabilities Before CVEs Published

   Summary: Dave Wreski lays out how to spot kernel security fixes before a CVE ever gets assigned, by reading the trail that's already public: LKML discussion threads, oss-security, LWN's writeups, kernel.org commit history, and syzbot's fuzzing reports. The real signal isn't the patch itself, it's the metadata around it: Fixes: and Cc: stable tags, Reported-by: syzbot, KASAN/UBSAN sanitizer findings, repeated review revisions, or multiple maintainers arguing over the same change. None of that proves a security bug on its own, but the pattern of it together is usually enough to know a fix deserves a closer look and faster testing, well before it shows up in a vulnerability scanner.

   Paul's take: This is less a news story than a good methodology piece, and it's making a point I've been saying on this show forever: a CVE is the moment the rest of the world catches up, not the moment the bug was found. The debugging, the arguing, the "wait, is this actually exploitable" conversation, all of that happened in public months earlier on a mailing list nobody was reading. The practical takeaway isn't "go read LKML all day," it's "know that Reported-by: syzbot and Cc: stable on an innocuous-looking commit title is worth five minutes of your attention before the CVE drops and everyone's scrambling." If you're prioritizing patches based purely on CVSS scores that show up after the fact, you're always going to be behind the curve compared to a team watching the commit trail.

8. Finding the Routers Energetic Bear Is Looking For

   Also, John Strand and I were both quoted in this article on the topic: https://securityboulevard.com/2026/07/u-s-allies-russia-abusing-network-devices-to-attack-critical-infrastructure/

   Summary: VulnCheck's Jacob Baines dug into a July 9 NSA advisory on Energetic Bear, the FSB-linked group also known as Dragonfly or Crouching Yeti, active since 2010 and historically focused on the energy sector. The technique isn't sophisticated: scan the internet for Cisco SNMP services on port 161, guess the default "public" community string, and use legitimate config-copy functionality to pull the running config, which hands over credentials, internal addressing, and routing relationships. Baines notes Metasploit has had a module for this exact trick since at least 2010, and his own scanning still found thousands of exposed, vulnerable Cisco SNMP endpoints out there right now, including routers in Saudi Arabia and Venezuela.

   Paul's take: Sixteen years. A Metasploit module from 2010, an NSA advisory in 2026, and thousands of routers still answering to "public" on SNMP in between. 1999 called, and it wants its exploits back! This should embarrass everybody more than any zero-day; an FSB-linked crew doesn't need a novel exploit chain when default credentials and exposed management ports have been sitting there since the Obama administration. If your org has Cisco gear with SNMP reachable from the internet (or Cisco SMI, good lord!), this isn't a "patch Tuesday" problem; it's a "why is this even exposed" problem. Turn it off, change the community string off default, and go run the same kind of exposure query Baines describes, because if a researcher can find your router this way, so can Energetic Bear. Also, you should block and detect when your router configs are leaving via the Internet!

9. Cracking Firmware with Claude: Senior-Level Skill, Junior-Level

   Summary: Bishop Fox handed Claude Sonnet 4.5 an encrypted SonicWall NSv firmware image and a decrypted filesystem from another appliance, then let it try to reproduce a senior researcher's earlier manual decryption work. Claude independently found the OpenSSL EVP structure, decompiled the web-front binary with Binary Ninja, located an embedded HashiCorp Vault holding the key, correctly reconstructed the Vault master key from Shamir secret shares, and pulled the RSA key to decrypt the firmware. No new CVEs came out of this; it was a known-answer reproduction, not novel research, and Claude got stuck twice, once grinding on a dead-end manual Vault decryption approach and once misjudging RSA-OAEP's hash parameters, both requiring a human to redirect it.

   Paul's take: The honest framing here is the useful part: "senior-level skill, junior-level autonomy." It knew finite-field math and Vault internals cold without being taught, but it kept failing at the thing that actually separates junior from senior, knowing when you're stuck and need to change approach instead of grinding the same dead end with full confidence. That's not a knock on the tooling; it's just accurate, and it tells you exactly how to deploy it: let it carry the long methodical middle of a reverse-engineering task while a human supplies judgment at the forks. Also worth remembering this was a reproduction of a known answer, not Claude finding something nobody had found before, so don't read this as "AI now does firmware research unsupervised." It reads more like "AI now makes your best researcher's week go a lot faster," which is a real result, just a smaller and more honest one than the headline implies.

10. The Two BIOS Passwords Everyone Confuses

    When I was analyzing YellowKey we started discussing the BIOS password. Interesting that not too much information was available or put into a consumable format. This post changed that. Turns out there are at least 3 different passwords you can set in the BIOS. It also turns out that all major vendors call these settings completely different names. Its very confusing. I had my team start creating tests for these passwords, which is neat to start having visibility into these settings. Also interesting to discuss who should use these controls and when and how.

11. Dell BIOS Passwords: Weak XOR Encryption Allows Recovery from SPI Flash (CVE-2026-40639) – MDSec

    Along the BIOS password line, we have conditions such as this. Perhaps you have set one of the BIOS passwords; the next question is whether it is stored securely. This is an example of a vulnerability in which the password can be recovered, effectively defeating this security control.

12. Bluetooth Low Energy Security Testing, Consolidated: Introducing Caeruleus
13. Apple says former employee exploited ‘rare’ bug to download confidential files after leaving for OpenAI
14. Forgotten UEFI shims undermining Secure Boot

    We talked about this last week, now everyone is talking about it.

15. The Linux find Command: A SOC Analyst’s Guide to Hunting Hackers
16. 0x4D31/stinger: Unprivileged endpoint deception for macOS and Linux workstations. Uses FIFO baits, other local traps, and protected sessions to detect secret collection as it happens.
17. Oomwoo is a new open-source robot vacuum you can 3D print yourself, sidesteps cloud security risks by running fully offline — project combines Raspberry Pi, 2D LiDAR, and a 3D-printed chassis
18. CISA KEV’s Revolving Door

Larry Pesce

1. Felons, Fraudsters Flog Offensive Cybersecurity Startup – Krebs on Security
2. How the GodDamn Ransomware Driver Bypasses Your EDR
3. Viral App BAT-BMS Under Scanner After Delhi E-Rickshaws Disabled Remotely, Drivers Left Helpless
4. HTTP gets a QUERY method so complex searches can stop pretending to be POST
5. Pentagon Suspends CMMC Phase II Requirements for Defense Contractors
6. Microsoft Patch Tuesday July 2026 – The AI Acopolypse is Here
7. Microsoft discloses ‘the mother of all’ vulnerability loads, tripling June’s previous record

Lee Neely

1. Progress orders emergency ShareFile server shutdown over mystery security threat

   Summary: Progress Software began contacting customers using the company’s ShareFile Storage Zone Controllers (SZC) and urging them to manually shut down servers hosting SZC due to what Progress says is a "credible external security threat." While Progress has disabled access to ShareFile accounts that use SZC, the company has deemed the manual shutdown process "a critical additional step to ensure the safety of [customer] data."

   Lee's Take: Progress is being doubly cautious having been bit by SZC flaws earlier this year as well as the 2023/2024 MOVEiT attack by the Clop ransomware gang. They sent the message to shutdown your SZC hosting environment, typically Windows, with promises of a follow-up message in 24 hours,they have updated their SZC service disruption guidance, login and access information KB article (https://support.sharefile.com/s/article/ShareFile-Storage-Zone-Controller-SZC-Service-Disruption-Guidance-Login-Issues-and-Access-Information) on July 11th, stating to leave those controllers alone (down/offline) and watch for email notifications from [email protected]

2. ACSC warns of large-scale campaign exploiting CMS vulnerabilities in Australia – Australian Cyber Security Magazine

   Summary: The Australian Signals Directorate's (ASD's) Australian Cyber Security Centre (ACSC) has published a critical alert warning of a large-scare exploitation campaign that is targeting website content management systems (CMSs). ACSC states that "as part of this campaign, malicious cyber actors are actively scanning websites for opportunities to deploy webshells, leveraging various vulnerabilities affecting CMS software and plugins.

   ACSC's recommended mitigations include inspecting CMSes for webshells and known vulnerable plugins for abnormal files in the plugin directory; examining web access logs for IP addresses making GET or POST requests to any webshell paths; treating servers on which webshells have been detected as compromised; reviewing network logs for suspicious activity; tracing back suspicious web requests that may account for the initial exploitation and deployment of webshells; reviewing network logs; investigating logging and hosts for evidence of persistence, lateral movement or other malicious activity; applying available fixes; and restoring compromised websites from known safe backups.

   Lee's Take: Beyond the actions and mitigations suggested by ASD, make sure that your enforcing MFA for users, particularly administrators, that updates are being installed automatically, and you're reviewing and removing unused plugins.

3. Lessons from CISA’s Cyber Incident

   Summary: CISA has published a blog assessing its own response to a researcher's May 15 report that a public GitHub repository called "Private-CISA" had been exposing CISA credentials and files for nearly six months.

   Lee's Take: Supply chain security remains a constant, CISA has published guidance includig incident response, lessons learned, what worked well and what to strengthen - perfect topics for a conversation in your shop, not just with developers, but also incident responders and security teams. Don't forget to include conversations about maintianing improvements made in this process, or even raising the bar further. Our adversaries aren't going to be resting on their laurels, and neither can we.

4. EU takes member states to court over unimplemented cybersecurity law

   Summary: The European Commission on Wednesday filed legal referrals at the EU’s top court against four member states for failing to implement the bloc’s flagship cybersecurity law covering critical infrastructure. Ireland, Spain, France and the Netherlands are more than 20 months late in transposing the NIS2 Directive, which sets minimum security standards for hospitals, energy networks, transport operators and public administrations. Ireland's National Cyber Security Bill will meet their requirements, no such delivery is on the horizon for Spain, France and the Netherlands. So, penalties are being levied. Regrettably, in practice, the fines being sought by the European Commission are rarely paid, meaning the penalty isn't sufficient to drive adoption.

   Lee's Take: Stepping aside from politics and regulation, our adversaries don't care what legislation we have in play and what our response is, they are going to attack on their terms, so start rolling with the essentails, we know the drill - authentication, segmentation, access controls, monitoring/logging, and response.

5. When Hackers Cut the Internet, Will the Water Still Flow?

   Summary: The US Environmental Protection Agency (EPA) held a National Cyber Drill on Wednesday, July 8, offering an opportunity for "emergency response planners, IT and OT security specialists and state and local partners, as well as utility managers from more than 200 water and wastewater utilities across the country" to simulate operating a large public water utility during a comprehensive outage of all third-party communications caused by a cyberattack. The participants were challenged to maintain a continuous safe water supply without cellular or landline phones, SMS, internet, cloud services including email and document sharing, and SCADA connections to remote sites. The exercise was offered in two forms: a tabletop scenario conducted as a video conference, or a live action drill where the participating utility would switch its actual service to entirely manual operation. "Of the 390 participants on the call, 67 had opted for the manual operations module, rather than the tabletop exercise," but only one participant who chose the manual drill confirmed they had carried it out, with four more stating intent to complete it soon.

   Lee's Take: I'm reminded of being in a session on disaster recovery where one participant wanted to know when they could start kicking switches/disrupting power/etc. While disaster preparedness is a learning process, at some point you do need to go to a physical situation to learn what it's like to run or rebuild a system without a lot of services taken for granted. Find a way to replicate/imitate production, the experience gained will make future production, aka real, outages much easier to respond to. Remember the old phrase "Practice like you play." If you don't practice well, you're not going to do well when the time comes.

6. Former DigitalMint ransomware negotiator who duped clients sentenced to 70 months in jail

   Summary: A former ransomware negotiator for DigitalMint was sentenced to 70 months in jail for deceiving his employer’s clients and conspiring with ransomware affiliates to extort a combined $75.3 million from five U.S. companies he was entrusted to aid during their moments of extreme crisis, the Justice Department said Thursday.

   Lee's Take: No so sure five years, less time served, plus future property and earnings will make his victims, who are out about $75 million feel whole. At this point that is decided. What we can learn from this is that given that Martino was already engaging in criminial activity at the time he was hired by DigitalMint, is that good background checks matter, particularly for sensitive positions. Further, take a serious look at how often you want to re-check your findings. A position like ransomware negeotiator comes with a lot of temptation/risks and reward, so you should have a validation process, and controls, which correspond with the need for increased standards of security, safety, reliability and mental stability they must demonstrate.

7. Context bombs: stopping AI attackers in their tracks

   Summary: Researchers from Tracebit have published research indicating that prompts designed to trigger an LLM's safety policies can be planted in decoy data to counter attacks carried out with agentic AI. This is a form of prompt injection dubbed a "context bomb," in which the LLM is manipulated to interpret ingested text as a prompt, but that prompt stops the agent from proceeding by asking for something the agent is designed to refuse.

   Lee's Take: Learn about Context Bombing. You're effectively doing prompt injection via information adjacent to legitimate data, doing in the attacker's AI. Keep in mind that this is not going to be set it and forget it, attack techniques will continue to evolve, this will need to as well. Keep an eye on this technique as it becomes part of your overall plan for cyber resiliency.

8. GigaWiper: Anatomy of a destructive backdoor assembled from multiple malware

   Summary: Microsoft Threat Intelligence (MTI) identified modular Golang-based backdoor malware it has dubbed GigaWiper. The malware incorporates command-and-control capabilities with a variety of malicious payloads. The payloads include a powerful, physical disk level wiper; a command that encrypts files with unsaved, randomly generated keys; and a command that repeatedly overwrites files, seriously impeding recovery efforts. A July 9 MTI blog that offers a code-level analysis of GigaWiper describes the malware as "an amalgamation of separate malware families that were folded into GigaWiper as on-demand backdoor commands, giving threat actors the flexibility to choose their mode of destruction."

   Lee's Take: GigaWiper, aka BLUERABBIT, was assembled by combinding and reimplementing components from at least three previously separate malware famailies. As such it's very capable, flexible, stealthy, and distructuve when needed. Grab the IoCs from the MTI blog, make sure your EDR is in blocking mode, look to your XDR platform to implement attack surface reduction rules, such as preventing executables from running unless they meet needed age or trust criteria, as well as blocking access to known C2 infrastructure, ideally with real-time updtaes to that block list.