Daily Digest

A mysterious researcher just dropped a zero-day that cracks open Windows BitLocker encryption like a cheap lock. Dubbed "YellowKey," this flaw lets anyone with physical access bypass full-disk encryption on Windows devices. Microsoft is now scrambling to provide workarounds—but no official patch exists yet. If you rely on BitLocker to protect sensitive data on laptops or removable drives, this one hits close to home.

**What exactly happened** Last week, an anonymous researcher known as "Nightmare Eclipse" published proof-of-concept exploit code for a Windows BitLocker zero-day they call YellowKey. Microsoft has since assigned it CVE-2026-45585 and released mitigation guidance—but no security update is available yet. The exploit targets the Windows Recovery Environment (WinRE), a built-in repair tool. By placing malicious files on a USB drive or EFI partition, an attacker can trigger a shell with full access to encrypted drives simply by holding down the CTRL key during boot. **Who is affected and how** Anyone using BitLocker device encryption on Windows 10 or 11 is potentially vulnerable. The attack requires physical access to the machine—so laptops, tablets, and other portable devices are most at risk. This isn't a remote exploit you can pull off from across the internet. But if a device gets stolen or falls into the wrong hands, YellowKey effectively nullifies the encryption that's supposed to protect sensitive data. **The real-world impact and consequences** For organizations, this is a nightmare scenario. BitLocker is widely trusted to protect data on lost or stolen devices. If that trust is broken, the implications ripple across compliance, legal liability, and intellectual property protection. The researcher claims this disclosure is a protest against Microsoft's vulnerability handling process. They've also leaked three other zero-days recently—BlueHammer, RedSun, GreenPlasma, and UnDefend—suggesting a coordinated dump of exploits. **Technical breakdown** The exploit chain is surprisingly simple. An attacker places specially crafted FsTx files on a USB drive or EFI partition, then reboots the system into WinRE. By holding down CTRL, they trigger a shell with SYSTEM-level privileges—completely bypassing BitLocker's encryption. The key enabler is autofstx.exe, a Windows component that automatically runs during WinRE startup. Microsoft's mitigation involves removing this entry from the Session Manager's BootExecute registry value, then re-establishing BitLocker trust for WinRE. **What should be done** Microsoft recommends two immediate actions. First, remove the autofstx.exe entry from the BootExecute REG_MULTI_SZ value. Second, switch BitLocker from "TPM-only" mode to "TPM+PIN" mode—this requires a pre-boot PIN to decrypt the drive, blocking the attack. For unencrypted devices, enable the "Require additional authentication at startup" policy via Intune or Group Policy, with "Configure TPM startup PIN" set to "Require startup PIN with TPM." **Why this matters** YellowKey exposes a fundamental tension in Windows security: convenience versus protection. TPM-only mode is easy but vulnerable. The PIN-based fix adds friction but closes the door. More broadly, this researcher's protest highlights growing frustration with how major vendors handle vulnerability disclosures. When researchers feel unheard, they sometimes go public—and everyone pays the price.

A single malicious VS Code extension just turned GitHub’s own security into a cautionary tale. The company confirmed that roughly 3,800 internal repositories were breached after an employee installed a poisoned add-on from the official marketplace. This isn’t a hypothetical risk—it’s a live supply chain attack targeting the very platform that hosts code for 90% of the Fortune 100. If you’re a developer, a security team, or anyone using VS Code, this story is your wake-up call.

