Daily Digest

Microsoft just dropped an emergency warning: a new zero-day flaw is actively being exploited in Exchange Server attacks. The vulnerability, tracked as CVE-2026-42897, lets attackers execute malicious code through cross-site scripting (XSS) by targeting Outlook on the Web users. If you're running Exchange Server 2016, 2019, or Subscription Edition, your organization is at risk right now. The kicker? There's no patch yet—only temporary mitigations. This is a race against time for IT teams everywhere.

**What exactly happened** On Thursday, Microsoft revealed that a high-severity Exchange Server vulnerability is being actively exploited in the wild. The flaw (CVE-2026-42897) allows attackers to execute arbitrary code via cross-site scripting (XSS) attacks, specifically targeting users of Outlook on the Web (OWA). The company has shared mitigations but no permanent fix yet. This is a classic zero-day scenario: the bad guys are already using it, and defenders are scrambling to catch up. **Who is affected and how** The vulnerability impacts up-to-date versions of Exchange Server 2016, Exchange Server 2019, and Exchange Server Subscription Edition (SE). That means even organizations that have been diligent about patching are still exposed. Attackers exploit this by sending a specially crafted email to a user. If that user opens the email in Outlook Web Access and certain interaction conditions are met, arbitrary JavaScript can execute in the browser context. It's a sophisticated phishing-style attack that doesn't require much from the victim beyond opening an email. **The real-world impact and consequences** The most immediate danger is that attackers can run arbitrary code on the victim's browser. This opens the door to data theft, credential harvesting, and lateral movement within the network. Given Microsoft's track record with Exchange vulnerabilities, this flaw could easily be weaponized in ransomware attacks. Over the past five years, CISA has added 19 Exchange Server vulnerabilities to its actively exploited list—14 of which were abused in ransomware campaigns. The pattern is clear: Exchange servers are prime targets. **Technical breakdown** The vulnerability is classified as a spoofing flaw, but its exploitation relies on XSS. An attacker sends a malicious email to a user. When the user opens it in OWA and meets specific interaction conditions, the attacker's JavaScript runs in the browser context. This isn't a server-side code execution—it's client-side, but the impact is still severe. The attacker can impersonate the user, access their mailbox, and potentially pivot to other systems. **What should be done — mitigation and recommendations** Microsoft's first line of defense is the Exchange Emergency Mitigation Service (EEMS). This Windows service runs on Exchange Mailbox servers and automatically applies interim mitigations for high-risk vulnerabilities. If you have EEMS enabled, it should already be protecting you. For those in air-gapped environments, Microsoft has released the Exchange on-premises Mitigation Tool (EOMT). Admins can apply the mitigation by running a script via an elevated Exchange Management Shell. The commands are straightforward: - Single server: `.\EOMT.ps1 -CVE "CVE-2026-42897"` - All servers: `Get-ExchangeServer | Where-Object { $_.ServerRole -ne "Edge" } | .\EOMT.ps1 -CVE "CVE-2026-42897"` But there's a catch: applying these mitigations breaks some functionality. OWA Print Calendar won't work, inline images may not display correctly, and the deprecated OWA light mode will fail. Microsoft suggests workarounds like using the Outlook Desktop client or sending images as attachments. **Why this matters in the bigger cybersecurity landscape** This isn't just another Exchange vulnerability—it's a reminder that on-premises servers are a persistent attack surface. Even with Microsoft's push to cloud services, many organizations still run Exchange on-premises for compliance, air-gap requirements, or legacy reasons. The fact that patches are only available to customers enrolled in the Period 2 Exchange Server ESU program adds another layer of complexity. Smaller organizations without extended support may be left exposed for longer. CISA and NSA recently released guidance to help harden Exchange servers, but guidance doesn't stop zero-days. The real takeaway? If you're running Exchange on-premises, you need a robust incident response plan, active monitoring, and a willingness to apply emergency mitigations—even if they break some features.

A hacker group called TeamPCP is selling nearly 450 stolen code repositories from Mistral AI for $25,000. The French AI company, known for its open-weight large language models, confirmed the breach stemmed from a wider supply-chain attack that hit hundreds of software projects. If no buyer steps up within a week, the hackers plan to leak the 5GB of internal data for free on forums. This puts Mistral’s proprietary training code and future AI models at risk—and it’s a stark reminder that even top AI labs aren’t immune to supply-chain chaos.

