Trending Topics

CISA Flags New Windows Shell Zero‑Day Under Active Exploitation

CISA has issued an urgent alert about a newly identified Windows Shell zero‑day that attackers are actively exploiting, adding the flaw to its KEV catalog and putting federal agencies on a short deadline to respond. Tracked as CVE‑2026‑32202, the vulnerability stems from a weakness in how Windows enforces certain security boundaries inside the shell, a design issue mapped to CWE‑693 that allows attackers to bypass expected protections once they gain an initial foothold. While the bug does not provide direct remote access on its own, it enables local or low‑privilege attackers to chain together actions to achieve more powerful actions on compromised systems, making it a useful building block in real-world intrusion campaigns. According to public reporting, CISA’s decision to list CVE‑2026‑32202 in the KEV catalog indicates that the agency has evidence the flaw is already being used in active attacks, alongside other Microsoft zero‑days affecting components such as the Windows Shell, the HTML engine, and Remote Desktop. Under Binding Operational Directive 22‑01, Federal Civilian Executive Branch agencies must either apply vendor fixes or implement approved mitigations by a specified deadline, reflecting concern that adversaries will exploit this weakness in ransomware and data theft operations if it remains unpatched. The advisory notes that these shell and privilege escalation issues often appear in multi‑step kill chains, where an attacker begins with phishing or a web shell, then leverages local bugs to escape sandboxes, gain SYSTEM‑level control, or disable defensive tooling, significantly raising the impact of otherwise “minor” footholds. Organizations should treat CVE‑2026‑32202 and the related Windows zero‑days as priority patch items, especially on internet‑facing systems, Remote Desktop gateways, and high‑value servers, where local access could quickly escalate to a full-environment compromise. Where patching cannot happen right away, teams should tighten access to shell‑exposed interfaces, restrict local admin use, and increase monitoring for signs of privilege escalation, unusual shell activity, or chained exploitation involving Microsoft Defender and Task Host components that have also been under active attack.

Critical GitHub Flaw Could Have Opened Millions of Repositories to Hijacking

A recently disclosed GitHub design weakness shows how fragile repository identity can be and how easily attackers could have hijacked popular codebases at scale. Researchers uncovered a race condition in GitHub’s “namespace retirement” mechanism, the feature intended to protect popular projects when their owners rename or delete their accounts. The logic that retires a namespace like user/repo after a username change could be bypassed with carefully timed operations, allowing an attacker to recreate that same user/repo path under a different account and silently take over its identity. Because many ecosystems treat the GitHub path as the canonical source for Go, Swift, PHP, and GitHub Actions, this kind of “repojacking” opens the door to wide-scale supply-chain attacks against downstream users. Checkmarx’s analysis found that exploiting the issue, combined with automated tools, would have enabled hijacking more than 4,000 code packages across multiple languages and CI/CD workflows, including hundreds of high-profile projects with over 1,000 stars each. Previous studies by Aqua Security and VulnCheck had already warned that millions of repositories are structurally vulnerable to repojacking when owners rename or delete their accounts, but this new exploit path showed that even GitHub’s protections for “popular” namespaces could be bypassed. The attack sequence is conceptually simple: wait for a maintainer to rename their username, race to re-register the old username and create a repository with the same name, and suddenly the old, trusted URL points to the attacker’s code rather than the original project. GitHub has since patched the flaw, but the research highlights that namespace and identity bugs can have a cascading impact far beyond any single repository. For organizations that depend heavily on open source, the incident is another reminder that repository trust cannot hinge solely on a URL and that automation can amplify even subtle platform bugs into large-scale risk. Security teams should treat repojacking as a realistic supply chain threat and adopt practices that reduce that risk, such as pinning dependencies by commit hash or release digest instead of just owner/repo@version, monitoring for sudden ownership or URL changes in critical dependencies, and using internal mirrors or registries for the most sensitive components. Developers should also be aware that renaming or deleting GitHub accounts can unintentionally expose their old namespaces to takeover if protections fail or new bypasses are discovered. Combined with the already massive problem of leaked secrets on GitHub, where tens of millions of credentials are exposed in public repos each year, namespace hijacking represents another way attackers can turn the convenience of modern development practices into a powerful avenue for compromise.

LiteLLM Pre‑Auth SQL Injection Turns AI Gateway into a Single‑Hop Path to Cloud Keys