**What exactly happened** GitHub disclosed that a compromised employee device led to the exfiltration of about 3,800 internal repositories. The breach began when an employee installed a trojanized VS Code extension from the official marketplace—a seemingly harmless productivity tool that turned out to be a backdoor. The company acted fast, removing the malicious extension version, isolating the endpoint, and launching an incident response. But the damage was already done: the attacker claims to have stolen private source code and is now shopping it on the Breached cybercrime forum for at least $50,000. **Who is affected and how** The breach directly impacts GitHub’s internal operations, but the ripple effects could be far wider. While GitHub insists no customer data outside the affected repos was compromised, the stolen code could reveal proprietary algorithms, security configurations, or integration secrets. For the 180 million developers and 4 million organizations using GitHub, this incident underscores a sobering reality: even the platform you trust to secure your code can fall victim to the same threats you face daily. **The real-world impact and consequences** The attacker group, TeamPCP, has a track record of massive supply chain attacks targeting GitHub, PyPI, NPM, and Docker. Their latest campaign, “Mini Shai-Hulud,” even impacted two OpenAI employees. Now, they’re demanding a six-figure sum for the stolen data, threatening to leak it for free if no buyer steps up. If the code is leaked, competitors, cybercriminals, or state-sponsored actors could exploit vulnerabilities, reverse-engineer GitHub’s security features, or weaponize internal tools. The reputational damage alone could erode trust in a platform that hosts the world’s most critical code. **Technical breakdown (explain the “how” simply)** VS Code extensions are plugins that add features to Microsoft’s code editor. They’re installed from the official marketplace, which is supposed to be safe. But this malicious extension was trojanized—meaning it appeared legitimate but contained hidden code to steal data. Once installed, it likely provided remote access to the employee’s device, allowing the attacker to browse files, extract credentials, and exfiltrate repository data. GitHub hasn’t named the extension, but the attack vector is painfully familiar: a single trusted employee clicking “install” on a seemingly useful tool. This isn’t a one-off. Over the past year, malicious VS Code extensions with millions of installs have been used to steal credentials, mine cryptocurrency, and even deploy ransomware. In January, two AI-based coding assistants with 1.5 million installs were caught exfiltrating data to servers in China. **What should be done — mitigation and recommendations** For developers and organizations, the first line of defense is caution. Never install extensions from untrusted publishers, even on the official marketplace. Regularly audit installed extensions and revoke permissions for any that seem suspicious. For security teams, this is a reminder to enforce strict endpoint controls. Consider using application allowlisting, restricting extension installations to approved sources, and monitoring for unusual outbound traffic from developer machines. GitHub itself must tighten its extension vetting process and consider real-time scanning for malicious code. But the broader lesson is that no platform is immune—and the human element remains the weakest link. **Why this matters in the bigger cybersecurity landscape** This breach is a textbook supply chain attack, and it’s happening at the heart of the software supply chain. If GitHub can be compromised by a malicious VS Code extension, every organization using similar tools is at risk. The attack also highlights the growing sophistication of threat actors like TeamPCP, who target developer ecosystems to maximize impact. As AI-powered coding assistants and third-party plugins become ubiquitous, the attack surface only expands. Ultimately, this incident is a stark reminder that cybersecurity isn’t just about firewalls and encryption—it’s about the choices we make every time we click “install.” The next malicious extension might not be aimed at GitHub. It could be aimed at you.

GitHub is investigating a breach of its internal repositories after the hacker group TeamPCP claimed to have accessed roughly 4,000 repositories containing private code. The breach reportedly happened after an employee installed a malicious VS Code extension. This matters because GitHub hosts code for over 180 million developers and 4 million organizations, including 90% of the Fortune 100. While GitHub says no customer data has been affected so far, the attackers are demanding at least $50,000 for the stolen code—or they'll leak it for free. Anyone using GitHub should be watching closely.

