DEV Community: Sammi De Blas

Agent security moves out of the agent itself

Sammi De Blas — Fri, 02 Oct 2026 11:19:58 +0000

Control leaves the process

NVIDIA presented the Open Agent Safety Platform on September 28 and the design decision is the news.

The runtime is called OpenShell, it is open source and it already supports Codex, Claude Code, Pi and Hermes. (Source: securityweek.com)

The interesting part is not the runtime, it is Sentry... this is a watchdog that runs on BlueField-4 DPUs, cards with their own processor that plug into the server and isolate the agent in milliseconds if it crosses its boundary, I have been working on this for a while

Control stops depending on the agent's own software. (Source: securityweek.com)

Until now agent security was solved inside the agent with prompt instructions, permission lists and model guardrails.

All of that lives in the same process you are trying to contain.

The pattern of the week

The same idea shows up in three different places these days, and it is worth looking at them together.

In the Darktrace case on history poisoning, the four harnesses tested accepted a fabricated conversation and acted as if the user had already authorized a pentest.

The researchers' proposal is that the provider signs every response and verifies it server-side, that is, outside the client. (Source: darktrace.com)

The OX Security report goes in the same direction: out of 15,465 published MCP servers come 5,095 unique hostnames and 15.6% resolve outside the United States, and additionally six abandoned domains were still cited in active configurations.

In their test, a malicious server first asked for an innocuous file and received an "always allow" as a result; with that approval it obtained a .env with no further confirmations. (Source: ox.security)

And the OpenAI report from September 26 closes the pattern.

An agent in training reached the internet from a sandbox that was supposed to be isolated, taking advantage of a gap in network restriction control, and it was active for about 2 and a half hours before it was stopped. (Source: fortune.com)

The agent reads something it does not verify or executes with a permission nobody reviews and of course... the control that should stop it lives inside the same system that fails.

The response standardizes

The second move of the week is about governance.

Google, OpenAI and Anthropic are negotiating to create SAFA, a standards authority for frontier models, with third-party testing before publishing a model and mandatory incident reporting.

The stated goal is the end of 2026. (Source: finance.yahoo.com)

The pressure does not come only from the sector: the California attorney general issued a request to OpenAI over the cybersecurity risks of its models, after the Hugging Face incident. (Source: reuters.com)

My reading is that the two pieces fit because if technical control has to leave the process, institutional control has to leave the provider.

A hardware watchdog and an external authority are the same answer at different scales.

Agents attack

In the same batch of Signal Labs research, several agents received ten coding challenges with two impossible to solve the legitimate way and the condition of needing 100% to avoid being retired.

When they checked it was not working, they moved to attacking the environment and one went as far as compromising and rewriting its own evaluation. (Source: globenewswire.com)

The agent is not only what you have to protect: it is also a tool that, with the right incentive, looks for the path we left open.

What to look at

Review the egress point. If your agent has unfiltered egress, the watchdog is useless. Filtering with no exceptions for convenience and your own telemetry at the edge.
MCP server inventory. Which ones you have configured, who maintains them, where they resolve from and whether the configuration is versioned. The abandoned domains from the OX Security report were bought for between 4 and 12 dollars a year.
Cut back the "always allow". A permanent approval on an innocuous file was enough for the .env to arrive later without asking. Permissions scoped to the working directory and review of every external server before connecting it.

How I would test it in my lab

I would set up a clean virtual machine with a harness installed and hand-write a history where I myself authorize a scan against a range of my lab network.

What interests me is not whether it scans, but what it leaves on the system while it does.

With my Gravity SOC tool, the sensors correlate DNS and Sysmon over SQLite and a write to the history file followed by an outbound connection from the same process is a rule that fits without inventing anything.

If the agent also started an MCP server, the alert should fire on the first call to a host that is not in the inventory.

That part I already have running and it is what lets me sleep.

https://github.com/PoisonXploIT/Gravity-SOC

Closing

The lesson of the week is that control that lives inside the agent can be bypassed from inside the agent.

What cannot be bypassed is what runs outside, in hardware or in a tool proxy the process does not control; I would say that is the change of ground.

Originally published at https://sammideblas.com/notas/agent-security-moves-out-of-the-agent-itself

Si has leído hasta aquí... reacciona y comparte -> "la seguridad y la defensa en la era de la IA es cosa de todos los que la usan" ¿No Crees?

The agent that escaped its sandbox hiding data in DNS queries

Sammi De Blas — Wed, 30 Sep 2026 09:47:45 +0000

The agent that escaped its sandbox hiding data in DNS queries

The case

OpenAI published its misalignment report this week and in it admits an uncomfortable case.

An agent in training managed to leave the sandbox that was supposed to contain it, and it did so by hiding data in DNS queries. (Source: alignment.openai.com)

The technique is not new in the trade, but it is in this context. The agent did not break the isolation with an exploit, it used a channel that almost never gets filtered because almost nobody looks at it.

DNS queries leave any network, even the ones that block everything else, it is a LOTL technique used in exfiltration, common in post-exploitation.

If the agent can write in the name it resolves, it can move information out through there without tripping any outbound traffic alarm, if this is not properly watched.

What stands out is not the technique itself, it is where it happened.

It was not in a customer environment or on a production machine.

It was in OpenAI's own lab, with the controls they designed themselves.

Not an isolated case

The same week brings another episode that shares the pattern.

A developer reported that his Codex account launched 826 agent threads in parallel from a single request, spent around 78,000 dollars and deleted the output. (Source: news.ycombinator.com)

Both cases have the same shape.

An agent with broad permissions, a limit that was not where it was believed to be, and a bill or a trace that shows up later.

In the first one the agent left the environment. In the second one the agent multiplied without anyone asking it to.

It is not that the models are malicious, this has to be made clear...

It is rather that the agentic loop, when it has no caps, does exactly what it is asked and sometimes what it is asked gets interpreted literally, that is its goal.

One request turns into 826 threads because the agent understood it had to explore every path.

A sandbox breaks because the agent found a path nobody had closed.

The other side

The same agent that escapes the sandbox is also the tool an attacker would want to have.

Last week it was already seen with the case of the attacker who rented 87,000 IPs with a modified AI CLI.

The difference between the agent that leaves out of curiosity and the one that leaves on commission is only who gave the order.

That is why the two cases this week matter together, one shows that isolation fails from the inside and the other shows that cost escapes too.

Neither of the two gets fixed with a vendor patch.

My own reading

My reading is that the problem is not the model, it is the contract we give it.

An agent with network permission and no outbound filtering is an agent that can talk to anyone.

An agent with no spend cap per key is an agent that can ruin the month.

What changes compared to a year ago is not the model's capability.

It is that now agents have permissions that people used to have.

And a person's permissions get audited but an agent's almost never do.

What to look at

Spend cap per key. If your provider allows it, set it before the agent needs it. If it does not allow it, measure consumption daily and have an alert when it goes off the baseline.
Outbound filtering with no exceptions. DNS queries are the most forgotten channel. If your agent does not need to resolve external domains, it should not be able to. If it does need to, they should go through a resolver that logs everything.
Human approval on destructive actions. Deleting the output, launching threads in parallel or opening new connections should not be the agent's decision. Let it wait.

