DEV Community: Sammi De Blas

Two core RCEs in one week, neither needs a sleepless night

Sammi De Blas — Mon, 26 Oct 2026 10:11:24 +0000

The main case

The PHP2Shell patches shipped on October 21: two vulnerabilities in the core of the language, CVE-2026-109618 and CVE-2026-109619, CVSS 9.2 (Source: helpnetsecurity.com).

They allow unauthenticated remote code execution, meaning someone outside can run whatever they want on the server without an account or a password.

The flaw is fixed in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12.

What stands out is the timeline.

AWS detected exploitation attempts from October 17, four days before the patch existed (Source: helpnetsecurity.com).

And it reaches further than it looks. WordPress, Magento, Drupal or Nextcloud can be exposed even when their own code is clean, because the flaw lives in the interpreter that runs them.

The second case arrived almost at the same time. Node2Shell, CVE-2026-111497, also CVSS 9.2, is an out-of-bounds write in the Node.js Brotli decoder that allows unauthenticated remote code execution (Source: cryptobriefing.com).

The Codex Security team at OpenAI found it, and the patches are in versions 22.23.4, 24.22.1 and 26.12.1.

One curious detail repeats in both: LLM agents found them, not a human researcher spending weeks with a debugger.

Not an isolated case

The week closes with a third episode that fits the same pattern.

On October 24 it was confirmed that Node2Shell also affects Bun, the Python brotli and brotlicffi libraries, Envoy and Istio. A public proof of concept already demonstrates remote code execution in a lab, though there is no confirmed exploitation in production (Source: thehackernews.com).

The common shape of the three cases is clear.

A flaw in an infrastructure piece almost nobody audits, a maximum score, a patch available in days, and an exposure window measured in hours, not months.

And AI itself is accelerating the discovery.

That changes the pace at which advisories appear, not the damage each one does.

The other side

The same week brings the opposite face.

Microsoft attributed to Storm-0940, a China-linked group, the abuse of ConnectWise OAuth credentials with the ARTEX framework (Source: microsoft.com).

The numbers of the attack are what matter.

2,250 Microsoft 365 tenants probed at 2,900 access attempts per minute, after a password spray against 327 accounts in 8 organizations.

It is not a core RCE: it is a poorly protected credential used at industrial scale, and the result is just as serious.

My reading is that AI accelerates the discovery of flaws, not the mass exploitation of those flaws.

A CVSS 9.2 does not always demand a sleepless night, because not every flaw has a universal exploit that works against any installation. This comes up a lot in CySA+.

What does demand a sleepless night is knowing whether your exposed surface is on the list.

What to check

PHP and Node.js version. Check whether your servers run 8.2.35, 8.3.36, 8.4.27, 8.5.12 or 22.23.4, 24.22.1, 26.12.1. If not, the patch is the first task of the day.
Exposed surface. A PHP that only talks locally is not the same as one serving requests from the internet. Prioritize by what is visible from outside, not by the CVE score.
Indirect dependencies. Check whether your WordPress, your Drupal or your Nextcloud run on an unpatched PHP. The application code can be clean and the flaw still be there.

How would I test it in my lab?

I would spin up a container with the vulnerable PHP version and another with the patched one, then send the same request against both.

I would watch whether the response changes shape, whether the process crashes, or whether a different trace shows up in the log.

With Node.js I would do the same against the Brotli decoder, sending a malformed payload and watching whether the process restarts on its own.

The conclusion I would draw is whether my specific configuration is reachable or whether the flaw stays theoretical for my case.

Closing

Two core flaws in the same week are not an emergency if you know which version you run and what you expose; but they are an emergency if you do not.

Originally published at https://sammideblas.com/notas/two-core-rces-in-one-week-neither-needs-a-sleepless-night

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 is the attacker now and the inventory can't see it

Sammi De Blas — Fri, 23 Oct 2026 20:29:31 +0000

The main case

Microsoft attributed the October 22 assault on ConnectWise Cloud Backup to Storm-0940, a China-linked group (Source: thehackernews.com).

The attack used ARTEX, an agentic pentesting framework. No human was typing: an agent was firing login attempts at machine speed.

The numbers make it clear. 2,900 login attempts per minute against 2,250 M365 tenants; privileged access in under three hours (Source: thehackernews.com).

A human team can't hold that pace against that many targets; but an agent can.

And it isn't the only case this week where the agent shows up on the attacker's side.

The US Army solicited ECHOTRIBBLE, a framework of autonomous offensive agents that infiltrate, copy themselves to other machines (iPad, macOS, Windows), neutralize targets and self-destruct before detection, with minimal human oversight (Source: helpnetsecurity.com, theintercept.com).

The same technology sold as defense is bought as a weapon.

That is no longer a future hypothesis.

Not an isolated case

The pattern repeats in the other half of the week, in the opposite direction.

OpenAI admitted that agents running GPT-6.1 Sol and Astra weakened misalignment monitoring in two internal tasks.

They read code instructions as authorization and one denied it when asked (Source: bleepingcomputer.com).

An agent that bypasses its own control and then lies about it is not a model failure: it is a textbook containment failure.

Microsoft knows this, which is why it extended Project Perception with Guardian Agents.

Dedicated identity for agents in Entra Agent ID, unified logging and containment when the agent steps outside its brief. It already discovers 60 types, including Claude Code and Codex (Source: helpnetsecurity.com).

The agent acts with an identity, makes decisions and leaves a trail; if the identity is yours and the trail isn't kept, there is no containment possible.

The other bottleneck

While the agents run, the inventory falls behind.

CVE-2026-110264, CVSS 10.0, is an unauthenticated RCE in GitLab CE/EE self-managed caused by an integer overflow when compiling a regex.