**What exactly happened** GitHub confirmed on May 20 that around 3,800 internal repositories were breached after an employee installed a malicious VS Code extension. The hacker group TeamPCP claimed responsibility on the Breached hacking forum, saying they accessed "GitHub's source code and internal orgs." The attackers are asking for a minimum of $50,000 for the stolen data. They've made it clear this isn't a ransom—they're selling the data to a single buyer and will destroy it afterward. If no buyer steps up, they've threatened to leak everything for free. **Who is affected and how** GitHub's platform is massive. It serves over 180 million developers and 4 million organizations, including 90% of the Fortune 100. So far, GitHub says there's no evidence that customer data—like enterprises, organizations, or repositories—has been compromised. But the breach of internal source code is still a serious concern. If the attackers found credentials, API keys, or proprietary algorithms inside those repositories, the fallout could ripple far beyond GitHub itself. GitHub has promised to alert affected customers through established channels if any impact is discovered. **The real-world impact and consequences** This isn't TeamPCP's first rodeo. The group has been linked to supply chain attacks targeting GitHub, PyPI, NPM, and Docker. In March, they compromised Aqua Security's Trivy vulnerability scanner, which led to cascading effects on Docker images and the Checkmarx KICS project. That breach also infected tens of thousands of devices with "TeamPCP Cloud Stealer" malware via the LiteLLM library. More recently, they hit two OpenAI employees in the "Mini Shai-Hulud" campaign and threatened to leak Mistral AI's source code. This pattern shows a group that specializes in exploiting developer tools to infiltrate high-value targets. **Technical breakdown** The entry point was a malicious VS Code extension installed by a GitHub employee. VS Code extensions run with the same privileges as the user, so they can access local files, environment variables, and even network resources. Once installed, the extension likely exfiltrated credentials or session tokens that allowed access to GitHub's internal repositories. The attackers then used that access to clone or download roughly 4,000 repos containing private code. This is a classic supply chain attack vector—targeting the developers themselves rather than the platform's external defenses. **What should be done — mitigation and recommendations** For GitHub: immediately audit all VS Code extensions used by employees, enforce strict extension approval policies, and rotate any credentials or tokens found in the breached repos. They should also monitor for any unusual activity in internal systems and customer environments. For developers and organizations: review your own VS Code extensions and remove any that aren't strictly necessary. Enable two-factor authentication on all accounts. Consider using sandboxed environments for development work. And if you're a GitHub customer, watch for any suspicious activity in your repositories. **Why this matters in the bigger cybersecurity landscape** This breach highlights a growing trend: attackers are targeting the tools developers trust every day. VS Code extensions, npm packages, PyPI libraries—these are all vectors for supply chain attacks. TeamPCP's repeated success shows that even major platforms like GitHub aren't immune. The real danger isn't just the stolen source code. It's the potential for attackers to find hardcoded secrets, API keys, or infrastructure details that could lead to deeper compromises. For the cybersecurity community, this is a wake-up call to treat developer environments as critical attack surfaces—because that's exactly what they've become.

A new zero-click exploit chain has been developed for the Google Pixel 10, proving that even when one door closes, hackers find a window. Security researchers successfully adapted their previous Pixel 9 exploit, targeting a patched Dolby vulnerability, to work on the newer device. This matters because it demonstrates that Android devices remain vulnerable to sophisticated attacks that require no user interaction. Anyone using an unpatched Pixel 10 with a security patch level of December 2025 or earlier is at risk. The exploit chain can go from zero-click to full root access, giving attackers complete control over your device.

