Daily Digest

A critical zero-day in KnowledgeDeliver, a popular learning management system, is already being weaponized in the wild. Hackers exploited a hardcoded machine key to bypass authentication and plant the Godzilla web shell on vulnerable servers. If your organization uses this LMS, your data and network may already be at risk. This isn't just another patch-me-now alert. The flaw, CVE-2026-5426, allows remote code execution without a single login credential. Attackers are using it to drop backdoors, steal data, and pivot deeper into corporate networks. The clock is ticking.

**What exactly happened** Mandiant discovered that threat actors exploited a zero-day vulnerability in KnowledgeDeliver, an ASP.NET-based learning management system. The flaw, tracked as CVE-2026-5426, is a deserialization issue that allows unauthenticated remote code execution. Attackers used it to deploy the Godzilla web shell, a .NET-based in-memory backdoor. The root cause? A shared, hardcoded machine key in the web.config file across all KnowledgeDeliver customer deployments. This key, meant to encrypt and sign ViewState payloads, was identical for every instance. Once attackers obtained it, they could forge malicious payloads that the server would trust and execute. **Who is affected and how** Any organization running a KnowledgeDeliver instance deployed before February 24, 2026 is vulnerable. The attack vector is stealthy: the malicious code injected into the platform convinced users to download a fake installer, which then dropped a Cobalt Strike beacon. This effectively planted a persistent backdoor on the victim's machine. Mandiant observed the attacker preparing payloads encrypted with the target organization's name, indicating a tailored, targeted attack. This wasn't a spray-and-pray operation—it was surgical. **The real-world impact and consequences** The immediate consequence is full server compromise. Attackers gained OS-level access, modified JavaScript files, and prompted users to install a "security authentication plugin" that loaded malicious scripts from attacker-controlled domains. This allowed them to steal credentials, exfiltrate data, and move laterally within the network. The broader impact is chilling. KnowledgeDeliver is used by educational institutions and corporate training departments, often housing sensitive user data and acting as a gateway to internal systems. A compromised LMS can become a launchpad for ransomware, data theft, or espionage. **Technical breakdown — the "how" explained simply** ASP.NET applications use ViewState to maintain page state across postbacks. This data is serialized and sent to the client, then deserialized on return. To prevent tampering, it's signed and encrypted using a machine key stored in the web.config file. In KnowledgeDeliver, that key was hardcoded and shared across all customers. Attackers reverse-engineered it, then crafted malicious ViewState payloads that the server would deserialize and execute. Because the server trusted the signature, it ran the attacker's code without any authentication. This is a classic deserialization attack, amplified by a catastrophic configuration error. **What should be done — mitigation and recommendations** First, update your KnowledgeDeliver instance immediately. The vendor released a patch on February 24, 2026, that randomizes the machine key per deployment. If you're running an older version, you're still exposed. Second, rotate your machine keys even after patching. Assume they've been compromised. Regenerate them and re-sign all ViewState data. Third, audit your server for signs of compromise. Look for unexpected JavaScript modifications, unknown scheduled tasks, or outbound connections to unfamiliar domains. Deploy endpoint detection and response (EDR) tools to catch web shell activity. Finally, implement network segmentation. An LMS should not have unfettered access to your crown jewels. Limit lateral movement by isolating it in a DMZ with strict firewall rules. **Why this matters in the bigger cybersecurity landscape** This incident is a stark reminder that shared secrets are a single point of failure. The same hardcoded key that made deployment easy for the vendor made exploitation trivial for attackers. We've seen this pattern before—in Gladinet CentreStack, in SharePoint, in Sitecore. Each time, a static machine key became the Achilles' heel. The rise of ViewState deserialization attacks targeting ASP.NET environments is a worrying trend. As more organizations move to cloud-hosted or hybrid LMS platforms, the attack surface expands. The lesson is clear: never trust default configurations, never share cryptographic secrets, and always assume that what's hardcoded today will be weaponized tomorrow.

The FBI just dropped a flash alert that reads like a spy thriller—except the villains aren’t hiding in the shadows. They’re walking right through your office door. The Silent Ransom Group (SRG) is now sending real people to law firms to plug USB drives into employee computers. No malware. No phishing click needed. Just a stranger in a suit claiming to be IT support, and your data is gone. If you work at a U.S. law firm or financial institution, you’re the target. This isn’t a theoretical risk—it’s happening now. And the attackers are using your own trust against you.

