AI agents speed up attacks

Three charged over alleged 129 million dollar deepfake fraud impersonating executives and lawyers

US authorities have charged Jacob Soall, 41, Sharon Hazan, 54, and Guy Sheetrit, 42. According to the US Department of Justice, they used AI to imitate the voices and/or images of corporate executives at numerous firms and of attorneys at major law firms. The aim was to trick employees into sending large payments to bank accounts around the world controlled by members of the conspiracy. These are allegations and the three have not been convicted.

ITPro reports that the fraudsters usually opened by posing as the CEO and saying they needed help with a confidential financial transaction. They mostly targeted accounts department staff. The employee was then told to contact lawyers at large international law firms who were said to be working on the deal. Soall, a UK citizen, mainly played these lawyers and kept a handwritten script titled "Lawyer Call", designed to persuade victims not to discuss the contact with colleagues. One of the fake lawyers would then tell the employee to wire a large sum to an account under the group's control. Hazan and Sheetrit are accused of laundering funds from the scheme. The charges carry a maximum sentence of up to 20 years in federal prison.

The FBI said the trio allegedly stole more than 129 million dollars. Victims named include a UK-based financial technology company (about 11.5 million dollars), a pet food company in Florida (5.2 million dollars), a Missouri hospital system (nearly 5 million dollars), a Massachusetts mutual fund company (4.6 million dollars), a California hospital system (3 million dollars) and a Rhode Island bank (2.7 million dollars). ITPro also cites Gartner research in which four in ten CISOs reported deepfake voice social engineering attempts over the last year, and 36% reported video-based attempts.

Fix: Require out-of-band verification for high-value transfers, using a known number or an internal channel rather than the call or video that made the request. Train finance staff to treat requests for secrecy, including from apparent lawyers, as a warning sign.

Source: ITPro, 6 Nov

Binance says 6.34 billion dollar theft followed a months-long campaign that compromised three engineers' computers

Binance says the attackers behind the 6.34 billion dollar theft reached its wallet signing systems after a months-long campaign that compromised three wallet engineers' computers. In its initial incident report of 3 Nov, the exchange said it was not a single breach or a simple phishing incident. The FBI has blamed the theft on TraderTraitor, a North Korean state-sponsored hacking group. North Korea rejects this. Kim Yo Jong called it a grave political provocation that the US misleads opinion as if all cyber crimes were North Korea's deeds.

According to Binance, as reported by SecurityWeek, the campaign started in June, when a Wallet DevOps engineer downloaded a tampered Homebrew installation while looking for a popular AI coding tool through a search engine. Binance caught it and replaced his device, but the attackers had already learned who he worked with. In September a second engineer was invited to two interviews with a fake HR representative and the alleged CEO of a company that did not exist. He was then asked to download a coding assignment onto his work computer. It hid a malicious repository that ran on setup, swapped in a rogue copy of a legitimate developer tool component and opened a channel to the attackers' server. Binance says the malware, which it calls "0-day", was not detected by its endpoint security protection tools at the time.

On 20 Oct the attackers used the infected machine and an internal AI tool to take control of the first engineer's system and a third engineer's system. The report does not explain how the AI tool was used. On 29 Oct they signed into the third engineer's computer, deployed a container with credentials taken from the first engineer, whose computer held a token that allowed container deployments, and kicked off the attack with a malicious script. Binance says the attackers exploited unauthorized access to an internal wallet signing service to move XRP, SOL, OP and BTC out of hot wallets, and used the same service to abuse Ethereum's EIP-7702 mechanism. This gave an attacker-controlled contract partial execution rights over a hot wallet. Because the wallet used multi-party computation, Binance had no single key to cancel the delegation at once. Roughly 2.85 billion dollars of the stolen assets has been frozen or intercepted. Binance says it has rebuilt the wallet system and AI tool, replaced devices and retired the engineers' credentials and tokens.

