Daily Digest

Day two of Pwn2Own Berlin 2026 just dropped a bombshell: researchers walked away with nearly $400,000 after shredding 15 zero-day vulnerabilities in products you probably use every day. The biggest scalp? Microsoft Exchange was completely owned by a single researcher who chained three bugs together to gain full SYSTEM-level remote code execution. Windows 11 also fell, along with Red Hat Enterprise Linux and NVIDIA's container toolkit. If you're running any of these, pay attention—because the clock is now ticking on patches.

**What exactly happened** The second day of Pwn2Own Berlin 2026 saw security researchers collect $385,750 in bounties after successfully exploiting 15 unique zero-day vulnerabilities. The competition, running from May 14-16 at the OffensiveCon conference, focuses on enterprise tech and AI—and the results show just how vulnerable these systems still are. The star of the show was Cheng-Da Tsai (Orange Tsai) from DEVCORE Research Team, who walked away with a massive $200,000 prize. He chained three separate bugs together to achieve remote code execution with SYSTEM privileges on Microsoft Exchange. That means he could run any code as the highest-level administrator on the server—no user interaction required. **Who is affected and how** If your organization runs Microsoft Exchange for email, Windows 11 on endpoints, or Red Hat Enterprise Linux on workstations, you're in the crosshairs. The bugs demonstrated at Pwn2Own are all zero-days—meaning they were previously unknown to the vendors. Siyeon Wi earned $7,500 for exploiting an integer overflow bug to hack Windows 11. Ben Koo of Team DDOS escalated privileges to root on Red Hat Enterprise Linux for Workstations, pocketing $10,000. Meanwhile, 0xDACA and Noam Trobishi used a use-after-free bug to exploit the NVIDIA Container Toolkit. **The real-world impact and consequences** These aren't just academic exercises. The Microsoft Exchange chain is particularly dangerous because Exchange servers are often internet-facing and handle sensitive communications. A remote code execution bug at SYSTEM level means an attacker could steal emails, deploy ransomware, or pivot to other systems on the network. The Windows 11 privilege escalation bugs—three of which were demonstrated on day one alone—could let attackers break out of restricted user accounts and take over machines. For enterprises, that's a nightmare scenario: one compromised endpoint becomes a launchpad for lateral movement. **Technical breakdown (the "how" explained simply)** Orange Tsai's Exchange exploit worked by chaining three bugs together. Think of it like picking three locks in sequence: the first bug bypassed authentication, the second gave him a foothold, and the third escalated his access to SYSTEM level. Each bug on its own might be harmless, but combined they create a devastating attack chain. The Windows 11 integer overflow bug exploited by Siyeon Wi works differently. It tricks the operating system into miscalculating memory allocation, causing a buffer overflow that lets the attacker write malicious code into protected memory areas. Once there, the code runs with elevated privileges. **What should be done — mitigation and recommendations** Here's the good news: vendors have 90 days to patch after disclosure at Pwn2Own. That means Microsoft, Red Hat, and NVIDIA are already working on fixes. But don't wait—apply any available patches immediately when they drop. For Exchange specifically, consider enabling Extended Protection and restricting access to trusted IP ranges until the patch arrives. For Windows 11, ensure your endpoint detection and response (EDR) tools are active and monitoring for privilege escalation attempts. **Why this matters in the bigger cybersecurity landscape** Pwn2Own isn't just a competition—it's a reality check. Every year, researchers prove that "fully patched" systems still have gaping holes. The fact that 15 zero-days were found in just one day shows how much work remains. The inclusion of AI coding agents like Cursor and OpenAI Codex in this year's event is also telling. Le Duc Anh Vu of Viettel Cyber Security hacked Cursor for $30,000, while Sina Kheirkhah demoed an OpenAI Codex zero-day for $20,000. As AI tools become embedded in development workflows, they're creating new attack surfaces that attackers will eagerly exploit. The bottom line? Stay vigilant, patch fast, and remember that even the most secure systems have secrets waiting to be uncovered.