**What exactly happened** The FBI warned on Tuesday that the Silent Ransom Group (SRG) is escalating its tactics. Instead of relying solely on remote tricks, they’re now sending physical operatives to victim locations. These actors pose as IT support. They call or email employees, urging them to grant remote desktop access. If that fails, they show up in person—claiming to be from the IT department—and plug a storage device into the victim’s computer. Once connected, they steal sensitive data in minutes. No advanced hacking required. Just social engineering and a USB drive. **Who is affected and how** The primary targets are U.S.-based law firms and financial organizations. SRG has been active since at least 2022, but this in-person twist is new. The attack starts with a phone call or phishing email. The employee is told to call “IT support” back. On that call, the attacker convinces them to allow remote access. If the employee hesitates, a real person shows up at the office. This hybrid approach—digital plus physical—makes it harder to detect. Traditional security tools won’t flag a person walking through the front door. **The real-world impact and consequences** Once the data is stolen, SRG sends a ransom email threatening to sell or leak the information. They don’t stop there. They also call the victim’s employees and clients to pressure them into paying. For law firms, this is catastrophic. Client confidentiality, privileged communications, and case strategies are all at risk. A breach could destroy trust, trigger lawsuits, and end careers. The financial sector faces similar risks—regulatory fines, reputational damage, and operational disruption. **Technical breakdown—explaining the “how” simply** SRG uses a technique called “callback phishing.” They send an email that looks urgent, often pretending to be a subscription renewal or IT alert. The email includes a phone number to call for help. When the victim calls, the attacker—posing as IT support—guides them through granting remote access. They use legitimate tools like TeamViewer or AnyDesk, which don’t trigger alarms. If the victim refuses, the attacker sends a person to the office. That person physically connects a USB drive or external hard drive to the computer. The data is copied and taken away. The FBI notes that indicators include unauthorized USB devices and strangers claiming to be IT support. **What should be done—mitigation and recommendations** First, verify all IT support requests. Never grant remote access based on an unsolicited call or email. Always call back using a known, official number. Second, enforce strict physical security policies. Require ID checks for anyone claiming to be from IT. Escort all visitors. Restrict access to sensitive areas. Third, disable USB ports on employee computers unless absolutely necessary. Use endpoint detection tools that monitor for unauthorized device connections. Finally, train employees on this specific threat. Make sure they know that IT will never ask them to plug in a random USB drive or grant remote access without prior verification. **Why this matters in the bigger cybersecurity landscape** This attack shows that cybercriminals are adapting. They’re blending digital deception with physical presence to bypass traditional defenses. The shift to in-person tactics is a wake-up call. It means that even the best firewalls and antivirus software can’t protect you if an attacker can walk through your door. For law firms and financial institutions, the stakes are incredibly high. They hold the most sensitive data—and attackers know it. This isn’t just about ransomware anymore. It’s about trust, reputation, and the very real threat of a stranger sitting at your desk.

A 35-year-old man is now in handcuffs for allegedly hacking Dutch football giant Ajax Amsterdam—not once, but multiple times. This wasn’t just a digital break-in. The suspect reportedly exploited security gaps to access data on hundreds of thousands of fans, manipulate stadium bans, and even reassign VIP season tickets in seconds. If you’re a fan, a season ticket holder, or just someone who trusts clubs with your personal info, this hits close to home. The breach exposed how vulnerable even major organizations can be—and why your data might be at risk.

**What exactly happened** The Dutch National Police arrested a 35-year-old man from Buren for hacking into AFC Ajax’s computer systems earlier this year. According to a May 26 press release, the suspect is believed to have broken into the club’s networks multiple times. Ajax first noticed the intrusion in early 2026. The club quickly alerted authorities, and a criminal investigation led straight to the suspect. **Who is affected and how** The breach impacted a few hundred individuals directly, but the potential reach was far wider. The hacker demonstrated they could access data on over 300,000 accounts, manipulate 538 supporter stadium bans, and reassign 42,000 season tickets. That means fans, VIPs, and even banned individuals were all in the crosshairs. The club’s systems weren’t just breached—they were effectively weaponized. **The real-world impact and consequences** This isn’t just a data leak. The hacker showed they could modify stadium bans, meaning dangerous individuals could have been allowed into games. They could also transfer tickets, potentially enabling fraud or unauthorized access. For Ajax, this is a reputational nightmare. For fans, it’s a stark reminder that your personal details—and even your physical safety at events—could be compromised when systems fail. **Technical breakdown** The attacker exploited vulnerabilities in Ajax’s IT systems, including flaws in APIs and shared keys. This allowed broad access to fan data without proper authentication. In a demonstration, the hacker reassigned a VIP season ticket in seconds. They also showed how they could modify 538 stadium bans and view details on more than 300,000 accounts. The root cause? Weak access controls and unpatched vulnerabilities. **What should be done** Ajax has since patched the exploited vulnerabilities and notified the Dutch Data Protection Authority and police. But for other organizations, the lesson is clear: audit your APIs, enforce strict access controls, and patch vulnerabilities fast. For fans, change your passwords and enable two-factor authentication. If you’re a season ticket holder, monitor your account for unusual activity. **Why this matters** This case is part of a troubling trend in the Netherlands. In September 2025, police arrested two teens for spying on Europol and Eurojust using a WiFi sniffer. More recently, financial crime investigators seized 800 servers tied to a web hosting company enabling cyberattacks and disinformation. The Ajax hack shows that no organization—not even a beloved football club—is immune. It’s a wake-up call for sports teams, event organizers, and anyone holding sensitive data. The stakes? Your privacy, your safety, and your trust.