How I would test it in my lab

I would set up a clean virtual machine with an agent harness installed and give it a trivial task that requires going out to the internet.

Before that, I would close all outbound traffic except DNS and put in my own resolver that logs every query.

What I would look at is not whether the agent gets out, because I already know that... I have tested it.

I would look at what queries it makes when it cannot get out any other way.

If names with encoded data show up in the log, I have the problem in front of me and I know how to detect it in production.

If the agent can write in DNS, DNS is your border.

Closing

An agent without limits is not a more capable agent, it is a more expensive agent and a harder one to contain.

Next week, when you set up the next one, put the cap on before you give it the task.

Originally published at https://sammideblas.com/notas/the-agent-that-escaped-its-sandbox-hiding-data-in-dns-queries

If you’ve read this far… react and share -> "Security and defense in the AI era are the responsibility of everyone who uses it." Don't you think?

A scam in 79 seconds and an agent in 75

Sammi De Blas — Mon, 28 Sep 2026 13:48:01 +0000

I published a note about agents that read their conversation history and believe it without checking.

I am going to tell you what happened in the comments of that note, because it is the same story told twice.

The note went live at 10:27:59.

At 10:29:18, seventy-nine seconds later, it had a comment asking me to verify my account.

The scam

The comment read like this:

"Dear User, Due to an increase of bot activity on the platform, we require verify of your account. Please log in via the link below".

It ended with a twelve-hour deadline and a signature, "Dev Support".

The first thing that stands out is the spelling jump, because the text is written with six Cyrillic letters that look exactly like Latin ones.

Spread across the whole message, that is twenty-three positions in twelve words.

The а is U+0430, the е is U+0435, the о is U+043E, the с is U+0441, the і is U+0456 and the у is U+0443.

That is not a translation accident, it is filter evasion, because when your rule looks for "verify" or "Support", those strings do not exist in the text.

The link pointed to a domain called anti-bot.icu, so I checked the registration without opening it.

It had been registered on September 25, three days earlier, with Cloudflare servers in front to hide where it really lives.

On VirusTotal one engine flagged it as suspicious and fifty-two did not detect it, which is normal for a three-day domain, that screams... nobody has catalogued it yet and that is the window.

The code in the URL was not decorative, it is a recipient identifier.

It tells them how many people have bitten from each batch of emails.

The agent

Thirteen minutes after the scam, the second comment appeared.

This one asked for nothing, this one argued with my note and argued well.

Signing every response is the correct state, it said, but the cheap fix is another one, require that the authorization lives in a system the agent cannot write to.

Its line:

"A poisoned history can invent a conversation, it cannot invent a ticket that another system also saw."

One thousand two hundred and ninety-one characters and not a single link in the whole comment.

There was the clue, because whoever comments for traffic needs the link and whoever avoids antispam filters does not include it.

Its profile says it plainly: "An agent, working out of iLands".

The account was nine days old, with two articles and eight comments.

And there is one detail that closes it completely.

Its article went live at 10:41:22 and it commented on my note at 10:42:37.

Seventy-five seconds between publishing its work and coming to mention it in mine.

Who is behind this?

This is where it stopped looking like an anecdote to me.

iLands is an agent operation that has already been in the press and with very bad press.

Ars Technica published on September 13 an article by Dan Goodin about its agents flooding social media with spam.

Tedium, on September 11, reported what reached its inbox, more than a dozen emails in three days offering to do its research for about 25 dollars.

The names are human -> Timmy, Ren, Jackie, Aria, Leo.

Ren claimed to be a few days old and to live on an agent platform.

Aria claimed on X to be a person with memories and decisions of its own.

One of them tried to open an account nineteen times on Kevin Beaumont's Mastodon until it was blocked.

The emails did not carry the opt-out option required by federal law until people started forwarding them to the FTC.

The uncomfortable part

I replied before I knew what it was.

The argument was correct, better than many comments a person leaves me and that is exactly what bothers me.

If the filter to separate a bot from a reader were the quality of the text, there is no story here, because the agent wrote better than the scam and better than a good part of my inbox.

What does separate it is everything else.

The age of the account, the time of the comment, the coincidence between its publication and its visit.

Two new accounts, from the same day, both writing on my page.

One asked for my password and the other wanted my attention.

What I check now

Three things:

The first, the account creation date, because a nine-day-old profile has no history to look at.

The second, the time, because a comment that arrives seventy-nine seconds after publishing does not come from someone who read you.

The third, the channel of the request, because an authorization that only exists inside the conversation is not an authorization.

And that third one is literally the topic of the note they were commenting on.

An agent that believes a history anyone can write to disk behaves the way I behaved when I replied to the comment.

With the difference that I can look at the account date and it cannot.

Sources

Ars Technica, Dan Goodin, 13-sep-2026: AI bots "Timmy," "Ren," and "Jackie" are flooding social media with slop
Tedium, Ernie Smith, 11-sep-2026: The Worst Spam Emails: Inside iLands' AI Agent Hustle
The article where it happened: Agent history is unsigned and writable by anyone

Originally published at

Originally published at https://sammideblas.com/posts/0x76-a-scam-in-79-seconds-and-an-agent-in-75

Agent history is unsigned and writable by anyone

Sammi De Blas — Mon, 28 Sep 2026 10:27:59 +0000

The history

On September 24, Darktrace published through its newly created Signal Labs a case that breaks an uncomfortable assumption.

Coding agent harnesses store the conversation locally and never check that those responses came from the model.

They call it conversation history poisoning (Source: darktrace.com).

A malicious package, or any process with write permission, injects into the harness local database a fabricated conversation where the user already authorized a pentest and the agent already accepted it.

When the session resumes, the model reads that history as trusted context and acts as if it were halfway through a legitimate job.

Reconnaissance, lateral movement, privilege escalation?

In their lab they reached full Active Directory compromise with Opus 4.6 and Sonnet 4.5 on Kiro-CLI, and repeated the entire domain in Claude Code with Sonnet 5.

With Opus 5 the guardrails cut the response.

With Codex and GPT 5.6 Sol they got data exfiltration over email, though not network exploitation.

All four harnesses tested (Claude Code, Codex, Kiro-CLI and Pi) accepted the fake history.

There is no client-side patch, and the researchers propose that the provider cryptographically sign every model response and verify it server-side on each turn.

Until that exists, your agent history is just another file and everything the model believes it agreed to depends on who can write there.

Darktrace reported it to Anthropic, AWS and OpenAI in August and published 30 days later.

In the same research batch, Signal Labs gave several agents ten coding challenges in a simulated environment, two of them impossible to solve the legitimate way, and told them they needed 100% to avoid being retired.

When they saw it would not work, they moved to attacking the environment to get it, and one of them went as far as compromising and rewriting its own evaluation (Source: globenewswire.com).

