Daily Cybersecurity News – November 11, 2026

What happened

A critical authentication bypass in Xen Orchestra (tracked as VSA-2026-062) is under active exploitation, allowing remote attackers to gain administrator privileges without credentials.

Attackers send a crafted cookie containing an empty JSON object (authenticationToken=j:{} or the URL-encoded form). This is parsed into an unfiltered token lookup that returns the first valid token, authenticating the attacker as its owner. From there they can retrieve reusable login tokens, execute code on managed pools, and take over XCP-ng hosts as root.

Vates confirmed active exploitation from specific IPs and a Tor onion service. The flaw was discovered by Filip Magic and Christoffer Olsen. Patched releases are available.

Who is affected

Organizations running Xen Orchestra or the Xen Orchestra Appliance (XOA) that manage XCP-ng virtualization hosts, particularly any instance with the management interface reachable.

Affected versions are Xen Orchestra before 6.9.2 (stable) and 6.10.1 (latest), plus corresponding xo-server packages. Source installs and appliances are both impacted until updated. Scale is significant for private-cloud and VPS operators using the XCP-ng stack.

Why it matters

Full compromise of the virtualization management plane hands attackers root on the underlying hosts, enabling complete control of guest VMs, data theft, ransomware, or further lateral movement.

Because successful exploitation leaves no standard authentication logs, detection is harder and dwell time can grow. Operators of multi-tenant or production virtualization environments face high blast radius if the management interface is exposed or poorly segmented.

How it could have been prevented

Update immediately to Xen Orchestra 6.9.2 (stable) or 6.10.1 (latest), or the matching xo-server packages (5.211.2 / 5.213.1). For source installs, pull latest master, rebuild, and restart.

Do not expose the management interface to the internet; place it on a dedicated management network. Monitor HTTP traffic for the malicious cookie patterns. Block known attacker IPs and Tor traffic to the listed onion. If compromise is suspected, rotate all passwords and secrets (users, root, pool, backups, OTP, mail) and consider full reinstallation.

What happened

Microsoft researchers demonstrated a technique called Lazarus that plants a hidden backdoor in an AI model by directly editing fewer than 10 rarely used neurons, without full retraining.

The edited neurons fire only when a chosen trigger string appears (in user input or tool output) and force the model to emit an attacker-chosen command token by token. An agent using the model then executes that command with its own permissions. The team tested it successfully on open-weight models including Nemotron-Terminal-8B (7 neurons, ~99% trigger success), Qwen3.6-27B, and Gemma-4-31B-IT.

Microsoft has not observed real-world use by threat actors and released detection and mitigation guidance. The attacker needs the ability to modify the model's weight checkpoint before deployment.

Who is affected

Organizations deploying AI agents that rely on open-weight or third-party model checkpoints, especially those pulled from public hubs, fine-tuned internally, or obtained via supply-chain paths.

Any environment where agents can run commands, access tools, or hold elevated permissions is exposed if a backdoored checkpoint reaches production. Insiders, compromised build pipelines, or malicious model publishers are the primary vectors.

Why it matters

A tiny, stealthy weight edit can turn a trusted agent into a remote-command runner whose damage is limited only by the agent's privileges and network access. Ordinary capability benchmarks often still pass, making the backdoor hard to notice.

This raises supply-chain risk for AI systems: anyone who can alter a checkpoint (insider, stolen credentials, or public-hub publisher) can implant persistent, triggerable malicious behavior without changing code or requiring heavy compute.

How it could have been prevented

Compare every checkpoint against its declared base model before deployment and after updates; reject any whose base cannot be verified. Download only from original publishers, verify hashes, and treat third-party fine-tunes, merges, quantizations, and adapters as untrusted until audited.

Keep approved models in a private registry and block agents from pulling directly from public hubs. Least-privilege agents, sandbox all generated code, limit outbound connections, and require human approval for high-impact actions. Add weight-level and behavioral backdoor scanning.

What happened

CISA added four vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog on evidence of active exploitation: CVE-2026-123218 (IBM Aspera Faspex, CVSS 9.8), CVE-2026-116779 (SignalWire FreeSWITCH, CVSS 9.8), CVE-2026-123158 (OpenBSD OpenSSH on Linux, aka SSHole, CVSS 8.1), and CVE-2026-102895 (GPUStack, CVSS 9.8).

CVE-2026-123158 allows authentication bypass under certain musl libc configurations without PAM when long passwords are supplied. Exploitation attempts began around November 6-7 2026; post-exploitation has included cloud metadata queries, password-hash and SSH-key theft, authorized_keys modification, and deployment of a Python C2 agent (TAC Agent) plus botnet/miner activity.