Check: Review how developer machines are protected against unsolicited coding tests and tampered tool installs. Check what tokens on those machines can deploy, and what internal AI tools can reach.

Source: SecurityWeek, 4 Nov

Google: LLMjacking attacks rack up fraudulent cloud AI charges, with cumulative charges reaching 1 million dollars at some organisations

Google's Threat Intelligence Group and Mandiant report that attackers are generating large fraudulent cloud charges through LLMjacking, the hijacking of access to large language models. They say two distinct operational clusters are coordinating. One scans for publicly exposed LLM endpoints and the other steals valid API keys from unprotected machines. After gaining initial access, attackers sell it to services known as LLM mixers, which use proxy infrastructure to relay subscribers' prompts to hijacked services through stolen API keys.

The victim organisation pays. The provider records the requests as legitimate use and bills the victim for the tokens, and request volumes can exceed 1,000 per second. Google says it saw fraudulent charges exceeding 100,000 dollars in a single day, and cumulative fraudulent charges at some organisations reached 1 million dollars. One example is Jet Night, which sells unlimited access plans for 60 dollars a month. Google says another actor made more than 500,000 LLM API calls in under eight hours with stolen third-party API keys to power Jet Night, which passed nearly one million dollars in token costs to the victim organisation. Google also identified a cluster, UNC6993, that appears to use gateway tools to aggregate stolen keys and distribute requests, and likely sells access via underground forums.

Entry comes through exposed or compromised cloud credentials, service account keys, GitHub tokens, session tokens and LLM API keys. Attackers then search for credentials, logs, databases and secret managers, and try to add backdoor accounts or SSH keys. Google also saw exploitation of CVE-2026-40217, a LiteLLM flaw that allows arbitrary code to run on the server through the custom-code guardrail testing endpoint. In some cases attackers used victims' cloud infrastructure to host unauthorised proxy endpoints and agentic workloads.

Fix: Follow Google's advice: deny permissions that are not explicitly required, including access to cloud LLM services, and manage keys in a central secrets platform with rotation. Set API usage and spending limits, enable cloud audit and inference logs, and alert on unusual usage.

Source: BleepingComputer, 3 Nov

NCSC expects AI to speed up and scale existing attacks, and judges it highly likely that AI malware will be used in a ransomware attack on UK CNI

The UK National Cyber Security Centre has published its assessment of how AI affects the cyber threat, as part of its Annual Review 2026. It says it is almost certain that AI will act as a force multiplier, letting skilled threat actors carry out tasks at greater scale, speed and efficiency. The NCSC says the greatest impact will be the acceleration of existing tactics, techniques and procedures, not new attack vectors. It also judges it highly likely that AI will be integrated into attacks rather than autonomously conduct end-to-end attacks, and that human operators remain essential, because AI output must be directed, validated and adapted. Loss of control while running an agentic AI will highly likely hinder attackers.

On vulnerabilities, the NCSC says AI models have become capable of detecting vulnerabilities in large codebases and misconfigurations in systems that have historically remained undetected. Not every flaw found will be exploitable, but it judges it highly likely that defenders face a race to shorten patch timelines before threat actors are able to develop working exploits against the influx of vulnerabilities. It also says it is almost certain that a digital divide will widen between organisations that can adopt AI for defence and those that cannot. Mature programmes with resources and AI governance are likely to improve detection, vulnerability prioritisation and automation. Weaker organisations with legacy technology may struggle to keep pace and become more attractive targets.

The NCSC also names two further risks. It judges that China highly likely has the intent and is best positioned to use AI for operations against critical national infrastructure (CNI) and other strategic targets, and says China benefits from its own frontier AI capability programmes. It says shadow AI, where staff move sensitive data onto personal devices to use AI tools, almost certainly means organisations will lose visibility of how that data is handled and who can access it, and highly likely leaves them open to exploitation by advanced persistent threat groups and cyber criminals. Finally, it judges it highly likely that AI malware will be used in a ransomware attack on UK CNI, with open source AI tools built for security researchers likely to be repurposed by criminals to automate existing workflows.

