Critical Patches, Supply Chain Risks, and a New Ransomware Campaign

Microsoft Patches CVSS 10.0 Flaw in Azure AI Foundry

Microsoft closed out a maximum-severity privilege escalation bug in Azure AI Foundry this month, part of a broader batch of critical cloud-service fixes.

What You Need to Know

Microsoft has fully remediated CVE-2026-85889, a CVSS 10.0 vulnerability in Azure AI Foundry (also known as Microsoft Foundry) that let an unauthenticated attacker escalate privileges over the network. The root cause was missing authentication on a critical function. Because Microsoft mitigated the issue at the service level, customers don't need to patch or take any direct action, but the disclosure came alongside several other high-severity cloud flaws worth tracking.

What's Vulnerable

Azure AI Foundry is Microsoft's platform for building, deploying, and managing generative AI applications and agents, which makes a privilege escalation bug here particularly consequential. A successful attacker could reach beyond their intended authorization scope into sensitive data, AI workloads, connected services, or administrative functions. Security researcher Rémy Marot is credited with discovering and reporting the flaw, and there's no evidence of exploitation in the wild.The same disclosure batch included CVE-2026-85885, a CVSS 9.9 command injection flaw in Microsoft 365 Copilot; CVE-2026-85878, a CVSS 9.9 improper authorization issue in Azure Database for PostgreSQL; and CVE-2026-87701, a CVSS 9.6 improper neutralization vulnerability in Azure Cosmos DB. Microsoft says it also fully mitigated all of these on its end.

Why This Matters

It's easy to read "fully mitigated, no action needed" and move on, but that's exactly the moment to double-check your own assumptions about what's exposed. AI agent platforms increasingly sit close to sensitive data and connected services, so a privilege escalation bug here has a wider blast radius than a typical cloud misconfiguration.

What to Do

No patching is required, but security teams should still review asset inventories to confirm reliance on Azure AI Foundry and the other affected services, validate that service ownership and access controls are current, and monitor Microsoft's advisories in case the exploitation status changes. This is also a good prompt to reinforce the basics across your Microsoft cloud environment: least-privilege access, MFA, and solid logging and monitoring.Cloud-provider patches don't remove the need for good hygiene on your side of the shared responsibility line.

Check Point Patches Critical Root RCE in Management Servers

Check Point has shipped fixes for a critical, unauthenticated remote code execution flaw that hits the servers organizations use to manage their own firewalls.

What You Need to Know

CVE-2026-91843 is a critical stack-based buffer overflow in the login process of Check Point Security Management Server and Log Server deployments. It lets an unauthenticated attacker execute code remotely with root privileges, with low attack complexity and no user interaction required. Every Security Management Server deployment is vulnerable regardless of configuration, including environments where VPN capabilities aren't even enabled.

What's Vulnerable

Security Management Servers are high-value targets because they centrally control firewall policy, gateway configurations, administrator accounts, and security event visibility. Root-level remote code execution on one of these systems could let an attacker rewrite security policy, push malicious configurations to managed gateways, pull sensitive logs, establish persistence, or outright interfere with incident response. Check Point Log Server installations are affected too, and they often hold valuable operational and security data.This follows other recently disclosed Check Point vulnerabilities: CVE-2026-85102, an authentication bypass and RCE issue in firewalls, and CVE-2026-85103, a heap overflow in VPN certificate ASN.1 decoding. No confirmed exploitation of these three yet, but Check Point products have been an active target lately, including a Qilin ransomware affiliate exploiting the CVE-2026-50751 authentication bypass 0-day and separately exploiting CVE-2026-16232 to gain admin privileges through SmartConsole.

Why This Matters

A management server compromise doesn't just affect one box; it potentially hands an attacker control over your entire firewall fleet and the visibility you'd normally rely on to catch them. Given Check Point's recent run of actively exploited flaws, this isn't a theoretical risk category for their customer base.

What to Do

Deploy the applicable Check Point LivePatch or vendor update as soon as possible. Where immediate patching isn't feasible, restrict management access to trusted IPs and subnets through the Trusted Clients configuration in SmartConsole. Review Audit and Admin login logs for the string "Administrator failed to log in: Username too long," which Check Point flagged as a potential exploitation indicator. Treat any externally exposed management interface as an urgent remediation target, locked down with network segmentation, VPN controls, allowlisting, and MFA.Validate patch status across every gateway, management server, and log collector, then keep watching for unexpected policy changes and odd administrator activity.