Microsoft just dropped a hefty optional update for Windows 11—KB5089573—and it’s not your typical patch. This preview release packs 30 changes aimed at making your PC feel snappier, from faster app launches to a smarter Windows Hello sign-in experience. Why should you care? If you’re running Windows 11 versions 25H2 or 24H2, this update targets the little annoyances that slow you down: laggy Start menus, sluggish File Explorer, and finicky lock screens. IT admins and power users get a sneak peek before next month’s Patch Tuesday, but everyone should know this is a test drive—not a security fix.

**What exactly happened** Microsoft released the KB5089573 preview cumulative update for Windows 11 versions 25H2 and 24H2 on May 2026. It’s part of the company’s non-security preview schedule, meaning it’s optional and designed for testing new features and fixes before they go mainstream during Patch Tuesday. This update introduces 30 changes focused on performance and reliability. Unlike regular cumulative updates, it doesn’t include security patches—so it’s a low-risk experiment for those who want to polish their system without the pressure of a mandatory install. **Who is affected and how** The update targets all Windows 11 users on versions 25H2 and 24H2, but it’s especially relevant for IT admins and early adopters. Microsoft is gradually rolling out general OS performance upgrades, including improvements to Windows Hello, Start menu, Search, and Action Center. For end users, the most noticeable change is a smarter sign-in experience. If you have Windows Hello face or fingerprint set up, it now becomes the default method every time you sign in—even if you used a PIN previously. But if you switch to PIN three times in a row, the system remembers your preference and sticks with it. **The real-world impact and consequences** This update aims to eliminate those micro-frustrations that chip away at productivity. Faster app launches and smoother shell experiences mean less waiting and more doing. File Explorer, sign-in screens, and touch gestures all get reliability boosts, which is a win for both casual users and enterprise environments. However, because it’s a preview, there’s always a risk of unexpected bugs. IT admins should test it in controlled environments before broad deployment. The bigger story here is Microsoft’s ongoing effort to refine Windows 11’s core experience, especially as the platform matures. **Technical breakdown** The update accelerates core shell experiences like Start menu and Search by optimizing how Windows handles background processes and memory allocation. For Windows Hello, the change in sign-in default behavior is driven by a new heuristic: the system tracks your last three sign-in methods and adjusts accordingly. This is part of a broader trend where Microsoft is using machine learning to personalize user interactions without explicit settings changes. It’s subtle but powerful—your PC learns your habits and adapts. **What should be done — mitigation and recommendations** For most users, this update is optional. If you’re not experiencing issues, you can wait for the next Patch Tuesday when these fixes become mandatory. But if you’re an IT admin, download and test KB5089573 in a staging environment to ensure compatibility with your apps and workflows. Also, keep an eye on the Secure Boot certificate refresh that Microsoft announced in January. The original 2011 certificates expire in late June, and this update may include preliminary steps for that transition. Don’t wait until the last minute—plan your certificate updates now. **Why this matters in the bigger cybersecurity landscape** This update highlights a shift in Microsoft’s strategy: delivering performance and reliability improvements outside of security patches. It’s a move toward a more proactive, user-centric approach to system maintenance. But it also underscores the complexity of modern OS management. With optional previews, certificate expirations, and separate security updates, IT admins must juggle multiple timelines. The takeaway? Stay informed, test early, and never assume an optional update is trivial—it might just be the key to a smoother, more secure Windows experience.