**What exactly happened** TeamPCP, a hacker group with a flair for drama, posted on a forum that they’re selling nearly 450 stolen code repositories from Mistral AI. The price tag: $25,000. If no buyer bites in a week, they’ll leak the data publicly. Mistral AI confirmed the breach to BleepingComputer, tracing it back to the Mini Shai-Hulud software supply-chain attack. That attack first compromised official packages from TanStack and Mistral AI by stealing CI/CD credentials and abusing legitimate workflows. From there, it spread like wildfire across npm and PyPI registries, hitting big names like UiPath, Guardrails AI, and OpenSearch. The hackers contaminated some of Mistral’s SDK packages for a brief period, the company admitted. **Who is affected and how** TeamPCP claims to have swiped nearly 5GB of “internal repositories and source code” used for training, fine-tuning, benchmarking, model delivery, and inference. That’s the guts of Mistral’s AI engine—experiments, future projects, and all. Mistral AI, a French startup founded by ex-DeepMind and Meta researchers, provides both open-source and proprietary LLMs. The breach doesn’t touch hosted services, managed user data, or research environments, but it does expose internal code that competitors could exploit. The hackers are open to negotiations, saying the price is flexible and interested buyers can submit a fair offer. If no deal is struck, the data goes free—a ticking clock for Mistral. **The real-world impact and consequences** For Mistral, this is a reputational and competitive blow. Leaked training and benchmarking code could give rivals a shortcut to replicate or undermine their models. It also erodes trust in their security posture, especially since they’re a high-profile AI player. The broader ecosystem feels the heat too. This isn’t an isolated hack—it’s a ripple from the TanStack supply-chain attack that hit OpenAI, UiPath, and others. OpenAI confirmed two employees had credentials stolen from limited source code repos, though no evidence of further attacks emerged. OpenAI rotated exposed code-signing certificates and warned macOS users to update their desktop apps by June 12 or risk failure. The message is clear: supply-chain attacks don’t discriminate. **Technical breakdown** The breach started with stolen CI/CD credentials from the TanStack attack. These credentials let TeamPCP access Mistral’s codebase management system, where they contaminated SDK packages. The contamination was brief but enough to exfiltrate data. Mistral’s forensic investigation found the impacted data wasn’t from core code repositories. But “internal repositories and source code” for training and inference is still sensitive—it’s the blueprints for their AI models. The hackers likely used legitimate workflows to mask their movements, making detection harder. TeamPCP’s post shows they’re savvy: they’re offering exclusive sale to limit buyers, threatening a free leak to pressure a quick sale. This is a classic extortion play, but with a supply-chain twist. **What should be done — mitigation and recommendations** Mistral has already rotated credentials and patched the compromised systems. But the damage is done—the data is out there. For other companies, the lesson is to audit CI/CD pipelines rigorously. Use multi-factor authentication, monitor for unusual workflow usage, and limit access to sensitive repos. Organizations should also segment their codebase management systems. If a developer device is compromised, it shouldn’t open the floodgates to hundreds of repos. Regular security training for developers on supply-chain risks is non-negotiable. For users of Mistral’s SDKs, check for updates and verify package integrity. The contamination was brief, but it’s a reminder to always validate software sources. **Why this matters in the bigger cybersecurity landscape** This incident underscores how supply-chain attacks are the new frontier of cybercrime. One compromised credential can cascade through hundreds of projects, hitting AI labs, enterprise tools, and open-source registries alike. AI companies are prime targets because their code is gold—training data, model architectures, and proprietary algorithms are worth millions. TeamPCP’s $25k ask is a bargain compared to the potential damage. The bigger picture? No one is safe. From OpenAI to Mistral, the attack surface is expanding, and hackers are getting more creative. The industry needs collective defense—sharing threat intel, hardening CI/CD pipelines, and treating every developer device as a potential entry point.

Microsoft just dropped 118 security fixes for Patch Tuesday, and for once, there are no zero-days being actively exploited. That sounds like good news, but don't let your guard down — 16 of these bugs are rated critical, meaning attackers can hijack your system remotely without you lifting a finger. The biggest headache? A nasty flaw in Windows Netlogon that gives hackers full control over your domain controller. If you're running Windows, Apple, Google, or Mozilla products, your update queue just got a lot longer. This month's patch batch is a reminder that even when the sky isn't falling, the ground beneath your feet might be cracking.