Plugin4Shell Undermines Plugin Pinning in AI Coding Agents

Researchers have found a way for a malicious repository owner to swap out a reviewed, pinned plugin for something else entirely, and several major AI coding agents were affected.

What You Need to Know

Plugin4Shell is a plugin supply-chain weakness affecting Claude Code, OpenAI Codex, GitHub Copilot, and Google Gemini CLI. It lets a repository owner substitute a reviewed, pinned plugin version with malicious code under specific conditions, which quietly defeats the whole point of commit pinning. No CVE has been assigned, and there's no evidence of exploitation, but the mechanism is worth understanding if your team relies on AI coding agent plugins.

How the Attack Works

The technique exploits Git behavior on hosting platforms that allow branch or tag names resembling commit hashes. An AI agent may fetch a plugin tied to a specific commit hash, but fail to verify that what actually gets installed matches that commit. A malicious or compromised repository owner can create a branch named to match the requested hash and redirect it to attacker-controlled code; the agent installs the substitute while still reporting that it used the approved commit. GitHub isn't vulnerable to this specific technique because it blocks branch and tag names that resemble commit hashes. Still, third-party Git hosts like Bitbucket and self-hosted infrastructure remain exposed.The impact is real because plugins run with the permissions of whoever's running the agent, potentially exposing source code, local files, credentials, API tokens, cloud configuration, and any authenticated services on that machine. Automatic plugin updates raise the stakes further, since a previously trusted plugin could get swapped out without the user approving anything new. Vendor response has varied: Anthropic fixed the issue in Claude Code 2.1.179, OpenAI fixed it in Codex 0.146.0 by tightening Git reference validation, GitHub Copilot had no fix at disclosure time, and Google isn't planning to patch the consumer Gemini CLI, which is being phased out in favor of Antigravity.

Why This Matters

Commit pinning exists specifically to guarantee you're running the exact code that was reviewed. A bypass like this quietly erodes that guarantee. Because plugins inherit the developer's full local permissions, a single substituted plugin can turn into a foothold across source code, credentials, and cloud access.

What to Do

Update Claude Code and Codex to the patched versions. Limit plugin installation to trusted, GitHub-hosted marketplaces where possible, and avoid pulling plugins directly from unverified external repositories. Review your existing plugin set, disable optional automatic updates for externally sourced add-ons, and start treating AI agent plugins like any other privileged software dependency: subject to code review, provenance checks, least-privilege execution, MFA-protected source control access, and ongoing monitoring.Plugin ecosystems for AI agents are new enough that the trust assumptions haven't fully caught up with the risk yet.

PhantomRaven npm Campaign Ties Info-Stealing to Bogus Bug Bounty Claims

A financially motivated actor used more than 100 malicious npm packages to steal developer credentials, and may have repackaged that access as legitimate bug bounty findings.

What You Need to Know

CrowdStrike has linked the JavaScript-based PhantomRaven information stealer to an actor who presented themselves as a bug bounty hunter. The campaign used over 100 malicious or typosquatted npm packages to steal authentication tokens, CI/CD secrets, GitHub credentials, and environment data from developers. It's a reminder that supply-chain compromise isn't only used for straightforward credential theft; it can also become the access an actor later dresses up as a "responsibly reported" vulnerability.

What Happened

PhantomRaven packages hid their payloads by fetching a remote dynamic dependency from an attacker-controlled server, which kept the malicious code largely invisible to developers and automated scanners reviewing the package upfront. Once installed, the payload collected public IP addresses, usernames, email addresses, Git and npm configuration data, system fingerprints, runtime details, and CI/CD environment variables tied to GitHub Actions, GitLab CI, Jenkins, and CircleCI.The operator appears to have been active since at least November 2022 and allegedly claimed bounty rewards from at least nine organizations spanning technology, retail, and hospitality. CrowdStrike didn't find PhantomRaven data being sold on stealer-log marketplaces, leading researchers to assess that the malware may have been used primarily to surface rewardable weaknesses in compromised environments rather than for resale. Researchers also assess with high confidence that the actor used an LLM to help write the malware, citing verbose comments and placeholder code patterns. The actor was tied to multiple npm identities, including jpd12, jpd13, npmhell, npmpackagejpd, npmtestdharsh, jpdhackerone11, and packagedharsh, and at least two of those accounts are no longer accessible.