Imagine running a thriving WooCommerce store, only to discover that every single checkout page is silently bleeding your customers' credit card data to criminals. That's exactly what's happening right now to thousands of WordPress sites. A critical, unauthenticated vulnerability in the Funnel Builder plugin—used by over 40,000 websites to customize checkout flows—is being actively exploited. Attackers are injecting malicious JavaScript that steals credit card numbers, CVVs, and billing addresses without leaving obvious traces. If you use Funnel Builder, your customers' financial data is at immediate risk.

**What exactly happened** Security researchers at Sansec uncovered an active exploitation campaign targeting the Funnel Builder plugin for WordPress. The vulnerability, which currently lacks an official CVE identifier, allows attackers to inject malicious JavaScript into WooCommerce checkout pages without any authentication. The flaw affects all versions of Funnel Builder prior to version 3.15.0.3. FunnelKit, the plugin's developer, released a patch yesterday to address the issue. **Who is affected and how** Funnel Builder is active on more than 40,000 websites according to WordPress.org statistics. Any WooCommerce store using an outdated version of this plugin is vulnerable. The attack works through an unprotected, publicly exposed checkout endpoint. This allows attackers to modify the plugin's global settings, specifically the "External Scripts" field, injecting arbitrary JavaScript that executes on every checkout page. **The real-world impact and consequences** The injected payload masquerades as a legitimate Google Tag Manager or Google Analytics script. In reality, it opens a WebSocket connection to an attacker-controlled server at wss://protect-wss[.]com/ws. Once connected, the server delivers a customized payment card skimmer that captures credit card numbers, CVVs, billing addresses, and other customer information. This data is then used for fraudulent purchases or sold on dark web carding markets. For store owners, the consequences are severe: stolen customer data, potential chargebacks, regulatory fines, and devastating reputational damage. **Technical breakdown** The malicious script is hosted at analytics-reports[.]com/wss/jquery-lib.js. It disguises itself as a legitimate analytics tool to evade detection. The WebSocket connection allows real-time data exfiltration, meaning stolen information flows directly to attackers as customers complete their purchases. This technique is harder to detect than traditional form-grabbing scripts because it mimics legitimate network traffic. **What should be done — mitigation and recommendations** FunnelKit has released version 3.15.0.3 of Funnel Builder. Website owners must update immediately from the WordPress dashboard. After updating, review Settings > Checkout > External Scripts for any suspicious scripts the attacker may have added. Remove anything unfamiliar. Consider implementing a Web Application Firewall (WAF) and monitoring for connections to known malicious domains like analytics-reports[.]com and protect-wss[.]com. **Why this matters in the bigger cybersecurity landscape** This incident highlights a growing trend: plugin vulnerabilities becoming entry points for supply chain attacks on e-commerce platforms. With over 40,000 potential targets, the blast radius is enormous. The lack of an official CVE identifier also raises concerns about vulnerability disclosure and patch adoption. Without proper tracking, many site owners may remain unaware of the threat until it's too late. For the cybersecurity community, this serves as a reminder that even popular, well-maintained plugins can harbor critical flaws. The real battle isn't just finding vulnerabilities—it's ensuring patches reach every vulnerable site before attackers do.

A new supply chain attack has hit the npm ecosystem, this time targeting **node-ipc** — a wildly popular inter-process communication package with over 690,000 weekly downloads. The malicious versions (9.1.6, 9.2.3, and 12.0.1) are now actively stealing credentials from developers' machines. If you or your team use node-ipc, your cloud keys, SSH secrets, Kubernetes tokens, and even macOS Keychain files could already be in the hands of attackers. This isn't just another bug — it's a silent heist that runs automatically the moment your application loads.