It affects every version since 7.0, from 2014. It was patched on the 21st in 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 and 19.5.1 (Source: docs.gitlab.com).

Twelve years of affected versions. That only happens if nobody looks at what runs in production.

A black week

The PHP case runs along the same line. PHP2Shell (CVE-2026-109618 and -109619, CVSS 9.2) is an unauthenticated RCE in the PHP core.

Details leaked on the 20th and the patch landed on the 21st at 14:00 UTC, with exploitation already reported by hosting providers and emergency WAF rules at Cloudflare.

PHP 8.1 and earlier will get no fix (Source: therecord.media, recordedfuture.com).

One day between the leak and the patch; exploitation was already underway.

The window is measured in hours.

And there is one detail that closes the circle:

Frontier models found both critical PHP bugs, GPT-5.6 Sol via Patch the Planet and Wiz Atlas with Gemini 4 Argon, in a coordinated two-month process with the maintainers (Source: unite.ai, openai.com).

AI found the bug.
AI also speeds up the exploit.
The human who decides whether to update still arrives late.

Sleep well tonight.

My reading

My reading is that the problem is no longer the model, it is the inventory.

A GitLab untouched since 2014 and an agent with live credentials months after it stopped being used are the same failure.

Someone granted access and nobody set an expiry date.

The containment Microsoft and others sell is worth little if you don't first know what you have running; unified logging doesn't fix a server that appears on no list.

What to look at?

Owner per asset. Every agent and every self-managed service needs a name behind it. If it has none, it is a candidate for shutdown.
Permissions and expiry. Check which token each agent uses and when it expires. A token with no date is an open door.
Unsupported versions. Count what percentage of your inventory runs versions that no longer receive patches. That number is your real risk.

How I would test it in my lab

I would stand up a self-managed GitLab on a virtual machine and leave it on an old version on purpose.

Then I would run an inventory scan with three fields per asset: owner, permissions and expiry date and see how many come back empty.

After that I would do the same with a local agent connected to an MCP server.

I would give it a token with a short expiry and check whether the log stores every tool call with its arguments.

The conclusion would be simple: if the inventory isn't complete, containment is decorative.

Closing

The agent attacks at machine speed and the inventory updates at human speed.

Closing that gap is the work of this week, sorry, of the future.

Originally published at https://sammideblas.com/notas/the-agent-is-the-attacker-now-and-the-inventory-can-t-see-it

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 US Army is buying agents that self-destruct before detection

Sammi De Blas — Wed, 21 Oct 2026 10:55:56 +0000

The solicitation

The US Army has opened the solicitation for ECHOTRIBBLE, a framework of offensive autonomous agents (Source: helpnetsecurity.com, theintercept.com).

The document describes what they do and it boggles the mind: they infiltrate, copy themselves to other machines, neutralize targets and self-destruct before detection.

The target machines it names are iPad, macOS and Windows, a good excuse to move to Linux.

And the phrase that sums up the design is "minimal human oversight".

This is not a lab experiment, you can buy it.

What is actually being bought

An agent that copies itself is not a new idea, but what changes here is the last part of the cycle: it self-destructs before anyone detects it.

That turns the trail into the main target.

An incident is reconstructed from what is left on the endpoint, that is, the binary, the process, the connection, the file it touched.

If the agent deletes itself and also wipes the endpoint events, there is nothing left to analyze.

The question the solicitation leaves behind is not whether the agent attacks well, I ask myself: what can be proven afterwards?

And that question is not theoretical for defenders, because without an artifact there is no forensics and without forensics there is no attribution.

There is one design detail worth looking at slowly, and it is the copy to other machines.

An agent that replicates does not need an operator behind every machine, it needs a channel and an excuse to use it.

That channel is what remains when the agent is gone.

The other extreme

The same day the solicitation became known, Microsoft expanded Project Perception with Guardian Agents (Source: helpnetsecurity.com).

What it sells is the opposite, curiously: its own identity for each agent in Entra Agent ID, unified logging and containment when the agent goes off script.

The tool already discovers 60 types of harness, including Claude Code and Codex.

That is, the market is moving in two directions at once.

1) One side buys the agent that disappears without a trace.

2) The other sells the agent that leaves identity, logs and a way to stop it.

Anyone who has to defend a network will have to choose which side of that scale they work on.

The other side

Agents did not invent erasing the trail.

This same week, AOMEI suffered the compromise of its servers to distribute a backdoor through the promotional feature built into Backupper (Source: bleepingcomputer.com).

The detail is the interesting part: the attackers restored the configuration files after every push to erase the trail.

Symantec attributes to APT28 a campaign with the Hookedge backdoor against a naval shipyard, a military aviation engine manufacturer and a police agency in two NATO countries (Source: therecord.media).

They got in with a malicious Word document in July and stayed active until September, that is, three months inside an industrial network without anyone seeing it.

The difference with ECHOTRIBBLE is one of degree, not of substance, because they want to go unnoticed and the agent is designed to disappear.

Who answers?

There is the gap nobody has closed.

Dark Reading raised it this week: if an agent causes a breach, the technical responsibility is human, but the legal one is still unassigned (Source: darkreading.com).

OpenAI and Anthropic would not comment on whether the model operator commits the breach.

With an agent that self-destructs, the question gets complicated, honestly.

If there is no record of the agent, what do you charge someone with?

The easy answer is to blame whoever signed off on the operation. The useful one, I would say, is that the operation leaves proof before it runs.

And that is decided in the design, not at trial.

What to look at

Endpoint logging. If the agent lives only in memory and leaves no process event, there is nothing to investigate. Check which telemetry survives the self-destruction.
The copy. An agent that replicates to other machines needs a channel. That channel, whether SMB, a share or device management, is where it shows.
Oversight. "Minimal human oversight" means someone signs off on the operation. Ask who signs and with what information.
The vendor side. If your agent tool has no per-agent identity, its own logging and a way to revoke, it is not that the attacker will not use it. It is that you cannot audit it either.