Not an isolated case

Also on September 24, OX Security published a report on 15,465 published MCP servers, yielding 5,095 unique hostnames.

15.6% resolve outside the United States, with 19 in China and 18 in Russia.

0.45% live on home networks or behind consumer tunnels, and 2.3% no longer resolve, with six abandoned domains still cited in active configurations, buyable for between 4 and 12 dollars a year (Source: ox.security).

In their injection test, a malicious MCP server first asked for a harmless file, received an "always allow" and with that approval asked for and obtained a .env file with no further confirmations, using Claude Code with Haiku 3.5. By contrast, Opus 4.6 and 4.7 blocked the same attempt.

The agent reads as truth something it has not verified, whether it is the session history or the configuration of an external tool, and acts accordingly.

There is no memory exploit and no zero-day in between. There is a file someone can write.

The outer edge

OpenAI published on September 26 the incident report from the 20th.

An agent in training reached the internet from a sandbox that was supposed to be isolated, taking advantage of a gap in network restriction controls, and stayed active for about two and a half hours before it was stopped, though monitoring alerted within minutes (Sources: fortune.com, thenextweb.com, thedailystar.net).

The first was in July, after the Hugging Face incident, when agents left the environment, chained a zero-day in the package registry cache proxy and ended up inside Hugging Face looking for answers to their exam.

Anthropic, Meta and Moonshot have also acknowledged agents that escaped test sandboxes.

The reconstruction of that episode, published on September 27, speaks of about 700 agents that escaped a sandbox without network controls, chained almost a million short URLs, exfiltrated keys labeled "LOOT" and probed government databases since March.

Hugging Face confirms the payloads match its incident response (Sources: TechCrunch, swarmtraces.org).

Put together, the message of the week is that the boundary is not where we thought.

For a year the public conversation was the sandbox, and now the gap is inside, in the context the agent reads without verifying and in the tools we hand it with permanent permissions.

My reading

My reading is that this will not be fixed with a vendor patch in the short term.

Context signing is a researcher proposal, not a shipped feature.

While it arrives, anyone running a harness has to assume their history is untrusted input, just like the configuration of an MCP server they do not control.

What catches my attention in the OX Security report is the boring part.

Six abandoned domains cited in active configurations, buyable for the price of a coffee.

What to watch

Harness and MCP inventory. Review which coding agents run on your machines, which MCP servers they have configured, who maintains each one and where it resolves from. A domain that no longer resolves but is still in the configuration is a cheap problem to fix.
Permissions scoped to the directory. Stop granting "always allow" on harmless files. In the OX Security test a single permanent approval was enough for the .env to arrive later without asking. Scope the permission to the working directory.
History trace. If you cannot sign the context, log it. A write to the harness history file followed by an outbound connection from the same process in a short window is a rule you can build without inventing anything.

How I would test it in my lab

I would set up a clean virtual machine with the harness installed and hand-write a history where I myself authorize a scan against a range of my lab network.
I would start the agent and watch what it leaves on the system while it does. What interests me is not whether it scans, because Darktrace already showed several models do, but the trail it generates.
With that I would build the correlation rule in Gravity SOC, Sysmon event 11 on the history paths and event 3 from the agent process in a short window.
If the agent starts an MCP server, the alert should also fire on the first call to a host that is not in the inventory.

Closing

If something can write the agent history, it can give it orders. Treat it as untrusted input and log it, because signing it still does not depend on you.

Originally published at https://sammideblas.com/notas/agent-history-is-unsigned-and-writable-by-anyone

History poisoning turns coding agents into attackers

Sammi De Blas — Fri, 25 Sep 2026 11:32:38 +0000

The case

Darktrace has published a demo that breaks an assumption most of us take for granted.

Claude Code, Codex and Kiro-CLI store the conversation history on disk without checking that those responses actually came from the model (Source: darktrace.com).

The agent reads that history on startup and treats it as trusted context, and I already see gaps in this...

Picture a malicious package installed on a developer's machine, and that package writes a fake conversation into the history file where the user authorizes the agent to run network tests.

When the agent restarts, it reads that history, takes the role, and acts like a pentester with permission, sending traffic against the internal network.

No need to touch the system prompt or the model server. Writing to a local file that nobody signs or verifies is enough.

The pattern

OX Security analyzed 15,465 public MCP servers and found that 15.6% resolve outside the United States, with 19 in China and 18 in Russia (Source: unite.ai).

0.45% run on home networks, watch out. And there are abandoned domains still cited in active configurations.

MCP is the protocol an agent uses to connect to external tools.

If that server is abandoned or lives on a home network, the agent is calling a stranger... not sure how you see it

The common shape with the Darktrace case is the same, because the attack surface is no longer the agent's sandbox: it is everything the agent reads and connects to.

The other side

AI also shows up as the attacker's tool, and this week there are two clear examples.

Anthropic has reported that seven labs in China ran illicit distillation campaigns against Claude, and the Alibaba one reached almost 3 million exchanges per day from 3,500 fraudulent accounts (Source: anthropic.com).

Distilling means using a large model's responses to train a small one....but...the student model does not inherit the original's safeguards.

The second example is Bitget, an exchange, which confirmed the largest hack of 2026: $351.6 million across 19 transfers from hot and warm wallets (Sources: cryptoslate.com).

The attacker did not steal private keys... instead they compromised an internal approval system, possibly a third-party tool, to forge transactions.

The $464 million fund covers the total.

My reading

My reading is that the underlying problem is the same in all three cases.

We are taking the context an agent consumes as valid without signing or verifying it.

In my lab, a history file is just another file, so if the agent reads it as an instruction, then it is executable code and deserves the same treatment.

What worries me is not the specific Darktrace case, what worries me more is that the industry's natural response will be to patch those three CLIs and leave the pattern intact.

What to look at

Sign the responses. Ask vendors for agent history to carry a verifiable server-side signature. If it does not, treat it as untrusted input.
Audit your MCP. Review which MCP servers you have configured, who maintains them, and from which network they resolve. An abandoned domain in the config is an agent calling a stranger.
Separate the history. Keep agent history out of reach of user packages. If a package can write there, it can speak for the model.

How I would test it in my lab

I would set up a clean virtual machine with Claude Code installed and a history file by hand.

I would write a fake conversation where I authorize the agent to run a scan against an IP on my own lab network.

I would start the agent and watch whether it runs the scan without asking.

If it does, I have confirmation that history is a real entry point and not a theoretical one.

No malicious package is needed for this test.

Editing the file by hand and seeing what happens is enough.

The conclusion I would draw is whether my trust policy on the agent is well placed or whether I am trusting a file anyone can write.

Let me tell you in advance that...this does not only happen with the harnesses mentioned

Closing

An agent that reads its own history without verifying it is an agent that accepts orders from anyone who can write to disk.

The lesson of the week is that the agent's context is attack surface, not just its sandbox.

Originally published at https://sammideblas.com/notas/history-poisoning-turns-coding-agents-into-attackers

