Daily Cybersecurity News – November 12, 2026

What happened

Darktrace researchers demonstrated in a lab that stolen Claude API keys can turn Anthropic's Claude Code coding agent into a remote-controlled implant.

They steered the agent via the memory stores feature of the Claude platform, using three files for heartbeat check-ins, job input, and results output. Jobs were plain English objectives. A 1 GB file was exfiltrated through the Claude Files API. All C2 traffic went through api.anthropic.com, blending with normal inference calls.

The technique requires prior compromise of a developer's machine to obtain credentials left by tooling. It needs no vulnerability in Claude itself and has not been observed in the wild.

Who is affected

Organizations and developers using Claude Code or Claude Managed Agents where API keys or credentials are stored insecurely on endpoints.

Any environment where Claude agents run with broad tool permissions and network access. Scale is limited to those with exposed keys; standard API keys can reach memory stores while OAuth cannot.

Why it matters

Once credentials are stolen, the agent becomes a stealthy C2 and exfiltration channel that looks like legitimate coding activity. Defenders monitoring only for malware or unusual destinations will miss it.

Builders and operators of AI agents must treat platform keys like production credentials because they unlock powerful, persistent capabilities inside the network.

How it could have been prevented

Prefer OAuth or identity federation over long-lived API keys. Scope keys tightly, make them short-lived, and store them securely outside shell history, dotfiles, or environment variables.

Monitor Claude Code processes for unusual command-line flags such as --dangerously-skip-permissions, atypical tool-call patterns, and abnormal ratios of data moving to and from the Anthropic API compared with baseline agent behavior. Correlate process activity with network traffic.

What happened

Since mid-August 2026 a phishing campaign has stolen live Google sessions from corporate users by delivering Google Calendar invites that lead through trusted Google redirects into a live reverse proxy in front of the real Google sign-in page.

Victims enter passwords and complete genuine MFA (SMS, authenticator, Tap-Yes, recovery) while the operator captures the resulting session in real time via the Nyasher framework. Material Security identified the activity and disrupted hundreds of domains under Operation CloudFire, blocking tens of thousands of messages.

Who is affected

Corporate Google Workspace users who accept calendar invites or click links that appear to come from known contacts or Google services.

Any organization relying on standard reputation checks, domain reputation, or MFA alone for session protection.

Why it matters

Every conventional signal (domain ownership, certificate, reputation, Google URL) stays clean by design, so link scanners and secure email gateways stay quiet. MFA is completed legitimately yet the session is stolen, granting full access to Gmail, Drive, and OAuth-connected apps.

Operators can move laterally or exfiltrate data under the victim's identity with no further alerts.

How it could have been prevented

Prefer phishing-resistant authentication such as hardware security keys or passkeys over SMS or push MFA. Monitor for anomalous session activity, new device logins, and unusual OAuth grants after calendar interactions.

Educate users that calendar invites from external or BCC senders carrying voicemail, RFP, court, or payment pretexts deserve extra scrutiny even when links look like Google. Revoke sessions and rotate credentials on any suspected compromise. Report and block attacker infrastructure promptly.

What happened

A critical race-condition flaw in Apache HTTP Server's mod_http2 module (CVE-2026-119618) lets an unauthenticated remote attacker achieve remote code execution on affected servers.

It stems from improper synchronization in assign_headers() when handling concurrent HTTP/2 streams, allowing one thread to corrupt memory belonging to another. The issue affects Apache HTTP Server 2.4.55 through 2.4.70 and standalone mod_h2 2.0.8 through 2.0.42. It is fixed in 2.4.71. Only servers with HTTP/2 enabled (Protocols h2 or h2c) are exposed. Red Hat rates it 9.8 CVSS and notes public research has demonstrated a reliable exploit against default configurations; it is not listed in CISA KEV and no widespread in-the-wild exploitation has been confirmed.

Who is affected

Any publicly reachable Apache HTTP Server instance running versions 2.4.55-2.4.70 with mod_http2 and HTTP/2 enabled, including many Linux distributions and cloud images.

Red Hat Enterprise Linux 9 and 10 packages are affected but rated Important due to per-stream allocators; RHEL 8 and earlier are not affected. Standalone mod_h2 users and certain Debian, Amazon Linux, and Ubuntu builds also need checks.

Why it matters

Unauthenticated RCE on a web server gives full control of the httpd process, enabling data theft, further malware deployment, or lateral movement. HTTP/2 is increasingly default for performance, so the blast radius includes high-traffic production sites.

Operators should treat any internet-facing Apache with HTTP/2 as high priority until patched.

How it could have been prevented

Upgrade Apache HTTP Server to 2.4.71 or apply vendor packages immediately (for example Red Hat mod_http2 updates). If patching is delayed, disable HTTP/2 by removing h2/h2c from the Protocols directive server-wide and in every virtual host.

Confirm the module is not loaded where unnecessary and monitor for anomalous HTTP/2 traffic or crashes. Review distribution-specific advisories for package names and backports.

What happened