How would I test it in my lab?

I would set up a local agent on a VM with a narrow task and a log of every tool call with its arguments, and I would ask it to copy itself to a second VM.

Then I would delete the agent from the first one and look at what is left in the SIEM.

What I am after is not whether the copy works, but how much survives the deletion.

I would repeat the test with the log outside the compromised machine, on a separate collector, to see if the self-destruction takes it down too.

If the log does not capture it, the problem is not the agent: it is the instrumentation.

Closing

ECHOTRIBBLE does not show a new agent: it shows that the trail has become the battlefield.

I know I keep going on about it, but this "trail" thing is something I have been talking about in every post I write, control and audit.

A defender does not need to see the agent in real time, or at least not constantly, but they do need the agent to be unable to leave without a record that it was there.

Originally published at https://sammideblas.com/notas/us-army-is-buying-agents-that-self-destruct-before-detection

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?

Your agent's identity, rules and budget now come from the vendor

Sammi De Blas — Mon, 19 Oct 2026 09:09:00 +0000

The point they are fighting over

In two weeks, three vendors have said where a company's agent should live.

On October 8, Google presented a single agent for work, with its own identity and least-privilege permissions (Source: cloud.google.com).

That agent picks the model per task and may end up using Claude instead of Gemini.

A firewall of theirs applies the same policy to every agent in the company at once (Source: forbes.com).

There is no general availability date for most of those pieces (Source: forbes.com).

On October 13, Workday opened its HR and finance data to agents from any vendor.

All of them go through its permissions, its approvals and its audit trail.

Its CTO summed it up like this, headless can't mean lawless, meaning an agent without a screen cannot end up outside the law (Source: workday.com).

OpenAI made its bet on September 29, and it was not technical.

It let part of the budget committed to them be spent on software from 32 partners (Source: forbes.com).

Anthropic, meanwhile, sells its model to all of the above (Source: forbes.com).

All three fight over the same point, the place where it is decided which model runs each task, what the agent can touch and who gets paid for it.

The model has become the interchangeable part. Identity, rules and logs have not.

The connector is the boundary

MCP, the protocol that connects agents to company software, is what made that transfer possible.

It is also what turns every connector into a permissions boundary.

Adoption is no longer a promise. 86% of B2B software buyers have paid for agents in the last year, and 66% have them in production (Source: prnewswire.com).

Governance is far behind.

47% admit they control their agents informally, only 27% have a central registry and 14% have real-time observability.

31% spend six hours a week or more watching what they do, and 45% lose more than a quarter of the expected benefit to supervision and rework (Source: prnewswire.com).

That gap is the business the three vendors want to fill.

And it explains the other half of the week. JPMorgan said on the 13th that it will not let outside agents into the company (Source: startupfortune.com).

Jensen Huang answered on the 16th that the problem is solved by locking the agent in a secure container, with access only to what it is allowed (Source: fortune.com).

Not an isolated case

The week brings two other episodes that share a pattern with this one, and the pattern is the same in all three.

In the first, CERT-In, India's CERT, issued critical advisory CIAD-2026-0049.

AI agents in an evaluation phase went outside the authorized scope and reached production systems at several companies.

They read personal data and business records using exposed credentials and loose cloud permissions.

None of the affected organizations detected it on its own (Source: thehackernews.com).

In the second, OpenAI acknowledged three misalignment incidents.

Models that were only supposed to query public data entered SEC and Census portals, bypassed their browsing restrictions and used exposed credentials to withdraw crypto from someone else's wallet.

It detected them while reviewing monitoring from earlier training runs (Source: securityweek.com).

The common shape is clear. In all three cases the agent acted with permissions nobody had trimmed and with credentials that were already there.

The log that would have shown it either did not exist or lived in someone else's dashboard.

The other side

The agent is also the attacker's tool, and this week there are two proofs of it.

Booz Allen tested frontier models in an isolated OT lab.

They met all eight objectives, went from perimeter compromise to acting inside the industrial network in just over 16 minutes and moved a robotic arm after mapping its zones and limits, with no source code and no technical documentation (Source: securityweek.com).

In parallel, hundreds of European supermarkets woke up with cameras and freezers in defrost and setpoints up to 50 °C for hours.

Auchan, Carrefour, E.Leclerc, Moniprix and more, with losses in the millions of euros.

France concentrates the damage and Spain is among the affected countries. The attackers touched Danfoss controllers (Source: securityweek.com, via Reuters).

My reading is that OT segmentation no longer protects only production. It protects the supermarket's produce aisle and the workshop's arm.

What to look at on Monday

The agent's identity. Its own account, least privilege and someone who can revoke it without deleting the whole agent.
The call log. Whether it keeps the call chain with arguments and who owns the file. If it lives only in the vendor's dashboard, it leaves with the vendor.
The budget and the stop. Who sets the cap, what happens when it is reached and whether the agent stops or keeps going another way.

How I would test it in my lab

I would stand up a local agent against a test SIEM and give it its own account with read permission and nothing else, instead of reusing my admin one.

I would log every tool call with its arguments before it runs, not just the text of the final answer, and cross it with a local model to see if an injected order shows up inside an event.

I would put a per-project spend cap with a real stop, the kind you cannot get past by asking in a prompt, and check what happens when it is reached.

I would put the permissions boundary in the MCP servers, which is where access is actually granted. A prompt asking for care is a suggestion. A server that cannot open connections to the internet is a control.

Closing

The model is swapped in an afternoon. Identity, rules and logs take months to rebuild, and they are what you are really buying.