Plan: Shorten your patch timelines, starting with internet-facing systems. Set a governed route for staff to use AI tools, and put controls in place to detect shadow AI.

Source: UK National Cyber Security Centre, 3 Nov

CrowdStrike adds AI Kill Switch to Falcon Guardian and plans to acquire Fiddler AI

At Fal.Con Europe in Barcelona on 3 Nov, CrowdStrike announced an AI Kill Switch in Falcon Guardian. CrowdStrike says it terminates unauthorised agents in real time, first at the Gateway. CrowdStrike says it works at the Gateway now, with the endpoint part coming soon, and that it also blocks terminated agents from running again across the organization. The AI Gateway is now generally available.

CrowdStrike also announced agent-level hooks and endpoint network inspection, which it says are unified with the endpoint on a single Falcon sensor. CrowdStrike says the aim is to cover what an agent is told to do, what it communicates over the network, and what it executes on the endpoint.

CrowdStrike also announced its intention to acquire Fiddler AI, which it describes as a leader in AI agent observability. It says the deal would increase AI safety through agent observability. The acquisition is planned, not completed, and the capability claims come from CrowdStrike's own announcement.

Take away: If you run AI agents, ask vendors how they stop unauthorised agent actions at runtime and which controls are generally available today. Treat the endpoint kill switch as a roadmap item until it ships.

Source: CrowdStrike, 3 Nov

Google Cloud adds agent credential, identity and network controls and new limits for CodeMender

Help Net Security reports that Google Cloud is extending security and governance controls across Gemini, Google Kubernetes Engine, Cloud Run and the new Agent Compute Engine. Auth Manager is now generally available. It centralises credential management in a Google-managed vault governed by IAM and refreshes user-delegated tokens. Agent Identity JWT support is in preview. It lets agents authenticate to services including AWS, Azure, on-premises backends and Model Context Protocol (MCP) servers without static, long-lived API keys.

Other additions include IAM role support in VPC Service Controls ingress and egress rules, which is generally available, and Workload Identity Federation for GKE, in preview. A Model Armor custom topic detector, also in preview, lets businesses define prompt-based rules to check whether agent conversations stay within approved topics. Google also made the Cloud NGFW advanced malware sandbox, powered by Palo Alto Networks WildFire, generally available, and introduced Cloud Armor managed rules in preview.

CodeMender, Google's AI tool for finding and fixing software vulnerabilities, remains in preview. New options let businesses verify vulnerabilities and simulate exploits in an operating system-level sandbox or an isolated virtual machine, with human checks for local writes and command execution. Scans can cover a whole repository, one folder, or only files changed since the last scan. Google also describes a shared data model connecting Wiz Defend and Google Security Operations. Separately, Google says autonomous agents analyse alerts, run correlation queries across telemetry and present mitigation actions for human approval. A Thales Group executive quoted in the report says early evaluation shows potential to cut vulnerability discovery time by over 95 percent. That is a customer view of an early evaluation, not a verified result.

Check: Find where your agents rely on static API keys and assess whether managed identities could replace them. Test preview features in non-production first.

Source: Help Net Security, 5 Nov

MCP tool poisoning succeeds in 22.9% of tests across 12 agent frameworks

Farooq Shaikh and Biagio Montaruli report the first cross-framework measurement of MCP tool poisoning that confirms real tool execution. The Model Context Protocol lets agent frameworks connect language models to external tool providers. It also carries attacker-controllable content, such as tool descriptions, schema fields and response data, into the model's context without validation. Earlier benchmarks measured whether a model complied with a poisoned instruction, not whether anything was actually executed. The authors use their open-source tool mcpvenom to run a 9,720-cell matrix across 12 frameworks, 18 models and 45 attack scenarios. A dual oracle confirms exfiltration when a canary HTTP request arrives at the attacker's endpoint.