**What exactly happened** Hackers compromised the account of an inactive maintainer named 'atiertant' and injected credential-stealing malware into three new versions of node-ipc. The malicious code hides inside the CommonJS entrypoint (node-ipc.cjs) and executes automatically whenever any application loads that package. The attack was detected by multiple security firms — Socket, Ox Security, and Upwind — who confirmed the following versions as dangerous: 9.1.6, 9.2.3, and 12.0.1. The malware is heavily obfuscated, making it difficult to spot during routine code reviews. **Who is affected and how** Anyone who installed or updated node-ipc to these versions is at risk. The package is a Node.js module used for inter-process communication across Unix, Windows, UDP, TLS, and TCP sockets — meaning it's embedded in countless applications and development environments. The malware doesn't need user interaction beyond a standard npm install or update. It runs silently in the background, fingerprinting the system and collecting sensitive data before you even notice anything unusual. **The real-world impact and consequences** This isn't a minor data leak. The malware targets a terrifyingly broad range of credentials: cloud keys from AWS, Azure, GCP, OCI, and DigitalOcean; SSH keys and configs; Kubernetes, Docker, Helm, and Terraform credentials; npm, GitHub, GitLab, and Git CLI tokens; .env files and database credentials; shell histories and CI/CD secrets; even macOS Keychain files and Firefox profile databases. For developers and DevOps teams, this is a worst-case scenario. A single infected machine could expose an entire cloud infrastructure, CI/CD pipeline, and source code repositories. The attackers are after the keys to your digital kingdom. **Technical breakdown — how it works** The malware uses a clever exfiltration method: instead of standard HTTP-based command-and-control traffic, it sends stolen data through DNS TXT queries. The attackers operate a fake Azure-themed domain (sh[.]azurestaticprovider[.]net:443) as a bootstrap resolver, transmitting data to 'bt[.]node[.]js' with query prefixes like xh, xd, and xf. This technique helps the malicious traffic blend into normal DNS activity. According to Socket, exfiltrating a 500 KB compressed archive could generate roughly 29,400 DNS TXT requests — a massive amount of data hidden in plain sight. The malware stores collected data in temporary compressed tar.gz archives, which are deleted after exfiltration to reduce forensic traces. It also skips files larger than 4 MiB and avoids scanning .git and node_modules directories to increase efficiency and reduce operational noise. Notably, the malware does not establish persistence or download any secondary payloads. This suggests the operation is laser-focused on rapid credential theft and exfiltration — grab what you can and disappear. **What should be done — mitigation and recommendations** If you or your team use node-ipc, act immediately. Remove the affected versions (9.1.6, 9.2.3, and 12.0.1) from all environments. Rotate every exposed secret and credential — cloud keys, SSH keys, API tokens, database passwords, and CI/CD secrets. Inspect your lockfiles and npm caches for any traces of the malicious versions. Run a full security scan on affected machines. Assume that any system that loaded these versions may have been compromised. **Why this matters in the bigger cybersecurity landscape** This attack is a stark reminder that the npm ecosystem remains a prime target for supply chain attacks. The fact that node-ipc still has 690,000 weekly downloads — despite its maintainer publishing weaponized versions in March 2022 that targeted Russian and Belarusian systems with a data-overwriting module — shows how deeply trust is embedded in open source dependencies. The use of DNS TXT queries for exfiltration is particularly concerning. It's a stealth technique that many traditional security tools miss, and it signals that attackers are evolving their tradecraft to evade detection. For the cybersecurity community, this is a wake-up call: we need better mechanisms for verifying package integrity, monitoring maintainer accounts for compromise, and detecting anomalous behavior in dependency chains. The next attack might not be so easy to spot.

Microsoft just did a 180 on a major security headache. After initially telling a researcher that Edge loading all your saved passwords into memory at startup was "by design," the company has now reversed course and is rolling out a fix. This matters because any attacker who gains admin access to your machine could dump every password stored in Edge in plain text—even if you never visited a login page. If you use Edge's built-in password manager, your credentials have been sitting exposed in memory since you launched the browser.

