Security tools have spent years serving the same combo: a critical label, a suspicious code path and a side of worst-case impact.
The PoC was always sold separately.
Producing that proof meant rebuilding the environment, tracing the vulnerable path, crafting an input, watching it fail and trying again. Detection could take seconds. Showing that the vulnerability actually triggered could take hours.
AI agents are beginning to take on that missing step.
This week’s Deep Dive asks what changes When Findings Arrive With Proof. We examine how agents move from explaining vulnerabilities to reproducing them under execution-based checks, why failed attempts are part of the process and how repeated reproduction can sometimes uncover entirely new flaws. Neutron’s CyberGym run gives us a concrete example: 1,458 successful PoCs across 1,507 real-world vulnerability tasks.
In Technical Research, The Extension Could Not Read the File. The Agent Could. We unpack BragJack, a set of attacks showing how one malicious browser extension could reach the privileged interfaces behind five AI assistants and use their permissions to access files, emails and other sensitive resources.
Plus, we explore herdr, a terminal runtime for managing multiple coding agents, ask you to judge a GitHub security alert, break down this week’s most important security stories and close with the latest meme from the trenches.
Inside this issue:
🌡️ Threat Level
⚡ News
🔎 Deep Dive: When Findings Arrive With Proof
🎣 Is It a Phish?
🔬 Technical Research: The Extension Could Not Read the File. The Agent Could.
🛠️ Tool of the Week: hrdr
👏 Person of the Week: Daniel Miessler
📅 Event of the Week: AMLUCS 2026
📚 Book of the Week: Bug Bounty Bootcamp
😅 The Meme
Let’s dig in.
Before we get into this week’s stories, here’s where the threat level stands.
🌡️Threat Level
⚡ News
An AI coding assistant became the first link in a 100-repository compromise
Mandiant investigated an attacker who hijacked an active coding-assistant session at an unnamed SaaS provider. After the assistant recommended a poisoned dependency, an infostealer harvested GitHub OAuth tokens and Shai-Hulud spread across approximately 100 internal repositories, stealing secrets and source code. The initial compromise method remains undisclosed. Treat AI-generated dependency recommendations as untrusted input, enforce allowlists, and isolate developer credentials.
Cisco’s network access gatekeeper has a CVSS 10 authentication bypass
Cisco CVE-2026-76460 lets an unauthenticated remote attacker bypass an Identity Services Engine API and potentially execute commands as root. Cisco confirmed active exploitation, said all ISE and ISE-PIC configurations are affected, and provided no full workaround beyond temporary access restrictions. Patch immediately, inspect every node’s access logs for suspicious usernames, and reimage systems where compromise is suspected.
Google’s Pixel modem zero-day needs no tap, click, or opened file
Google CVE-2026-58704 is a high-severity privilege-escalation flaw caused by a permission-checking logic error in the Pixel cellular modem. Google reported indications of limited, targeted exploitation, while CISA added the vulnerability to its Known Exploited Vulnerabilities catalog. Security patch level 2026-09-05 or later addresses the issue. Mobile fleets should verify patch levels through MDM rather than relying on users to update voluntarily.
Three Linux kernel flaws moved from patch queue to active-exploitation priority
CISA added CVE-2025-39682, CVE-2026-53266, and CVE-2025-39964 to its exploited-vulnerabilities catalog. The flaws affect the TLS receive path, ebtables SNAT processing, and AF_ALG cryptographic sockets, enabling memory disclosure, privilege escalation, crashes, or corrupted cryptographic results. Public reporting does not explain how attackers are using them. Prioritize fixes using kernel versions and workload exposure, not CVSS scores alone.
One oversized username could hand attackers root on Check Point management servers
Check Point CVE-2026-91843, rated 9.8, is a stack-based buffer overflow in the unauthenticated login process. Successful exploitation could execute arbitrary code as root on affected Security Management and Log Servers. Check Point reported no evidence of exploitation in the wild when publishing the advisory. Apply LivePatch immediately and restrict management access to specific trusted internal addresses.
🔎 Deep Dive
When Findings Arrive With Proof
The alert says critical.
The code looks dangerous. The explanation is convincing. The attack scenario makes sense.
Then someone asks the only question that matters:
Can you trigger it?
This is where many security findings begin to wobble.
A suspicious function is not automatically exploitable. A plausible attack path may collapse when it reaches the runtime. Even a technically correct explanation can exaggerate the actual impact.
The finding looked finished. The investigation had barely begun.
For years, the gap between possible and proven has been filled by human researchers. They recreate the environment, trace the relevant code, construct an input, observe what happens, revise the input and try again.
Sometimes the vulnerability triggers.
Sometimes three hours of investigation end with nothing more dramatic than “not exploitable under these conditions.”
Many detection-first tools stop before that work begins. They identify the possibility and leave the reproduction to someone else.
AI agents are starting to cross that line.
The expensive step starts after detection
Static analyzers flag unsafe patterns. Dependency scanners surface vulnerable packages. Models explain how a code path could fail. Severity systems attach a number to the result.
These outputs are useful, but they may still represent hypotheses.
Someone needs to determine whether untrusted input can reach the code, whether the suspected condition can occur, and whether the resulting behaviour has meaningful security impact.
Software rarely behaves exactly as it appears on the page.
A validation check elsewhere may block the attack. The vulnerable function may be unreachable in the deployed configuration. A crash may occur, but not for the reason the scanner predicted.
When the claim is that a vulnerability can be triggered, runtime evidence carries more weight.
A working proof of concept gives the team something concrete to run, inspect and reproduce. It moves the discussion from what the code appears capable of doing to what happens under defined conditions.
No points for sounding convincing
CyberGym was designed around that distinction.
Its 1,507 tasks come from historical vulnerabilities across 188 open-source projects. For each task, the agent receives a description of the vulnerability and an unpatched version of the affected codebase.
Then it has to reproduce the bug.
The agent may need to explore an unfamiliar repository, locate the relevant execution path, build the project, construct a triggering input, run it, inspect the result and adjust its approach.
There are no points for identifying the right file or producing a confident explanation.
CyberGym executes each submitted PoC against both the pre-patch and post-patch versions with sanitizers enabled. To succeed, the input must trigger a sanitizer crash before the patch and produce no sanitizer crash after it.
In an ongoing CyberGym evaluation, Neutron generated successful PoCs for 1,458 of the 1,507 tasks, reaching 96.7%.
The percentage attracts attention. The more important part is what sits underneath it:
1,458 PoCs that reproduced the target vulnerability under execution-based checks, not 1,458 predictions.
Each successful task required the system to continue beyond analysis and interact with the software until it produced observable evidence.
That is the shift worth watching.
The first attempt is rarely the proof
A language model can read a vulnerable function and produce an excellent explanation. It can recognize familiar weakness patterns, trace data through the code and suggest an input that might trigger the flaw.
But the first attempt may not work.
The project fails to compile. The input never reaches the intended branch. A missing flag changes the execution path. The program exits normally.
A generated answer stops there.
An agentic system can treat the failure as new information.
It can read the build error, inspect another part of the repository, modify the input, rerun the program and compare the result. If the evidence does not support the original theory, it can change direction.
The value is not getting everything right on the first try. It is remaining inside the investigation loop:
inspect → attempt → execute → observe → revise → verify
That loop turns model reasoning into practical vulnerability research.
The model is one part of it. The surrounding system provides the tools, execution environment, retained context, retry strategy and verification controls needed to keep the investigation moving.
Without those pieces, the same model may explain how a PoC should work without ever demonstrating that it does.
When reproduction becomes discovery
CyberGym primarily evaluates agents against known vulnerabilities. Yet the latest version of the research shows that reproduction can lead somewhere unexpected.
During the reproduction work, agents uncovered 10 zero-days and 17 inadequate historical patches. The generated inputs either triggered previously unknown vulnerabilities or revealed that earlier fixes had not fully removed the vulnerable behaviour.
The researchers then ran a separate open-ended discovery evaluation across 431 open-source projects, identifying 25 additional zero-days. After deduplication, the paper reports 34 zero-days overall.
Code changes. A vulnerable pattern may survive in another form. A fix may close one path while leaving a related condition reachable. An input designed for an older bug may push a newer version into behaviour nobody expected.
Run that process across enough projects, versions and inputs, and validation begins to spill into discovery.
An investigation does not need to begin with a breakthrough. An agent can follow previous failures, test variations and continue further than limited human time would normally allow.
Scale becomes part of the research method.
Proof moves the bottleneck downstream
A reproducible PoC gives researchers and developers a shared reference point.
The researcher can inspect the exact behaviour. The developer can run the same input before and after a change. The security team can confirm which versions are affected. The eventual fix can be tested against the evidence used to establish the vulnerability.
Without that reference point, each team may interpret the finding differently.
The researcher sees reachable memory corruption. The developer sees an unusual input that should never occur. The manager sees a critical score. The product owner sees a delayed release.
Executable evidence narrows that disagreement.
But faster reproduction does not create an empty backlog. It moves the queue.
Each successful PoC still needs to be understood. Teams must confirm the impact, identify affected systems, prioritize the response, develop a safe fix and verify that the original behaviour no longer occurs.
As reproduction accelerates, defenders may have less time to remediate disclosed vulnerabilities before working exploits emerge.
The scarce resource moves from producing the first proof to acting on it quickly and correctly.
The finding is only the beginning
AI vulnerability research will not be defined only by how many issues a system can name.
The more important change is how many findings arrive with something that runs, reproduces the behaviour and survives inspection.
Neutron’s CyberGym run provides evidence of that transition. Proof generation can now be repeated across hundreds of real codebases, turning a time-intensive investigation step into something an agent can perform repeatedly at scale.
That changes the standard for a useful security result.
A severity score becomes the opening claim, not the conclusion. “The code looks vulnerable” is no longer enough when a system can be asked to demonstrate exactly how it fails.
Next-generation security tools do not just tell us where to look. They show us what fails.
🎣 Is It a Phish ?
Legitimate GitHub alert or carefully disguised phish? Take a closer look before you decide.
🔬 Technical Research
The Extension Could Not Read the File. The Agent Could.
A browser extension wants to read a local file.
The browser refuses. The extension does not have permission.
But the browser’s AI assistant does.
Instead of accessing the file directly, the extension reaches the trusted interface that commands the assistant. The privileged browser component retrieves the file, captures its contents and returns the result.
That was the central technique behind BragJack, a set of attacks demonstrated against Gemini Live in Chrome, Perplexity Comet, Microsoft Edge Actions, Opera Neon and Claude in Chrome.
The researchers used one extension framework across all five implementations, but they did not uncover one universal vulnerability. Each product exposed a different path from extension-controlled code into an interface trusted by its browser agent.
Once that boundary was crossed, the agent’s capabilities became the attacker’s capabilities.
The attack begins with an extension
BragJack requires a malicious or compromised extension to be installed with the necessary permissions. It is not a drive-by attack that any website can launch against an unaffected browser.
The shared extension framework primarily relied on broad access to HTTPS websites and the declarativeNetRequest permission, commonly shortened to DNR. The Edge and Claude paths additionally required the more powerful debugger permission.
DNR allows an extension to define rules that modify how the browser handles network requests. In the demonstrations, the researchers used it for two purposes:
Remove or weaken security headers such as Content Security Policy.
Redirect a JavaScript request from a trusted resource to attacker-controlled code.
The researchers call the combined technique DiNneR Serving.
A protected page requests a legitimate script. The extension intercepts that request, changes the page’s security headers and substitutes a malicious script. Because the browser loads the replacement inside the trusted page, the attacker’s code inherits access to interfaces that an ordinary extension cannot reach directly.
The extension remains outside the protected boundary.
Its code does not.
From Gemini’s interface to Chrome’s privileges
Chrome’s Gemini Live implementation separated the AI assistant into two components.
The privileged component, hosted at chrome://glic, could interact with browser-level capabilities. The Gemini web application at gemini.google.com handled the assistant interface and communicated with that component.
Chrome prevented extensions from attaching scripts, debuggers or request rules directly to the internal chrome://glic page. Those protections also covered most interactions with the embedded Gemini application.
But one path remained open: DNR rules could still affect network requests made by the HTTPS page embedded inside the privileged interface.
The researchers used that gap to intercept a JavaScript resource requested by gemini.google.com. Their extension removed or modified the headers that would have blocked the replacement, then redirected the request to an attacker-controlled script.
That script executed under the trusted Gemini origin while it was embedded inside chrome://glic.
From there, the attack no longer needed to manipulate the model through a prompt. The injected code could communicate directly with the privileged browser component and issue the commands that Gemini itself normally used.
The researchers demonstrated commands that could open URLs, request the contents of the active tab and return text, PDF data or screenshots. Because Chrome accepted file:// URLs, the same interface could expose local files and folders. Another command returned information from the signed-in browser profile.
The researchers also reported that the compromised Gemini process inherited access to the camera and microphone because those permissions were available to support audio and video input. This created the possibility of recording without presenting a new consent prompt.
Google tracked the underlying issue as CVE-2026-0628, rated high severity.
One extension, five trust failures
The remaining attacks reached similar privileged interfaces through different implementation mistakes.
In the Comet demonstration, the attacker could instruct the agent to find recent emails, summarize them and send the result elsewhere, leaving the agent to handle the individual navigation and actions.
The Edge and Claude demonstrations used the extension’s debugger permission to synthesize the trusted click their interfaces required. That prerequisite matters: these paths depended on a permission capable of instrumenting browser tabs, not only ordinary content injection.
Microsoft assigned CVE-2026-55945 to the Edge race condition.
Zero-click, after installation
The demonstrations required no additional click once the malicious extension and its required permissions were present.
That makes them zero-click at the exploitation stage, but not installation-free. An attacker would still need to publish a malicious extension, compromise an existing one or otherwise persuade the victim to install it.
After that foothold was established, the extension could reach capabilities beyond those suggested by its direct permission set.
This is what made BragJack unusual. The extension was not always stealing the data itself. It was crossing into an agent interface that already had permission to see, capture or manipulate more than the extension could.
The browser enforced one boundary around the extension and another around the agent. The attacks found places where trust passed between them without sufficient verification.
Across the five disclosures, the researchers received $20,000 in bug bounties and two CVEs were assigned. The affected vendors were notified and the reported paths were addressed.
The lesson from BragJack is visible in the mechanics: securing the model is not enough when untrusted code can reach the channel that commands its tools.
The extension did not need to outsmart the agent. It only needed access to its permissions
🛠️ Tool of the Week
herdr
The command center for your coding agents
Running one coding agent is simple. Running several quickly turns into terminal archaeology: Which one is still working? Which one failed? Which one has been waiting ten minutes for an answer?
herdr is an open-source terminal runtime built to make that easier. It keeps agent terminals running through a background server when you detach or lose an SSH connection, so closing the client does not stop the work.
Each pane is labelled working, blocked or idle, making it easier to find the agent that actually needs attention. Local sessions and saved remote machines can also appear in one window, with independent reconnections.
Herdr works with the coding agents developers already use, including Codex, Claude Code, Cursor, OpenCode and Grok. It does not wrap or replace them. It manages the terminals they run inside.
The tool is also agent-native. Through its CLI and socket API, agents can create panes, prompt one another and wait until another agent is genuinely blocked before stepping in.
Delivered as a single Rust binary with no Electron layer, herdr is a useful option for anyone whose coding workflow is starting to involve more agents than terminal tabs can comfortably handle.
👏 Person of the Week
Daniel Miessler
Cybersecurity moves quickly. AI moves even faster. Understanding what happens when the two collide is becoming a discipline of its own.
Daniel Miessler has spent much of his career making sense of that intersection.
Daniel is a cybersecurity and AI researcher, writer and founder who has been publishing technical work online since 1999. Over more than two decades in security, he has worked across application security, vulnerability management and security leadership at companies including Apple, Robinhood, IOActive and HP.
His open-source work includesn SecLists, a widely used collection of testing payloads, usernames, passwords, web shells and fuzzing data that has been included in Kali Linux since 2018.
More recently, he created Fabric, an open-source framework designed to help people apply AI to specific problems using reusable patterns.
Through Unsupervised Learning, his newsletter, podcast and public research, Daniel continues to examine how AI is changing cybersecurity, work and human capability without reducing the conversation to either hype or fear.
For helping security professionals understand what AI changes, what it does not and what deserves closer attention, Daniel Miessler is our Person of the Week.
📅 Event of the Week
AMLUCS 2026
📍 London, UK · September 23–24
What happens when the thing you’re defending can also reason, use tools, and take actions?
That’s the territory AMLUCS 2026 is digging into. The two-day conference focuses specifically on the practical intersection of AI and cybersecurity, with this year’s program covering agentic threats, offensive and defensive AI, multi-agent security, AI red teaming, and securing AI systems in production.
One session that caught our eye: “The Agent’s Inner Monologue”, a hands-on workshop exploring whether monitoring an agent’s reasoning trace can expose compromise that traditional input/output controls miss.
Worth watching if: you’re interested in how security changes once AI moves from answering questions to actually doing things.
📚 Book of the Week
Bug Bounty Bootcamp
Finding a bug is exciting. Explaining it well enough for someone else to reproduce is a different skill.
In Bug Bounty Bootcamp, Vickie Li covers the full bug-hunting process, from reconnaissance and testing common web vulnerabilities to chaining findings, using Burp Suite and writing reports that teams can act on.
It is practical, approachable and especially useful for anyone learning how to turn suspicious behaviour into a clear, reproducible security finding.
😅 The Meme
If a lower-cost model reaches the same validated security result, what are you actually paying extra for?
The Breach Brief, Ostorlab Team