The overall attack success rate is 22.9%, or 2,113 vulnerable cells. Of those, 64.9% dispatch an attacker tool call, 23.0% contact the attacker endpoint and 12.1% verifiably exfiltrate a secret. The authors find that resistance comes from the model, not the framework. Nine core frameworks cluster between 23% and 26%, and a code audit finds no intentional defence in any of the twelve. Model success rates range from 0.4% to 49.7%. Claude Opus 4.8 was vulnerable in 8 of 530 cells while issuing 223 explicit refusals. A regex scanner for tool descriptions rejects 20 of 45 scenarios at a 7.2% false-positive rate, so the authors call metadata scanning a partial control. All five coordinated disclosures to four vendors were rejected. The paper is accepted at AISec '26.

Check: Do not rely on your agent framework to block poisoned tool metadata. Test your own MCP setup with mcpvenom, and treat the choice of model and any description scanning as partial controls.

Source: arXiv 2611.03555, 2 Nov

An estimated 90% of destructive MCP tools lack server-side confirmation, and most hosts have no default approval

Junwei Yao and colleagues measured, from source code, who asks a human before an MCP tool deletes data or moves money. The MCP specification asks for a human who can deny tool calls, but it splits the job. The server can annotate a tool or ask the user through the host, which is called elicitation. The host application decides whether to prompt. In a 1,000-repository sample of the official MCP registry, an estimated 90% of destructive tools (95% CI 82-95) have no server-side confirmation. Most servers that do elicit go ahead, or fall back to a flag the model can set, when the host cannot relay the question.

On the host side, 32 of 41 popular open-source hosts and agent SDKs have no approval step by default, including 16 of 25 applications. Pairing sampled destructive tools flagged by a rule-based extractor with these applications, 60.7% of pairs have no enforced human approval by default. Through four agent SDKs, four of five low-cost models executed an injected deletion in 479 of 960 runs. The authors estimate that if hosts prompted for every tool not annotated read-only or non-destructive, the unapproved share would fall to 5.4%. Universal elicitation support alone would leave 56.7%. They conclude that applications should configure approval themselves.

Fix: Configure your agent host to require human approval for every tool not marked read-only, rather than relying on server-side confirmation or defaults.

Source: arXiv 2611.02527, 2 Nov

Fake safety hazards in reviews can steer AI agents without any injected command, authors show

Ilan Zendel and colleagues describe an attack they call voluntary servitude. Agents act on retrieved public information they treat as credible. Instead of writing a command into that content, the attacker plants a single fabricated hazard, written as an ordinary review. The authors show that the agent can then disqualify the legitimate options through its own harm-avoidance reasoning and select the attacker's target. There is no command syntax for a detector to recognise. The paper is accepted at NeurIPS 2026.

The payloads steer agents about as often as instruction injection, at 60.4% against 66.0%. The authors report that deployed injection detectors score them as benign, so the authors report that behind a filter they are 1.7 to 4.4 times more effective. The authors tested six models across ten consumer-service domains and three attack families. The 60.4% and 66.0% figures were measured at the generation stage. The authors report that the attack transfers to production browser agents, outperforming instruction injection, and to a retrieval pipeline with 1.0% to 57.0% end-to-end success depending on the retriever. The authors report that a corroboration requirement added to the agent's instructions removed roughly 95% of the exposure in the authors' tests against a non-adaptive attacker, without retraining. The agent still reads the planted hazard but no longer acts on it.

Plan: Do not count on injection detectors to catch this class. Where agents choose between options using public reviews, test an instruction that requires corroboration before the agent acts on a warning.

Source: arXiv 2611.04393, 3 Nov

Honeypot planned from source code cuts real compromise by autonomous attack agents