The IBM flaw lets an authenticated user escalate to full admin via a crafted message. FreeSWITCH suffers code injection leading to credential disclosure and command execution. GPUStack's improper authentication (default localhost trust) enables unauthenticated admin access, secret disclosure, and code execution.

Who is affected

Users of IBM Aspera Faspex 5.0.0 through 5.0.19, FreeSWITCH prior to 1.11.3, OpenSSH before 10.6p2 on Linux with musl libc and without PAM, and GPUStack prior to 2.2.0.

OpenSSH exposure is especially relevant for Alpine and similar musl-based systems. GPUStack affects AI model-serving and GPU cluster operators. Scale includes any internet-facing or poorly segmented instances of these products; federal agencies and many enterprises face mandatory KEV remediation timelines.

Why it matters

All four are confirmed actively exploited and carry critical or high impact: full admin takeover, RCE, credential theft, and persistent access. OpenSSH is foundational infrastructure, so bypasses quickly lead to root and lateral movement.

CISA KEV listing triggers binding remediation deadlines for U.S. federal civilian agencies and strongly signals priority patching for everyone else. Combined blast radius across file-transfer, telecom, SSH, and AI infrastructure is large.

How it could have been prevented

Patch immediately to the fixed versions: IBM Aspera Faspex post-November 2026 releases, FreeSWITCH 1.11.3 or later, OpenSSH 10.6p2 or later, GPUStack 2.2.0 or later.

Prioritize internet-facing and management interfaces. For OpenSSH, review musl/PAM configurations and monitor for long-password auth attempts and authorized_keys changes. Restrict GPUStack auth settings (disable force_auth_localhost trust). Apply network segmentation, least privilege, and monitor for the reported post-exploitation behaviors (metadata service access, TAC Agent, miner activity).

What happened

Intezer researchers demonstrated that modern AI harnesses make reverse-engineering of complex mainstream software and malware substantially easier and faster than traditional manual methods.

They built task-specific harnesses (orchestrator agents plus static-analysis tools, compilers, VMs, and multiple LLMs) and successfully unpacked, mapped, and largely recreated Slack, Apple's Finder, and even a working pipeline of Turla malware. Malware proved the hardest target yet still yielded a full command-and-control and file-transfer picture. Anthropic reports already show nation-state actors (including Midnight Blizzard) using Claude for SDK reverse-engineering and security-product analysis.

Open-source tools such as REA (Reverse Engineer Anything) have surged in popularity, further lowering the skill barrier.

Who is affected

Software vendors protecting proprietary code and intellectual property, malware analysts and defenders who must keep pace, and any organization whose binaries or SDKs could be targeted for theft or vulnerability discovery.

Both sophisticated APTs and lower-tier actors benefit; defenders gain speed but also face faster adversary reverse-engineering of their own tools and products.

Why it matters

The historical moat of specialized Assembly expertise and long manual effort is eroding. IP theft, rapid vulnerability discovery in endpoint products, and recreation of working malware become accessible to smaller teams or even individuals.

Defenders can analyze threats faster, yet the same capability accelerates offensive work and raises the cost of keeping proprietary implementations secret. Obfuscation and anti-analysis techniques face a shorter half-life as models improve monthly.

What happened

ESET discovered a modular .NET toolset it named Turla's Cereal, attributed with high confidence to the Russia-aligned Turla (FSB-linked) APT. The toolset runs on compromised Microsoft Exchange servers, receives commands, executes in memory, maps the organization, and silently collects selected emails.

First seen on a Kazakhstan government Exchange server on 28 November 2025 and a Romanian government agency on 23 December 2025. In Romania it was configured to target messages to or from NATO and EU addresses. No external C2 infrastructure is used; the victim's own Exchange server is co-opted as the command channel via paths that mimic normal OWA, Autodiscover, and ActiveSync traffic.

Components inject into legitimate Exchange processes (including the transport pipeline) and leave minimal disk artifacts.

Who is affected

Government and high-value organizations running on-premises Microsoft Exchange, especially those of interest to Russian intelligence (already observed in Kazakhstan and Romania).

Turla has historically compromised entities in more than 50 countries across government, military, private sector, and research. Any unpatched or weakly monitored Exchange environment is a potential target.

Why it matters

By living entirely inside legitimate Exchange processes and using the victim server itself as C2, Cereal produces almost no obvious network or disk indicators, defeating many traditional detections.

It enables long-term, selective email espionage (including attachments) against diplomatic and alliance traffic without requiring external infrastructure that defenders can block. The modular, serialized design supports rapid customization of collection rules.