A critical SQL injection flaw in LiteLLM, tracked as CVE‑2026‑42208, has been exploited in the wild within roughly 36 hours of public disclosure, underscoring how quickly attackers now move against AI infrastructure. LiteLLM is a popular open-source AI gateway that fronts providers like OpenAI, Anthropic, and AWS Bedrock, and the bug sits in the proxy’s API key verification path, where the value from an Authorization header was concatenated directly into a database query rather than passed as a parameter. Because that check runs before authentication completes, any remote client that can reach LiteLLM’s HTTP port can send a crafted request to trigger the injection, read from the proxy’s database, and potentially modify key records, all without valid credentials. The maintainers patched the issue in version 1.83.7‑stable on April 19, 2026, but telemetry from Sysdig shows the first exploitation attempt hitting a production instance on April 26, about 26 hours after the advisory was indexed in the GitHub Advisory database and picked up by scanners. Rather than a generic SQLMap spray, the attacker ran a focused series of UNION-based queries aimed at three specific tables: litellm_credentials, which stores upstream model provider keys; litellm_config, which can hold environment variables and runtime secrets; and the verification token table used for virtual API keys. Notably, there were no probes against user or team tables, suggesting the operator already understood LiteLLM’s schema and was interested solely in high-value secrets that could unlock cloud accounts and provider consoles. Security researchers warn that the blast radius from a successful exploit is closer to full cloud-account compromise than to a typical web app SQL injection. A single row in the credentials table can bundle an OpenAI organization key with a five‑figure monthly spend cap, an Anthropic workspace admin key, and an AWS Bedrock IAM credential, all for a single LiteLLM instance. Organizations running vulnerable versions (>= 1.81.16 and < 1.83.7) should assume that any internet-exposed gateway may have been probed and treat stored keys and tokens as compromised until rotated. Immediate steps include upgrading to 1.83.7 or later, rotating all provider and cloud credentials stored in LiteLLM, tightening network access to the gateway, and adding specific monitoring for suspicious Authorization headers and anomalous database reads from LiteLLM, since AI gateways are rapidly becoming high-value targets rather than just plumbing for model traffic.

Lotus Wiper Shows How Quiet Intrusions Can End in Catastrophic Destruction for Energy Operators

A newly discovered malware called Lotus Wiper has been linked to highly targeted attacks on Venezuela’s energy and utilities sector, offering a stark example of how long-running intrusions can end in pure destruction rather than extortion. Researchers at Kaspersky report that the campaign, which unfolded in late 2025 and early 2026, used two carefully staged batch scripts to prepare victim environments before unleashing the wiper on core systems supporting oil and power operations. Once active, Lotus Wiper disables recovery mechanisms, overwrites physical drives, and systematically deletes files across volumes, leaving Windows systems in an unrecoverable state with no ransom notes, no negotiation channel, and no obvious financial motive. The attack chain is notable for its coordination and apparent knowledge of the victim environment. Initial batch scripts, including one dubbed OhSyncNow[.]bat, sweep through specific folders, shared drives, and even legacy Windows paths, checking for trigger files and conditions that indicate the right moment to strike. They then weaken defenses by stopping services, disrupting normal operations, and pushing wiper components across network shares so that multiple systems can be hit in a synchronized wave. The final payload masquerades as a system-like executable that decrypts and runs the Lotus Wiper implant with elevated privileges, erasing restore points, clearing volume journals, and destroying data on attached drives. Analysis of the scripts suggests the attackers had been in the domain long before the destructive phase, tailoring their tools for older Windows versions still present in the environment and aligning the strike with a period of heightened malware activity against Venezuelan energy firms. For energy and utility operators worldwide, Lotus Wiper is another warning that destructive operations against critical infrastructure are no longer theoretical. The fact that the malware was compiled months before it was uploaded to a public platform and appears to target specific organizations, including Venezuela’s state oil company PDVSA, underscores how these campaigns are premeditated and customized rather than opportunistic. Defenders in similar sectors should prioritize hardening domain shares and NETLOGON paths, monitoring for unusual use of native tools such as fsutil, robocopy, and diskpart, and closely watching for signs of privilege escalation and token abuse that often precede a wiper deployment. Just as importantly, they need to validate that backups are both logically segregated from production and regularly tested for restoreability, since in a Lotus-style scenario, the only realistic path to recovery is rebuilding from clean, offline copies after the malware has rendered affected systems unusable.

Lazarus Group Turns macOS Users into a Prime Target for Crypto Theft

North Korea’s Lazarus Group is running a new macOS-focused campaign that targets high-value targets in crypto and finance by turning ordinary business workflows into attack-delivery channels. Rather than relying on classic exploits, the operation leans on social engineering, using hijacked Telegram accounts to send urgent fake meeting invitations that appear to be for Microsoft Teams, Zoom, or Google Meet sessions. Victims, often executives and engineers at crypto exchanges, fintechs, or investment firms, are redirected to convincing lookalike meeting pages where they are told to paste a “connection fix” command into the macOS Terminal, unknowingly launching the compromise themselves. Once run, that command pulls down and installs a native malware toolkit known as “Mach-O Man,” a macOS-specific package designed to blend into normal system activity while quietly harvesting sensitive data. Researchers say the malware targets browser passwords and cookies, macOS Keychain items, Telegram session data, VPN profiles, and credentials and secrets linked to desktop- and browser-based crypto wallets, giving attackers everything they need to drain assets and pivot deeper into corporate environments. The campaign builds on years of Lazarus investment in Apple platforms, following earlier AppleJeus and crypto-themed macOS malware, and aligns with broader reporting that the group has shifted heavily toward stealing digital assets to fund North Korea’s sanctions-evading programs. For macOS-heavy organizations, especially those in crypto and financial services, this is a clear signal that “Mac-first” environments are no longer a safety net against advanced threat actors. Security teams should treat unsolicited “fix your connection” or “run this command” instructions as a red flag, enforce policies that prohibit users from pasting unknown commands into Terminal, and ensure macOS EDR is tuned to catch user-launched scripts and new unsigned binaries, not just traditional exploit chains. It is equally important to harden and monitor access to password managers, browser storage, Keychain, and wallet software on macOS endpoints, since Lazarus targets these layers to bypass MFA and gain durable access to both funds and internal systems.