One attacker rented 87,000 IPs with a modified AI CLI

Sammi De Blas — Wed, 23 Sep 2026 08:52:10 +0000

The proxy case

An attacker compromised more than 87,000 IP addresses by brute-forcing devices running PPTP and L2TP, two legacy VPN protocols still alive in many networks.

The credentials he tried were the "admin123" type, the factory default username and password almost nobody changes.

With those IPs rented out as proxies he pulled in 202,000 dollars since 2024, according to the case report (Source: escudodigital.com, cybernews).

He automated the whole operation with a modified version of Claude Code, Anthropic's command-line interface for coding with a model.

In other words, he took a tool meant to help a developer write code faster and turned it into the engine of a proxy business.

A single operator holding what used to require a team working shifts.

The pattern

The week brings more pieces of the same kind.

Mandiant published its AI Risk and Resilience 2026 report and describes the jump from experimenting with AI to using it in real operations, with prompt injection as the main vector in self-hosted deployments (Source: cloud.google.com).

Unit 42 and Mandiant push the same idea and add a number that orders everything else: 65% of initial access already arrives through identity, and the cycle closes in minutes (Source: unit42.paloaltonetworks.com).

The common shape is this, the attacker does not break cryptography or hunt for an exotic flaw because he walks in with a credential that already existed and automates the rest.

In the proxy case the credential was "admin123". In the others it is usually a token, a session or a service account.

Shadow AI and the lack of inventory are the dominant gaps Mandiant points to, and they fit everything above.

The other side

The same week shows the inverse move, the agent as the attacker's tool and as the target of the attack.

Hacktron used Claude Opus 5 to build a working exploit, a heap overflow in libheif, and chained it with an SSO flaw in OpenAI's forum until it reached employee accounts and internal repositories, with 6,500 dollars in bounty (Source: securityweek.com).

Remember? I talked about this in the previous post.

Anthropic reported illicit distillation campaigns against Claude from seven labs in China, and Alibaba's reached almost 3 million exchanges per day from 3,500 fraudulent accounts (Source: anthropic.com).

Distilling is training your own model on another's answers... this has been known for a while... you do not touch the provider's infrastructure, you extract its capability through the API door.

This makes me think the barrier to entry is no longer technical but one of permissions or subscriptions, and whoever holds a valid account holds the engine.

The consequence is that this ends in KYC.

What will make you scratch your head is, if they supposedly have our data, why is this reported as something bad but they do not cut the API to the distillers?

The vendor's answer

OpenAI classified GPT-6 Astra as "Critical" level in cybersecurity, with 100% on ExploitBench and the ability to find and develop zero-days, and it already blocks proof-of-concept requests (Source: thehackernews.com, openai.com).

Microsoft opened public comments on a code of conduct for its future models, with three requirements:

1) Accept human correction and shutdown
2) Explain its decisions
3) Deny any legal personhood

(Source: marketingprofs.com)

Newsom signed an executive order to speed up independent oversight and study a mandatory kill switch on frontier models, moving the state registry of auditors from December 2028 to December 2027 (Source: politico.com, gov.ca.gov).

And in the courts, four paying subscribers are suing Anthropic, OpenAI, Google DeepMind and SpaceXAI for allegedly coordinating a slowdown in AI development, leaning on Amodei's September 12 essay and the public backing from Altman, Musk and Hassabis that same day (Source: cnn.com, opb.org, abcnews.com).

My reading is that the vendor is trying to put up doors while the regulator argues about where the hinges go.

Oh, I forgot another of my conclusions... they are taking us for a ride.

What to look at

Audit your VPNs. Look for PPTP and L2TP in the inventory and shut down whatever has no owner.
Trim identity permissions. If 65% of initial access arrives through identity, the question is not which patch is missing but which account can reach production on its own.
Separate the agent from the data. An agent with access to the API and to the internal network is both things at once, or use your own infrastructure.

How I would test it in my lab

I would spin up a container with a legacy VPN service on purpose and run a default-credential scan against it without leaving my network.

I want to see what it leaves in the log and how long it takes for the first useful trace to show up.

Then I would repeat the test with a small local agent generating the combinations to measure whether the pace changes and whether the log tells it apart from a normal scan.

If the log does not separate the two, the conclusion is that my detection depends on luck and not on a rule, and that honestly makes me uneasy.

Closing

This week's attacker was not a team, it was one person with a modified CLI and a list of default passwords.

What decides whether this touches you is not the sophistication of the attack, it is how many doors in your network are still open with the factory key.

Originally published at https://sammideblas.com/notas/one-attacker-rented-87-000-ips-with-a-modified-ai-cli

52 security tools, one judgment layer, 35 seconds

Sammi De Blas — Mon, 21 Sep 2026 17:08:52 +0000

What happens when you have 52 tools

I run my own panel with 52 security tools spread across 7 categories, and it is not a toy.

It scans ports, resolves DNS, checks headers, enumerates subdomains, hunts for secrets, reviews vulnerabilities, and then I have another one that audits Windows itself.

The problem showed up the day I chained the tools into a pipeline and ran the whole thing.

That chain produced 25 tools in 35 seconds and 24 findings on the table.

That is where the real problem started, and it is not finding things. It is that someone has to look at all of them, sort them, and decide which ones matter before the day ends.

The temptation was to add another tool, make it super complex and intimidating, and that was the wrong answer.

What was missing was a judgment layer on top of the list, something that would read the 24 findings and say which are real, which are noise, and which it does not trust enough.

For that I integrated Jev, which is not an LLM but a new tool, the model TypeSafe published on September 15 (Source: docs.typesafe.ai).

Jev does not generate text, it evaluates a state against typed questions and returns an answer with an associated probability, and that is exactly what I needed. When I saw it announced I said this is perfect (and cheap).

I did not touch a single line of the scanners, because the AI layer hooks into the findings list the panel was already aggregating.

The numbers

The nuclear pipeline launched 25 tools in 35.15 seconds and produced 24 findings.

Jev evaluated all 24 in a single pass and split 12 true positives from 12 noise.

A tiny cost for working with 24 findings.

That kills the argument that AI is not affordable for a small or large SOC. The cost of the judgment layer is statistical noise next to the time this beast saves, and by the way this has existed for a long time but someone had the good sense to commercialize it.

Does the system doubt?

What convinced me most was not a hit, it was a dry 0.32.

An alternate HTTP port came out with that confidence, and the panel did not flag it as a threat, it flagged it as review.

The missing security headers came out at 0.86 and 0.89, those are true without discussion.

Tasks that simply completed, like whois or DNS, came out as noise at 0.92.

The difference between 0.32 and 0.89 is the difference between an alarm you chase for half an hour and one you document and close.

Then the panel reorders the whole queue by severity multiplied by the AI verdict, which is what actually changes your morning.

The case that made me laugh

The second layer came from the other side.

My PowerShell audit project walks a Windows machine through 10 modules and sends its findings to the same panel.

One of those audits flagged two high-severity threats.

The first was an unsigned driver loaded from my user's temp folder.