**What exactly happened** Microsoft kicked off May 2026's Patch Tuesday with 118 vulnerabilities patched across Windows and its ecosystem. Sixteen of these carry a "critical" rating, meaning they allow remote code execution with minimal user interaction. Notably, this is the first Patch Tuesday in nearly two years without any zero-days under active attack or publicly disclosed flaws — a rare breather for defenders. But don't mistake calm for safety. The absence of exploited bugs doesn't mean these flaws are harmless. Attackers are already reverse-engineering the patches to weaponize them. **Who is affected and how** Anyone running Windows, Microsoft Office, Exchange, or Azure is in the crosshairs. The most dangerous bug, CVE-2026-41089, is a stack-based buffer overflow in Windows Netlogon. It lets an unauthenticated attacker gain SYSTEM privileges on a domain controller — the crown jewel of any corporate network. Small businesses and enterprises are especially vulnerable because domain controllers manage authentication for entire networks. If one falls, attackers can move laterally, deploy ransomware, or steal credentials at will. **The real-world impact and consequences** Imagine a hacker walking into your office, sitting down at the domain controller, and having full admin access without a password. That's what CVE-2026-41089 enables. No user interaction, no phishing email needed — just a network connection. For organizations that delay patching, the risk is existential. Ransomware groups love these types of bugs because they offer a fast track to domain-wide compromise. Even without active exploitation now, proof-of-concept code will likely emerge within days. **Technical breakdown** CVE-2026-41089 exploits a buffer overflow in the Netlogon Remote Protocol, which handles authentication between computers and domain controllers. By sending a specially crafted request, an attacker can overwrite memory and execute arbitrary code with SYSTEM privileges. The flaw is stack-based, meaning it corrupts the call stack — a common but dangerous vulnerability class. Microsoft rates it as "Exploitation More Likely," signaling that weaponization is probable. No privileges or user interaction are required, making it a wormable candidate in network environments. **What should be done — mitigation and recommendations** Patch immediately. Prioritize domain controllers and any internet-facing Windows servers. If you can't patch right away, restrict Netlogon traffic to trusted networks and monitor for unusual authentication attempts. For home users, enable automatic updates and restart your device. For IT teams, test patches in a staging environment first, then deploy broadly. Don't forget to update browsers and third-party software — Google, Mozilla, and Apple also shipped fixes this month. **Why this matters in the bigger cybersecurity landscape** This Patch Tuesday highlights a paradox: AI is getting better at finding bugs, but humans are still terrible at patching them. The volume of fixes is growing, yet attackers are becoming more efficient at exploiting unpatched systems. The absence of zero-days this month is a statistical anomaly, not a trend. Organizations must treat every Patch Tuesday as a deadline, not a suggestion. The real battle isn't about finding vulnerabilities — it's about closing the window between disclosure and exploitation.

Microsoft just gave itself a powerful new weapon against bad drivers — the ability to remotely roll back faulty ones without waiting for hardware partners to act. Called Cloud-Initiated Driver Recovery, this feature lets Microsoft directly trigger a rollback to a stable driver version through Windows Update, closing a dangerous gap where devices could be stuck with subpar drivers for weeks or months. This matters because faulty drivers are a leading cause of system crashes, security vulnerabilities, and compatibility nightmares. If you run Windows, your device could soon be protected from driver disasters without you lifting a finger — but it also means Microsoft now holds the keys to your driver stack. Hardware partners and IT admins should pay close attention.