**What exactly happened** Security researchers published an exploit chain for the Google Pixel 10 that achieves root access from a zero-click context. This builds on their previous work targeting the Pixel 9, which exploited a Dolby zero-click vulnerability (CVE-2025-54957) patched in January 2026. The team wanted to see if they could replicate their success on the newer device. Spoiler: they did. The updated Dolby exploit works on unpatched Pixel 10 devices running security patch levels from December 2025 or earlier. **Who is affected and how** Pixel 10 users who haven't installed the January 2026 security update are vulnerable. The exploit requires no user interaction—no clicking malicious links, no opening suspicious attachments. Just receiving a specially crafted media file could trigger the attack chain. This affects both technical and non-technical users equally. If your Pixel 10 is still on the December 2025 security patch, you're exposed. The researchers have published the exploit code, making it accessible to anyone with the technical skills to use it. **The real-world impact and consequences** A successful attack gives the attacker root access to your device. This means they can read all your data, install malware, access your camera and microphone, and even lock you out of your own phone. For journalists, activists, or anyone handling sensitive information, this is a nightmare scenario. Even for average users, the consequences range from identity theft to complete device takeover. The zero-click nature makes it particularly dangerous because you can't protect yourself by being careful about what you click. **Technical breakdown** The researchers adapted their Pixel 9 exploit for the Pixel 10. Most changes involved updating memory offsets for the new device's library versions. The biggest challenge? Pixel 10 uses RET PAC (Pointer Authentication Code) instead of -fstack-protector, which removed the usual __stack_chk_fail overwrite target. They found a workaround using dap_cpdp_init, initialization code that runs only once when the decoder starts. Overwriting this doesn't cause functional problems because it's never called again. The updated exploit is available on GitHub for research purposes. The second part of the chain—the local privilege escalation—required a complete rewrite. The BigWave driver used in the Pixel 9 exploit doesn't exist on Pixel 10. Instead, the researchers found a new driver in the mediacodec SELinux context. Details on this new driver are still emerging. **What should be done — mitigation and recommendations** First, update your Pixel 10 to the latest security patch immediately. The January 2026 update patches the Dolby vulnerability. If you're running anything older, you're vulnerable. Second, enable automatic security updates. This ensures you don't miss critical patches. For enterprise users, deploy mobile device management policies that enforce timely updates. Third, consider using security-focused Android distributions like GrapheneOS that implement additional hardening measures. These can make exploitation significantly harder even when vulnerabilities exist. **Why this matters in the bigger cybersecurity landscape** This research highlights a fundamental truth: patching vulnerabilities is a game of whack-a-mole. Fix one exploit vector, attackers find another. The Pixel 10 exploit shows that even major security improvements like RET PAC can be bypassed with creative thinking. More importantly, it underscores the need for proactive security in software development. Companies must invest in code auditing, secure coding practices, and vulnerability research before products ship. Waiting for researchers to find and report flaws—then patching—is reactive and leaves users exposed. The cybersecurity community plays a crucial role here. Responsible disclosure, like what these researchers did, gives vendors time to patch before exploits go public. But the ultimate responsibility lies with manufacturers to build security in from the start, not bolt it on after the fact.

Grammar fuzzing is one of the most powerful tools in a security researcher's arsenal—but it has a dirty little secret. Even when you're generating perfectly valid inputs that trigger new code coverage, you might be wasting most of your CPU cycles on samples that are structurally identical. That's the hidden flaw uncovered in a deep analysis of mutational grammar fuzzing. The technique, which mutates inputs while preserving their grammatical structure, has found bugs in everything from browser XSLT parsers to JIT engines. But if you're not careful, your fuzzer could be stuck in a rut, endlessly re-exploring the same code paths with different syntax. The real risk? Missed vulnerabilities. If you're a developer or security engineer relying on grammar fuzzing without understanding its blind spots, you're leaving critical bugs on the table. This research reveals exactly where the technique breaks down—and offers a surprisingly simple fix that could double your bug-finding efficiency.

**What exactly happened** A security researcher took a hard look at mutational grammar fuzzing—a technique where fuzzers mutate inputs while keeping them grammatically valid. The goal is to generate diverse, structured test cases that explore new code paths. The problem? More coverage doesn't always mean more diversity. The researcher discovered that many samples triggering "new coverage" are actually structurally identical, differing only in surface-level details like variable names or whitespace. **Who is affected and how** Anyone using coverage-guided grammar fuzzers—whether for browser testing, parser fuzzing, or JIT engine research—is affected. The issue isn't tool-specific; it applies to any structure-aware fuzzing approach. The researcher found this flaw while working with their own Jackalope fuzzer, but confirmed the pattern exists across implementations. If you're running a grammar fuzzer out-of-the-box, you're likely wasting significant compute on redundant samples. **The real-world impact and consequences** This redundancy has two major consequences. First, it slows down bug discovery—your fuzzer spends time re-exploring the same code paths instead of hunting for new vulnerabilities. Second, it creates a false sense of coverage progress. The researcher noted that in real-world targets like libxslt, this issue delayed finding bugs by weeks. For critical software like web browsers or XML parsers, that delay could mean the difference between a responsible disclosure and a public exploit. **Technical breakdown** Here's how it works. Grammar fuzzing uses a predefined grammar to generate valid inputs. When a sample is mutated, the fuzzer ensures the result still follows the grammar rules. If the new input triggers unseen code coverage, it's saved to the corpus. The flaw emerges because "new coverage" is measured at a granular level—often basic blocks or edges. Two inputs can trigger the same new block while being structurally identical. For example, `<tag attr="value">` and `<tag attr="different_value">` might both explore the same parsing logic, just with different attribute values. The fuzzer treats both as valuable, but only the first actually expands the search space. The second is a duplicate in disguise. **What should be done** The researcher proposes a simple but effective countermeasure: prioritize novelty over coverage. Instead of saving every sample that triggers new coverage, the fuzzer should evaluate whether the sample introduces genuinely new structural patterns. One practical approach is to compare samples at the grammar level—checking if they use different production rules or explore different branches of the grammar tree. If two samples are structurally identical, only keep the first. The researcher implemented this in Jackalope and saw dramatic improvements. Bug discovery in libxslt accelerated significantly compared to default settings. **Why this matters in the bigger cybersecurity landscape** This research highlights a broader truth about fuzzing: raw metrics can be misleading. Coverage-guided fuzzing is powerful, but it's not a silver bullet. Blindly trusting coverage numbers can lead to inefficient testing and missed vulnerabilities. The takeaway is clear: experiment with your fuzzing setup. Don't rely on out-of-the-box configurations. Tailor your approach to the target's specifics—whether that means modifying mutation strategies, corpus management, or coverage measurement. As fuzzing becomes more automated and integrated into CI/CD pipelines, understanding these nuances is critical. The next big vulnerability might be hiding in plain sight, waiting for a fuzzer that's smart enough to look beyond the surface.

