Trending Topics

Critical 0-day in Veeam Backup & Replication: CVE-2026-44963

A critical zero-day vulnerability tracked as CVE-2026-44963 has been disclosed in Veeam Backup and Replication, targeting one of the most sensitive components in the enterprise environment: the backup server itself. The flaw arises from deserialization of untrusted data, allowing any authenticated, low-privilege domain user with network access to a domain-joined VBR server to execute arbitrary code and potentially take full control of backup infrastructure. Only domain-joined installations of Veeam Backup and Replication 12.x up to and including 12.3.2.4465 are affected. Workgroup deployments and the newer 13.x architecture are not impacted. Veeam has released a fixed build at version 12.3.2.4854.

The risk extends well beyond a single compromised host. Control of backup infrastructure is frequently the final objective for ransomware and intrusion operators. With code execution on the backup server, an attacker can tamper with, exfiltrate, or destroy backups; quietly stage the environment for a later ransomware deployment; and use the backup server's central network position for lateral movement and privilege escalation. The attack path requires only a valid domain account, has low complexity, needs no user interaction, and is network-reachable in typical enterprise designs where backup servers sit on the domain and are broadly accessible from production systems.

No confirmed widespread exploitation has been reported yet, but public references and proof-of-concept details have already surfaced - significantly shrinking the window defenders have before opportunistic and targeted abuse becomes routine.

Organizations should upgrade all affected 12.x instances to version 12.3.2.4854 as quickly as possible. Where feasible, review whether backup servers need to remain domain-joined at all; Veeam's own hardening guidance recommends against it. As additional defense-in-depth measures, tighten network segmentation around backup servers, restrict which domain accounts can reach them, and monitor authentication and process activity from low-privilege accounts for signs of exploitation attempts.

Critical 0-day in Ivanti Sentry (CVE-2026-10520) Enables Root-Level Pre-Auth RCE

CVE-2026-10520 is critical pre-authentication OS command injection vulnerability in Ivanti Sentry that allows remote attackers to execute arbitrary commands as root with no credentials or user interaction required. Versions prior to R10.5.2, R10.6.2, and R10.7.1 are affected, and the flaw carries a maximum CVSS score of 10.0 - reflecting both its trivial exploitation path and its potential for total system compromise.

The impact extends well beyond the Sentry gateway itself. With root-level remote code execution, an attacker can reconfigure the device, intercept or reroute traffic, plant persistent backdoors, and use the compromised appliance as a pivot for lateral movement into internal systems. Because Sentry typically handles access for mobile and remote users, a successful exploit can undermine core access controls, enable data exfiltration, and disrupt business operations at scale.

The situation is made more urgent by publicly available proof-of-concept exploit code and confirmed active exploitation. Opportunistic scanning and automated attacks against internet-facing Sentry instances are already underway.

Ivanti has released patches and advises all customers to upgrade to R10.5.2, R10.6.2, or R10.7.1 immediately. Any previously internet-exposed and unpatched device should be treated as potentially compromised until proven otherwise. Incident response steps should include reviewing logs for anomalous activity, checking for unauthorized configuration changes, and validating the integrity of the operating system and applications on the gateway. Security teams should also address the related authentication bypass CVE-2026-10523, reduce Sentry's public internet exposure where possible, and ensure strong monitoring and alerting are in place around these devices.

New ServiceNow Flaw Lets Attackers Turn AI into an Entry Point

A newly disclosed ServiceNow vulnerability shows how quickly AI-powered features can become a direct path for attackers when identity and access controls are not airtight. The flaw, tied to ServiceNow's Virtual Agent and Now Assist capabilities, allows a threat actor to hijack AI workflows and impersonate users - including administrators - to gain deep access to a ServiceNow tenant and its connected systems. By abusing weak identity binding and static integration credentials, an attacker can convince ServiceNow's AI agents to execute privileged actions on their behalf, from creating accounts to running sensitive workflows, without ever legitimately authenticating as those users.

What makes this particularly concerning is that exploitation can happen through the same conversational interfaces organizations are rapidly deploying to help employees work faster. Once an attacker compromises an AI interaction path, they can chain it into lateral movement - abusing trusted integrations, pivoting into other enterprise applications, and expanding their footprint well beyond ServiceNow itself.