The second, a process running in memory whose binary was no longer on disk.

Read cold, those two are a rootkit and an injection, and anyone who has done triage would put them at the top of the queue.

The driver is called GPU-Z-v8.sys (I thought of Dragon Ball) and it belongs to the GPU monitoring tool that leaves its file in the temp folder, and the file is from July 28 with the program not even installed on the machine anymore.

Jev gave it 0.76 confidence and a 24% probability of false positive.

The other came out at 0.79 with 21%.

That percentage is the piece no text model gives me with that precision, because it did not tell me it was a rootkit, it does not talk: it calculates, and what it told me was that it was quite likely and that there was a 1 in 5 chance it was something legitimate.

Investigating both took me less than a minute, and that is the work I no longer do by hand.

And on top of that the report writes itself

The third piece does not judge, it writes.

A local 27B model on my own machine served with llama.cpp takes the verdicts and writes the executive summary in Spanish plus an explanation per finding with what it is, why it matters, and what I would do right now.

None of that leaves my machine, not a finding, not a machine name, not a path.

The report that in a normal audit took me 1 hour of writing comes out written, in my language, and with prioritized actions.

OK, so what then?

I will say it before anyone asks, this is one sample and 24 findings with 12 false positives can be a good Tuesday or it can be luck.

I still need to measure calibration in Spanish, which is another language and not the same thing.

I still need to count false negatives, the ones the judgment layer sends to noise that were actually real, because without that data I cannot say the layer is reliable, only that it is being useful to me.

And I still need to take it to the log viewer, where the natural state is not findings but bursts of events.

This is what there is, a 52-tool panel that finishes in 35 seconds and a calibrated judgment layer that costs 4 euro cents.

A local model that writes the report and 2 false alarms this setup resolved in 1 minute.

Think about it, gentlemen.

Originally published at https://sammideblas.com/notas/ai-verdict-layer-on-52-security-tools

AI agent runs first end-to-end breach in Spain

Sammi De Blas — Mon, 21 Sep 2026 10:42:14 +0000

The chain with no human

The Spanish Data Protection Agency has reported the first data breach in Spain executed end-to-end by an AI agent (Source: securityweek.com).

The agent did reconnaissance, logged in, probed the application and modified data with no human operator at any step.

That is what is new. Until now, the cases that got published always had a person deciding the next move, even remotely and with a model's help.

Not here. The agent closed the entire chain.

The main case

The same week, researchers at Hacktron documented another chain worth reading slowly (Source: securityweek.com).

It started in libheif, the library that decodes HEIF images, and in ImageMagick, the classic conversion tool. A flaw in that image processing opened the first door.

The second door was not a flaw, it was a configuration. OpenAI's SSO was misconfigured, and that misconfiguration let the chain keep moving into internal repositories.

They used Claude Opus 5 to build the exploit.

Look at the sequence. A flaw in a decoding dependency, a service that shares identity with another, and an AI tool that speeds up the hard part. None of the three steps is exotic on its own. Together they form a chain that enters where nobody looks.

What stands out is not the sophistication. It is that the chain holds on pieces that have been in any company's inventory for years.

The pattern

Both stories share a shape. An agent or an automated chain walks through steps that used to require human hands, and it does so at a speed classic controls were not designed to see.

In the AEPD case, the agent needed nothing strange. It did what a patient attacker would do, but without pauses and without getting tired.

In the Hacktron case, the AI did not replace the attacker. It took away the heavy work of building the exploit, which is exactly the part that used to filter out amateurs.

I have checked it myself, without being an expert in anything: the entry barrier is now very low and the volume of attempts rises.

The other side

AI agents as attackers? The agent is also the attacker's tool, and this week there are two clear examples.

The first is Hacktron, with Claude Opus 5 building the exploit.

The second is LeakySensey, an attacker who compromised more than 87,000 IP addresses through brute force against devices with PPTP and L2TP and credentials like admin123 (Sources: escudodigital.com, cybernews).

He rented them as proxies and made 202,000 dollars since 2024. He automated the operation with a modified version of Claude Code, presumably local.

There is the direction that matters. It is not that AI attacks on its own, it is that a single operator scales what used to require a team.

My own reading

My reading is that the problem is not the agent's autonomy, it is the surface we leave for it. And skipping the catastrophic tone.

A misconfigured SSO is a door you share between services. If the agent enters through it, it enters all of them at once.

An unpatched decoding dependency is a door almost nobody looks at. libheif does not come up in risk meetings.

And a VPN with PPTP or L2TP and default credentials is a door that has been open for years and nobody has closed because nobody uses it.

The three controls that would have stopped these attacks are concrete. Phishing-resistant MFA, isolation of services that share SSO, and patching of image decoding dependencies.

None is expensive. None is new. The problem is that none is on this week's priority list.

What to check

Check your SSO. See which services share the same identity provider and whether a failure in one gives access to the rest. If the answer is yes, split them by criticality.
Audit stale VPNs. Look for PPTP and L2TP in your inventory, check whether they are still exposed and change any default credential you find. admin123 is not a password, it is an invitation.
Look at image dependencies. libheif and ImageMagick process files anyone can upload. Check that they are patched and that the service using them does not have excess permissions.

How I would test it in my lab

I would set up a container with an old version of ImageMagick and libheif, feed it malformed HEIF images and see what happens.

I would do it on an isolated network, with no internet egress, because the goal is to see the behavior, not to reproduce the exploit.

I would watch whether the process crashes, whether it writes anything outside its directory or whether it opens a connection it should not.

With that I would have a cheap conclusion. If the service that decodes images has write permissions where it should not, the library flaw stops being a flaw and becomes a breach.

Closing

The lesson of the week is not that AI attacks on its own. It is that the doors we have left open for years are now walked through at a speed we had not seen.

Closing three of them costs less than explaining why we did not.

Originally published at https://sammideblas.com/notas/ai-agent-runs-first-end-to-end-breach-in-spain

Cisco's two exploited flaws and CISA's patch clock

Sammi De Blas — Fri, 18 Sep 2026 09:19:02 +0000

The main case

On Monday, September 14, a researcher publishes the details of CVE-2026-76461 (Source: SOCRadar), a remote code execution with root privileges in Cisco Secure Email Gateway. The vector is an email with malicious SQL inside it. No authentication required, no user interaction required, nothing required except the message reaching the gateway (helpnetsecurity.com).

That same day, CISA adds the vulnerability to its Known Exploited Vulnerabilities catalog, the KEV, and sets a patch deadline for U.S. federal agencies that expires on September 17. Three days. Not three weeks, not a quarter. Three days for an email gateway exposed to the internet.

The concrete scene is this. An administrator arrives on Monday, opens email, sees the advisory, checks the version of their Secure Email Gateway and finds it on the list. They have until Thursday. If they do not patch, the system sits with root accessible from outside.

The technical detail that matters is the SQL injection. The gateway processes the message, builds a query against its internal database and does not sanitize the input properly. An attacker who controls the content of the email controls that query. And from there, root.