**What exactly happened** Microsoft announced Cloud-Initiated Driver Recovery, a new capability that lets the company remotely roll back problematic Windows drivers delivered through Windows Update. The feature removes the need for hardware partners or end users to manually fix driver issues once drivers have been distributed to devices. The recovery process is entirely managed by Microsoft, with no partner-side actions required. It will only be initiated for Windows drivers rejected due to quality issues during shiproom evaluation — meaning Microsoft's internal testing flagged them as problematic after distribution. **Who is affected and how** Every Windows device that receives drivers through Windows Update is potentially affected — which is essentially the entire Windows ecosystem. Hardware partners (OEMs, IHVs, ODMs) no longer need to scramble to submit replacement drivers when quality issues emerge. End users benefit from automatic fixes without manual uninstallation or tech support calls. IT administrators managing fleets of Windows devices will see faster resolution of driver-related issues, reducing downtime and support tickets. **The real-world impact and consequences** Under the current system, faulty drivers can leave devices vulnerable for extended periods. Hardware partners must submit replacements, and users must manually uninstall problematic drivers — a process that can take weeks or months. This creates a security and reliability gap. A bad driver can cause Blue Screens of Death, data corruption, or open security holes. Cloud-Initiated Driver Recovery closes that gap by rolling back to the last known-good version almost immediately after a problem is detected. **Technical breakdown** The system works through coordinated updates to the PnP (Plug and Play) driver stack and Microsoft's driver flighting and publishing services. When a driver fails quality checks during shiproom evaluation, Microsoft can trigger a recovery action directly from the Hardware Dev Center (HDC) Driver Shiproom. The rollback targets the previously known-good driver version via the Windows Update pipeline. Critically, devices where a Driver Shiproom-approved driver cannot be located will not attempt recovery — preventing unintended changes. No new client agent or partner tooling is required. The recovery is delivered through existing Windows Update infrastructure, making deployment seamless. **What should be done — mitigation and recommendations** For IT administrators: Review your driver update policies and ensure Windows Update is configured to allow automatic driver rollbacks. Test the feature during its pilot phase (May to August 2026) before full rollout in September 2026. For hardware partners: Ensure your drivers pass rigorous shiproom evaluation. Microsoft will now have the ability to override your driver updates — so quality gates are more important than ever. For end users: Keep Windows Update enabled. The automatic rollback protects you without requiring any action on your part. **Why this matters in the bigger cybersecurity landscape** This move is part of Microsoft's broader Driver Quality Initiative (DQI), announced at WinHEC 2026 alongside the Windows Resiliency Initiative. Together, they signal a shift toward proactive, automated driver management — reducing the attack surface from driver vulnerabilities. In June 2025, Microsoft also announced plans to periodically remove legacy drivers from the Windows Update catalog to mitigate compatibility issues and security risks. Cloud-Initiated Driver Recovery complements this by providing a safety net for drivers that slip through quality checks. The bigger picture: Microsoft is taking more control over the Windows ecosystem's reliability and security. For users, this means fewer headaches. For hardware partners, it means higher quality standards — and less room for error.

A Brazilian cybersecurity firm that sells DDoS protection has been caught red-handed launching massive DDoS attacks against its own potential customers. The company, Huge Networks, apparently had its CEO's private SSH keys exposed in an open directory online—along with custom malware tools designed to cripple Brazilian ISPs. The CEO claims this was all a setup by a jealous competitor trying to frame his company before a major industry event. But security researchers have tracked these attacks for years, and the evidence tells a different story. If you're a Brazilian ISP or rely on one for connectivity, your network may have been under siege by the very people offering to protect it.