Seungdeok Roh and colleagues study a defence against LLM agents that exploit web vulnerabilities faster than patches arrive. An LLM defender plans a static honeypot from the application's source. A router then sends every later request from a client it confirms as an attacker, including a working exploit, to an isolated shadow copy. Earlier deception work mostly lured agents away from a real target that stayed reachable. On the 40 critical CVE-Bench tasks, with the static plan, real compromise fell from 26/40 to 5/40 for Claude Opus 4.8, and from 20/40 to 0/40 (31 valid runs) for the ARTEX attack framework. On 20 new tasks not used in the design, ARTEX went from 15/20 to 0/20.

The authors state the limits. In about half of the deception-arm runs ARTEX's exploit succeeded on the shadow while the real target stayed intact; the authors say the defence moved a working exploit rather than stopping it. The authors name requests that reach the real target before confirmation as the remaining risk. ARTEX reported a planted fake secret as genuine on 30 of the 120 deception-arm tasks. With ARTEX's real compromise at zero in both deception configurations, the static plan and the augmented configuration with a runtime LLM responder did not differ significantly on the remaining outcomes, so that comparison does not isolate the responder.

Take away: Treat this as an early result on benchmark tasks. Requests made before an attacker is confirmed can still reach the real system, so do not treat it as a replacement for patching.

Source: arXiv 2611.07611, 5 Nov

Baya web agent compiles the task into code first and records 0% attack success on WASP

Annabella Chow and colleagues introduce Baya, a web agent built to prevent prompt-injection hijacking of its control flow by design. Most web agents follow the ReAct pattern, choosing each action from runtime observations that mix trusted and untrusted content. Baya instead compiles the user's request into an executable Python program that calls a Trusted Website API, before it accesses the live site. The planning model never sees live page content. Untrusted data can set program values or pick between branches defined at compile time, but, according to the authors, it cannot redefine the task or make the model create new website operations at runtime.

On 581 valid WebArena Verified tasks, Baya reaches 77.8% aggregate utility, against 55.1% for browser-only ReAct and 66.7% for API-enabled ReAct. On WASP, a security benchmark for web agents, Baya has a 0% attack success rate. API-enabled ReAct scores 16.2% and browser-only ReAct 25.5%. The approach depends on a Trusted Website API that gives the compiler a view of the site's action space.

Take away: When designing web agents, consider fixing the plan before the agent reads untrusted pages, instead of relying on filters to spot injected text.

Source: arXiv 2611.06039, 4 Nov

GPUStack treats loopback requests as the admin, and exploitation has been reported in the wild

GPUStack versions before 2.2.0 promote any request whose source looks like loopback to the built-in administrator account. This applies when force_auth_localhost is False, which is the default. The advisory describes two ways to make a request appear to come from loopback. In the common self-hosted setup, GPUStack sits behind a reverse proxy on the same host that forwards to 127.0.0.1. Every remote request then arrives at GPUStack with a TCP peer of 127.0.0.1, so no header or credential is needed. Alternatively, a forged X-GPUStack-Real-IP: 127.0.0.1 header can cause the request source to be treated as loopback.

Either route gives unauthenticated administrative access over the network. The advisory says an attacker can enumerate and modify users, models, workers and configuration, create persistent admin API keys (full scope) that are valid from any source IP, and read worker credentials and cloud or provider secrets. Combined with the admin-only endpoint POST /v2/inference-backends/from-yaml, this leads to code execution on worker hosts. The advisory says exploitation was observed in the wild against a v2.1.1 deployment, reported by Javier Sixto (ulex.fr), where attacker-created custom backends ran reverse shells. NVD scores it 9.8 (Critical).

Fix: Upgrade GPUStack to 2.2.0 or later. If you ran an earlier version behind a same-host proxy, review admin API keys, custom inference backends and stored provider secrets, and rotate any that may have been exposed.

Source: GPUStack advisory, 4 Nov

Two more GPUStack flaws allow forged logins and cluster access