**What exactly happened** Security researcher Tom Jøran Sønstebyseter Rønning dropped a bombshell on May 4. He discovered that Microsoft Edge decrypts every saved password stored in its built-in password manager the moment the browser starts—and keeps them sitting in process memory in clear text. Even if you never open a login page, your credentials are there, exposed. Rønning even released a proof-of-concept tool that can dump passwords from other users' Edge processes, as long as the attacker has Administrator privileges. **Who is affected and how** Anyone using Edge's built-in password manager is affected. That includes millions of consumers and enterprise users who rely on Microsoft's browser for credential storage. The risk is highest for shared or corporate devices. If an attacker gains admin access—through malware, a compromised account, or physical access—they can extract every password you've ever saved in Edge. On personal machines, the threat is lower but still real if malware escalates privileges. **The real-world impact and consequences** This isn't a theoretical vulnerability. Rønning's PoC tool demonstrates a practical attack path that requires no special skills. An attacker with admin rights can silently dump passwords from memory without triggering alerts. For enterprises, this is a compliance nightmare. Saved credentials for corporate apps, VPNs, and cloud services could be exfiltrated in seconds. The fact that Microsoft initially dismissed this as "by design" only amplified the concern. **Technical breakdown** Here's the simple version: Most Chromium-based browsers, like Chrome, only decrypt passwords when you actually need them—like when autofill triggers on a login page. Edge was doing the opposite: decrypting everything at startup and keeping it in memory. This means the passwords were always accessible in process memory, even when the browser was idle. An admin-level attacker could simply read that memory dump and extract plaintext credentials. Chrome's architecture makes this far harder because decryption happens on-demand. **What should be done — mitigation and recommendations** Microsoft has finally listened. The fix is already live in Edge Canary and will roll out to all channels (Stable, Beta, Dev, Extended Stable) in build 148 and newer. In the meantime, users should consider switching to a dedicated password manager that encrypts credentials at rest and only decrypts them on demand. Enterprise admins should enforce this update as soon as it's available and review their threat models for scenarios where admin-level access could be compromised. **Why this matters in the bigger cybersecurity landscape** This incident highlights a growing tension in the industry: what vendors consider "by design" vs. what security researchers and users consider acceptable risk. Microsoft's initial dismissal was a red flag, but their reversal shows that public pressure and researcher disclosures can drive meaningful change. The bigger lesson? Password managers are only as secure as their implementation. Even trusted built-in tools can have blind spots. As credential theft remains the top attack vector, every layer of defense-in-depth matters—and this fix is a practical step in the right direction.

A massive data extortion attack just hit Canvas, the education platform used by nearly 9,000 schools and universities across the U.S. Hackers defaced the login page with a ransom demand, threatening to leak data on 275 million students and faculty. Classes were disrupted nationwide as Instructure, Canvas's parent company, scrambled to shut down the platform. The cybercrime group ShinyHunters is behind the breach, and they've already stolen names, emails, and student IDs. If you're a student, teacher, or admin at an affected institution, your personal info may be in the crosshairs.