**What exactly happened** KrebsOnSecurity obtained a file archive exposed in an open directory containing Portuguese-language Python malware and the private SSH keys of Huge Networks' CEO. The same archive showed that Huge Networks' infrastructure was being used to command a botnet that has been hammering Brazilian ISPs with massive DDoS attacks for years. The firm's CEO, when confronted, blamed a security breach and accused an unnamed competitor of planting the evidence. But the timing—just before a major industry event where this competitor is set to appear for the first time—raises more questions than answers. **Who is affected and how** The primary targets are Brazilian internet service providers, many of which are small to mid-sized operators. These ISPs have been hit with sustained, high-volume DDoS attacks that can knock entire regions offline. Huge Networks itself offers DDoS protection services to these very same ISPs. If the attacks were indeed launched from its network, it means the company was both the attacker and the would-be savior—a classic conflict of interest that undermines trust in the entire DDoS mitigation industry. **The real-world impact and consequences** For Brazilian ISPs, these attacks mean lost revenue, angry customers, and damaged reputations. For Huge Networks, the fallout could be catastrophic: loss of business, legal liability, and potential regulatory action from Brazilian authorities. The broader cybersecurity community now faces a crisis of confidence. If a DDoS protection firm can be compromised or turned rogue, how can any organization trust its mitigation provider? The incident also highlights the difficulty of attribution in cyber attacks—especially when the evidence points to an inside job or a sophisticated frame-up. **Technical breakdown** The exposed archive contained Python scripts designed to launch DDoS attacks, along with SSH keys that allowed access to Huge Networks' servers. SSH keys are the digital equivalent of master keys—they grant unrestricted access to systems without needing a password. With these keys, an attacker (or the CEO himself) could command the company's infrastructure to flood target ISPs with junk traffic. The malware was written in Portuguese, suggesting a local threat actor. The fact that the keys belonged to the CEO himself indicates either a serious security lapse or intentional involvement. **What should be done — mitigation and recommendations** First, Huge Networks must immediately revoke all compromised SSH keys and conduct a full forensic audit of its systems. The company should also notify affected ISPs and cooperate with law enforcement. For other DDoS protection firms, this incident is a wake-up call: segment your networks, monitor for anomalous traffic, and never assume your own infrastructure is immune to compromise. Brazilian ISPs should diversify their DDoS mitigation providers and demand transparency about security practices. **Why this matters in the bigger cybersecurity landscape** This case exposes a fundamental vulnerability in the cybersecurity ecosystem: the people you trust to protect you might be the ones attacking you. Whether it's a rogue employee, a compromised CEO, or a competitor's dirty trick, the result is the same—eroded trust in an industry built on confidence. It also shows how DDoS attacks have evolved from simple vandalism to strategic business weapons. When a mitigation firm can weaponize its own infrastructure, the line between protector and predator blurs. For everyone relying on third-party security services, this is a stark reminder to verify, not just trust.

A 24-year-old British hacker who once topped the leaderboards of the cybercrime underworld just pleaded guilty in a U.S. courtroom. Tyler Robert Buchanan, known online as "Tylerb," admitted to orchestrating a wave of text-message phishing attacks that ripped through some of the biggest names in tech. The result? Tens of millions of dollars in cryptocurrency stolen from investors, and a potential 22-year prison sentence hanging over his head. If you use Twilio, LastPass, DoorDash, or Mailchimp, this story directly involves data that was used to target you or people like you.

**What exactly happened** Tyler Robert Buchanan, a senior member of the infamous cybercrime group "Scattered Spider," pleaded guilty to wire fraud conspiracy and aggravated identity theft. His hacker handle "Tylerb" once sat near the top of a leaderboard tracking the most successful English-speaking cyber thieves. Now in U.S. custody, he faces a sentencing hearing scheduled for August 21, 2026. The statutory maximum is 22 years, though mitigating factors like his age and cooperation with authorities could reduce that significantly. **Who is affected and how** Scattered Spider is not your average ransomware gang. They are English-speaking social engineers who specialize in tricking IT help desks into handing over access. They impersonate employees or contractors to bypass security controls with nothing more than a convincing phone call or text. In the summer of 2022, Buchanan and his crew launched tens of thousands of SMS-based phishing attacks. Their targets included Twilio, LastPass, DoorDash, and Mailchimp. These are not small startups—they are infrastructure providers used by millions. **The real-world impact and consequences** The group didn't stop at corporate breaches. They used the stolen credentials and access to execute SIM-swapping attacks. In a SIM swap, criminals trick a mobile carrier into transferring a victim's phone number to a device they control. Once they own the phone number, they can reset passwords for cryptocurrency exchanges and drain wallets. The result was tens of millions of dollars stolen from individual investors, many of whom had no idea their phone number was the weak link. **Technical breakdown — the "how" explained simply** The attack chain is deceptively simple. First, the group sends a phishing text that looks like it's from the target's employer or a trusted service. The message asks the recipient to click a link and log in. Once the victim enters their credentials, the group captures them and calls the company's IT help desk. Posing as the employee, they claim to have forgotten their password or lost their phone. The help desk, trained to be helpful, resets the credentials or issues a new SIM card. From there, the group accesses corporate networks, steals data, and then uses that data to target cryptocurrency investors. It's a cascading attack that starts with a single text message. **What should be done — mitigation and recommendations** For companies, the fix starts with the help desk. Implement multi-factor authentication that cannot be bypassed by a phone call. Use out-of-band verification, like a physical token or a callback to a known number. For individuals, especially cryptocurrency investors, use a hardware wallet for large holdings. Never rely on SMS for two-factor authentication—use an authenticator app or a hardware key instead. If you receive an unexpected text asking you to click a link, pause. Call the company directly using a number you know is real, not one from the message. **Why this matters in the bigger cybersecurity landscape** Scattered Spider represents a shift in cybercrime. They are not script kiddies or state-sponsored hackers. They are conversational, patient, and highly organized. Their success proves that the human element remains the weakest link in security. Buchanan's guilty plea is a win for law enforcement, but it's also a warning. The group is still active, and its methods are being copied by others. The attack vector—social engineering—is not going away. It's evolving.