Think grammar fuzzing is the silver bullet for finding deep bugs? Think again. A seasoned security researcher just pulled back the curtain on why mutational grammar fuzzing—despite its impressive track record—has hidden flaws that could be silently sabotaging your bug hunts. If you're fuzzing anything from web browsers to JIT engines, the blind spots revealed here might explain why you're missing critical vulnerabilities.

**What exactly happened** A veteran cybersecurity researcher published a deep-dive analysis exposing critical limitations in mutational grammar fuzzing—a technique widely used to find complex bugs in parsers, compilers, and interpreters. While the approach has successfully uncovered issues in XSLT implementations and JIT engines, the researcher argues that its effectiveness is often overstated due to subtle but systemic flaws. **Who is affected and how** Anyone using coverage-guided grammar fuzzers—whether for browser security, compiler testing, or protocol fuzzing—is potentially impacted. The flaws affect not just grammar fuzzing but other structure-aware techniques too. The researcher's findings are based on their Jackalope fuzzer, but the issues are implementation-agnostic. **The real-world impact and consequences** The core problem? More coverage doesn't always mean better fuzzing. The researcher demonstrates that coverage-guided grammar fuzzing can get stuck in local optima, repeatedly exploring the same code paths while missing entirely new ones. This creates a dangerous false sense of security—you might think you're thoroughly testing a target when you're actually just spinning your wheels. **Technical breakdown (explain the "how" simply)** Here's the mechanics: Grammar fuzzers mutate inputs while preserving structure. When a mutation triggers new code coverage, that input gets saved for future mutations. Sounds smart, right? The catch is that "new coverage" doesn't distinguish between genuinely novel behavior and trivial variations. The fuzzer can become obsessed with minor code paths, wasting compute cycles on marginal gains while ignoring entire swaths of the attack surface. The researcher's countermeasure is elegantly simple: periodically inject entirely fresh seeds into the corpus, even if they don't immediately improve coverage. This "novelty injection" forces the fuzzer to explore new territory, breaking out of local optima. **What should be done — mitigation and recommendations** First, don't blindly trust default fuzzer configurations. Experiment with seed selection strategies that prioritize diversity over coverage metrics. Second, implement periodic corpus refreshing—replace older samples with newer ones even when coverage doesn't change. Third, monitor for "coverage stagnation" as a red flag that your fuzzer might be stuck. The researcher's own tests showed this approach helped discover bugs in libxslt faster than default settings. **Why this matters in the bigger cybersecurity landscape** This research underscores a uncomfortable truth: our most sophisticated fuzzing tools still have fundamental blind spots. As software complexity grows, so does the gap between what we think we're testing and what we're actually testing. The lesson isn't to abandon grammar fuzzing—it's to approach it with healthy skepticism and a willingness to experiment. The best fuzzer isn't the one with the most features. It's the one you understand well enough to know its weaknesses.

A forgotten Windows API just handed attackers an open door to your system—and Microsoft only just slammed it shut. The GetProcessHandleFromHwnd function, long buried in Windows internals, turned out to be a silent privilege escalator that let low-level processes grab high-value process handles without proper checks. This wasn't a theoretical flaw. It was already weaponized in the wild through Quick Assist, a built-in Windows tool, to bypass User Account Control (UAC). If you're on Windows 11 before the 24H2 update, your system was exposed to a quiet but powerful attack vector that could let malware steal credentials or spy on your most sensitive apps.

