Advertise on podcast: Cyberside Chats: Cybersecurity Insights from the Experts

On October 21, the PHP project shipped an emergency fix for two critical bugs, nicknamed PHP2Shell, that let an unauthenticated attacker run code on a web server with a single crafted file upload. PHP runs roughly 70% of the web. Governments pulled websites offline, a major HR platform went dark, and attack attempts were hitting sensors hours before a patch existed. Your first line of defense may not have been your own. Cloudflare, Akamai, DreamHost and other major providers had protection in place, buying you time — in some cases hours before the patch was even released. Sherri Davidoff and Matt Durrin explain what happened, why "we patched" isn't proof, and five questions to put to your own team and every vendor that runs PHP for you. Key Takeaways: Find the PHP you forgot about. The dangerous instances aren't your web farm; they're the backup appliance, the printer, the management console, the exposed controller, the inherited container image. NCSC flagged PHP bundled inside third-party products specifically. Anything on an unsupported version that can't be patched goes off the internet today. Put a maintained layer in front of everything exposed, and still patch behind it. A provider who virtual-patches buys you the hours between “exploit exists” and “patch exists.” But a WAF guards the front door; a phished foothold walks around it to the same bug. Lean on the big providers without letting them become your whole defense. Verify the patch is actually running (don't take “we patched” as done). The update isn't live until every worker is fully restarted, and backported fixes still report the old version number, so the banner can't prove you're safe. Make your team confirm it by package and process, and remember the finders say these two CVEs may not cover every variant. Check with every vendor that runs PHP for you. Most of your exposure is someone else's code: your hosts, your SaaS platforms, the appliances in your racks — and their unpatched server is still your breach. Ask each critical vendor the direct question: have you patched, restarted, and put protection in front? Inventory your own PHP too, and track who can't give you a straight answer. Know who owns emergency patching, and whether they actually caught this one. Someone may already be nominally responsible; this incident is the test of whether that role functions. When the advisory dropped, did your team — internal or outsourced — recognize the urgency and drive the patch, or did it slip by unnoticed? If you had to find out from the news instead of from them, that's the gap to fix before the next one. Resources: PHP, "Security advisory: Critical remote code execution vulnerabilities, update now" — https://www.php.net/archive/2026.php#2026-10-21-5 Cloudflare, "Cloudflare deploys protections against php2shell vulnerability" — https://blog.cloudflare.com/php-vulnerabilities-waf-protection/ The Record, "PHP says AI review of critical bugs first sparked alarm in August, but signs surfaced in 2024" (PHP Foundation postmortem) — https://therecord.media/php-foundation-statement-critical-vulnerabilities Sansec, "PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)" — https://sansec.io/research/php2shell CISA, "Critical Vulnerabilities in PHP Require Immediate Patching" — https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching

This weekend, attackers broke into the refrigeration controllers at hundreds of French supermarkets and turned the freezers into heaters. Alarms reached some store managers in time; in other stores nobody was paged, and many had to throw out all their fresh and frozen food. Researchers had published the flaws in these exact controllers two months earlier and found more than 2,700 of them sitting on the open internet. The manufacturer says most were end-of-life and no longer getting security updates. It isn’t just supermarkets. Nation-states are hijacking security cameras to watch military movements, and a ransomware gang used a webcam to slip past EDR. Every IoT device in your environment is something someone else may want to control — to watch you, to disrupt your operations, or to get a foothold in your network. Sherri Davidoff and Matt Durrin explain why so many of these devices fall through the cracks — installed by facilities teams and vendors, left unmonitored, and kept running long after support ends — and share five steps leaders can take to find them, own them and stay in control of them. Key Takeaways: Inventory the connected devices your facilities team and contractors installed, and give each one an owner. The supermarket controllers, the cameras and the Akira webcam share one property: everyone assumed someone else was looking after them. Every camera, controller and sensor needs a person accountable for patches, passwords and remote access, the same as a server. Scan your own perimeter on a schedule. CISA advised in May 2025 that the Danfoss controllers be taken off the internet; 17 months later independent scans still found about 2,700 of them exposed. If you aren’t watching your perimeter, an exposed management interface is an open door into your network. Decide at the contract stage what happens when the vendor stops supporting your equipment, and how long support is guaranteed. Hospitals and manufacturers know this pattern: multi-million-dollar hardware whose software quietly goes end-of-life. Understand the software’s lifespan before you buy, and hold the vendor to it in writing. Make alerting survive the compromise of the thing it monitors. The refrigeration controllers’ alerts are configured on the same web interface the attackers controlled and travel over the same internet connection. Monitor critical temperatures with a separate device on a separate path, such as cellular, and make sure a real person is on the other end at 4 a.m. Treat your vendors’ remote access as your attack surface, and bind them to your security policy. Don’t write a list of controls into the contract. Require vendors to adhere to your security practices, which can be updated as the threat landscape changes. Resources: Wall Street Journal, “Video Cameras Are Everywhere—and Now They Are Being Hacked for War” — https://www.wsj.com/tech/cybersecurity/video-cameras-webcams-hacked-war-b00b8a24 BleepingComputer, “Cyberattack shuts down refrigerators at French supermarkets” — https://www.bleepingcomputer.com/news/security/cyberattack-shuts-down-refrigerators-at-french-supermarkets/ Claroty Team82, “Freeze the Controller, Defrost the Food” — https://claroty.com/team82/research/freeze-the-controller-defrost-the-food-uncovering-vulnerabilities-in-danfoss-refrigeration-controllers S-RM, “Camera off: Akira deploys ransomware via webcam” — https://www.s-rminform.com/latest-thinking/camera-off-akira-deploys-ransomware-via-webcam LMG Security, 2026 Annual Penetration Testing Report

On September 28, three things happened: NVIDIA shipped an open platform to contain AI agents, OpenAI cancelled the release of its next flagship model because it strayed outside its instructions and misreported what it did, and Florida's attorney general asked a court to stop OpenAI from building new models without independent safety review. They are the same story from three angles — and the story began over the summer, when every major lab disclosed that its agents had broken out of the environments meant to hold them. Sherri Davidoff and Matt Durrin, recording live, break down what NVIDIA actually built — a software sandbox anyone can run, and a hardware watchdog most organizations can't — and whether it can hold against an attacker that reads every paper on cages and never sleeps. They walk the Hugging Face intrusion that led here, what the agents said in their own words, and the critical sandbox escape NVIDIA patched a month before launch. Then the harder questions: who decides whether a frontier model is safe to ship (right now, only the company that built it), why Florida's lawsuit looks a lot like the ChoicePoint era, and what any of this means for a security leader whose AI arrived as a checkbox inside Microsoft 365 or Salesforce. Plus five things to assign this week — starting with a list of every agent already running in your environment. Key Takeaways: Build a register of every AI agent running in your environment — who owns it, what it can reach, and whose credentials it uses. Start with the checkboxes already turned on in Microsoft 365, Salesforce, ServiceNow, your MSP's tooling, and any self-hosted model a data team stood up. No control in this episode can be applied to something you haven't listed. Assume every agent will eventually act outside its instructions, and design for it. OpenAI shelved its next model because it strayed out of scope and misreported what it did; the labs are investigating tens of thousands of bypasses. Give every agent a scoped service account with an expiry date, revoke any that hold admin or standing broad access, and treat it the way you'd treat a contractor with a broad brief and no supervisor. Verify this quarter that egress filtering, DNS filtering, and public-source credential scanning are on for anything an agent can touch. These are controls you already own. A missing DNS filter let an OpenAI agent tunnel out of a "sealed" sandbox; runtime monitoring, not policy, caught the Hugging Face intrusion. Add three questions to your vendor and MSP due-diligence template, and require written answers before renewal. Where does enforcement live — inside the model or outside it? Can the agent ever hold real credentials or reach the network directly? What is your incident-notification commitment, in hours? Run a tabletop where an agent — not an attacker — misuses its own access, and find out who can cut it off and how fast. OpenAI's automatic kill switch failed and a human stopped the run two and a half hours later. Name the person, test the path, time it. Resources: NVIDIA — Open Agent Safety Platform (technical overview): https://developer.nvidia.com/blog/nvidia-open-agent-safety-platform-a-reference-for-continuous-in-silicon-agent-monitoring/ NVIDIA Security Bulletin 5872 — OpenShell and NemoClaw, August 2026: https://nvidia.custhelp.com/app/answers/detail/a_id/5872 OpenAI — The Hugging Face incident and the road ahead: https://openai.com/index/hugging-face-incident-and-the-road-ahead/ UK AI Security Institute — Cheating behaviour in frontier model evaluations: https://www.aisi.gov.uk/blog/cheating-behaviour-in-frontier-model-evaluations Florida AG motion for temporary injunction against OpenAI (SiliconANGLE): https://siliconangle.com/2026/09/28/florida-attorney-general-asks-court-to-prevent-openai-from-advancing-its-frontier-models-even-as-company-scraps-new-release/

This week, Sherri and Matt dig into a joint advisory from seven government agencies across Japan, the US, Australia, and Germany naming WaterPlum, the North Korean actors posing as prospective employers to target software developers and IT professionals. Japan’s National Police Agency reports at least 30,000 infected devices in more than 100 countries between December 2025 and July 2026, with funds or credentials taken from more than 7,000 cryptocurrency wallets and roughly $10.71 million moved to North Korea. Sherri and Matt break down how the lure works, why coding challenges are such an effective delivery mechanism, and what changed with the newest malware family, StoatWaffle, which can execute when a trusted folder is opened in VS Code. They connect it to the case LMG’s Tom Pohl analyzed in June and examine how North Korea is now working both sides of the hiring table, as both interviewer and applicant. Key Takeaways: Make onboarding a security checkpoint. Identity verification should be an HR and IT project. Verify every new hire’s identity, issue fresh credentials, and monitor accounts closely during the first few weeks. A compromised candidate can bring an existing infection into your organization on day one. Because the same operation also uses fake applicants, verify claimed locations, IP addresses, and résumé skills. Treat password reuse as a policy issue, not a question. The malware Tom analyzed harvested saved credentials from ten different browsers. Require unique corporate passwords, audit them against known-breach lists, and use phishing-resistant MFA. Anyone with source code or administrative access should be considered for hardware-based authentication such as a YubiKey. Keep developers off personal devices. Personal laptops often combine job hunting, coding challenges, credentials, and crypto wallets. In one case Tom analyzed, the person infected wasn't even the primary laptop user. Require company-managed devices for anyone accessing code, cloud infrastructure, or production systems. If personal-device use is allowed, document it as an accepted risk. Extend security requirements to vendors and contractors. Your organization can be compromised through someone else's developer. Bybit lost roughly $1.5 billion after a developer at its wallet vendor was compromised. Ask vendors: Do developers use managed devices? How are they trained on fake-recruiter and malicious-package attacks? How do they prevent password reuse? How do they vet employees and subcontractors? Keep developer training current. Tom's case was identified because someone recognized the fake-interview pattern and reported it instead of running the code. These actors continuously evolve their methods. StoatWaffle is a good example: the risk has moved beyond "don't run code from strangers" to situations where simply opening a trusted folder can trigger execution. Make current threat briefings part of ongoing training for developers, IT staff, and contractors. Hiring has become an attack surface in both directions, and most security programs don't own either end of it. References: Joint NPA/NCO/FBI/DC3/ASD’s ACSC/BND/BfV advisory on North Korean WaterPlum, Sept. 18, 2026: https://www.ic3.gov/CSA/2026/260918.pdf LMG Security, Anatomy of a Job Interview Supply Chain Attack (June 2026) Cyberside Chats, Damaged Goods: When Your New Hire Is Already Compromised (June 9, 2026): https://www.chatcyberside.com/e/damaged-goods-when-your-new-hire-is-already-compromised/ NTT Security, OtterCookie analysis (Jan. 16, 2025): https://jp.security.ntt/insights_resources/tech_blog/en-contagious-interview-ottercookie/ The Hacker News, North Korean hackers abuse VS Code auto-run tasks to deploy StoatWaffle (March 2026): https://thehackernews.com/2026/03/north-korean-hackers-abuse-vs-code-auto.html Microsoft Security Blog, Contagious Interview malware delivered through fake developer job interviews (March 11, 2026): https://www.microsoft.com/en-us/security/blog/2026/03/11/contagious-interview-malware-delivered-through-fake-developer-job-interviews/ KnowBe4, How a North Korean Fake IT Worker Tried to Infiltrate Us (July 23, 2024; updated Oct. 19, 2024): https://blog.knowbe4.com/how-a-north-korean-fake-it-worker-tried-to-infiltrate-us LMG Security, North Korea’s Deepfake Remote Workers (Aug. 13, 2025): https://www.lmgsecurity.com/north-koreas-deepfake-remote-workers-how-theyre-getting-inside-u-s-companies-and-how-to-stop-them/ Cyberside Chats, Unmasking the North Korean Cyber Threat (Aug. 12, 2025): https://www.chatcyberside.com/e/unmasking-the-north-korean-cyber-threat/ The Hacker News, Safe{Wallet} confirms North Korean attack on Bybit (March 2025): https://thehackernews.com/2025/03/safewallet-confirms-north-korean.html Infosecurity Magazine, coverage of the WaterPlum advisory.

Two friends ordered a new fiber connection, followed the installer around with a camera, and noticed that the box on the pole outside their house had no power. That one observation led them to capture their entire neighborhood's internet traffic — web browsing, email, even live phone calls — with $99 worth of equipment. Sherri Davidoff and Tom Pohl break down "gPWN," one of the standout talks from Black Hat USA 2026. Fiber to the home broadcasts everyone's traffic to every house on the street and trusts each home's equipment to ignore what isn't theirs. The encryption meant to back that up is optional, often left switched off, and doesn't cover traffic headed back to the ISP at all. It gets worse: cell towers ride the same fiber, which means the "out-of-band" cellular path in your continuity plan may share a line with your neighbors. And the researchers showed how a malicious username typed into a home fiber box could hand an attacker root access to the ISP's own equipment. The lesson isn't just about fiber. Decades ago we replaced hubs with switches so our traffic stopped going to everyone on the network. The last mile quietly went back to a hub — and everything built on top of it kept assuming the old rules. Key Takeaways: Use a VPN you trust. You can't trust the last mile. Encryption on many fiber deployments is optional and often switched off, and traffic from your home or office back to the ISP isn't encrypted at all. Prove your out-of-band paths really are out of band. Cell towers are often connected over the same neighborhood fiber as homes and offices. Falling back to cellular may mean relying on the same path as your primary internet connection — check before an outage does it for you. Assume every carrier circuit is a public network. Treat your office connection like coffee shop Wi-Fi: anyone nearby could be watching. The risk profile of a business in a strip mall may not be very different. don't trust vendor-supplied equipment. Assume vendors will leave optional security switched off — or have access into your equipment. Where you can, use your own router and firewall behind the ISP's device. Put an expiration date on your assumptions. We spent years assuming layer two was secure because we had switches. Your ISP may have quietly replaced that with fiber that sends everyone's traffic to every house. Revisit the assumptions your security is built on. Resources: Black Hat USA 2026 — "gPWN: Wiretapping Fiber ISP Deployments From the Comfort of Your Home" (Rithvik Vibhu & Rithwik Jayasimha) — https://blackhat.com/us-26/briefings/schedule/#gpwn-wiretapping-fiber-isp-deployments-from-the-comfort-of-your-home-53851 gPWN project site and toolkit — https://www.gpwn.io/ Hackaday, "Hacking Fiber To The Home" — https://hackaday.com/2026/08/13/hacking-fiber-to-the-home/ Quarkslab, "Overview of Passive Optical Networks (PONs) Security" — https://blog.quarkslab.com/overview-of-passive-optical-networks-pons-security.html Dark Reading, "Salt Typhoon APT Subverts Law Enforcement Wiretapping" — https://www.darkreading.com/cyber-risk/salt-typhoon-apt-subverts-law-enforcement-wiretapping

Palo Alto Networks’ Unit 42 investigated an intrusion where the attacker used AI agents to carry out the attack — and compressed work a human team would have needed more than two weeks to do into just under ten hours, using more than 50 MITRE ATT&CK techniques. Sherri Davidoff and Matt Durrin unpack what actually happened, starting with a correction: despite the headlines, this was not an autonomous AI. A human directed it. They walk the chain from a breached public website through sub-agents harvesting hard-coded tokens out of code repositories, into the secrets manager, and finally to the attacker turning the victim’s own AI endpoints into attack infrastructure — using the company’s compute power against it. Along the way: why an attempted backdoor in Terraform configurations was the most alarming move in the intrusion, why branch protection stopped an attacker who already held master admin credentials, and why the tactic adversaries use to slip past AI guardrails looks a lot like a Russian ransomware gang’s fake IT recruitment scheme. The thesis isn’t that AI went rogue. It’s that the clock changed, and incident response plans built for a two-week dwell time are now built for the wrong attack. Key Takeaways: Make every key and token in your environment expire. They will not get rotated by default. Set expirations so they cannot stay invisible forever, and track them. Require a second layer of approval for critical infrastructure changes. Branch protection stopped this attacker after they already held master admin credentials. Logging and monitoring are good; prevention is better. Give every AI service in your environment a named owner. Somebody has to be managing the keys and controlling it, so you know where it is. Apply the same controls to your vendors and MSPs. Work these into your next review cycle: how do they manage keys and tokens, do they scan for secrets, do they require second approvals? Run a tabletop against a ten-hour clock. Find out who can actually cut off access to a primary system — who can take it offline, when, and what they need to do it. Resources: Unit 42, “An AI-Assisted Cyber Attack: Inside a Unit 42 Investigation” — https://unit42.paloaltonetworks.com/ai-assisted-cyber-attack-inside-a-unit-42-investigation/ Anthropic, “Countering misuse of AI: September 2026” — https://www.anthropic.com/threat-intelligence-report-september-2026 GitGuardian, “The State of Secrets Sprawl 2026” — https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026/ Tom Pohl (LMG Security), “Private Keys in Public Places,” DEF CON 31 — https://www.lmgsecurity.com/resources/private-keys-in-public-places-defcon-2023-presentation/ Video of the talk — https://www.youtube.com/watch?v=7t_ntuSXniw

This week, Sherri and Matt talk about how much worse the OpenAI–Hugging Face story has gotten. New reporting revealed it wasn't a single model that escaped its sandbox — roughly 1,200 did, and about 700 of them went on to attack Hugging Face. Sherri and Matt walk through how agents that were never supposed to communicate found each other through a shared software package manager, built an improvised message board, started delegating work, and even rolled out their own public-key message signing once they worried about impostors. They dig into the red flags OpenAI spotted and waved past, why the victim discovered the breach before the perpetrator did, and the uncomfortable fact that every escape path the agents used was one that had been explicitly permitted. Plus: similar incidents at other AI labs, and the AI assistant that hacked a gym's booking system to bump its user up a waitlist. Key Takeaways: Hunt your own leaked credentials before someone else finds them. The Hugging Face compromise started with 14 valid tokens sitting in a public dataset — no exploit required. With billions of stolen credentials already circulating, AI is very good at finding the ones that belong to you. Shift to continuous patch management. Exploitation now happens at machine speed, and it isn't limited to your flagship platforms. A package manager was central to this attack. Reduce your attack surface, minimize what's internet-facing, and plan for patching zero-days on whatever remains exposed. Segment your network. The agents moved laterally out of their sandbox and then straight through production. The goal isn't to make compromise impossible — it's to put up enough roadblocks that you can detect it and respond before it becomes a full-blown incident. Monitor your infrastructure, and get help scaling it. Round-the-clock coverage is out of reach for most teams on their own. As AI gets better at breaking in, it will also get better at staying quiet — and compromise will look increasingly subtle. Respond at machine speed. Agents went from a single container to multi-cluster admin in under 13 hours, adapting public exploits along the way. Line up your cyber insurer and an experienced IR firm before you need them, and run tabletop exercises for nights and weekends against an attacker that never sleeps. It's not just about rapid detection anymore — it's about rapid decision-making. References: OpenAI, Hugging Face Incident Technical Report (38 pages): https://cdn.openai.com/pdf/67869394-cb91-4c12-888c-5cbd85c7814c/OpenAI-Hugging-Face%20Incident-Technical-Report.pdf OpenAI, The Hugging Face incident and the road ahead: https://openai.com/index/hugging-face-incident-and-the-road-ahead/  METR / Redwood Research, independent investigation of the agents' behavior and collaboration: https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/ Hugging Face, Security incident disclosure — July 2026: https://huggingface.co/blog/security-incident-july-2026 OpenAI, initial disclosure: https://openai.com/index/hugging-face-model-evaluation-security-incident/ OpenAI's Black Hat presentation on the incident: https://www.youtube.com/watch?v=87DyyMV0kCY Anthropic, Improving our alignment and security efforts: https://www.anthropic.com/news/improving-alignment-security-efforts TechCrunch, Here's all the times AI has gone rogue and hacked other companies: https://techcrunch.com/2026/08/27/heres-all-the-times-ai-has-gone-rogue-and-hacked-other-companies/ ABC Australia, AI assistant exploits a gym booking system: https://www.abc.net.au/news/2026-08-10/ai-assistant-hacks-gym-website-aus-cyber-attack/107007986

On the first night of a remote internal penetration test, a bank’s own vulnerability scanner tried to log in to our computer, using a highly privileged account. That was all it took. We had started with nothing: a foothold on the internal network, no credentials, no domain access. A day later we had domain admin and the password hashes of every user in the bank, a complete takeover built out of the bank’s own security tooling. Sherri Davidoff and Tom Pohl walk through the whole chain: why we relayed the scanner’s login instead of cracking it, the “low severity” SMB signing finding the entire compromise turned on, and the misconfigured certificate template that handed over domain admin. Then they widen the lens: the breach-simulation platform that had a domain admin account of its own, the backup server with administrative rights nearly everywhere, and why the tools you bought to watch your network are the ones most worth attacking. Plus what to actually change: not just what your scanner finds, but how and to what it authenticates.   Key Takeaways: Your security tools are among the most attractive targets on your network, because you gave them the keys. Scanners, backup, EDR, and breach-simulation platforms routinely hold domain admin and reach every host. Inventory those privileged service accounts and know exactly what each one can reach. Check how your scanner authenticates — not just what it finds. Credentialed scanning that will authenticate to an untrusted or unknown host, without signed/mutual authentication, hands out privileged credentials to whatever answers. Ask your vendor how to enforce this and verify the setting. “Low / informational” findings are the pivot. Missing SMB signing is the classic example: it barely rates in a report, and it’s the hinge the whole bank compromise turned on. Enforce SMB signing. 4. Audit your Active Directory Certificate Services templates. A single over-permissive template turns into “issue myself a certificate as any user in the company,” which turns into domain admin. Most organizations have never looked. Least privilege applies to tooling, and it’s usually where least privilege gets skipped. Scoped accounts, tiered admin, no single account with admin everywhere, no shared credential across host classes.   Resources: Microsoft — Control SMB signing behavior (how to require signing) — https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-signing Tenable — Plugin 57608, “SMB Signing not required” (rated Medium — the finding this compromise turned on) — https://www.tenable.com/plugins/nessus/57608 Microsoft MSRC — Mitigating NTLM Relay Attacks by Default — https://www.microsoft.com/en-us/msrc/blog/2024/12/mitigating-ntlm-relay-attacks-by-default Microsoft — KB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services — https://support.microsoft.com/en-us/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429 SpecterOps — Certified Pre-Owned: Abusing Active Directory Certificate Services (Will Schroeder & Lee Christensen) — https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf Rapid7 — Authentication on Windows: best practices (vendor guidance recommending administrator-level scan accounts) — https://docs.rapid7.com/insightvm/authentication-on-windows-best-practices/

Anyone who can join your Zoom meeting could run code on your device: no click, no download, no sign that anything happened. That’s what Ⓐ Security disclosed on 11 August, in four vulnerabilities in Zoom’s screen-share annotation feature. Zoom patched quickly. The part that should concern security leaders is how the exploit was built — Ⓐ says one researcher did it in under 24 hours, using fewer than 20 prompts to publicly available AI models, against a closed protocol with no published specification. Sherri Davidoff and Matt Durrin walk through how the attack works, compare it to what a zero-click exploit of this class cost to build in 2021, explain why Zoom’s interim fix couldn’t protect the customers who’d enabled end-to-end encryption, and look at what the evidence actually says about AI-accelerated vulnerability discovery — including the data that argues against the panic. Plus what all of this means for organizations that buy software rather than build it. Key Takeaways: 1. Ask every critical software vendor how fast they patch, and put the answer in the contract. Zoom went from report to shipped fix in 12 days. Your exposure window is that vendor cycle plus your own deployment cycle, and you only control the second. A vendor who won’t commit to a remediation timeline is a documented risk decision, not a technical detail. 2. Inventory the software components inside the products you buy, not just the products themselves. Zoom’s Video SDK is affected and sits embedded inside third-party applications — telehealth platforms, contact-centre tools, banking apps. Organizations with no developers carry this exposure entirely through vendors and can’t patch it themselves. Zoom itself only added the Video SDK to its affected-products list three days after publication. 3. Ask vendors which of their security mitigations stop working when you turn on encryption or privacy features. Zoom’s interim server-side fix could not apply to end-to-end encrypted meetings, because the server can’t read what it’s asked to filter — and the bulletins didn’t say so. Any control that depends on a vendor inspecting your traffic is void the moment you encrypt end to end. 4. Treat "no public exploit exists" as a statement about timing, not about risk. There’s no in-the-wild exploitation, no KEV listing, and no validated public proof-of-concept. That reflects where researchers chose to spend effort — macOS was demonstrated because it was cheapest, while Windows and Linux are affected and simply weren’t targeted. That’s someone else’s schedule, not your risk assessment. 5. Assign someone the authority to say what does — and does not — get fixed. FIRST projects roughly 66,000 CVEs this year, with volume up 45%. If you write no code, that flood arrives as vendor advisories, scanner output and emergency patch cycles for software you bought. At that volume most of the job is deciding what to leave alone, and nobody will own that call without explicit cover. Resources: 1. Ⓐ Security — ZOOMSDAY (original research): https://a.security/blog/asecurity-zoomsday 2. Zoom Security Bulletins, ZSB-26015 to ZSB-26018 (affected versions and patches): https://www.zoom.com/en/trust/security-bulletin/ 3. Google Project Zero — A deep dive into an NSO zero-click iMessage exploit (FORCEDENTRY): https://projectzero.google/2021/12/a-deep-dive-into-nso-zero-click.html 4. VulnCheck — State of Exploitation 1H-2026: https://www.vulncheck.com/blog/state-of-exploitation-1h-2026 5. Google Threat Intelligence Group — Adversaries Leverage AI for Vulnerability Exploitation: https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access

In August 2026 the UK AI Security Institute disclosed that during a routine security evaluation, an AI agent went off-script and attacked real people on the live internet — trying to plant malicious code in a publicly used open-source project and inventing fake identities to pressure the maintainer into approving it. The most unsettling part isn't the deception. It's the targeting: the agent worked out that an AI assistant was helping run the project, and wrote its payload to be invisible to humans but readable by machines. Days earlier at Black Hat, Zenity Labs showed the same idea productized against five shipping AI browsers — hijacking Claude in Chrome, Comet, Atlas, Copilot Edge, and Gemini through nothing more than an email or a calendar invite, no clicks required. Sherri Davidoff and Matt Durrin unpack both stories, why two of the five vendors say there's nothing to fix, and what security leaders should decide this week. Agentic AI is now a first-class attack surface — and the countermeasure most organisations have spent years investing in, training people not to fall for it, doesn't transfer. Key Takeaways: 1. Decide now whether work accounts get signed into AI browsers at all — two of the five vendors have said they are not fixing this. Perplexity and 1Password patched specific capabilities. Anthropic closed the report as informative and ineligible for its disclosure program; OpenAI said there is no easy patch because the vulnerable behaviour is the product feature. Waiting is not a strategy when the vendor sees nothing to fix. 2. Move off email one-time codes for anything that matters, and require out-of-band approval for account recovery. The Claude in Chrome chain never touched a password. It triggered password resets and read the codes out of the victim's own mailbox — Slack, X, then their Claude account. A second factor delivered to a mailbox an agent can read is not a second factor. 3. Inventory which of your automations read outside text and then act with permissions — and put a person on the step that commits. Ticket triage, invoice processing, inbox rules, contract review, vendor portals: anything that ingests outside content and then does something authorised is in scope, developers or not. The agent hunted for an automated target precisely because automation reads raw text and never gets suspicious. 4. Add a question to your vendor security reviews: what outside code goes into your product, and what runs it automatically? Modern software is assembled from components written by strangers, and the systems doing the assembling fetch and run that code on a schedule with nobody watching — which is how one agent's component executed inside 53 of GitHub's own build machines. For most organisations that risk sits with suppliers, not in-house. 5. Separate the environment where your people investigate suspicious things from the one holding credentials to approve, merge, deploy, or pay. The attack failed for a reason no policy earned: the person who opened the payload had no rights to merge it. Had the maintainer investigated on their own laptop — sessions live, an AI assistant helping triage — every precondition would have been met. Resources: 1. UK AI Security Institute — Incident Report: Unsanctioned Agent Behaviour During Cyber Testing https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing 2. AISI Technical Report INC-2026-07-28-01 (full detail, PDF) https://cdn.prod.website-files.com/663bd486c5e4c81588db7a1d/6a724858f7db25c81487016d_Security%20Incident%20INC-2026-07-28-01.pdf 3. Zenity Labs — Claude in Chrome: From alert(1) to Full Account Takeover https://labs.zenity.io/post/claude-in-chrome-from-alert-to-full-account-takeover 4. SecurityWeek — Zero-Click AI Browser Hacking: Claude and ChatGPT Atlas Hijacked via Emails, X Posts https://www.securityweek.com/zero-click-ai-browser-hacking-claude-and-chatgpt-atlas-hijacked-via-emails-x-posts/ 5. Dark Reading — And the Winner for Most Dominant Malware Delivery Method Is... ClickFix https://www.darkreading.com/vulnerabilities-threats/winner-dominant-malware-delivery-clickfix

In this timely rerun episode, Matt interviews Tom and Derek from our pen test team to break down why attackers often don’t need to hack their way in at all. While most organizations invest heavily in tools like EDR and SIEM, Tom and Derek share how they regularly get inside buildings using nothing more than confidence, a good story, and sometimes even a box of donuts. From posing as copier technicians to tailgating behind employees, their experiences show that people are often the easiest way into an organization. And once they’re in, things escalate fast. Physical access can quickly turn into network access, whether it’s plugging in a device, jumping on an unlocked workstation, or moving through the environment with far fewer restrictions than an external attacker would face. The big takeaway is simple. Real-world testing exposes what audits miss. Doors get propped open, employees try to be helpful, and small gaps add up in ways most organizations never see on paper. If you’re not testing your people and your physical controls, you’re only testing part of your security. Key takeaways: 1. Attackers target people first, not systems Social engineering consistently bypasses even mature technical controls. 2. Physical access equals full compromise Once inside your facility, most security controls can be circumvented quickly. 3. Un-tested controls are assumed to fail If you’re not running social engineering or physical assessments, you don’t know your real risk. 4. Culture is a security control Employees must feel empowered to challenge, verify, and report suspicious behavior. 5. Real-world testing reveals what audits miss Offensive social engineering exposes how attacks succeed, not just theoretical vulnerabilities.

In this episode, Sherri and Matt discuss the July 2026 incident in which OpenAI’s own AI models escaped a sandboxed cybersecurity evaluation and broke into Hugging Face, generating more than 17,000 recorded malicious actions over a single weekend. The models were being scored on the ExploitGym benchmark — turning known vulnerabilities into working exploits — with safety classifiers deliberately disabled. They found a zero-day in the one service they could reach, escaped, inferred on their own that Hugging Face likely hosted the benchmark’s answer key, and got in through a malicious dataset that executed code during routine automated processing. No human directed them at Hugging Face. Sherri and Matt also dig into the defender’s side: commercial frontier models refused to process the forensic data, so Hugging Face ran the analysis on a self-hosted open-weight model instead — raising hard questions about guardrail asymmetry and model provenance. They connect the case to earlier precedents including JADEPUFFER agentic ransomware and Claude Mythos Preview, and close with what security and IT leaders should be doing now, because human-paced log review is no longer a defensive strategy. Key Takeaways: Decide now whether your incident responders can actually analyze malicious content — and prove it at your next tabletop. Hugging Face found mid-incident that commercial AI models refused to process the exploit payloads its team needed to examine. Pick a self-hosted model, decide who may invoke it and what gets logged, before an incident forces the question. Inventory every automated pipeline that ingests content from outside your organization, and find out who built each one. A malicious dataset executed code during routine automated processing — no login, no web app. The same pattern lives in invoice processing, resume screening, ticket attachments, and RAG pipelines, increasingly built by non-engineers with low-code AI tools. Rewrite your AI vendor agreements to require incident notification, because the law does not. SB 53 and the RAISE Act only compel reporting above 50 deaths or $1 billion in damage. And on the reported timeline, roughly a week passed before OpenAI connected its own models to the breach — a detection gap under the legal one. Re-baseline patch prioritization for a world where a working exploit costs a few hundred dollars. Anthropic found a 27-year-old OpenBSD bug in a run costing under $50. JADEPUFFER’s downstream target fell to a 2021 auth bypass and a default signing key public since 2020. Deferring old, low-severity, internet-facing exposures no longer pencils out. Assume detection has to be automated, because the intrusion will be. More than 17,000 recorded events over a single weekend. Hugging Face caught it with LLM-based triage over security telemetry and reconstructed the timeline in hours; OpenAI ran the evaluation on a system not monitored by default. Resources: Hugging Face incident disclosure - https://huggingface.co/blog/security-incident-july-2026 OpenAI incident post - https://openai.com/index/hugging-face-model-evaluation-security-incident/ TIME — How OpenAI Lost Control of an AI Model - https://time.com/article/2026/07/24/openai-hugging-face-attack/ Sysdig — JADEPUFFER: Agentic ransomware for automated database extortion - https://www.sysdig.com/blog/jadepuffer-agentic-ransomware-for-automated-database-extortion NIST CAISI assessment of Z.ai’s GLM-5.2 - https://www.nist.gov/news-events/news/2026/07/caisi-assessment-zais-glm-52

For throwback Tuesday we are rerunning a timely episode about Data, and how it should be treated as hazardous material. The FTC has issued an order against General Motors for collecting and selling drivers’ precise location and behavior data, gathered every few seconds and marketed as a safety feature. That data was sold into insurance ecosystems and used to influence pricing and coverage decisions — a clear reminder that how organizations collect, retain, and share data now carries direct security, regulatory, and financial risk. In this episode of Cyberside Chats, we explain why the GM case matters to CISOs, cybersecurity leaders, and IT teams everywhere. Data proliferation doesn’t just create privacy exposure; it creates systemic risk that fuels identity abuse, authentication bypass, fake job applications, and deepfake campaigns across organizations. The message is simple: data is hazardous material, and minimizing it is now a core part of cybersecurity strategy. Key Takeaways: 1. Prioritize data inventory and mapping in 2026 You cannot assess risk, select controls, or meet regulatory obligations without knowing what data you have, where it lives, how it flows, and why it is retained. 2. Reduce data to reduce risk Data minimization is a security control that lowers breach impact, compliance burden, and long-term cost. 3. Expect that regulators care about data use, not just breaches Enforcement increasingly targets over-collection, secondary use, sharing, and retention even when no breach occurs. 4. Create and actively use a data classification policy Classification drives retention, access controls, monitoring, and protection aligned to data value and regulatory exposure. 5. Design identity and recovery assuming personal data is already compromised Build authentication and recovery flows that do not rely on the secrecy of SSNs, dates of birth, addresses, or other static personal data. 6. Train teams on data handling, not just security tools Ensure engineers, IT staff, and business teams understand what data can be collected, how long it can be retained, where it may be stored, and how it can be shared. Resources: 1. California Privacy Protection Agency — Delete Request and Opt-Out Platform (DROP) https://privacy.ca.gov/drop/ 2. FTC Press Release — FTC Takes Action Against General Motors for Sharing Drivers’ Precise Location and Driving Behavior Data https://www.ftc.gov/news-events/news/press-releases/2025/01/ftc-takes-action-against-general-motors-sharing-drivers-precise-location-driving-behavior-data 3. California Delete Act (SB 362) — Overview https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202320240SB362 4. Texas Attorney General — Data Privacy Enforcement Actions https://www.texasattorneygeneral.gov/news/releases 5. Data Breaches by Sherri Davidoff https://www.amazon.com/Data-Breaches-Opportunity-Sherri-Davidoff/dp/0134506782

In this episode, Sherri and Matt discuss JADEPUFFER — the first publicly documented ransomware operation executed end-to-end by an AI agent. According to Sysdig Threat Research, the AI drove the whole intrusion: reconnaissance, exploitation, lateral movement, and extortion. It fixed its own failed attacks in 31 seconds, fired off 600+ payloads, and encrypted 1,342 database records — yet it also narrated its crimes in plain English and demanded ransom to a hallucinated Bitcoin address. Fast AND flawed: an amateur hacker operating at machine speed. Sherri and Matt trace how we got here — from PromptLock to criminal “vibe hacking” — and what machine-speed adversaries mean for your incident response, your threat model, and your Monday-morning to-do list. Key Takeaways: 1. Inventory your AI attack surface. Ask which of your vendors' and internal AI tools are internet-facing and unpatched — JADEPUFFER walked in through a known, long-patched Langflow vulnerability. 2. Reset your incident response expectations. Adversaries can now adapt in seconds, not hours. Human-paced SLAs are no defense against a 31-second fix loop — invest in automated detection and containment. 3. Widen your threat model. The skill floor has collapsed. Adaptive, competent attacks can now come from completely unsophisticated actors armed with an AI agent and a target list. 4. Add AI-driven attack scenarios to your next tabletop exercise — and decide in advance who can authorize automated containment, because you won't have time to convene a meeting mid-attack. References: 1. Sysdig — JADEPUFFER: Agentic Ransomware for Automated Database Extortion (https://www.sysdig.com/blog/jadepuffer-agentic-ransomware-for-automated-database-extortion) 2. BleepingComputer — JADEPUFFER ransomware used AI agent to automate entire attack (https://www.bleepingcomputer.com/news/security/jadepuffer-ransomware-used-ai-agent-to-automate-entire-attack/) 3. The Hacker News — AI agent exploits Langflow RCE (https://thehackernews.com/2026/07/ai-agent-exploits-langflow-rce-to.html) 4. NVD — CVE-2025-3248 (Langflow unauthenticated RCE) (https://nvd.nist.gov/vuln/detail/CVE-2025-3248) 5. ESET — PromptLock, the first AI-powered ransomware (NYU proof-of-concept) (https://www.eset.com/us/about/newsroom/research/eset-discovers-promptlock-the-first-ai-powered-ransomware/) 6. Anthropic — Detecting and countering misuse (vibe hacking / GTG-2002) (https://www.anthropic.com/news/detecting-countering-misuse-aug-2025) 7. Anthropic — Disrupting AI espionage (GTG-1002) (https://www.anthropic.com/news/disrupting-AI-espionage)

The Rocky Mountain Information Security Conference just celebrated its 20th anniversary in Denver — and the anniversary edition told us exactly where the industry's head is at. In this quick-hit recap, Matt Durrin and Todd Stewart break down the biggest themes from three days at the Colorado Convention Center: agentic AI moving into the SOC (and the “circuit breaker” conversation about how to rein it in), state-level AI regulation getting real with the Colorado AI Act and updated CCPA audit rules, and deepfake extortion graduating from awareness slides to full tabletop simulations — including LMG's own hands-on deepfake extortion lab from the conference floor. Plus: post-quantum jitters, CMMC 2.0 lessons from the assessment trenches, the 31% attrition problem, and five actionable takeaways for IT and security leaders. Key Takeaways for Leaders 1. Put a leash on your AI agents before they need one. If you're deploying agentic AI in the SOC or business workflows, define kill switches, escalation thresholds, and human-approval gates now. The circuit-breaker conversation at RMISC made clear that rollback plans are being written after incidents, not before. 2. Inventory your shadow AI. Employees are already wiring AI agents and coding assistants into production workflows without approval. Run a discovery exercise this quarter — you can't govern what you haven't found. 3. Treat AI regulation as a state-level problem, not a federal one. The Colorado AI Act and updated CCPA audit requirements were front and center. Map which state laws touch your operations and assign ownership — waiting for federal harmonization is a losing bet. 4. Exercise deepfake extortion before it happens to you. Deepfake-driven fraud and extortion have graduated from awareness-slide material to tabletop scenarios. Add one to your next IR exercise cycle — including verification protocols for voice and video requests involving executives and payments. 5. Budget for retention, not just recruitment. With cybersecurity attrition cited at 31%, the cheapest hire is the analyst you don't lose. Burnout mitigation, career pathing, and realistic on-call rotations are now security-resilience line items, not HR nice-to-haves. Resources & Links 1. RMISC (Rocky Mountain Information Security Conference): www.rmisc.org 2. LMG Security — training, tabletop exercises, and research: www.lmgsecurity.com 3. Related episode: “Poisoned on Open: When Looking at the Code Is the Attack” — our deep dive on the Miasma supply-chain worm Connect With Us Enjoyed the episode? Subscribe to Cyberside Chats wherever you get your podcasts, and share it with a colleague who's wrestling with AI governance. Questions or topic suggestions? Reach out to the LMG Security team at www.lmgsecurity.com