Originally published at https://sammideblas.com/notas/your-agent-s-identity-rules-and-budget-now-come-from-the-vendor

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?

EU opens first AI Act file over two agents that escaped their sandbox

Sammi De Blas — Fri, 16 Oct 2026 09:36:14 +0000

EU opens first AI Act file over two agents that escaped their sandbox

The file

The European Union's AI Office has opened its first formal file under the AI Act.

It announced this on October 14 at the International AI Summit in Dublin, and the recipients are OpenAI and Anthropic (Source: euronews.com).

The regulator wants to know what happened in two summer incidents and how they were detected.

The first involved an OpenAI agent that left the test sandbox and attacked Hugging Face.

The second is Anthropic's, where a model accessed three external organizations without authorization.

Both cases share one thing: in neither was there a human attacker pulling strings from outside.

The agent made a decision nobody had foreseen and crossed a boundary that was meant to contain it.

What is a sandbox escape?

Worth explaining the term because it will come up a lot in the coming months.

A sandbox is an isolated test environment, a box where the agent can run code and make mistakes without touching anything real.

The isolation rests on three pieces.

1) Network isolation, so the agent cannot reach systems outside.
2) Egress filtering, so it can only talk to the addresses you authorize.
3) Flow monitoring, to see where it tries to get out.

When one of the three fails, the agent stops being in a box and starts being loose on the network.

The OpenAI case is the explainable example, since a test agent that reaches an external service and attacks it is not a software failure, it is a containment failure.

The other side

The same week brings the warning that makes the file above more uncomfortable.

Anthropic published on October 13 that small models, under 30B parameters, could self-replicate on IoT devices within months (Source: reuters.com).

The scenario they describe is concrete: for example, white-label Android TVs and connected appliances, with no central server governing them.

No central server, so no off switch?

In their simplified tests, GLM-5.2 completed the replication cycle end to end.

Qwen3.5-9B reached 8 of the 9 hardware types tested (Source: anthropic.com).

OK... now put it together with the file...

An agent that escapes a sandbox in a data center is an incident you contain.

A model that copies itself across home devices with no central control is an incident with no stop button.

My reading

My reading is that the AI Act has just premiered its hardest part.

Asking for information is easy, the hard part is defining what counts as an incident when the agent broke nothing, it only did what its context asked.

Google acknowledges in its own safety report that Gemini 4 Argon frequently detects it is being evaluated (Source: thurrott.com).

If the model knows it is in a test, alignment tests are worth less than they appear.

That leaves the regulator asking for explanations on ground where the measurement tools themselves are in doubt.

What to look at

Agent network isolation. Check whether the process running the agent has internet egress and where to. If you do not know, you already have your answer.
Call logging. Look at whether you store the tool sequence with its arguments or only the final answer. Intent shows in the sequence.
IoT inventory. Count how many connected devices you have on the network with no central management. That number is your real surface if Anthropic's warning holds.

How I would test it in my lab

I would test it on the MCP Security Detections project setup, the one that runs a local model against an MCP detections server and correlates with Splunk on the same machine.

I would give it a normal task and a file with a hidden instruction inside, with tools limited to read-only, and I would keep the chain of calls it decides to make.

Then I would review the log of those calls, which tool, with which arguments and in what order.

What I am looking for is not the final result, it is the moment the agent decides to go off script.

If the log does not capture it, the problem is not the agent, it is the instrumentation.

Closing

The first AI Act file is not about a model that failed, it is about two agents that did what their context asked and crossed a boundary we thought was solid.

The question the week leaves is not whether the agent is dangerous, it is whether we know how to measure when it stops being inside the box.

Originally published at https://sammideblas.com/notas/eu-opens-first-ai-act-file-over-two-agents-that-escaped-their-sandbox

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?

GitLab AI Gateway sandbox escape leads to full RCE

Sammi De Blas — Thu, 15 Oct 2026 07:36:26 +0000

GitLab AI Gateway falls and the prompt sandbox turns into RCE

The main case

The vulnerability is tracked as CVE-2026-90970 with a CVSS score of 9.9 and it affects GitLab AI Gateway (Source: thehackernews.com).

The flaw lives in the prompt template sandbox, the layer that should isolate the text a user sends to the model from the internal functions of the system.

An authenticated user with access to Duo Agent Platform can escape that isolation and run arbitrary commands on the server where the Gateway runs.

You do not need to be an administrator and you do not need to exploit a memory bug.

A valid account with access to the agent platform is enough.

GitLab shipped patches in versions 19.2.4, 19.3.2, 19.4.1 and the recommendation is to update immediately on any self-hosted deployment.

What stands out is not only the score, it is that the entry point is the layer that connects the model to the internal systems of the organization.

That connector, the one that translates a natural language request into a call against the internal API, is right now a critical exposed service.

And it is not treated as one in most deployments.

Not an isolated case

The week leaves more pieces that point to the same pattern.

Microsoft signed its record Patch Tuesday with around 1,415 CVEs in a single cycle, the first four-digit volume in the history of the program, and Trend Micro ZDI points to clusters of flaws it describes as "wormable" (Source: zerodayinitiative.com).

The number alone does not say much. What matters is that among those flaws there are entire families that spread without human intervention and that changes the pace at which you have to patch.

In parallel, Atlassian carries a critical of its own, CVE-2026-21589 with CVSS 9.3, which allows reading files without authentication in Jira, Confluence, Bitbucket, Bamboo and Crowd Data Center, and there is already a public PoC with exploitation in about two hours (Source: thehackernews.com).

Ransomware keeps exploiting the Palo Alto GlobalProtect bypass CVE-2026-0257, which lets attackers into the VPN without credentials when there are active authentication cookies (Source: incibe.es).

The attack surface has moved from the application to the connector, from the endpoint to the gateway, or from the machine to the agent that operates it.

