Daily Cybersecurity News – September 28, 2026

What happened

Citrix patched eight vulnerabilities in NetScaler ADC and Gateway, confirming that CVE-2026-88771 and CVE-2026-88772 were exploited as zero-days for weeks to plant webshells on unmitigated devices.

CVE-2026-88771 (CVSS 9.8) is an improper input validation flaw enabling unauthenticated remote command execution on default configurations with no user interaction. CVE-2026-88772 (CVSS 8.1) is a memory overflow leading to remote code execution or denial of service, exploitable remotely when DTLS is enabled (default on virtual VPN servers). Both are in CISA KEV and can be used independently. Attacks appear well-resourced and possibly nation-state aligned for espionage.

Who is affected

Customer-managed Citrix NetScaler ADC and NetScaler Gateway deployments: v14.1 before 14.1-73.37, v13.1 before 13.1-64.23, plus FIPS and NDcPP variants before the listed builds. Secure Private Access Hybrid deployments using NetScaler are also affected.

Organizations worldwide running internet-facing or gateway NetScaler appliances in default or DTLS-enabled setups face exposure, with European government warnings circulating prior to the public patch.

Why it matters

Successful exploitation grants full control of the gateway and direct access to internal corporate networks behind it. Webshells enable persistent access for further lateral movement, data theft, or ransomware.

NetScaler is widely used for application delivery, load balancing, and remote access, so unpatched instances create high-value entry points that operators must treat as urgent, especially given confirmed global exploitation before patches.

How it could have been prevented

Upgrade immediately to fixed builds (14.1-73.37, 13.1-64.23, or corresponding FIPS/NDcPP versions). After patching, inspect every appliance for webshells and signs of compromise using Citrix guidance and NetScaler Console indicators.

Follow full incident response if compromise is found. Limit exposure of management interfaces and review DTLS configurations. CISA directed federal agencies to remediate by September 30, 2026, with forensic triage.

What happened

CVE-2026-65660, a code injection remote code execution flaw in Microsoft SharePoint, is under active exploitation roughly six weeks after its August 2026 Patch Tuesday fix and days after technical details were disclosed.

Microsoft confirmed reliable evidence of attacks as of September 25, 2026. CISA added it to the KEV catalog that day with a federal patching deadline of September 28. Previdian observed exploitation attempts on September 24 and webshell creation attempts on September 25, matching details from Viettel Security researchers. CVSS is 8.8. It requires low-level authenticated access and no user interaction; unauthenticated RCE needs chaining with a separate auth bypass.

Who is affected

Organizations running on-premises Microsoft SharePoint Server versions fixed in the August 2026 updates (Subscription Edition, 2019, and 2016 builds). Internet-facing or poorly segmented SharePoint instances with authenticated low-privilege users are most at risk.

CISA KEV now lists 16 SharePoint vulnerabilities total, underscoring ongoing targeting of the platform.

Why it matters

Authenticated RCE lets attackers execute arbitrary code, install webshells, and pivot into broader enterprise environments. SharePoint often holds sensitive documents and integrates with identity systems, amplifying blast radius.

Exploitation ramped up quickly after public technical details, showing how rapidly defenders must act once PoC-level information appears. Builders and operators relying on SharePoint for collaboration face elevated risk of data exposure or further compromise.

How it could have been prevented

Apply the August 2026 SharePoint security updates immediately if not already done (specific KBs and builds for SE, 2019, and 2016). Verify patch level and hunt for webshells or anomalous authenticated activity.

Restrict SharePoint access with least privilege, network segmentation, and monitoring for code-injection indicators. Federal agencies had a hard deadline of September 28, 2026.

What happened

Researchers disclosed the Carbonato botnet, which targets exposed unauthenticated Docker daemons on port 2375 to deploy the open-source Hermes Agent AI framework under attacker control.

The implant launches a privileged container, establishes persistence and reverse SSH tunnels (relay in Costa Rica), then installs unmodified Hermes Agent and overwrites its SOUL.md persona file with a 39-line prompt. The agent (named GH0ST) executes Telegram-received tasks via an LLM gateway, prioritizes stealing AI API keys and credentials, and scans neighboring networks every five minutes for worm-like spread. ThreatDown found evidence via a public unauthenticated Docker registry spanning months of activity.

Who is affected

Any organization or individual running Docker hosts with the daemon API exposed to the internet without authentication on port 2375. Cloud, self-hosted, and development environments with misconfigured Docker are primary targets.

Compromised hosts can lose credentials, AI keys, and full system control; the campaign also linked to a separate trojanized crypto wallet distribution effort.

Why it matters

This is an early example of a botnet whose command-and-control is an autonomous AI agent rather than static scripts, allowing adaptive task execution and credential harvesting at scale.

Exposed Docker APIs remain a common, high-impact misconfiguration. Operators lose host control, face lateral movement, and risk further AI-powered abuse. Builders integrating AI agents must assume they can be co-opted if the host is compromised.

How it could have been prevented

Never expose the Docker daemon API (port 2375/2376) to the internet without strong authentication, TLS, and network controls. Use firewalls, VPNs, or Docker's built-in auth; prefer rootless or least-privilege setups.

Scan for and close exposed daemons, monitor for privileged container launches and unexpected reverse tunnels or cron/watchdog persistence, and rotate any credentials or AI API keys on potentially affected hosts. Hunt for Hermes Agent artifacts and the custom SOUL.md persona.

What happened

Threat actor JADEPUFFER (tracked by Microsoft as Storm-3168) used two compromised Azure service principals in the same tenant to conduct reconnaissance then destructive operations lasting about 18 hours in early June 2026.

One principal performed over 300 read operations mapping VMs, subscriptions, resource groups, and more for roughly 16 hours. The second handled discovery plus more than 150 destructive and credential-collection actions in about 35 minutes, targeting Storage Accounts, SQL databases, Key Vaults, Function Apps, recovery locks, VMs, and App Services. Microsoft called it an evolution of the actor's tradecraft. Initial access involved service principal credentials (client ID, secret, tenant ID) exposed in a public GitHub issue edit history. The actor was previously linked to agentic ransomware via Langflow CVE-2025-3248.

Who is affected

Azure tenants whose service principals or workload identities have been compromised, especially those with overly broad roles such as Contributor or Storage Account Contributor and secrets exposed in public repositories or logs.

Any organization using Azure service principals for automation is potentially exposed if secrets hygiene and least privilege are weak.

Why it matters

Compromised service principals enable silent, high-speed discovery and mass deletion of cloud resources without needing interactive user sessions, turning identity into a destructive weapon.

This demonstrates how agentic and automated tradecraft can rapidly escalate from recon to irreversible damage (deleted storage, databases, recovery protections). Cloud operators must treat workload identities with the same rigor as human admin accounts.

How it could have been prevented

Enforce least privilege on service principals and managed identities; avoid broad Contributor roles. Store secrets in Key Vault or equivalent, never in code or public GitHub issues (including edit history).

Enable Microsoft Defender for Cloud protections, monitor for anomalous service principal activity (mass reads then deletes), protect recovery locks and soft-delete features, and rotate any exposed credentials immediately. Review and clean public repository history for leaked client secrets.

What happened

Extortion group ShinyHunters claimed a breach of FBI systems and shared samples of stolen medical and fitness-for-work records with journalists, including blood and urine test results, doctors' notes on conditions such as high cholesterol or blood in urine, and allergies.

Samples appear genuine and also contain names, addresses, phone numbers, badge numbers, job titles, and spouse information. The group claims access to FBI MedLink (medical records), FBI BEAST (background checks), and related systems, asserting data on around 60,000 current and former staff plus applicants. Motive is non-financial: demand that the FBI retract a May advisory the group calls false. FBI has acknowledged an incident affecting FBIJobs-related systems and is investigating, without full confirmation of the medical data scope.

Who is affected