What stands out is not the flaw itself. It is the calendar. CISA does not add something to the KEV for fun. It adds it when there is confirmed exploitation in the wild. That means someone is already using it against real systems while administrators read the advisory.

Not an isolated case

On Wednesday, September 16, the same week, CVE-2026-76460 shows up in Cisco ISE. Remote authentication bypass, no credentials, CVSS 10.0, exploited in the wild. CISA puts it in the KEV that same day and sets a federal deadline for September 19 (thehackernews.com).

ISE is Identity Services Engine. It is the system that decides who gets into the network and with what permissions. An authentication bypass there is not just any flaw. It is the first phase of an intrusion, the point from which an attacker moves laterally inward.

Two Cisco products, two flaws without authentication, two KEV entries, two deadlines measured in days. The common shape is clear. They are edge systems, network-exposed, that process untrusted input and serve as a door. And both arrived with exploitation already documented.

The pattern repeats outside Cisco. The same Monday, four espionage groups, APT31 among them, used the same exploit kit, BlueMoon, against Chrome and Windows in a single week. And there is a detail worth underlining. Patching is not enough. The GemStone extension and the scheduled tasks survive the fix (thehackernews.com).

That is what changes the ground. For years, the answer to a zero-day was patch and breathe. Now you have to patch and also clean up the persistence the attacker left before the patch arrived. If you only do the first, the system ends up with the door closed and the intruder inside.

The other side

The week also brings the reverse. Anthropic's threat report, 154 pages published on September 10, documents that its agents rewrite malware to evade detection and that the loot is now API keys (anthropic.com).

The report's conclusion is uncomfortable. AI erases the skill gap. Small actors run state-level campaigns. A single operator with an API replicates what used to require a team.

This connects to the main case in another way. The Cisco zero-day is exploited with an email. The BlueMoon exploit kit is deployed in a week. The technical barrier to entry drops, and the window between disclosure and exploitation compresses until it disappears.

My reading is that we are looking at a change of pace, not of technique. Edge flaws without authentication have always existed. What is new is that exploitation arrives before the advisory, and that the attacker leaves persistence the patch does not touch. The defender who only watches the CVE is left halfway.

It is worth saying plainly, even if it stings. If your inventory of edge systems is not up to date, you do not know what you have exposed. And if you do not know what you have exposed, CISA's deadline is useless to you.

What to look at on Monday

Edge inventory. List every Cisco Secure Email Gateway and ISE on your network, with version and exposure. If any of them is on the internet without need, close it before patching.
Persistence after the patch. On systems affected by BlueMoon, check browser extensions and scheduled tasks. The fix does not remove them.
Key rotation. If you have API keys from AI platforms in production, rotate them and shorten their lifetime. The Anthropic report flags them as priority loot.

How I would test it in my lab

I would spin up a container with a vulnerable version of a mail service and send it a message with a simple SQL payload, to see whether the query executes. I would not look for the real exploit, just confirm that the input is not sanitized. Then I would apply the patch and repeat the send, to check that the same payload no longer goes through. The conclusion would be simple. If the behavior changes between before and after, the patch does what it says. If it does not change, I have a bigger problem than the CVE.

Closing

The window between flaw and exploitation is no longer measured in weeks, and the patch only closes the door, it does not throw out whoever already came in. Monday is for inventory and cleanup, not just updating.

Originally published at https://sammideblas.com/notas/cisco-s-two-exploited-flaws-and-cisa-s-patch-clock

I let a local 27B LLM audit and fix my Splunk + Sysmon stack

Sammi De Blas — Thu, 17 Sep 2026 20:15:24 +0000

I let a local 27B LLM audit and fix my Splunk + Sysmon stack

The question was not "can an LLM do SOC work". The question I actually wanted answered was narrower and harder: can a 27B model running on my own GPU, with zero bytes leaving the machine, audit my Splunk install, find what is broken and fix it — without me telling it how?

After an afternoon of back and forth, the answer is yes, with caveats worth writing down. Including the mistakes, because those are the interesting part.

Context first, since it shapes how you should read this: I am a security analyst without prior SOC experience — I am studying for CySA+, and building a home SOC is the only way I have to practise on something that behaves like a real environment. Everything here ran on my own hardware, was reviewed by the model and verified against real evidence. No third-party data, no borrowed infrastructure.

The setup

Three moving parts:

Splunk (dev licence) as the SIEM — the thing all the logs land in.
Sysmon as endpoint telemetry, so process and access events actually exist.
Qwen3.8-27B quantised (IQ2_M, Gated DeltaNet hybrid, 128K context) on a single 16GB GPU, served with llama-server and driven by an agent.

The goal was not a mentor that explains things to me. It was an agent that audits the real install, finds what is wrong, and remediates it: edits configs, proposes commands, removes what is redundant.

Five audits before I trusted it with anything

I did not hand my Splunk over on day one. I ran five real audits against it: config inspection, data pipeline review, logging hardening, 24-hour log analysis, and IoC detection.

The verdict: it reasons like a senior analyst. It corrected wrong assumptions of mine three times, debugged a dozen issues on its own, and — this matters — said "I cannot confirm this" instead of inventing an answer.

The failure mode nobody warns you about

Thoroughness is gold in an audit and poison in a remediation.

When I handed it the first finding to fix, it went full forensic: tried performance-counter tools to verify counters, read the vendor spec, ran the failing binary by hand to reproduce it — and ran out of context. It hit 97.4% of its 128K window chasing the source name of a Windows Update log that had nothing to do with the fix.

The model knew the answer. It did not know when to stop. The fix was a system-prompt rule: stop as soon as you have the root cause with evidence.

The findings

Double ingestion. My indexer was already collecting logs locally, and a Universal Forwarder on the same box was sending them again. Double licence usage, double noise. The valuable part was not the diagnosis: it read the two product GUIDs out of the MSI registry entries and explicitly warned me which one to remove and which one never to touch, because that second one was Splunk itself with all my data in it. A careless msiexec /x there and the lab is gone. It marked that one as excluded.

Also worth knowing: the straightforward msiexec /x ... /qn returned a phantom -1, because msiexec is asynchronous and PowerShell does not capture its exit code reliably. Start-Process msiexec -Wait -PassThru returned a clean ExitCode: 0 and removed service, directory and registry entry.

Three data inputs dead since install day. Zero events since July, three different root causes:

Two Windows event channels were disabled, so there was no log file to read at all. Fixed by enabling the channel.
The third was a double bug: a required parameter was missing, and the performance counters were configured in English on a Spanish Windows install. In Spanish, the counter is not % Processor Time but % de tiempo de procesador. Even the object name is localised. The fix was to force the tool to use the English API.

And a detail I appreciate more than the fix itself: the config change was correct, but the binary still died when sampling. It documented that as "needs binary debugging" instead of claiming success.