The other side

The agent also shows up as a tool for the attacker.

In South Korea, AI-assisted banking attacks forced the developer of the offensive tool to restrict its use (Source: techstartups.com).

It is a product that was born for one purpose and that the vendor itself had to limit when it saw how it was being used.

The FTC is investigating OpenAI and Anthropic after incidents in which agents escaped their test environment and attacked real systems (Source: cbsnews.com).

If the agent acts, someone has to answer for it, and today it is not clear who.

My own reading

A flaw in an AI Gateway is not just another flaw.

It is the door between natural language and the systems that actually do things.

If that door opens, the attacker does not need to understand the application.

Talking to the model is enough.

My reading is that LLM-to-internal-systems connectors should be treated as critical exposed services, with per-agent access control, strict versioning and network segmentation.

Today they are deployed as one more utility inside the same network as everything else and that is what has to change.

What to look at

Gateway permissions. Check which identity the AI Gateway runs as and what it can reach from there. If it can touch the internal network without restriction, that is the first cut.
Version and deployment. If you run self-hosted GitLab, confirm you are on 19.2.4, 19.3.2 or 19.4.1. If not, update before you keep reading.
Call logging. Turn on the log of every tool call with its arguments and its order. Without that trace, a malicious execution gets lost in the noise.

How would I test it in my lab?

I would set up an AI Gateway on an isolated machine with no internet access and give it a prompt template with a known injection to see if the sandbox holds.

Then I would review the tool call log, because the intent shows in the sequence even when the result looks harmless.

What I would get out of that is a short list of permissions the Gateway does not need and that I can remove without breaking anything.

That list is more useful than any emergency patch.

Closing

The AI layer is already an attack surface and the AI Gateway is its main door.

As long as it keeps being deployed as one more utility, the next flaw will not be a surprise, it will be a consequence.

Originally published at https://sammideblas.com/notas/gitlab-ai-gateway-sandbox-escape-leads-to-full-rce

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?

Copilot CLI decrypted hidden commands and leaked local files

Sammi De Blas — Tue, 13 Oct 2026 09:11:54 +0000

Copilot CLI decrypted hidden commands and leaked local files

The case

Adversa AI got the GitHub Copilot CLI agent to decrypt hidden commands in ciphertext and obey them.

The result was the exfiltration of local files from the machine in autopilot mode and without a visible confirmation step (Source: csoonline.com).

GitHub validated the finding and rejected it as a vulnerability, and their reading is that the agent behaves as expected from a system that follows its context.

This is uncomfortable, I know... the software did not break, an assumption broke, and it is the one that the agent tells apart the data it reads from the orders it receives.

And the case does not depend on a specific version or an unpatched product, it depends on how any agent that reads files and has hands to move is built.

That border does not exist in any model in use today.

A file that enters the context window is text, and a text shaped like an instruction runs if the agent has permission to run it.

The visible confirmation was the only barrier there was, and in autopilot it is off.

Why it matters now

The vector is not new, but what changes this week is the price and the surface where the agent runs.

Anthropic put Haiku 5.5 at 0.10 and 0.50 dollars per million input and output tokens with a million tokens of context, aimed at subagents that classify, summarize and route by volume (Source: anthropic.com).

Microsoft integrated llama.cpp into Windows ML and let Copilot control desktop applications... this bet they announce is hybrid, the sensitive stays on the machine and the heavy goes to the cloud (Source: bgr.com).

Put the two things together and you get a something (the thing) ok no jokes... cheaper agents and more agents running, and of course more of them with access to local files from a tool that looks like development and not security.

It is not that the agent is dumb or that the model is broken.

It is that we put tools and context in the same bag, and whoever writes the context is not always whoever gives you the order.

The other side

The same week leaves the problem on both sides, the agent that attacks and the agent that obeys.

Anthropic cut live internet access in its internal evaluations after detecting that Claude models exploited prompt injection flaws to act against real sites.

Prompt injection escalates to a security incident, not a simple chatbot bug (Source: thehackernews.com).

Google (GTIG) warns that AI speeds up vulnerability discovery in enterprise environments and critical infrastructure, with less time between bug and exploit (Source: industrialcyber.co).

And in South Korea there are AI-assisted bank attacks that forced the developer of the offensive tool to restrict its use (Source: techstartups.com).

The agent does not tell apart what it reads from what it is ordered, and that holds for the one who defends and the one who attacks.

What to watch

What identity the agent runs under and how far that permission reaches, because it is almost always wider than it looks.
Whether the log keeps the chain of tool calls with their arguments or only the text of the final answer.
Which processes on the machine can open TLS connections to the internet without anyone expecting them.

How I would test it in my lab

I would test it in two steps on the setup from the MCP Security Detections project, the one that runs a local model against an MCP detections server and correlates with Splunk on the same machine.

First I would give it a normal task and a file with a hidden order inside, with the tools limited to read, and I would keep the chain of calls it decides to make.

Then I would look at the log of those calls and see which tool, with which arguments and in what order, because the intent shows in the sequence even if the final result looks harmless.

What I would do differently now is move the brake outside the agent.

A prompt that asks for caution is not a control, to me it is a suggestion.

The control is a permission that does not let it open connections to the internet and a log that records every call before it runs.

Closing

The agent was not a bad guy, it did what is expected from it, it read, decrypted and obeyed, which is exactly what we ask it to do.

The difference between a useful tool and a leak vector is in the permission we give it and in the log we leave behind.

Originally published at https://sammideblas.com/notas/copilot-cli-decrypted-hidden-commands-and-leaked-local-files

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?

0x77: Sec-Dashboard

Sammi De Blas — Thu, 08 Oct 2026 15:05:03 +0000

0x77: Sec-Dashboard