**What exactly happened** On May 6, ShinyHunters—a notorious cybercrime group—claimed responsibility for breaching Canvas, the dominant learning management system in U.S. education. They defaced the login page with a ransom note, threatening to leak data on 275 million users unless paid by a deadline that was later extended to May 12. Instructure responded by temporarily disabling the platform, causing widespread disruption. Schools and universities lost access to coursework, assignments, and communication tools, effectively freezing academic operations for thousands of institutions. **Who is affected and how** The breach impacts nearly 9,000 educational institutions across the U.S., including K-12 school districts and major universities. Anyone with a Canvas account—students, faculty, and administrators—is potentially affected. The stolen data includes names, email addresses, and student ID numbers, as well as internal messages between users. While Instructure claims no passwords, birth dates, or financial data were taken, the exposed information is still a goldmine for phishing attacks and identity theft. **The real-world impact and consequences** For students, this means a heightened risk of targeted scams. Hackers can use names and email addresses to craft convincing phishing emails that appear to come from school officials. For institutions, the reputational damage is severe—trust in digital learning platforms is shaken. The immediate disruption also caused academic chaos. Classes were delayed, assignments went missing, and communication channels went dark. Some schools had to revert to paper-based learning, highlighting how dependent education has become on a single platform. **Technical breakdown** ShinyHunters likely gained access through compromised credentials or a vulnerability in Canvas's third-party integrations. Once inside, they exfiltrated user data from databases and then defaced the login page by modifying server-side files or exploiting a content management system flaw. The defacement itself was a bold move—it served as both a ransom demand and a public shaming tactic. By targeting the login page, the hackers ensured every user saw the threat, amplifying pressure on Instructure to pay up. **What should be done** Instructure has since paid the ransom and received digital confirmation that the stolen data was destroyed. They've assured customers that no further extortion attempts will target them directly. For affected users, the immediate steps are clear: change your Canvas password if you haven't already, enable multi-factor authentication, and be extra vigilant for phishing emails that reference the breach. Schools should also review their incident response plans and consider diversifying their edtech tools to avoid single points of failure. **Why this matters in the bigger cybersecurity landscape** This breach is a wake-up call for the education sector, which has long been underfunded in cybersecurity. With over 275 million records at stake, it's one of the largest education-related data breaches in history. It also underscores a troubling trend: cybercriminals are increasingly targeting critical infrastructure—and education is now squarely in their crosshairs. The fact that Instructure paid the ransom sets a dangerous precedent, potentially encouraging more attacks on similar platforms. For students and educators, the lesson is harsh: your digital classroom is now a battleground.

Google's Pixel 10 just got hit with a zero-click exploit chain that proves one thing: patching one door doesn't mean the windows are locked. Researchers took their Pixel 9 exploit—a two-step chain that goes from zero-click to full root access—and adapted it for the Pixel 10. The old vulnerability in Dolby audio code was fixed, but a new driver called VPU opened an even bigger attack surface. If you're on a Pixel 10 with a security patch level before December 2025, your device is at risk.