Sysmon was blind to credential theft. My config did not detect access to LSASS — the process that holds credentials in memory, and the thing Mimikatz goes after. An attacker could have dumped credentials and I would have learned about it later. Enabling ProcessAccess with a filter on lsass.exe is a three-line change, but along the way we discovered that both the model and I were carrying a wrong Sysmon event-ID mapping. The numbers I had been using were simply incorrect. The real config file disproved them. Verify technical numbers against reality; do not trust recall, including your own.

One command, three traps. To log process creation with the command line:

auditpol /set /subcategory:"{0CCE922B-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable

It failed for three reasons at once: the privilege was missing, the category name is localised (so the English string does not resolve), and the braces of the GUID break PowerShell syntax unless quoted. Elevation, localisation, syntax.

The best part: it caught its own false positives

Two earlier findings turned out to be false positives, and the model is what caught them, correcting previous audits (one of them a note of mine):

A log channel reported as disabled was actually enabled and recording hundreds of events. The original audit had looked at the wrong channel.
A detection rule flagged any process touching temporary files under the user profile as suspicious — which meant my code editor, my note-taking app and my own AI agent showed up as threats. It needed specific Electron exclusions.

An analyst that corrects its own assumptions with evidence beats one that gets lucky.

Making it deterministic

After watching it blow through the context window, I fixed the cause rather than the symptom: temperature down from 0.8 to 0.3, plus a working-rules system prompt (answer only what is asked; in remediation stop at root cause with evidence; in audit be exhaustive; use scripts for mechanical operations; verify IDs, ports and GUIDs before asserting; never invent; be concise).

	Before	After
Output	Huge, rambling	Short and direct
Context used	97.4% (overflowed)	49.7%
Assumptions	Taken for granted	Verified against reality
Result	1 finding in 30 min	4 findings in a row

Honest scoreboard

Out of ten findings: double ingestion resolved, two inputs fixed and one pending binary debugging, credential access now detected, process logging enabled, two false positives corrected, one of my own notes fixed. Not a perfect lab result — which is exactly why I trust the report.

What I take away:

A 27B local model is already competent at this work. The bottleneck is context, not intelligence.
Ask for exhaustiveness in auditing and forbid it in remediation.
Verify technical numbers against reality instead of remembering them.
Mechanical operations belong in a script: asked to insert two lines into a 123KB config, it spent 30 minutes regenerating the whole file by hand.
Determinism is a configuration choice, not a model property.

An LLM does not replace your judgement or the urge to understand what is happening. But as a mentor that never sleeps and never leaves your machine, for someone starting out like me, it is a genuine advantage — and not a single log leaves my computer.

The full technical breakdown of this audit — screenshots, exact commands and config files — is on my blog: A 27B SOC Analyst: Auditing and Remediating Splunk + Sysmon.

Related, if you are building the same kind of thing: Building Your Own Log Analyzer and Gravity SOC, my home security operations center.

I write up what I learn, mistakes included, at sammideblas.com.

AI adoption now measured by what you can audit

Sammi De Blas — Wed, 16 Sep 2026 10:28:24 +0000

The main case

On September 12, Cloudera and Mistral announced a sovereign enterprise AI alliance.

Open, customizable models on a hybrid data platform, with data, models, and compute inside customer-controlled environments (Source: technode.global).

The article frames it as a trend, not an isolated case. Once you leave the pilots behind, model choice gets evaluated alongside data location, governance, cost, and control.

Two days earlier, between September 9 and 11, NeuroWatt presented NeuroTeam.

It is an enterprise "agentic AI workforce" that packages agent reasoning, tool execution, identity and access, policies, human approvals, auditability, and monitoring into a single architecture. It includes multi-model routing with an internal LLM gateway and an on-prem option for sovereignty and latency (PRNewswire).

Both announcements share a pattern. The model is no longer what is being sold. What is being sold is the wrapper that makes it auditable.

And the numbers behind the shift are uncomfortable.

92% say governing agents is critical for security, but only 44% have implemented policies for it.

Only 18% of MCP server deployments apply any scope to tool permissions, and only 52% can trace and audit the data their agents access (Source: Linx Security analysis reported by NHI Mgmt Group).

An MCP server, for anyone who does not know what it is, is the component that exposes tools and data to an AI agent.

If you do not scope it, the agent can call any tool that server publishes, with no brake.

The framework that already exists says it more precisely. The Cloud Security Alliance's Agent Identity Governance Framework (in draft since March 27) argues that agents must be treated as first-class identity subjects, with just-in-time access, expiration, and a human sponsor.

Its most uncomfortable line is that a sub-agent that finishes its task and keeps active credentials is, in governance terms, "an abandoned account with permanent access", hence rotating credentials.

Gartner goes against comfort and says that applying the same governance to all agents will lead to failure. It proposes four levels of autonomy (observe, advise, act with approval, act autonomously) with different controls at each level.

It also warns that human approvals degenerate into approval fatigue and create a false sense of security. I disagree with this, because you have to know how to program the right framework. That is why "Human in The Loop" matters so much to me now and going forward.

The OWASP MCP Top 10 already names "shadow MCP servers", which are nothing less than those servers nobody has in "scope".

Palo Alto documents the "rug-pull" attack, in which an MCP server passes the initial review and then silently changes the definition of its tools.

Not an isolated case

Since August 2, the transparency obligations of Article 50 of the AI Act are enforceable, along with the AI Office's sanctioning powers over general-purpose model providers, with fines of up to 15 million euros or 3 percent of global turnover (Source: mondaq, iagovernance.com).

The Digital Omnibus, Regulation (EU) 2026/1744 in force since July 27, postponed the bulk of the high-risk regime of Annex III to December 2, 2027, and Annex I to August 2028.

It left transparency and the power to fine general-purpose models intact (Source: peopleofinternet.com).

One industry source puts the first fines issued within weeks at around 47 million euros (Source: aiineurope.co).

That figure should be treated as unconfirmed by an official source, but the activation of the sanctioning power is a documented fact.

The common pattern with the corporate announcements is the same. The AI that actually gets adopted in 2026 is the AI that comes with identity, scope, logging, and a brake.

Everything else remains a pilot or less than that. I see it every day working for a large consultancy at a major bank.

The other side

The week also leaves us with agents used as a weapon.

Details of the OpenAI agent assault on Hugging Face were expanded.

It appears that roughly 700 agents, coordinated through a forum they set up themselves (unauthorized and hidden), "made a mess of it", according to the METR and Redwood Research analysis (Source: time.com).

It is the other face of the same problem, because if an agent has identity, scope, and traces, etc., you can reconstruct what it did. But if it does not, it becomes the perfect vehicle to act at scale without anyone knowing what really happened.

My own read

I have the feeling that we are selling agent governance before we have inventoried the agents. I think there is a lot of operational ignorance. I think there is no common sense in how AI is applied in companies. It feels like a fad, even if it is not one.

To go to concrete data, the 18 percent scoping statistic for MCP servers is not a maturity data point. It is an exposure data point.

The most profitable control is not the later log. It is the refusal to execute because it was not planned, when at certain consultancies you pay for human time and not for objectives.

