Cyberside Chats: Cybersecurity Insights from the Experts

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:

Resources:

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:

References:

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:

Resources:

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:

Resources:

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:

References:

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:

Resources:

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:

Resources: