Daily Cybersecurity News – October 19, 2026

What happened

Threat actors began targeting the Plex2Shell exploit chain against internet-facing Plex Media Server instances roughly one day after a researcher published technical details and working proof-of-concept code on October 16.

The chain combines four flaws tracked as CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656. Together they enable unauthenticated arbitrary code execution on exposed servers, with the payload running under the privileges of the Plex service. A researcher monitoring a honeypot running a vulnerable build first saw in-the-wild use on October 17. Attackers delivered an XMRig-based cryptocurrency miner and later dropped proxy software identified as myawesomeproxy.

Who is affected

Operators of Plex Media Server versions before 1.43.3.10861, especially any instance left reachable from the public internet. Plex confirmed the issues after a July report, shipped fixes, and urged upgrades starting September 1. Home and small-lab servers are common targets because many run on residential connections.

Why it matters

Successful exploitation installs resource-consuming miners and residential proxy software. The latter can turn a home IP into a hop for later attacks against corporate VPNs or email, expanding the value of each compromised host far beyond simple crypto mining.

Media servers are frequently exposed for remote access and often run with limited monitoring, giving attackers a quiet foothold.

How it could have been prevented

Upgrade every Plex Media Server to 1.43.3.10861 or newer without delay. Remove direct internet exposure; place the service behind a VPN, authenticated reverse proxy, or zero-trust access control.

Monitor processes and outbound connections for unexpected miners or proxy binaries, and review any published honeypot indicators of compromise while treating them as incomplete.

What happened

A fake Web3 venture accelerator calling itself Apex Accelerator (tracked as REF8801) has been distributing information-stealing malware and backdoors through malicious npm packages. The packages were promoted to cryptocurrency startups and founders with offers of free AI credits for Claude and Gemini, coding tools, and security audits.

Elastic Security Labs identified packages including @apexacc/cli and @apexacc/audit that target both Windows and macOS. Earlier related packages delivered Atomic Stealer (AMOS). The operation also repackaged a legitimate coding agent to redirect model traffic through attacker infrastructure and produced fabricated audit findings. Russian-language comments appeared in commit history, though attribution remains unconfirmed. Associated domains and GitHub accounts have since been taken down.

Who is affected

Cryptocurrency founders, wallet developers, and Web3 teams who installed the advertised npm packages or ran the supposed due-diligence and audit tools. Both Windows and macOS endpoints are targeted. The campaign has been active in waves since at least April 2026 under Apex Foundation branding.

Why it matters

Supply-chain lures that blend investment promises with free AI and security tooling are highly effective against startup developers who routinely install new packages. Once on the machine the malware steals credentials, crypto keys, and session data while the hijacked AI agent path lets attackers observe or manipulate sensitive development traffic.

Fabricated audit results can also create false confidence in insecure contracts or wallets.

How it could have been prevented

Treat unsolicited investment or free-tool offers with extreme skepticism. Verify npm publisher accounts and package reputation before install, pin dependencies with lockfiles, and scan new packages with multiple malware and secrets detectors.

Run development tools inside isolated environments or containers, prefer official package sources, and monitor for unexpected outbound connections or new persistence after any npm install.

What happened

Security researcher Quentin Kaiser disclosed a flaw in Broadcom’s Wi-Fi Protected Setup (WPS) implementation that lets an attacker within radio range achieve root code execution on affected routers without knowing the network password or completing any pairing step.

The bug mishandles reassembly of fragmented WPS messages, enabling memory corruption. Kaiser demonstrated reading the Wi-Fi PSK from an Orange Belgium Askey TCG3000 gateway and opening a reverse shell over the air on a Proximus Sagemcom BBOX3V+. No CVE has been assigned and no patches have been deployed to the tested devices. He reports no evidence of real-world exploitation yet; the working exploits are his own. The vulnerable code dates to at least 2010.

Who is affected

Routers and access points using Broadcom Wi-Fi chips in the older eCos families (BCM3380, BCM3383, BCM33834) and newer Linux-based families (BCM3390, BCM65xx, BCM68xx). Kaiser estimates millions of devices worldwide. In Belgium the flaw was confirmed on gateways from Proximus, Orange Belgium and VOO, representing hundreds of thousands of subscribers; a wider vendor list includes Cisco, Huawei, ARRIS and others at varying confidence levels.

Why it matters

An attacker needs only radio proximity, not credentials or physical access, to take full control of the gateway. That control yields the Wi-Fi password, local network traffic, and a persistent foothold that can pivot into every device behind the router.

On older eCos chips the issue is described as a forever-day with no usable fix ever shipped, leaving large installed bases permanently exposed.

How it could have been prevented

Disable WPS on every router where the option exists. Replace end-of-life or unpatchable Broadcom-based gateways, especially older eCos models. On newer Linux-based hardware press vendors for hostapd migration or firmware updates.

Segment critical devices onto wired or separate SSIDs, monitor for unexpected wireless clients or configuration changes, and treat any Broadcom WPS-enabled device as high risk until proven otherwise.

What happened

ConnectWise suspended several cloud services after discovering unauthorized access to application identities inside its Cloud Backup environment. Investigation of suspicious activity began October 15; by October 17 the company confirmed the access.

The affected services (Cloud Backup, formerly SkyKick, plus SaaS Security and Cloud Management) were taken offline. An attacker possessing the application credential can authenticate as the backup app and obtain tokens that inherit its broad permissions, reaching customer mailboxes, OneDrive, SharePoint, Teams data and directory information. MFA does not apply because the sign-in is application-based. Huntress observed at least one tenant where the attacker assigned themselves Global Administrator and attempted to alter other application permissions. ConnectWise states it has not yet found evidence that partner backup data was taken, but investigation continues. No threat-actor attribution has been given.

Who is affected

Managed service providers and their customers who rely on ConnectWise Cloud Backup, SaaS Security or Cloud Management for Microsoft 365 protection and administration. Any tenant that had granted the ConnectWise application the necessary backup permissions is potentially in scope while the investigation remains open.

Why it matters

Backup and management tools necessarily hold high-privilege, long-lived access to customer M365 environments. Compromise of those application identities bypasses user MFA and can give an attacker the same reach as the legitimate service across mail, files and identity data.

For MSPs the blast radius spans many downstream organizations, turning a single vendor incident into a multi-tenant event.

How it could have been prevented

Follow ConnectWise guidance: verify the status of listed application connections and keep affected apps disabled until official restoration instructions appear. Preserve sign-in and audit logs immediately.

In Microsoft 365 review enterprise applications and service principals for unexpected Global Admin or high-privilege grants, rotate any suspect secrets, enable continuous access evaluation where possible, and monitor for anomalous backup-style activity or permission changes.

What happened

An intruder reached a legacy system at OpenCode on the night of October 16 and may have exposed third-party AI provider API keys that users had stored in OpenCode Console. The company notified the affected subset of users by email on October 17 under the subject “Action Required: Potential provider key breach.”

Console is an optional hosted service where a workspace saves its own OpenAI, Anthropic or Google key so team members can call models without seeing the secret. Only 1.4 % of Console users (those with an external provider linked) are in scope; local keys kept in the OpenCode CLI or desktop SQLite database were not involved. OpenCode described the incident as ongoing and related to a large-scale distillation attack, without providing further technical detail or confirming that any key was actually copied or used. Some users have publicly reported unauthorized billable usage ranging from hundreds to roughly $1,700.

Who is affected

The 1.4 % of OpenCode Console users who had pasted OpenAI, Anthropic or Google API keys into a Console workspace. Users who never received the notification email are stated to be unaffected. Keys stored only on local machines remain outside the breach scope.

Why it matters

Provider API keys are bearer credentials: anyone who possesses a copy can generate billable requests, exhaust quotas, or abuse the account until the key is revoked. Console budgets and deletion of the key from the UI do not stop direct use at the provider.

Developers and teams that centralize keys for convenience therefore face both financial exposure and potential data leakage through model queries.

How it could have been prevented

Immediately revoke every provider key that was ever saved in OpenCode Console and issue fresh keys from the OpenAI, Anthropic or Google dashboards. Update all applications and scripts that referenced the old keys.

Review provider usage and billing logs back to at least October 16 for unrecognized traffic, set hard spend limits and alerts, and assign each tool or environment its own dedicated key so blast radius stays small. Prefer local key storage over hosted Console when practical.

What happened

MITRE released version 20 of the ATT&CK framework, expanding coverage of recent adversary tradecraft with new techniques and sub-techniques focused on AI abuse, MFA bypass and attacks against industrial control systems.

In the Enterprise domain, prompt injection is now tracked in two forms (direct interface instructions and indirect instructions hidden in ingested content), along with abuse of an organization’s own AI agents for data theft, poisoning of web content to influence AI recommendations, and disruption of LLM-assisted malware analysis. Additional entries cover theft of application-specific passwords that skip MFA prompts, CAPTCHA bypass (both automated solving and avoidance), and compromised IDE or coding-agent configuration files. In ICS, new campaign entries document internet-exposed PLC attacks that locked operators out of more than 30 Minnesota water and wastewater utilities, plus an AI-assisted breach that reached a Mexican municipal water utility. Defenders also receive 15 new detection strategies (six Enterprise, nine ICS) supported by 38 analytics.

Who is affected

Security teams, detection engineers, red teams and ICS/OT operators who rely on ATT&CK for threat modeling, detection content and gap analysis. The updates are especially relevant to organizations deploying internal AI agents, LLM tools or internet-facing industrial controllers.

Why it matters

ATT&CK is the common language defenders use to map adversary behavior and prioritize detections. Codifying AI-specific and MFA-bypass techniques gives blue teams concrete IDs and analytics to hunt for tactics that are already appearing in the wild, while the water-utility campaigns highlight the real-world risk to critical infrastructure.

Organizations that lag in updating their ATT&CK-based content will have blind spots around the newest abuse paths.

What happened

SANS ISC handler Didier Stevens published a concise YARA rule that detects orphaned VBA projects embedded inside AutoCAD DWG files. The rule looks for the AutoCAD signature “AC10” at offset zero, a specific 32-bit value at offset 0x24, the OLE compound-file magic bytes, and the ASCII string “[Host Extender Info]”.

A VirusTotal retrohunt with the rule returned only two matching samples, indicating the pattern is currently rare in public corpora.

Who is affected

Organizations that process or receive AutoCAD DWG files, especially those that allow macros or VBA inside engineering drawings. Security teams that already use YARA for file triage or malware hunting can add the rule immediately.

Why it matters

Orphaned VBA projects can carry malicious macros that execute when a drawing is opened in a VBA-enabled AutoCAD environment, yet they may evade simple extension or keyword checks. A lightweight YARA signature gives defenders an inexpensive way to surface these oddities during intake scanning or threat hunting.

Low current hit counts suggest the technique is uncommon, but the rule provides early warning if it spreads.