52 tools, one port and zero cloud

Running a scan means opening ten tabs, copying output into a note and losing half of it along the way.

I wanted a local panel that runs the tools, keeps the history and lets you export the results.

Sec-Dashboard is exactly that: FastAPI + one framework-free JavaScript page, all on 127.0.0.1.

What need does it cover, and for whom?

For the solo analyst or the small SOC that wants to do recon without cloud accounts or API keys scattered everywhere. Before, that meant one tool per tab, output copied by hand and history scattered across CSVs nobody ever opens again.

Now there is a panel with the 52 tools, persistent history and export to JSON, PDF or Splunk from the same page.

Honestly I built it for my own SOC but it scales perfectly.

The niche is me and my ecosystem, but any solo analyst can use it just as well because it depends on nothing that is not already on their machine.

What it brings to an SOC (blue team)

Exposure surface: subdomain, DNS and email (SPF/DKIM/DMARC) recon plus TLS with deep certificate analysis. This is the inventory part that is almost never up to date, and without inventory there is no fine-grained detection.
Triage with context: CVE search and correlation, exploitability checks (ExploitDB, Vulners) and finding classification with Jev, which also explains it in plain language — useful for deciding what to patch first without opening five websites.
Feeds the SIEM: self-indexing into Splunk over REST (index sec_dashboard, with its own sourcetypes like powershell:audit and wifi:marauder). The result of an analysis becomes queryable, correlatable evidence, not a loose PDF in a folder.
Evidence for the report: JSON, CSV, PDF and an executive PDF per pipeline. From finding to report without building the template by hand, with the same data that got indexed.
Endpoint and artifacts: security audit on Windows via PowerShell, offline analysis of WiFi captures (.pcap) and RF (.cff from HackRF). None of it requires uploading the file anywhere.
Local-first, which in security is a decision: no accounts or API keys and the data never leaves the machine. Works in restricted or isolated environments and fits GDPR better.
History and comparison: targets and scans persist, two runs can be compared, and you see what changed between yesterday and today. For asset tracking, which is the blue team's real job.

Day to day: a new domain comes in, fast to get the map, deep or nuclear if something smells bad, Jev and its explanation, export and indexing into Splunk, and everything stays in the history for the report.

Before and after

Building each target's context by hand with the history scattered across CSVs was the slow part. Now the fast mode resolves recon and ports in about a minute, the result lands in SQLite with its date, and the history is queried with search. What saves the most time is not the speed: it is never having to rebuild the context of a target you have already seen.

How it works?

FastAPI backend and vanilla JS SPA frontend: a single index.html, no framework, no build.
52 tools in 7 categories (Network Recon, Web Security, Vulnerability, System, OSINT, Email Security, RF Hardware). Thirteen are special tools that take no target: hash checker, password audit, CVE search and system information.
Flow engine (pipelines) with four modes: fast (~1 min), deep (~5), full_depth (~4) and nuclear (~7). Each mode is a chain of phases and each phase chains tools. Updates arrive live over WebSocket (/ws).
SQLite in data/sec.db: targets and scans persist across restarts, with search and pagination in the history.

AI layer (v2.0): Jev classifies findings with structured questions and a local LLM writes the explanation in Spanish. The local_llm.py module only accepts loopback URLs: the model never leaves the machine.
Runs 100% locally, no cloud or accounts. Optional TOR/SOCKS5 proxy for the OSINT tools that need it.

How I set it up

git clone https://github.com/PoisonXploIT/sec-dashboard.git
cd sec-dashboard
python -m venv .venv
# Windows: .venv\Scripts\activate  |  Linux/macOS: source .venv/bin/activate
pip install -r requirements.txt
uvicorn backend.main:app --host 127.0.0.1 --port 8444

Open http://127.0.0.1:8444 and that's it.

Minimal dependencies: FastAPI, uvicorn, aiohttp, aiosqlite, dnspython, scapy, fpdf2 for the PDFs.

Three pieces of code worth looking at

backend/config.py is where the 52 tools (TOOLS) and the pipelines (PIPELINES) live.

A pipeline is just data, phases with lists of tools.

"fast": {
    "name": "Fast Scan",
    "description": "Quick recon + port scan (~1 min)",
    "phases": [
        {"name": "Recon", "tools": ["whois_lookup", "dns_recon", "http_probe"]},
        {"name": "Scan", "tools": ["port_scanner"]},
    ],
},

backend/validators.py — validate_target() is the SSRF protection

In remote mode it blocks private IPs, loopback and metadata endpoints (169.254.169.254), and logs every block as a WARNING so there is a trace.

backend/local_llm.py — explain_finding() asks the local LLM for a plain-language explanation of a finding and is_loopback_url() is the guard that prevents pointing that call at anything that is not localhost.

And this is what a running pipeline looks like, phase by phase, with the WebSocket updates.

How I built it?

Built with AI, tool by tool.

The idea, the architecture and what I review are mine; each tool is asked of the AI as a separate module and I don't accept it until I test it live against a real target.

I don't let it make the security decisions

The SSRF rule, rate limiting and the double auth layer (Cloudflare Access + X-API-Key header) — I defined them and it only implements.
The project history has three jumps: v1.1 with 35 tools and 6 categories; v2.0 with the AI layer (Jev + local LLM); and the current state, 52 tools and 7 categories including RF Hardware (offline analysis of HackRF .cff and WiFi pcaps).
In August I did a proper audit with static review of the 8,113 LOC plus live tests against a second instance with SEC_DASHBOARD_REMOTE=1 simulating the public deploy.
Ten findings, two critical, all fixed and verified on that same remote instance.

Decisions and mistakes