Current and former FBI special agents, employees, applicants, and their family members whose data resided in the affected HR, background, or medical systems. Rough scale claimed is tens of thousands.

Journalists and the public have seen limited samples; full release was threatened if demands were unmet.

Why it matters

Medical and psychiatric details cannot be rotated like passwords and create lifelong blackmail, social-engineering, and targeting risks for law-enforcement personnel and their families.

Exposure of badge numbers, addresses, and assignments also aids impersonation and physical threats. The incident underscores how attacks on HR and medical systems of high-value organizations produce uniquely persistent harm beyond typical credential dumps.

How it could have been prevented

Affected individuals should monitor FBI.gov for official guidance, change any reused passwords (especially FBIJobs accounts), enable multi-factor authentication everywhere possible, and watch for targeted phishing or extortion.

Organizations handling similar sensitive personnel data must isolate medical and background systems, apply strict access controls and logging, and treat third-party or cloud HR platforms as high-risk. Assume samples are real until proven otherwise and prepare identity-theft and insider-threat responses.

What happened

Authorizer is an open-source authentication and authorization server written in Go that teams can self-host, connecting to a database of their choice so user accounts stay under their control.

It supports email/password, magic links, passkeys, social login (10+ providers), MFA one-time codes, SAML 2.0, and OpenID Connect. Fine-grained permissions come from an embedded OpenFGA (Zanzibar-style) engine. A built-in MCP server exposes read-only profile and permission-check functions for AI agents over local stdio only, so an agent acting for a user receives only the intersection of its own and the user's permissions. This directly addresses AI assistants that perform vector search without prior authorization checks.

Who is affected

Development teams building web or mobile apps who want self-hosted auth without vendor lock-in or per-user pricing, especially those integrating AI agents that need to respect document-level or resource-level permissions.

Supports 13+ databases including PostgreSQL, MySQL, MongoDB, and DynamoDB.

Why it matters

Self-hosted auth keeps identity data in the team's own database and avoids SaaS pricing and data residency issues. The AI-agent interface helps prevent over-privileged chatbots from retrieving documents a user should not see.

Builders adding copilots or RAG pipelines gain a practical way to enforce authorization before retrieval, reducing a common source of data leakage in AI features.

What happened

Cryptocurrency exchange Bitget resumed Bitcoin withdrawals after suspending them following a breach in which suspected North Korean hackers stole approximately $387.5 million from hot and warm wallets.

Attackers compromised a critical backend system in the wallet infrastructure, spoofed transaction data, and triggered unauthorized transfers across multiple chains (Ethereum, XRP Ledger, Arbitrum, Avalanche, Optimism, BSC, Base, and others) without stealing private keys. Initial estimate was $351.6 million; on-chain tracing raised it to $387.5 million. CEO Gracy Chen cited IP patterns and on-chain behavior consistent with DPRK groups. The incident is contained, user balances remain covered by the Protection Fund, and a recovery bounty program is active.

Who is affected

Bitget users whose withdrawals were paused; the exchange itself lost funds from hot/warm wallets. Trading and deposits continued. No indication of widespread individual account drains beyond the platform wallets.

Phased resumption: BTC first, then ETH networks, USDT, and remaining assets/fiat/P2P on subsequent days.

Why it matters

A nearly $400 million theft from a major exchange via backend spoofing (not key theft) shows that wallet infrastructure and authorization logic remain high-value targets for state-linked actors.

Users face temporary liquidity freezes even when balances are protected. Operators of exchanges and any service handling hot wallets must assume sophisticated adversaries will target internal transfer authorization paths.

How it could have been prevented

Bitget stated it has fixed the exploited vulnerability. Other exchanges should audit backend authorization flows for transaction spoofing, enforce multi-party approval and anomaly detection on large or unusual hot-wallet movements, and maintain robust insurance or protection funds.

Users should enable all available account security features, withdraw to self-custody when practical, and monitor official status channels during incidents. On-chain tracing and bounty programs aid recovery but do not replace prevention.