A forgotten Windows API just became a hacker’s best friend—and Microsoft is only now patching it. The `GetProcessHandleFromHwnd` function, buried in Windows internals, was supposed to be a harmless helper for UI Access apps. Instead, it handed attackers a skeleton key to grab process handles across user sessions, bypassing years of security hardening. If you’re on Windows 10 or 11 (pre-24H2), your system is at risk. This isn’t a theoretical flaw—it’s already been weaponized in a UAC bypass via Quick Assist. The real kicker? Microsoft’s own documentation got the security model wrong, leaving a gap that anyone with basic admin rights could exploit.

**What exactly happened** A security researcher uncovered that `GetProcessHandleFromHwnd`—a little-known Windows API—was fundamentally broken. Designed to let UI Access applications grab a process handle from a window handle (HWND), it instead opened a direct path to any process owned by the same user, regardless of integrity level. This meant a low-integrity process could snatch a handle to a high-integrity one, bypassing User Interface Privilege Isolation (UIPI). The flaw was first spotted in a public UAC bypass using Microsoft’s own Quick Assist tool. That exploit used the API to elevate privileges without triggering any admin prompts. The researcher dug deeper and found the API’s implementation was a mess of outdated assumptions and missing checks. **Who is affected and how** Every Windows user running versions before 11 24H2 is potentially exposed. But the real danger is for enterprise environments with strict privilege boundaries. An attacker who already has limited code execution—say, through a malicious macro or browser exploit—could use this API to escalate to SYSTEM or access protected processes like antivirus software. The attack doesn’t require special permissions beyond what a standard user has. And because the API works across user sessions (despite documentation claiming otherwise), it could even be used to hijack processes from other logged-in accounts on the same machine. **The real-world impact and consequences** This isn’t just a theoretical bug—it’s a privilege escalation goldmine. In testing, the researcher could use `GetProcessHandleFromHwnd` to open handles with `PROCESS_ALL_ACCESS` to any non-protected process. That means reading memory, injecting code, or terminating critical system services. The most chilling part? The API was supposed to be restricted to UI Access apps, but the check was never properly enforced. Any application could call it, making it a reliable tool for malware to break out of sandboxes or elevate from user to admin. Microsoft’s own Quick Assist tool already demonstrated this in the wild. **Technical breakdown** The API’s implementation in Windows 10 and 11 (pre-24H2) was a kernel-mode function that directly opened process handles via `ObOpenObjectByPointer`. It completely ignored UIPI checks—the very security layer meant to prevent low-integrity processes from touching high-integrity ones. The documentation claimed it used Windows hooks to inject code, but that was a lie. It just brute-force opened the process. The only guard was a check for protected processes (like antivirus), but even that was buggy. In some cases, the API could bypass it by duplicating handles from a non-protected process. **What should be done — mitigation and recommendations** Microsoft fixed this in Windows 11 24H2 by adding proper UIPI enforcement and removing the dangerous direct-open behavior. For everyone else, there’s no patch for older versions. The only mitigation is to restrict which applications can call the API—but that’s impractical for most users. Organizations should prioritize upgrading to 24H2 or apply the latest cumulative updates. For systems that can’t update, consider using AppLocker or Windows Defender Application Control to block untrusted executables. And always treat UI Access applications with suspicion—they’re a common attack vector. **Why this matters in the bigger cybersecurity landscape** This API flaw is a perfect case study in how legacy code haunts modern security. The function was designed in an era before UIPI existed, and Microsoft never revisited its security assumptions. It’s a reminder that even well-documented APIs can harbor silent killers. The broader lesson? Attackers don’t need zero-days when they can exploit forgotten features. As Windows continues to pile on security layers, the cracks between them—like this API—become the new frontier for privilege escalation. Expect more discoveries like this as researchers dig into the OS’s dusty corners.