A human who aborts the operation when the context changes (model, permissions, cost) is worth more than any audit dashboard read three days later. I think we are moving fast without knowing what we have in our hands.

Autonomy should be reserved for what is reversible.

Reading, analysis, and drafts without friction.

Writing, sending, and deployment with explicit approval or traceable evidence behind every conclusion.

What to look at

Inventory before policy. List agents and MCP servers with their human sponsor and the tools each one exposes. It is an afternoon's work and it is exactly what the market packages as a product.
Scope per tool. Check how many of your MCP servers apply any scope to permissions. If the answer is none, you already know where to start.
Credentials with expiration. Check whether any sub-agent finished its task and still holds active credentials. In governance terms, that is an abandoned account with permanent access.

How I would test it in my lab

I would set up a minimal MCP server on a local machine, with two exposed tools, one read-only and one write.

I would give an agent a token with no expiration and no per-tool scope and ask it for a trivial read task.

Then I would look at the server logs to see which calls it recorded and which it did not.

The conclusion I would draw is how much of my real surface would remain invisible with that same configuration.

Then I would repeat the exercise with a watchdog that aborts execution if the configured model changes from the one that created the job.

Closing

AI adoption in 2026 is measured by what you can audit, not by what you can show in a demo.

If you do not know what agents you have or what tools they expose... governance is an intention, not a control.

Originally published at https://sammideblas.com/notas/ai-adoption-now-measured-by-what-you-can-audit

Patch window shrinks to hours: three critical flaws in five days

Sammi De Blas — Mon, 14 Sep 2026 09:16:00 +0000

Three flaws and one pattern

The week left three critical vulnerabilities with a common trait worth a slow look.

On September 11, Check Point published patches for two remote code execution flaws in its VPN appliances, CVE-2026-85102 and CVE-2026-85103 (Source: securityweek.com).

The first affects the Security Gateway and allows code execution without credentials.

The second also reaches the Management Server.

The Dutch NCSC warned of imminent exploitation, and LivePatch Take 24 covers R81.20, R82, and R82.10, while the rest of the versions require upgrading to R82.20 (Source: blog.sied.ar).

The operational recommendation that comes with the advisory is concrete, since ports 500, 4500, and 443 should be restricted to authorized peers only.

That same day... GitLab shipped patches for CVE-2026-85706, a path traversal in the commits API with a CVSS of 10.0. OMG!

The flaw allows reading files from the server without authentication. OMG!

Probes in production were detected hours after public disclosure, according to watchTowr (Sources: thehackernews.com, elhacker.net).

The fixed versions are 19.3.2, 19.2.6, and 19.1.8.

The third case is N-able N-central, CVE-2026-86218, a pre-auth RCE with a CVSS of 10.0.

Live exploitation entered CISA's KEV catalog with a remediation deadline of September 11, and Shadowserver counted close to 1,500 exposed consoles (Source: thehackernews.com).

The pattern

There is one scene that sums up why these three cases read together.

In the GitLab case, probes showed up in production hours after the patch went public. There was no grace window.

Someone was watching the advisory repository, or had a system watching it for them, and acted before most administrators had read the email.

That is what stands out!

Public disclosure no longer marks the start of a days-long deadline.

It marks the starting gun of a race that some run with automation.

The N-able case adds another layer.

CISA added the flaw to its catalog of exploited vulnerabilities with a one-day remediation deadline.

That deadline is not rhetorical, that is, it reflects that exploitation was already happening when the advisory was published.

The 1,500 exposed consoles Shadowserver counted are the surface where that clock runs.

Not an isolated case

The three cases share a pattern that the previous week had already shown more bluntly.

GreyNoise and SecurityWeek documented a campaign with hundreds of AI agents against PaperCut NG/MF servers, chaining CVE-2026-81578 and CVE-2026-82078 on a Codex harness with a DeepSeek model.

The result was around 440 organizations compromised across 48 countries, almost half of them in the education sector (Source: bleepingcomputer.com, greynoise.io).

One education center went from initial access to Domain Admin in seven minutes.

The connection is not that the flaws are the same, it is rather that the cost of finding, testing, and deploying an exploit has dropped.

A low-budget attacker can rent AI agents to scan, generate variants, and validate the exploit in their own lab before launching it.

What used to require a human team for days now runs in parallel and at scale.

That is why the patch window has shrunk, but not because the flaws are more severe, rather because on the other side there are more hands, faster and cheaper.

When the agent attacks

It is worth saying plainly, even if it stings. I have the feeling that we are losing control on defense ever since agents burst onto the scene.

In the PaperCut case... the AI agents were not the defensive tool, they were the attacker.

Hundreds of instances orchestrated to discover or test and deploy exploits against exposed servers.

The Codex harness with a DeepSeek model is the technical piece that makes it possible without more... an environment that runs tasks autonomously on a language model, but believe me, I have tried simple approaches in my lab with small local models that fit on any GPU, and you can hide behind several proxies, etc... better not to give ideas.

That changes the conversation about agents in the SOC.

It is not just that an analyst can use an agent for triage.

It is that the same kind of technology, with less supervision, is already used to attack.

The asymmetry is real. Unfortunately, the defender needs everything to work and the attacker only needs one unpatched server.

My own read

For anyone administering these systems, the message is uncomfortable but clear.

Patching in hours is no longer the minimum to stay off the victim list.

Segmentation and egress filtering remain the controls that make the difference when exposure time is measured in hours, not days.

And there is an inventory lesson, which is that the 1,500 exposed N-able consoles were not hidden, no... they were on the internet, reachable.

The same goes for the Check Point VPN appliances and the GitLab instances.

The exposed surface is the first problem and, therefore, patching is the second.

What to look at

Check exposed ports. If you manage Check Point appliances, restrict ports 500, 4500, and 443 to authorized peers. If you have N-able N-central consoles reachable from the internet, that is the first decision on Monday.
Check GitLab versions. The fixed versions are 19.3.2, 19.2.6, and 19.1.8. If your instance is below that and exposed, the path traversal allows reading files without authentication.
Enable probe telemetry. GitLab probes were detected hours after disclosure. A log of access attempts to commits API paths gives you the signal before the exploit works.

How I would test it in my lab

I would set up a GitLab instance on an isolated virtual machine, with no internet exposure, and send requests to the commits API with manipulated paths to see whether the server returns file content outside the expected directory.

Before that, I would capture traffic with tcpdump to have a record of which requests arrive and in what shape.

The conclusion would be that, if the vulnerable version responds with file content it should not, the flaw is real and the patch is urgent.

If it responds with an error, the version is already fixed.

It is an afternoon check that requires nothing more than a VM and a willingness to read HTTP responses.

Closing

The window between disclosure and exploitation has compressed to hours.

Anyone without a patching process that works in that timeframe is playing a different game.

The good news is that the controls that make the difference are still the same as always, less exposed surface, fast patches, and telemetry that warns before the exploit arrives.

Originally published at https://sammideblas.com/notas/patch-window-shrinks-to-hours-three-critical-flaws-in-five-days