A house newsletter · daily · researched and written by the Kurzia AI
Thursday 12 November 2026 · Issue 12 · 4 min read
AntiFox agents mine AWS credentials; Xen Orchestra admin bypass under attack; BroadWorks XXE hits CISA's list; llm 0.37.2 plugs a key leak
Act on this first
BleepingComputer · yesterday
AntiFox
Takeaway: hundreds of API calls
Arctic Wolf has tied several intrusions to attackers running self-hosted copies of AntiFox — an open-source, Chinese-language agentic penetration-testing fork of ARTEX — on Alibaba Cloud and pointing it at exposed web services and AWS accounts. The intruders used valid AWS identities, including IAM users and assumed EC2 roles, and in one case fired hundreds of API calls at AWS endpoints in about 30 minutes; most were blocked but some succeeded and yielded production secrets, and a separate incident saw S3 objects read, copied and deleted. AntiFox remains a public GitHub download, now at version 2.0, with usage rules its publishers enforce with nothing technical.
Start in your AWS logs: look for bursts of denied calls with a few successes inside them, correlate any IIS webshell activity with unusual API use, then revoke exposed sessions and rotate credentials that live in application files. The barrier to this kind of attack is now a clone-and-run, so it belongs in your cloud threat model today. In one highlighted break-in the attacker dropped an ASPX webshell on an internet-exposed IIS server and pulled database connection strings out of the application settings.
Under attack
Xen Orchestra — Xen Orchestra/XOA: an empty-object cookie logs an attacker in as admin, leading to root takeover of XCP-ng hosts; Vates confirms attacks; patch: xo-server 5.211.2/5.213.1; VSA-2026-062. Vates also warns of a second zero-day, needing admin rights, that lets a malicious VM import compromise XCP-ng hosts; no fix for that one yet.
Affected: Xen Orchestra and the Xen Orchestra Appliance (see the Vates advisory for affected releases) · Fixed in: Xen Orchestra 6.9.1 (stable) and 6.10.0 (latest), with patched xo-server packages 5.211.2 and 5.213.1 · We had it 10 Nov, 23:06 UTC
Cisco BroadWorks — Cisco BroadWorks (before RI.2026.07): unauthenticated XML flaw reads sensitive files and keys; now in CISA's exploited catalogue; fix: RI.2026.07; CVE-2026-20320. Malbear Labs says a Chinese-speaking actor ran the campaign with a jailbroken DeepSeek Flash model against a European telecom and thirteen other organisations, recovering the system identity key BroadWorks components use to authenticate to each other. Note the vendors are not saying the same thing: Cisco's original advisory still says PSIRT knows of no malicious use, while CISA's catalogue now treats the CVE as exploited — patch on the catalogue's word, not the vendor's sentence.
Affected: BroadWorks Application Delivery Platform, Application Server, Profile Server and Xtended Services Platform running releases earlier than RI.2026.07 · Fixed in: RI.2026.07 · We had it 10 Nov, 23:06 UTC
Holes in AI tools
Simon Willison · yesterday
llm
Takeaway: 0.37.2
Simon Willison's llm command-line tool has fixed a flaw in extra-openai-models.yaml, the mechanism for pointing llm at OpenAI-compatible endpoints run by other companies, that could ship your configured OpenAI API key to those providers. Two paths triggered it: a model whose api_key_name was never actually stored, and a responses:true model run with the chat_completions option switched on. Daniel de Araujo reported it, and version 0.37.2 fixes it while moving configuration to the new `llm openai endpoint add` command.
If you use llm against third-party OpenAI-compatible endpoints on anything older, treat the OpenAI key as shared with whoever runs those endpoints: rotate it after upgrading. No attack reported. Tracked under two advisories, GHSA-v9h7-jj4g-f862 and GHSA-r639-rr7r-x72w.
Affected: llm releases before 0.37.2 using extra-openai-models.yaml · Fixed in: 0.37.2 · We had it 11 Nov, 23:05 UTC
The Hacker News · yesterday
Grok-built apps
Security company Claroc scanned for apps generated with Grok's builder and counted 37,571 of them on the public internet, of which 35,578 were reachable without any sign-in. Most were throwaway games and landing pages, but roughly one in ten held internal business material, and the open set included 24 apps built by people working at X and at SpaceXSI, Grok's maker.
If someone at your company has prototyped a Grok-built tool with real data in it, assume it is publicly readable unless you checked — AI app builders have made shipping an exposed internal tool a one-prompt operation, and no vendor patch fixes how an app was deployed. Some of the open apps leaked confidential data and passwords.
The Hacker News · yesterday
Railway
Takeaway: estimated $740,000 in charges
Platform-as-a-service provider Railway says AI keys lifted from customer secrets in a recent breach were used to run up an estimated $740,000 in charges, and that it will pay the bill itself whenever an AI provider refuses a refund. The secrets at issue were the model keys and database credentials customers attach to the apps the platform hosts for them.
This is a classic secret-store breach with an AI twist: model keys are now metered spending accounts, so they deserve the same leak-response handling as payment credentials — revoke, rotate, then check usage and billing. Railway has committed to covering the unauthorized charges that providers will not refund.
The Hacker News · yesterday
Ten edited neurons hide a backdoor in a model
Microsoft researchers demonstrated that an AI model can be quietly backdoored by editing fewer than ten of its rarely used neurons, with no retraining involved. When a chosen trigger appears in the input, the model emits a command of the attacker's choosing, which an agent running that model would execute with the agent's own permissions. The prerequisite: the attacker needs write access to the model's weights.
For anyone pulling open-weight models or fine-tunes from third parties, this is the argument for pinning weights to a hash and checking provenance on download — a file can now be weaponised without any training run to give it away. The backdoor is invisible to ordinary use because the edited neurons are rarely activated outside the trigger.
Found or caused by AI
codename MDASH — Microsoft's FORGE Lab ran its codename MDASH AI scanning system over a subset of Linux kernel subsystems for roughly two weeks and got 26,502 raw findings; after screening agents, QEMU-based reproduction and expert review that became 59 public upstream reports and 33 assigned CVEs — eight with confirmed root privilege-escalation exploits, and 24 of the CVEs rated High or above. Fixes for 38 of the reports are merged into mainline so far. The number that matters for patching is the imbalance, not the bug count: two weeks of scanning produced findings that took months of expert work to report and fix, and the pipeline is now the bottleneck on both the hunter's and the maintainer's side. Expect kernel CVE volume to keep climbing as more teams point this machinery at the same code. The average reported bug had been sitting in the kernel for 8.1 years — one, CVE-2026-74544, for at least 21 — and the median run from first public patch to a mainline release was 41 days.
Patches worth knowing
mcp-gateway-registry — mcp-gateway-registry 1.0.3–1.34.0; server-registration permission lets a user point the gateway at internal services and read responses; fixed in 1.35.0; CVE-2026-125926 (AWS: Important). The fix validates upstream addresses only when a server is registered or modified — addresses stored before the upgrade keep working, so review them after updating.
Affected: >= v1.0.3 AND <= 1.34.0 · Fixed in: 1.35.0 · Disclosed 11 Nov · We had it 11 Nov, 23:06 UTC
mcp-gateway-registry — mcp-gateway-registry 1.0.9–1.24.7; any signed-in user could become registry administrator and read stored server credentials; fixed in 1.25.0; CVE-2026-100307 (AWS: Important). Upgrading does not undo the damage: privileged group mappings created before the fix keep conferring admin until removed from the mcp_scopes store, and AWS says to rotate registry-managed credentials if abuse cannot be ruled out.
Affected: >= 1.0.9 AND <= 1.24.7 · Fixed in: 1.25.0 · Disclosed 11 Nov · We had it 11 Nov, 23:06 UTC
One thing to do
Sweep XCP-ng hosts for the ustar campaign artefacts. Vates says the Xen Orchestra exploit writes nothing to product logs, so check the hosts directly: use the `xe vm-list` platform check from the advisory to find virtual machines whose serial port is bound to a file, and look for the `zz-ustar` cron entries and `/.ustar*` files among the published indicators. Point HTTP monitoring at requests carrying an empty `authenticationToken` cookie — that is the exploit signature — and if anything matches, rotate the passwords and secrets the virtualization environment holds. BleepingComputer