Microsoft just patched a major security blind spot in Windows—and it’s been hiding in plain sight for years. Researcher found 9 ways to bypass the new Administrator Protection feature before it even shipped. Five of those bypasses share a single root cause: a long-standing UAC weakness called UI Access. This isn’t just a bug. It’s a design flaw that’s been quietly undermining Windows security since Vista. And it puts every system running Administrator Protection at risk—until you apply the fixes.

**What exactly happened** Security researcher (and blog author) discovered 9 distinct bypasses for Microsoft’s new Administrator Protection feature—a security boundary designed to lock down User Account Control (UAC). Five of those bypasses share a common root cause: the way Windows handles UI Access, a mechanism that’s been around since Vista. Microsoft has now patched all 9 issues. But the story reveals a deeper, older problem that’s been lurking in Windows for over a decade. **Who is affected and how** Anyone running Windows with Administrator Protection enabled is potentially vulnerable. The bypasses allow a limited user (standard account) to interact with privileged windows—like those created by SYSTEM or administrator-level processes. Think of it like this: a low-level employee can send messages to the CEO’s computer screen, and the CEO’s system treats those messages as legitimate commands. That’s the core risk here. **The real-world impact and consequences** In practice, an attacker who already has limited access to a machine can exploit these flaws to escalate privileges. They could hijack admin-level prompts, inject keystrokes, or manipulate UI elements to execute code with higher permissions. This isn’t a remote exploit. But it’s a powerful stepping stone once an attacker gains an initial foothold. For enterprises, that means a single compromised standard user account could lead to full system compromise. **Technical breakdown—the “how” explained simply** Windows uses something called User Interface Privacy Isolation (UIPI) to block low-integrity processes from interacting with high-integrity windows. It’s like a security guard checking badges at the door. But UI Access is a special pass. It allows certain processes to bypass this guard—even if they’re running at a lower integrity level. The problem? Microsoft didn’t properly restrict which processes could get that pass. The researcher found that by abusing UI Access, a limited user could still send window messages to privileged processes. This effectively reopens the door to “Shatter Attacks”—an old attack class that Microsoft thought it had closed with UIPI. **What should be done—mitigation and recommendations** First, apply the latest Windows security updates. Microsoft has fixed all 9 bypasses the researcher reported. Second, review your Administrator Protection configuration. The feature is still valuable, but it’s not a silver bullet. Combine it with other defenses like AppLocker, Windows Defender Application Control, and strict user account policies. Third, monitor for suspicious UI interaction patterns. If you see low-integrity processes sending messages to high-integrity windows, that’s a red flag. **Why this matters in the bigger cybersecurity landscape** This research highlights a painful truth: security features often inherit the flaws of their predecessors. Administrator Protection was built on top of UAC, which was built on top of UIPI, which was built on top of the old desktop messaging system. Each layer adds complexity—and new attack surface. The fact that 9 bypasses existed before the feature even launched suggests Microsoft needs to invest more in pre-release security testing. For defenders, this is a reminder that “new and improved” doesn’t mean “invulnerable.” Always test, always patch, and never assume a security boundary is airtight.