Why This Matters

This blurs a line that bug bounty programs depend on: the difference between authorized testing and unauthorized access dressed up after the fact. If your organization runs a disclosure or bounty program, this is a concrete example of why "how did you find this" deserves real scrutiny, not just a rubber stamp.

What to Do

Inventory your npm dependencies and remove anything unmaintained or unnecessary. Watch for packages that download or execute remote code post-install; that's the exact pattern PhantomRaven used. Apply least-privilege permissions to CI/CD tokens, rotate anything potentially exposed, and restrict outbound network access from build systems. If you run a bug bounty or vulnerability disclosure program, validate that reported findings came from authorized testing and look for signs that access actually came from compromised developer systems or malicious dependencies.Open-source dependencies and CI/CD pipelines are initial-access vectors now, not just build tooling.

Feral Wolf Hits Confluence and 1C Deployments with GenieLocker Ransomware

A threat actor has been chaining exposed collaboration and ERP software into full ransomware deployments against Russian organizations.

What You Need to Know

The Feral Wolf threat actor compromised exposed Atlassian Confluence servers and insecure 1C: Enterprise deployments between May and August 2026, then deployed GenieLocker ransomware against retail, construction, manufacturing, and IT-sector organizations in Russia. Investigators point to a combination of publicly exposed software, weak credentials, thin administrative controls, and container-to-host lateral movement as the enabling factors.

How the Attack Works

One intrusion path started with an internet-accessible Confluence instance running in a Docker container, exploited through CVE-2023-22515. After gaining access, Feral Wolf created an administrative account, installed a malicious plug-in, and used command execution to deploy the GSocket reverse-connection utility, disguised with Linux kernel-like process names such as "[kcached]" and "[rcu_preempt]" and configured to run over TCP port 53 to blend in with DNS traffic. A second GSocket instance served as a fallback channel. To break out of the container, the group used exploits for CVE-2021-4034 (PwnKit) and CVE-2026-31431 ("Copy Fail"), then used fscan to find exposed services and landed on a PostgreSQL instance secured with the weak credential postgres:12345678, which let them pivot from the application container to the Docker host.A second path targeted externally accessible 1C: Enterprise cluster-management services directly, connecting to the cluster-manager on TCP port 1541 and interacting with 1C processes on ports 1570 and 1571. Missing administrator controls or debug-mode configurations allowed operators to perform administrative actions without proper authentication. From there, they used 1C-Shell database dumps and malicious external processing files to run OS commands, and attempted local privilege escalation with PrintSpoofer. For credential access, they used Magnet DumpIt to capture physical memory and MemProcFS to pull LSASS-related artifacts from the dump, avoiding more easily flagged credential-dumping tools.The group also relies on two Rust-based backdoors, MQTTDoor and MatrixDoor, which execute commands via PowerShell or CMD while using public MQTT and Matrix infrastructure for command-and-control, plus RDPSocksProxy for SOCKS4/5 tunneling over an RDP Dynamic Virtual Channel.

Why This Matters

Nothing in this chain relies on a novel technique. It's exposed software, weak passwords, and known privilege escalation bugs, strung together patiently enough to end in ransomware. That's exactly the profile that's easy to dismiss as low-sophistication and easy to miss until it's a full-blown incident.

What to Do

Prioritize patching exposed Confluence systems and restrict external access to 1C cluster-management services entirely where possible. Disable unnecessary 1C debug functionality and enforce strong credentials on PostgreSQL and other administrative services; the weak postgres:12345678 password was the pivot point in this campaign. Hunt for unexpected GSocket binaries, altered shell-profile files, suspicious services like cplsupport and wtas, memory-dump activity, and outbound connections to public MQTT brokers or Matrix homeservers.Exposed management interfaces and default credentials are still doing most of the work for attackers, even in a campaign this involved.