CVE-2026-102894 affects the SAML callback in GPUStack versions from 0.7.1 up to but not including 2.2.2. The callback decodes the posted XML, reads the NameID and attributes, finds or creates the user and issues a session JWT. It never calls OneLogin_Saml2_Auth.process_response(), which checks the signature, issuer, audience, destination and time conditions. The advisory says SAML does not need to be configured, so every deployment is affected. Anyone who can reach /auth/saml/callback can post a response naming an existing user, such as an administrator, and receive that user's session. A name that matches no one creates a new non-admin account. Because response IDs are never consumed, a captured signed response can also be replayed.

CVE-2026-103002 is a separate flaw in the Kubernetes API proxy, in versions from 2.2.0 up to but not including 2.2.2. The cluster_apiserver_proxy handler forwards requests from authenticated non-admin users to the selected cluster through a worker, using that worker's ServiceAccount credentials, without a resource-level authorization check. Depending on those permissions, an attacker could read sensitive resources, create or modify workloads, or delete resources. Creating workloads could give code execution in the cluster. It needs a Kubernetes-provider cluster with a reachable worker. NVD scores it 8.8.

Fix: Upgrade GPUStack to 2.2.2, which fixes both flaws. Until then, limit network access to the instance, and for the proxy flaw restrict it to trusted administrator accounts.

Sources: GPUStack SAML advisory, 4 Nov · GPUStack Kubernetes proxy advisory, 4 Nov

Kubeflow Pipelines skips authorization on shared pipeline uploads

In multi-user mode, the Kubeflow Pipelines API server does not check authorization on its HTTP upload endpoints when the target namespace is empty. An empty namespace is how the system addresses shared, cluster-wide pipelines, and it is the default when the caller leaves out the namespace parameter. The advisory says REQUIRE_NAMESPACE_FOR_PIPELINES defaults to false and is unset in every shipped manifest. In that case the helper canUploadVersionedPipeline returns early and skips the SubjectAccessReview.

A low-privilege tenant can therefore create shared pipelines or inject new versions into existing ones; the advisory says this can replace the container image, command and args that other tenants execute. An enabled, unpinned recurring run that follows the latest version would then run the injected version in another tenant's namespace. The upload bypass was reproduced live against the API server. The maintainers verified the recurring-run execution path by source inspection, not by an end-to-end run. If the API server is directly reachable, an unauthenticated caller can do the same. The advisory notes that the gRPC route for the same write remaps the empty namespace to the system namespace and authorizes, which it says confirms the gap is an omission. Affected versions are 2.17.3 and earlier. NVD scores it 9.6 (critical); the advisory says its CVSS vector assesses the authenticated tenant scenario.

Fix: Upgrade the Kubeflow Pipelines API server to 2.18.0. Keep the API server off networks that untrusted callers can reach, and review recent versions of shared pipelines for unexpected images or commands.

Source: Kubeflow Pipelines advisory, 5 Nov

AG2 shell tool filter can be bypassed with a newline

AG2's SandboxShellTool offers restricted modes: an explicit allowed list of commands, and readonly=True, which uses a built-in list of read-only commands. Both rely on a filter that checks a set of shell metacharacters but leaves out newline and carriage-return characters. The command is then run through sh -c, where an embedded newline works like a semicolon between statements. A command that passes the allow check can therefore carry a second, arbitrary statement.

The advisory says an agent, or content that steers the agent through prompt injection, can use this to run arbitrary shell commands. With the default LocalEnvironment() backend the command is a real subprocess on the host, which the tool's own documentation says has no real isolation. It runs with the privileges of the agent process. The advisory lists ag2 versions from 0.13.2 before 1.1.1 as affected, with the fix in ag2 1.1.1. NVD's record lists autogen 0.13.2 to 0.14.1 as affected and names no fixed autogen version, and the advisory lists no patched autogen release. NVD scores it 8.8.

Fix: Upgrade to ag2 1.1.1. Check which autogen version you run against the advisory, and do not rely on allowed lists or readonly mode as the only control on a host that holds sensitive data.

Source: AG2 advisory, 5 Nov