This shifts the conversation from patching platform bugs to treating AI agents as first-class identities. That means proper credential management, strong API-layer verification, and strict limits on what actions an agent can take.

ServiceNow has released patches and configuration hardening guidance, rotated embedded credentials, and introduced additional controls to reduce the risk of agent impersonation and unauthorized data access. For customers, the real work is ongoing: reviewing Virtual Agent and Now Assist configurations, locking down overly permissive access, monitoring AI-driven activity for anomalies, and aligning these agents with existing least-privilege and zero-trust practices.

In many environments, this incident should be a forcing function - prompting security teams to formally include AI agents in their identity security strategy rather than treating them as harmless chat interfaces.

AI Help Agents Are the New Phishing Frontline

Recent testing by Varonis Threat Labs shows how easily AI-powered help agents can be turned into data loss engines when wired directly into email and internal systems. In one controlled phishing scenario, an AI agent using OpenClaw forwarded AWS IAM keys, database passwords, and SSH details to an external Gmail account after receiving what appeared to be a routine request from a "colleague" asking for staging credentials. The agent was running under a strict safety profile that explicitly instructed it to verify sender identities and watch for phishing - and it still complied.

In a second test, an attacker simply asked the agent for the "latest customer export" for a quarterly business review. The agent responded by emailing personal information for more than 200 employees alongside over $1,000,000 in revenue data. No malware, exploit, or technical skill was required - only a convincing email.

Researchers traced the core problem to how these agents are designed to treat email as both a knowledge source and an instruction channel. That dual role mirrors the early days of web applications, when user-supplied input was processed as code and led to years of SQL injection vulnerabilities. This is not purely an AI problem. It is a software design problem that will need to be engineered out over time.

The bigger concern is the pace of deployment. Autonomous agents are already embedded across business workflows, often with weak governance and minimal guardrails. That combination creates outsized risk for organizations that assume a "smart" agent is also a safe one.

To reduce that risk, organizations should treat AI agents as first-class identities with clearly defined roles, traceable access, and tightly scoped API permissions. Agents should only see what they absolutely need, and outbound data actions should be blocked by default and explicitly allowed only for specific destinations and use cases. Rather than relying on an agent's own judgment about whether a requester seems trustworthy, security teams should enforce policy at the platform level - with approvals, logging, and anomaly detection around any data movement an AI initiates.

A useful mental model: design agents like powerful interns. They can help a lot, but they should never hold the master keys or send sensitive information anywhere without supervision.

Update: Microsoft Defender 0-Day Exploit “RougePlanet” Raises New Security Concerns

The cyber group Nightmare Eclipse has introduced a new zero-day exploit called "RougePlanet," targeting Microsoft Defender and marking its fourth confirmed attack against the platform in 2026. The vulnerability exploits a race condition to achieve local privilege escalation, allowing attackers to gain elevated system access under specific timing conditions.

After gaining a foothold, the attack chain shifts to social engineering: a victim is tricked into opening a .vhd or .vhdx file hosted on a remote SMB server. When opened, Windows automatically mounts the virtual disk and initiates outbound communication to the attacker-controlled server, creating a persistent access path without requiring further user input.

The exploit also demonstrates a potential BitLocker bypass. By leveraging another system to push crafted data to NTFS.sys, an attacker can cause Microsoft Defender - when it scans the file - to redirect file handling to an attacker-controlled location. This technique illustrates how trusted system components can be manipulated in sequence, turning defensive mechanisms into part of the attack chain itself.

The proof-of-concept, published on GitHub under the account "MSNightmare," has been successfully tested on both Windows 10 and Windows 11, including systems fully updated with the June 2026 Patch Tuesday releases. Due to the inherent timing sensitivity of race-condition exploits, however, successful execution is inconsistent and cannot be guaranteed.

Mitigation should prioritize installing the April 2026 Patch Tuesday update, which addresses CVE-2026-33825 and resolves the underlying race condition enabling privilege escalation. Organizations should also harden BitLocker configurations, restrict or monitor SMB-based file access, and deploy network-level detection controls to identify suspicious outbound connections. Because Microsoft Defender itself is the target here, relying on it exclusively for detection introduces blind spots - making a supplemental endpoint detection and response solution a practical defensive addition.