**What exactly happened** A seemingly innocuous API called GetProcessHandleFromHwnd became the center of a security storm. Designed as a convenience function to get a process handle from a window handle, it had a critical flaw: it bypassed Windows' own protection mechanisms, allowing lower-integrity processes to obtain handles to higher-integrity processes. The vulnerability was first publicly disclosed through a UAC bypass using Quick Assist, a Windows accessibility tool. Researchers found that the API didn't properly enforce User Interface Privilege Isolation (UIPI), which is supposed to prevent lower-privileged processes from interacting with higher-privileged ones. **Who is affected and how** Every Windows user running versions prior to Windows 11 24H2 was potentially at risk. The attack chain was deceptively simple: a malicious process running at medium integrity could call this API to get a handle to a high-integrity process like a system utility or security software. Once obtained, that handle could be used to inject code, read memory, or escalate privileges. The attacker didn't need admin rights—just a foothold on the machine. Think of it as a master key that worked even when the door was supposed to be locked. **The real-world impact and consequences** This wasn't just a theoretical bug. In the Quick Assist case, attackers could bypass UAC entirely, gaining administrative control without triggering any warnings. The implications are severe: credential theft, ransomware deployment, and persistent backdoor installation all become easier when you can silently elevate privileges. The most dangerous part? The API was documented with misleading statements about its security properties. Microsoft's own docs claimed it required UI Access and same-user conditions—both of which turned out to be incomplete or outright false. **Technical breakdown** Here's how it actually worked under the hood. On Windows 11, GetProcessHandleFromHwnd is implemented as a Win32k kernel function that directly opens the target process. It doesn't use Windows hooks as the documentation suggested. The critical oversight was in how it handled protected processes. Normally, you can't duplicate a process handle with sensitive access rights (like PROCESS_VM_READ) from a protected process to a non-protected one. But because the entire operation happened in kernel mode, the check for protected processes was simply forgotten. This meant any process—even one running at low integrity—could request a handle to any other process on the system, as long as they shared the same user account. The integrity level check was missing entirely. **What should be done** Microsoft finally fixed this in Windows 11 24H2, which includes a general overhaul of UIPI. The API is no longer as dangerous, and the integrity checks are now properly enforced. If you're on an older version, your options are limited. Apply all available Windows updates immediately. Consider using application whitelisting tools to block unknown executables. And be especially wary of any software that requests UI Access privileges—that's the exact path attackers used. **Why this matters in the bigger cybersecurity landscape** This story is a classic example of how legacy code can become a ticking time bomb. An API that's been around for decades, documented incorrectly, and never properly audited for security—until someone weaponized it. It also highlights the fragility of Windows' privilege model. UIPI was supposed to be a robust barrier, but one overlooked function in kernel mode was enough to bypass it entirely. As Windows continues to evolve, the lesson is clear: every line of old code needs to be re-examined with fresh eyes, because attackers are already doing just that.

Windows just got a shiny new security feature called Administrator Protection—but it had a rocky start. Security researcher Michael "m417z" discovered nine ways to bypass it before it even hit the public, and five of those share a common, ancient root cause: UI Access abuse. This isn't just a minor glitch. It's a legacy problem that's been lurking since Windows Vista, and it puts every user of the new feature at risk. If you're running Windows with Administrator Protection enabled, your so-called "secure boundary" might be more porous than you think.

**What Exactly Happened** Microsoft introduced Administrator Protection to finally fix User Account Control (UAC), a feature that's been more of a polite suggestion than a real security boundary for years. But before the feature even shipped, researcher m417z found nine separate bypasses. Five of them trace back to a single, neglected vulnerability: UI Access abuse. **Who Is Affected and How** Anyone using Windows with Administrator Protection enabled is potentially affected. The bypasses allow a standard user process to interact with privileged administrator windows—the exact scenario Administrator Protection was designed to prevent. This means an attacker who already has limited access could escalate privileges without triggering any alarms. **The Real-World Impact** Imagine a malware sample that can silently elevate itself to administrator without ever showing a UAC prompt. That's the practical outcome here. While Microsoft has patched all nine issues, the underlying design flaw remains a concern. For enterprise environments relying on this feature as a security boundary, the implications are serious—especially if similar bypasses emerge in the future. **Technical Breakdown (The "How" Explained Simply)** The problem dates back to Windows Vista's introduction of UIPI (User Interface Privilege Isolation). UIPI was supposed to prevent low-integrity processes from sending window messages to high-integrity processes, blocking classic "shatter attacks." But there was an exception: processes with UI Access privilege could bypass these restrictions. The researcher discovered that Administrator Protection's implementation didn't properly handle this exception. A limited user process could abuse UI Access to interact with administrator-level windows, effectively bypassing the security boundary. Think of it as giving a guest a special key that lets them walk into any room in the house—including the one with the safe. **What Should Be Done — Mitigation and Recommendations** Microsoft has already fixed all nine bypasses in the latest Windows updates. Users should ensure their systems are fully patched. For administrators, the researcher recommends reviewing the Administrator Protection implementation carefully if you're planning to deploy it. Consider additional monitoring for UI Access abuse, and don't treat this feature as a silver bullet—it's a layer, not a fortress. **Why This Matters in the Bigger Cybersecurity Landscape** This research exposes a deeper truth: security features built on legacy foundations often inherit their ancestors' flaws. UI Access has been a weak link in Windows security for over a decade, and Administrator Protection was supposed to finally address it. Instead, it became another example of how hard it is to retrofit security onto an aging operating system. The bigger lesson? When Microsoft rushes new security features to market, the cracks show. Rigorous testing during development—not after—would have caught these issues. For defenders, this is a reminder that every new security boundary needs independent scrutiny before you trust it with your network's crown jewels.