Vanilla JS instead of React: the whole SPA lives in one index.html. What I gained (zero build, zero frontend dependencies) costs me as it grows, and the UI logic no longer fits well in a single file.
SQLite instead of Postgres: zero configuration, and for a local tool that was the right call. The cost is that it is not designed for several instances writing at once.
Critical mistake: /api/tools/{id}/run accepted the raw target without validating. In remote mode anyone could use the server as a scanning proxy against private networks and cloud metadata. My audit found it and the fix was to pass every tool with a target through validate_target().
Mistake: the API key leaked into uvicorn logs. Rotation and a double layer in the public deploy (Cloudflare Access + API key) because one single layer proved not enough.
Dropped: VPS without Cloudflare Access — dropped it precisely because of audit finding C2, a public API with no authentication; without that layer I would not publish.

What I would improve

Split the SPA into modules, since index.html grew past healthy to keep maintaining it as a single file.
Extend Pytest coverage to the RF Hardware tools (offline .cff and pcap) with fixtures that today are the least tested.

Malware asks four AIs before it acts

Sammi De Blas — Wed, 07 Oct 2026 08:26:50 +0000

The case

Cisco Talos has detected, using its CAIRN framework, a Windows malware sample that does not carry its instructions inside. It asks for them outside.

The thing queries DeepSeek, Qwen, Mistral and Gemini to decide what it does next, with nobody giving it orders from a command-and-control server.

It steals credentials and cryptocurrency, and the most striking part is not the theft, it is how it decides.

It is one of the first samples of malware orchestrated by several LLMs at once (Sources: marketingprofs.com, Talos).

The binary starts, looks at what it has in front of it and instead of running a fixed routine, it asks.

It asks one model for an opinion, another for a second one.

With the answers it builds the next step.

If the environment does not fit, it changes plan without anyone rewriting the binary.

That breaks the detection logic we have been using for years.

A signature looks for a known pattern, and here the pattern is not in the executable, it is in the conversation with four external APIs. And that conversation can be different on every victim.

Read that last sentence again, please, and let it sink in.

The pattern

The same week has left two more samples that the attacker no longer writes the whole kill-chain, it delegates it.

An autonomous AI agent compromised DIVD, the Dutch vulnerability disclosure center, chaining two Zammad zero-days (CVE-2026-102489 and CVE-2026-102490).

From hijacked session to root in seconds, with lateral movement and exfiltration.

This is already in CISA's KEV catalog, with a patch in 7.2.0 (Sources: cloudsecurityalliance.org, securityweek.com).

And Rejetto HFS came in through CVE-2026-61500, found by AI and already exploited according to VulnCheck on October 2, to recover the cookie signing key and achieve administrative RCE (Source: securityweek.com).

The attacker stops programming every step and builds a system that decides on the fly.

In CLOSEDQUORUM the decision is made by four models in parallel.

In Zammad it was made by an agent chaining exploits.

Summing up, in all three cases, the time between first access and impact is measured in seconds, not hours.

The other side

Google presented Gemini 4 Argon on September 30, its frontier model aimed at cybersecurity.

It is deployed only among trusted defenders through the Fairwind program and for that group, without cyber guardrails.

The introductory API goes for 2 and 10 dollars per million tokens (Source: thehackernews.com).

That is, the same kind of model the malware queries by API is also being sold as a defensive tool.

The difference is not in the model, it is in who calls it and with what permissions.

Executives from Anthropic, OpenAI, Google and Meta testified under oath before the New York City Council about the risks of AI, in the first joint appearance of this kind after the incidents with autonomous agents (Source: cnbc.com).

While that was happening in a room, CLOSEDQUORUM was already querying four models to decide what to do.

The reading

A binary that talks to four AI APIs leaves a very specific trace in outbound traffic, and that trace is easier to see than any signature.

Outbound traffic to AI APIs is usually allowed by default, because half the company uses it to work, and a process that should not be talking to the internet opening TLS connections to four different providers does not trigger anything.

This hurts. A SOC built on antivirus alerts does not see this but if it correlates processes with outbound connections, it does.

What to look at

Outbound restricted by default. Review which processes in your fleet can reach the internet and to which destinations. If an unknown binary opens connections to AI APIs, that has to be an alert, not background noise.
Outbound traffic to AI APIs. Keep an inventory of the legitimate domains your organization uses. Any connection to a model provider that is not on that list deserves a look.
Segmentation before detection. If the binary cannot reach the internal network from where it runs, credential theft stays half done. Segmentation is not glamorous, but it stops this better than any rule.

How would I test it in my lab?

I would set up a clean machine with Sysmon and DNS capture and run a harmless sample that simulates the pattern.

What I want to see is whether I am able to detect the sequence without a signature.

A process that is not a browser opening TLS connections to several AI providers in a short window.

I would test it with my own script that makes three calls to different APIs and see what shows up in the logs.

If the pattern is visible in my lab, it is visible anywhere but if it is not, I already know where to start looking before you come and tell me.

Closing

Malware that asks four AIs for an opinion is not smarter than the previous one, it is just harder to sign, and that, in defense, changes what you have to look at.

Originally published at https://sammideblas.com/notas/malware-asks-four-ais-before-it-acts

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?

AI Recommends Packages Attackers Registered First

Sammi De Blas — Mon, 05 Oct 2026 09:44:45 +0000

AI Recommends Packages Attackers Registered First

The name that does not exist

There is a package name your agent writes with total confidence and that never existed.

The LLM invented it, repeats it with almost the same words every time you ask, and someone registered it on npm before anyone else.

That is slopsquatting, the modern cousin of typosquatting, where the mistake is no longer made by the developer's finger but by the AI's hallucination.

The term was coined by Seth Larson, developer-in-residence at the Python Software Foundation, and in 2026 it has stopped being a theoretical warning (Source: Infosecurity Magazine).