Microsoft researchers showed that editing fewer than 10 rarely used (dormant) neurons in an open-weight language model is enough to plant a hidden backdoor called Lazarus, without full retraining.

When a chosen trigger string appears in the context, the model emits an attacker-chosen command that an agent will execute with its own permissions. The edit targets the final feed-forward layer; each neuron forces one payload token. Tests on Nemotron-Terminal-8B (7 neurons), Qwen3.6-27B and Gemma-4-31B-IT achieved high trigger success rates while models still passed ordinary benchmarks. Microsoft has not observed the technique in the wild and published defensive guidance.

Who is affected

Organizations deploying open-weight models as the backbone of AI agents that have tool, terminal, or code-execution permissions, especially if model checkpoints can be modified by insiders, supply-chain actors, or untrusted downloads.

Anyone who accepts model weights from external sources without integrity checks.

Why it matters

A backdoored model can look completely normal on evaluations yet, on a mundane trigger, cause the agent to download and run arbitrary code under the agent's privileges. The damage is bounded only by the agent's access, not by the size of the weight edit.

Supply-chain and insider risks to model files become direct paths to agent compromise.

What happened

CISA added four actively exploited vulnerabilities to its Known Exploited Vulnerabilities catalog on or about November 9, 2026, covering IBM Aspera Faspex, SignalWire FreeSWITCH, OpenSSH, and GPUStack.

The flaws include improper authentication, code injection, and authorization bypasses, several scored 9.8 CVSS. Exploitation has been observed in the wild. Federal agencies face a remediation deadline of November 12, 2026 under binding operational directive requirements.

Who is affected

Operators of IBM Aspera Faspex 5.0.0–5.0.19, SignalWire FreeSWITCH before 1.11.3, OpenSSH before 10.6p2 on musl-libc Linux systems without PAM, and GPUStack before 2.2.0.

Any internet-exposed instances of these products, especially those used in file transfer, VoIP, remote access, or GPU orchestration.

Why it matters

KEV listing confirms real-world exploitation, elevating these above theoretical high-CVSS bugs. Successful attacks can yield unauthenticated admin access, command execution via SIP, authentication bypass, or privilege escalation to full control.

Federal civilian agencies must act within days; private organizations face the same active threats.

How it could have been prevented

Apply vendor patches immediately: GPUStack 2.2.0+, FreeSWITCH 1.11.3+, OpenSSH 10.6p2+, IBM Aspera Faspex 5.0.19 PL1. Where patches lag, restrict network exposure, disable vulnerable features, and perform forensic triage for prior compromise.

Prioritize internet-facing systems and monitor for indicators of exploitation associated with each CVE.

What happened

Security firm Claroc discovered that of 37,571 live Grok-built apps on grok.me, 35,578 (about 94.7 percent) were openly accessible to anyone with the link and required no sign-in.

Twenty-four of the open apps were built by staff at X and SpaceXSI (formerly xAI) and contained confidential material such as sales territory maps, onboarding plans, and proposals. Roughly one in ten open apps held internal business or personal data from at least 30 other organizations, including Fortune 500 firms, hospitals, and defense-related entities. Sensitive examples included employee lists, patient briefings, shift boards, and plaintext passwords. SpaceXSI removed its own staff apps after notification.

Who is affected

Anyone who published a Grok Build app with the default "Anyone with the link" setting, plus the organizations whose internal data ended up inside those apps.

Users of Grok's chat-to-app builder whose subdomains appeared in passive DNS after the first visit.

Why it matters

Default-open publishing plus discoverable hostnames turned a convenient AI app builder into a mass data-exposure vector. Confidential business plans, credentials, and even patient information became reachable without authentication.

The incident shows how AI coding and app-generation features can silently create shadow IT and data-leak surfaces at scale.

How it could have been prevented

Immediately audit every Grok Build app you have published. Change access from "Anyone with the link" to "Invited users" or "Only you", or unpublish apps that hold sensitive data.

Treat AI-generated apps the same as any other production service: require authentication by default, avoid embedding secrets or internal data, and monitor passive DNS and public indexes for unexpected exposures. Review organizational policies on employee use of consumer AI builders for work data.

What happened

Token Security built an internal browser agent named Rehearsal that deliberately violated the three core rules the company gives customers for securing AI agents: distinct identities, least-privilege access fitted to the task, and separate traceability.

Because the agent runs inside the user's authenticated browser session, the backend application sees only the human user. Clicks and form fills are indistinguishable from the user's own actions. The exercise showed how common UI agents inherit the full reach of the logged-in session and lack independent identity or scoped permissions.

Who is affected

Any organization deploying or allowing browser-based or UI-driving AI agents that operate inside existing user sessions for CRMs, cloud consoles, internal dashboards, or similar tools.

Security and identity teams responsible for agent governance as agent use scales.

Why it matters

When an agent shares a human's session cookie, classic identity, authorization, and audit controls collapse. The application cannot tell agent from user, so least privilege and attribution fail by default.

As agents proliferate, this gap becomes a systemic risk rather than an edge case. Standards are emerging but incomplete.