Grammar fuzzing sounds like the ultimate cheat code for bug hunting—until it isn't. A seasoned researcher just pulled back the curtain on why mutational grammar fuzzing, despite its track record of finding browser and JIT engine bugs, has hidden flaws that could be silently sabotaging your fuzzing campaigns. If you're relying on coverage-guided grammar fuzzing out-of-the-box, you might be missing critical vulnerabilities. The problem? More coverage doesn't always mean better results, and your fuzzer could be stuck in a deceptive comfort zone. Here's what's going wrong and how to fix it.

**What exactly happened** A veteran fuzzing researcher published a deep dive into the limitations of mutational grammar fuzzing—a technique where mutations preserve the structure of inputs based on predefined grammar rules. While this approach has uncovered serious bugs in XSLT implementations and JIT engines, the researcher identified fundamental flaws that casual users often overlook. The core issue: coverage-guided grammar fuzzing can create a false sense of progress. When a mutated sample triggers new code coverage, it gets saved to the corpus. But more coverage doesn't automatically mean more effective bug hunting. **Who is affected and how** Anyone using grammar fuzzing tools—from browser security teams to embedded systems testers—is at risk. The flaws affect not just grammar fuzzing but also other structure-aware fuzzing techniques. If you're using tools like Jackalope (where this research was based), AFL, or custom fuzzers, your results could be suboptimal. The researcher noted that these issues aren't implementation-specific, meaning they're baked into the approach itself. Teams relying on out-of-the-box configurations are especially vulnerable to missing deep, complex bugs. **The real-world impact and consequences** The most dangerous consequence? Your fuzzer might be wasting compute cycles on "coverage inflation"—saving samples that technically hit new code paths but don't actually stress the target in meaningful ways. This leads to bloated corpora, slower fuzzing, and missed vulnerabilities. In practice, this means critical bugs in parsers, interpreters, or compilers could slip through. The researcher's own experience showed that default settings often underperform compared to custom configurations that account for these flaws. **Technical breakdown: the "how" explained simply** Think of grammar fuzzing like a language tutor who only lets you form grammatically correct sentences. While this ensures valid inputs, it also limits your ability to explore edge cases. The first flaw: **coverage bias**. The fuzzer prioritizes samples that trigger new coverage, but these samples often cluster around similar grammar structures. You end up with many variations of the same pattern rather than diverse, structurally different inputs. Second flaw: **stale corpus syndrome**. Once a sample hits new coverage, it stays in the corpus forever—even if later mutations from other samples would be more effective. The fuzzer keeps mutating the same "successful" samples, creating a local optimum. Third flaw: **grammar rigidity**. Mutations that preserve grammar rules can't explore truly malformed inputs that might trigger parser bugs. The grammar becomes a cage. **What should be done — mitigation and recommendations** The researcher's countermeasure is surprisingly simple: periodically replace older corpus samples with newer ones, even if coverage doesn't change. This forces the fuzzer to explore fresh mutation paths. Other recommendations include: - Implementing sample aging mechanisms that deprioritize old samples - Using multiple grammar variants to break structural monotony - Combining grammar fuzzing with random mutation phases that violate grammar rules - Regularly resetting the corpus to prevent coverage stagnation The researcher tested this approach on libxslt and found it discovered bugs faster than default settings—proving that small tweaks can yield big results. **Why this matters in the bigger cybersecurity landscape** This research highlights a uncomfortable truth: even sophisticated fuzzing techniques have blind spots. As software becomes more complex—with parsers, compilers, and interpreters handling increasingly intricate input formats—the need for smarter fuzzing strategies grows. The takeaway? Don't trust your tools blindly. Experiment with different configurations, challenge assumptions, and remember that more coverage doesn't always mean more security. The best bug hunters are the ones who understand not just how their tools work, but where they fail.