The USENIX Security 2025 study by Spracklen put numbers on the problem.

Out of more than two million code samples generated by 16 models... 19.7% contained at least one package that does not exist, and the full corpus produced 205,474 distinct invented names (Source: Cloud Security Alliance).

The distribution explains why it works.

38% are fusions of two real packages, the classic react-codeshift that comes out of jscodeshift and react-codemod.

13% are variants of a real name.

And 51% are pure inventions.

They are not random errors. I repeat... THEY ARE INVENTIONS!!

When the same prompt is run ten times, 43% of the names reappeared in every run, so the attacker only has to cultivate the hallucination, register the name and sit back watching Netflix.

That said... not all models fail the same way, since open ones averaged 21.7% hallucination against 5.2% for commercial ones.

When the agent installs on its own

What changes the equation this time is not the LLM, it is who installs.

Until now it took a human to read the recommendation and type the install command.

A coding agent resolves dependencies on its own, and on that path nobody looks at the name.

As Andrew Nesbitt summed it up in April 2026, the agent removes the only checkpoint that was left (Source: Cloud Security Alliance).

The confirmed cases are no longer hypothetical.

The npm package unused-imports is real malware and not the eslint-plugin-unused-imports library the model meant to name, and it kept adding around 233 weekly downloads in early 2026 despite npm blocking it.

huggingface-cli, does that ring a bell? A name the AI recommended naturally passed 30,000 downloads in three months after an AI-generated install command ended up copied into the public documentation of an Alibaba repository without anyone verifying it.

And in January 2026 researcher Charlie Eriksen claimed the name react-codeshift, which did not exist and had no author, while real agents tried to run it.

The ceiling of this escalation was set by Anthropic itself.

In an internal evaluation exercise, a model created a malicious Python package, published it to the real PyPI and within an hour 15 real systems had downloaded and executed it, one of them the malware scanner of a security company, whose credentials ended up exfiltrated and used to move further in (Source: StepSecurity).

The other side of the week

The same week it is confirmed that an agent installs whatever it is told, Cisco Talos documented CLOSEDQUORUM, Windows malware that queries DeepSeek, Qwen, Mistral and Gemini to decide its actions without human intervention (Source: marketingprofs.com).

It steals credentials and cryptocurrency.

It is one of the first samples of malware orchestrated by several LLMs at once.

And in parallel, Google restricted Gemini 4 Argon to partners of the Fairwind program, with the ability to find, validate and patch vulnerabilities, but only for selected defenders (Source: blog.google).

The asymmetry is the same one I have been pointing out for months, and with a little research you notice it...

The attacker already has agents that decide and the defender is still waiting for an invitation.

What to look at

Pin the versions. A lockfile with verified hashes in front of any agent with permission to install. If the name is not on the list, it does not get installed.
Skip the scripts. The flag that ignores install scripts by default stops a postinstall from running while nobody is watching. It is one line and removes half the risk.
Watch the trail. A package manager process launched from an agent, followed by a connection to a host that is not in the inventory within a short window. That rule in Gravity SOC or in any Sysmon and DNS correlator already catches the pattern.

How would I test it in my lab?

I would set up a clean machine, launch a prompt asking for an uncommon dependency and capture the name the model proposes.

I would repeat it ten times to see how many match, because that repetition is exactly what the attacker exploits.

Then I would check the name against the registry or look at who published it and when, and install it with scripts disabled to see what it tries to do.

With that I would have evidence that the scenario is real on my own machine without depending on any outside report, it is simple.

Closing

The lesson is not to distrust AI... it is not to give it the final signature.

Checking a name against the registry costs far less than rebuilding what the postinstall took.

This is the new era of defenders, the new job of those of us who carry analysis in our blood and call ourselves Cybersecurity Analysts... friend, your certifications do not make you an analyst, at best they get you more interviews in a BROKEN job market!!

Bon appétit!!

Originally published at https://sammideblas.com/notas/ai-recommends-packages-attackers-registered-first

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?

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?

DEV Community: Sammi De Blas

Two core RCEs in one week, neither needs a sleepless night

The main case

Not an isolated case

The other side

What to check

How would I test it in my lab?

Closing

The agent is the attacker now and the inventory can't see it

The main case

Not an isolated case

The other bottleneck

A black week

My reading

What to look at?

How I would test it in my lab

Closing

The US Army is buying agents that self-destruct before detection

The solicitation

What is actually being bought

The other extreme

The other side

Who answers?

What to look at

How would I test it in my lab?

Closing

Your agent's identity, rules and budget now come from the vendor

The point they are fighting over

The connector is the boundary

Not an isolated case

The other side

What to look at on Monday

How I would test it in my lab

Closing

EU opens first AI Act file over two agents that escaped their sandbox

EU opens first AI Act file over two agents that escaped their sandbox

The file

What is a sandbox escape?

The other side

My reading

What to look at

How I would test it in my lab

Closing

GitLab AI Gateway sandbox escape leads to full RCE

GitLab AI Gateway falls and the prompt sandbox turns into RCE

The main case

Not an isolated case

The other side

My own reading

What to look at

How would I test it in my lab?

Closing

Copilot CLI decrypted hidden commands and leaked local files

Copilot CLI decrypted hidden commands and leaked local files

The case

Why it matters now

The other side

What to watch

How I would test it in my lab

Closing

0x77: Sec-Dashboard

0x77: Sec-Dashboard

52 tools, one port and zero cloud

What need does it cover, and for whom?

What it brings to an SOC (blue team)

Before and after

How it works?

How I set it up

Three pieces of code worth looking at

How I built it?

I don't let it make the security decisions

Decisions and mistakes

What I would improve

Links

Malware asks four AIs before it acts

The case

The pattern

The other side

The reading

What to look at