**What exactly happened** Security researchers published an exploit chain for the Google Pixel 10 that demonstrates a complete zero-click to root compromise. This builds on their earlier work targeting the Pixel 9, which used a Dolby audio vulnerability (CVE-2025-54957) patched in January 2026. The key finding? Even when Google fixed the original Dolby bug across all Android devices, the Pixel 10 introduced a new driver called VPU that replaced the removed BigWave driver. This created a fresh attack surface. **Who is affected and how** Pixel 10 users with security patch levels from December 2025 or earlier are vulnerable. The exploit requires no user interaction—just receiving a specially crafted media file can trigger the chain. The attack works in two stages. First, a zero-click exploit targets the Dolby audio decoder to gain code execution in a privileged media process. Second, a local privilege escalation exploit uses the VPU driver to elevate that access to full root. **The real-world impact and consequences** Root access on Android means an attacker can read any data, install persistent malware, bypass all security controls, and even modify the device firmware. This is the nightmare scenario for mobile security. For journalists, activists, or corporate executives, a zero-click root exploit means their device can be compromised without any warning. No phishing email, no malicious link—just receiving a media file is enough. **Technical breakdown** The researchers updated their Dolby exploit for Pixel 10 by recalculating memory offsets and adapting to a new security feature called RET PAC. Instead of overwriting `__stack_chk_fail` (which wasn't available), they targeted `dap_cpdp_init`—initialization code that runs once and never again. The bigger challenge was the missing BigWave driver. But the VPU driver, which handles video processing, turned out to be exploitable. The researchers found a vulnerability in how VPU manages memory, allowing them to escalate privileges from the media process to root. **What should be done** Pixel 10 users must install the January 2026 security update immediately. This patch fixes both the Dolby vulnerability and the VPU driver issue. For organizations, this is a reminder to enforce strict patch management policies. Zero-click exploits don't give users a chance to react—only proactive patching can prevent compromise. **Why this matters** This research exposes a fundamental problem in mobile security: closing one vulnerability often opens another. When Google removed the BigWave driver, they introduced VPU without adequate security review. The bigger lesson is that software vendors need to treat every new feature as a potential attack surface. Code auditing and security testing should happen before release, not after researchers find the flaws. For the cybersecurity community, this chain proves that Android's defense-in-depth is only as strong as its weakest link. And sometimes, that link is a brand-new driver nobody thought to test.

A long-forgotten Windows API called GetProcessHandleFromHwnd has been quietly handing attackers a golden ticket to escalate privileges. Originally designed to help UI Automation apps grab process handles, it turns out this function bypasses critical security checks—letting low-integrity processes steal handles from higher-integrity ones. The bug was publicly exposed through a UAC bypass in the Quick Assist app, but the real story runs deeper. Microsoft's own documentation is outdated and misleading, while the kernel-level implementation has been missing a crucial protection check for years. If you're running Windows 11 24H2 or earlier, your system may be vulnerable to privilege escalation attacks that exploit this API.

**What exactly happened** Security researchers discovered that GetProcessHandleFromHwnd, a Windows API intended for UI Automation scenarios, contains a critical security flaw. The API was designed to return a process handle for any given window handle (HWND), but its kernel-mode implementation bypasses User Interface Privilege Isolation (UIPI) checks. The vulnerability was first noticed in a publicly disclosed UAC bypass using the Quick Assist UI Access application. Researchers digging deeper found the API's behavior contradicted Microsoft's own documentation in three key ways: it doesn't actually use Windows hooks, it doesn't require UIAccess for all scenarios, and it can succeed across different integrity levels. **Who is affected and how** Any Windows system running versions prior to Windows 11 24H2 is potentially vulnerable. The attack vector is particularly dangerous for systems with UI Access applications installed, as these programs can call the API from a lower integrity level and obtain handles to higher-integrity processes. The Quick Assist application became the poster child for this exploit, but the underlying API flaw affects any software that can invoke GetProcessHandleFromHwnd. Attackers who already have limited access to a system can use this to escalate privileges, potentially gaining SYSTEM-level access. **The real-world impact and consequences** This isn't just a theoretical vulnerability. The UAC bypass using Quick Assist has already been weaponized in real attacks. The ability to obtain process handles across integrity boundaries means attackers can: - Inject malicious code into higher-privilege processes - Read sensitive memory from protected applications - Escalate from standard user to administrator or SYSTEM - Bypass security software that relies on process isolation The fix in Windows 11 24H2 suggests Microsoft recognized the severity, but older systems remain exposed until patched. **Technical breakdown** The API's implementation reveals a classic security oversight. GetProcessHandleFromHwnd runs entirely in kernel mode (win32k.sys), where it directly opens the target process handle. The original design assumed that only UI Access applications would call it, but the kernel doesn't enforce this restriction. The critical missing check was for protected processes. While the API correctly verifies the caller has appropriate access rights, it fails to validate whether the target process is a protected process (like antivirus or critical system components). This means an attacker can obtain handles to processes that should be completely isolated. The fix in Windows 11 24H2 adds proper UIPI enforcement and protected process checks, making the API behave as originally documented—but it took years to correct. **What should be done** For immediate protection, organizations should: - Apply the Windows 11 24H2 update or relevant security patches - Disable or restrict UI Access applications like Quick Assist where not needed - Monitor for unusual process handle duplication events - Implement application whitelisting to prevent unauthorized UI Access programs Users should ensure Windows Update is enabled and apply patches promptly. Security teams should prioritize testing and deploying the 24H2 update in their environments. **Why this matters** This vulnerability highlights a recurring theme in Windows security: legacy APIs with outdated assumptions. GetProcessHandleFromHwnd was designed in an era when UIPI didn't exist and UI Access was considered sufficient protection. The disconnect between documentation, implementation, and security reality created a blind spot that attackers exploited. The fix in 24H2 signals Microsoft's renewed focus on UIPI enforcement, but it also raises questions about other undocumented API behaviors. For defenders, this case reinforces the importance of auditing even "convenience" functions, as they often bypass security controls in unexpected ways. The lesson is clear: in cybersecurity, assumptions are the enemy of security.

Microsoft just patched nine critical bypasses in its shiny new Administrator Protection feature for Windows—and five of them share a dirty little secret. The root cause? A decades-old UI Access mechanism that’s been quietly undermining UAC security since Vista. If you’re running Windows 11 or Server 2022+, your Administrator Protection might not be as bulletproof as you think. These bypasses let attackers silently elevate privileges from a standard user to full admin, and the fix only arrived after public disclosure. Time to check if your defenses are truly locked down.

**What exactly happened** Security researcher [Author] uncovered nine distinct ways to bypass Windows Administrator Protection—a feature Microsoft designed to create a real security boundary for User Account Control (UAC). Five of those bypasses share a common root cause: the UI Access (UIA) mechanism, a legacy component that’s been a hidden weak spot since Windows Vista. Microsoft has now patched all nine issues, but the research reveals a deeper problem. The UIA system, originally meant to let accessibility tools interact with elevated windows, was never designed for today’s privilege separation requirements. **Who is affected and how** Anyone running Windows 11 22H2 or later, or Windows Server 2022+, with Administrator Protection enabled is potentially exposed. The bypasses allow a standard user process to interact with administrator-level windows, sending messages that can trigger privilege escalation. This isn’t a theoretical attack—it’s a practical one. An attacker who already has limited user access (say, through malware or a compromised account) can exploit these flaws to gain full admin rights. No additional vulnerabilities needed. **The real-world impact and consequences** The stakes are high. Administrator Protection was supposed to be Microsoft’s answer to years of UAC bypasses—a feature that finally makes “run as administrator” mean something. These bypasses undermine that promise entirely. For enterprises, this means a feature marketed as a security boundary could be silently bypassed by determined attackers. The fix is out, but patching requires coordination, and many organizations may not even know they’re vulnerable. **Technical breakdown (the “how” explained simply)** Here’s the core issue in plain language: Windows uses something called Mandatory Integrity Control to separate processes by privilege level. A standard user process (low integrity) shouldn’t be able to send messages to an admin process (high integrity). But UI Access was designed as an exception—it lets certain trusted processes (like screen readers) interact across integrity levels. The researchers found that this exception was too broad. By abusing how UI Access tokens are assigned and how windows are created, an attacker can trick the system into allowing cross-integrity communication. Think of it like a VIP lounge with a special door for service staff. The researchers found that the service staff badge could be easily copied, and the door didn’t check who was actually holding it. **What should be done — mitigation and recommendations** First, apply the latest Windows security updates immediately. Microsoft has fixed all nine bypasses in the November 2023 Patch Tuesday release. Second, review your Administrator Protection configuration. The feature is still valuable, but it’s not a silver bullet. Combine it with other security layers like AppLocker, Windows Defender Application Control, and least-privilege principles. Third, test your own environment. If you’re a security admin, simulate these bypasses (using the public research) to ensure your patching is effective. Don’t assume—verify. **Why this matters in the bigger cybersecurity landscape** This research exposes a fundamental tension in Windows security: legacy features versus modern threats. UI Access was designed for a world where privilege separation barely existed. Today, it’s a liability. Microsoft is taking Administrator Protection seriously, but the fact that nine bypasses existed at launch—and that five stem from a known weak point—raises questions about the company’s testing rigor. For defenders, the lesson is clear: trust features, but verify them. And never assume a security boundary is impenetrable just because it’s new.