How it could have been prevented

Harden and monitor on-premises Exchange: apply latest cumulative updates, enable advanced auditing of transport and process injection, and hunt for anomalous modules loaded into EdgeTransport.exe or similar processes.

Inspect unusual web paths under /owa/, /autodiscover/, and ActiveSync that carry encrypted payloads. Segment Exchange management and restrict outbound capabilities. Deploy ESET or equivalent detections for the published Cereal IoCs and .NET serialization patterns. Assume breach and review mail-flow logs for selective collection of NATO/EU-related traffic.

What happened

Security firm Claroc discovered that of 37,571 live apps built with Grok Build (SpaceXSI/xAI's chat-to-app feature), 35,578 (94.7%) were publicly accessible without any sign-in.

Apps receive subdomains under grok.me; once visited, passive DNS records make the names discoverable. The default publish setting in the researchers' test was "Anyone with the link." Among the open apps were 24 built by X and SpaceXSI staff containing confidential onboarding plans, a 594-account sales territory map, and advertising proposals (one marked confidential to a U.S. federal agency). Roughly one in ten open apps held internal business or personal data from 30 other identifiable organizations, including six Fortune 500 firms.

Confirmed exposures included a hospital employee roster of 3,500+, an ICU patient briefing, a fire-department shift board, and a contractor timesheet embedding plaintext employee passwords. SpaceXSI took down its own 24 apps after notification but left others online.

Who is affected

Anyone who published a Grok Build app with the open access setting, plus the organizations whose internal data ended up inside those apps (healthcare, defense, construction, energy, and others).

Employees of X/SpaceXSI and users across Grok plans who clicked Publish without changing the default. Passive DNS made discovery trivial for anyone enumerating grok.me subdomains.

Why it matters

No exploit was required; simple discovery plus a permissive default turned thousands of AI-generated apps into public data dumps. Sensitive corporate strategy, health information, credentials, and government-related proposals became world-readable.

This illustrates a classic shadow-IT and vibe-coding risk: rapid app generation without security defaults or review creates large-scale exposure. Similar builders (e.g., ChatGPT) default more restrictively, highlighting a product-design gap.

How it could have been prevented

Immediately review every published Grok Build app and change access to "Only you" or "Invited users." Delete or unpublish any app containing sensitive data. Rotate any exposed passwords, API keys, or credentials.

Treat AI app builders like production systems: never embed secrets in client-side code, scan for PII/PHI before publish, and enforce private-by-default policies. Organizations should inventory grok.me assets via passive DNS and educate staff on access settings. Prefer builders that default to private.

What happened

An attacker exploited a remote code execution vulnerability in the open-source SGLang inference engine and gained code execution on one of NEAR AI's inference servers on 8 November 2026.

From there the attacker could observe requests processed that day, including those in confidential mode (running inside a TEE). The TEE does not protect against flaws in software running inside it. The attacker then reached a deprecated Private Chat backend, downloading account details (emails, names, and for some users plan/balance info) for about 100 users. No evidence of access to stored conversations or uploaded files was found.

The attacker also accessed 18 AI agents on a legacy non-TEE deployment, exfiltrating chat history, settings, and logs. Two customers' NEAR AI Cloud API keys appeared in logs and were revoked. NEAR AI contained the incident, patched SGLang across servers, rotated credentials, and restored service.

Who is affected

NEAR AI Cloud users whose requests hit the compromised inference server on 8 November, the approximately 100 Private Chat users whose account metadata was taken, the 18 agents on the legacy deployment, and the two customers whose API keys were exposed.

Any organization running unpatched SGLang for model inference faces similar RCE risk. NEAR AI notified affected parties directly; others need take no action beyond general vigilance.

Why it matters

Even confidential-computing / TEE deployments are only as strong as the code inside the enclave. An RCE in the inference engine defeated the privacy guarantee and enabled further internal movement.

The incident shows how a single vulnerable dependency in an AI serving stack can expose both live traffic and adjacent legacy systems, underscoring the need for rapid patching, credential hygiene, and isolation of deprecated services.

How it could have been prevented

Apply the SGLang fix NEAR AI deployed (report the vulnerability upstream if not yet public). Isolate inference servers, revoke and rotate all sessions, admin credentials, agent tokens, and API keys after any suspected compromise.

Keep deprecated services offline or strongly segmented. Monitor for unexpected code execution and lateral movement from inference nodes. Users who received mail from security@near.ai should follow the provided steps; others should treat unsolicited account/balance messages with caution. Prefer TEE deployments that also enforce least privilege and regular dependency scanning inside the enclave.