Daily Digest

Imagine logging into your school's main platform to check assignments, only to find a ransom demand plastered across the screen instead. That's exactly what happened today to students and faculty across the U.S. when the widely-used education platform Canvas was hit by a massive data extortion attack. The cybercrime group ShinyHunters defaced login pages and threatened to leak data on 275 million users from nearly 9,000 institutions. This isn't just a minor glitch—it's a full-blown crisis that disrupted classes nationwide and exposed personal information on a staggering scale. If you're a student, teacher, or administrator using Canvas, your data may already be in the crosshairs.

**What exactly happened** The attack unfolded in two brutal waves. First, ShinyHunters claimed responsibility for breaching Canvas's systems and stealing data on tens of millions of users. Then, they defaced the platform's login page with a ransom demand, effectively holding the entire educational ecosystem hostage. Instructure, Canvas's parent company, responded by temporarily disabling the platform. This move caused immediate chaos for schools and universities that rely on Canvas for coursework, assignments, and communication. The hackers initially set a payment deadline of May 6, later extended to May 12. In a twist, Instructure confirmed they eventually paid the extortionists in exchange for a promise to destroy the stolen data and received digital confirmation of the data's destruction. **Who is affected and how** The breach impacts a mind-boggling 275 million students and faculty across nearly 9,000 educational institutions. That's not a typo—275 million individuals potentially exposed. Canvas isn't just used by K-12 schools and universities. It's also deployed by businesses for training and development, meaning the ripple effects extend far beyond the classroom. For students, this means disrupted access to assignments, grades, and course materials. For faculty, it's lost teaching time and compromised communication channels. For IT administrators, it's a nightmare of damage control and reputation management. **The real-world impact and consequences** The immediate impact was a service outage that ground academic life to a halt. Imagine thousands of schools unable to deliver lessons or collect homework on the same day. The longer-term consequences are more insidious. Stolen data includes names, email addresses, and student ID numbers—the perfect ingredients for targeted phishing attacks and identity theft. Even though Instructure claims no passwords, financial data, or government IDs were taken, the exposed information is still dangerous. Cybercriminals can use these details to craft convincing scams aimed at students and faculty for years to come. **Technical breakdown** The breach appears to have originated from a compromise of Instructure's internal systems, though the exact entry point hasn't been disclosed. ShinyHunters, a group known for targeting education and tech platforms, likely exploited weak access controls or a vulnerable API. The stolen data specifically includes "identifying information" such as names, email addresses, and student ID numbers, plus internal messages between users. This suggests the attackers gained access to user directories and communication databases. Instructure's investigation found no evidence of password hashes, financial records, or biometric data being compromised. However, the sheer volume of data—275 million records—makes this one of the largest education sector breaches on record. **What should be done** For affected institutions, the first step is to assume all exposed data is now in the hands of criminals. Reset any non-password credentials, like student ID numbers, if possible. Users should be on high alert for phishing emails that reference Canvas or their school. Cybercriminals will weaponize the stolen names and email addresses to make scams look legitimate. Enable multi-factor authentication on all school-related accounts immediately. Even if passwords weren't stolen, this extra layer of security can prevent account takeovers. Instructure has promised to directly contact all affected organizations with validated information. Schools should coordinate with them to understand exactly what data was exposed and what remediation steps are available. **Why this matters in the bigger cybersecurity landscape** This breach is a stark reminder that education technology platforms hold a treasure trove of personal data, often with weaker security than financial or healthcare systems. The decision by Instructure to pay the ransom—and the hackers' apparent compliance in destroying the data—sets a dangerous precedent. It signals to cybercriminals that targeting edtech platforms can be highly profitable. More importantly, the attack exposed a critical vulnerability in our educational infrastructure. When a single platform like Canvas goes down, it doesn't just inconvenience students—it halts learning for millions. As schools increasingly rely on centralized digital platforms, the attack surface grows. This breach should serve as a wake-up call for every educational institution to audit their third-party vendors and demand stronger security guarantees.

A massive software supply chain attack just hit the developer community hard. Hackers hijacked trusted build pipelines to push malicious packages with verified security stamps onto npm and PyPI. The Shai-Hulud campaign, linked to the TeamPCP group, compromised hundreds of packages from major projects including TanStack, Mistral AI, Guardrails AI, and UiPath. If you're a developer who installed any of these packages recently, your credentials might already be stolen.

**What exactly happened** The Shai-Hulud attack is a sophisticated supply chain compromise that weaponizes trust. The threat actor stole valid OpenID Connect (OIDC) tokens from legitimate CI/CD pipelines, allowing them to publish malicious package versions that carried verifiable provenance attestations (SLSA Build Level 3). This means the infected packages looked completely authentic. They were signed by npm's own infrastructure and tied to legitimate release workflows. The attackers didn't break in through the front door—they walked through the authorized entrance. **Who is affected and how** Hundreds of packages across npm and PyPI have been compromised. The attack started with TanStack and Mistral AI packages but quickly spread to Guardrails AI, UiPath, OpenSearch, Bitwarden CLI, and official SAP packages. Endor Labs reports over 160 compromised npm packages. Aikido recorded 373 malicious package-version entries. Socket tracked 416 compromised entries. The scale is massive. **The real-world impact and consequences** This isn't just about broken code. The malware delivers credential-stealing payloads. For developers, that means exposed API keys, database credentials, and cloud access tokens. The previous iteration of this campaign already exposed hundreds of thousands of developer secrets in automatically generated GitHub repositories. This wave is likely worse. If you've installed any affected package, your entire development environment could be compromised. **Technical breakdown** The attack exploits a fundamental trust gap. Modern package ecosystems use provenance attestations to verify that a package came from its legitimate source. The Shai-Hulud attackers bypassed this by stealing CI/CD credentials and running their malicious builds through the real project's pipeline. The result? Packages that pass all automated security checks. They have valid signatures, correct provenance, and appear in the official registry. Traditional security tools that only verify signatures would flag these as safe. **What should be done — mitigation and recommendations** Immediate action: Check your project dependencies against the published lists of compromised packages. Rotate any credentials stored in environments that may have installed these packages. For the short term, add behavioral analysis at install time. Don't rely solely on provenance verification. Implement signature-based checks specifically designed to detect malicious packages. For the long term, enforce lockfile-only installs. This prevents automatic or silent package updates that could pull in compromised versions. Consider using package pinning and dependency locking as standard practice. **Why this matters in the bigger cybersecurity landscape** This attack exposes a critical vulnerability in how we trust software supply chains. Provenance attestations were supposed to solve the trust problem, but attackers have already found a way to weaponize them. The Shai-Hulud campaign shows that signature verification alone is not enough. We need multi-layered security that combines provenance checks with behavioral analysis, anomaly detection, and real-time monitoring. For the developer community, this is a wake-up call. The tools we trust to protect us can be turned against us. The only defense is to never trust any single verification method and always verify from multiple angles.

Edtech giant Instructure just paid off ShinyHunters to stop a massive data leak. The deal covers 30 million Canvas users across 8,000 schools worldwide. But here’s the catch: paying extortionists never guarantees your data is safe. The FBI has warned repeatedly that stolen data often gets sold again anyway. If you use Canvas, your information may still be at risk.

**What exactly happened** Instructure confirmed this week that it reached an “agreement” with the ShinyHunters extortion group to prevent stolen data from being leaked online. The cybercrime gang claimed responsibility for stealing over 3.6TB of uncompressed data from the company’s systems. The company says the attackers returned the stolen data and provided shred logs confirming its destruction. But as any cybersecurity professional will tell you, digital shred logs are about as trustworthy as a politician’s promise. **Who is affected and how** Over 30 million educators and students use Canvas across more than 8,000 schools and universities worldwide. That’s a massive attack surface, and every single one of those users could be impacted. ShinyHunters didn’t just steal data. They also defaced Canvas login portals at institutions like the University of Texas San Antonio, leaving extortion messages warning that customers had until May 12 to negotiate a ransom. **The real-world impact and consequences** Instructure claims that “no Instructure customers will be extorted as a result of this incident.” But here’s the uncomfortable truth: paying ransoms creates a dangerous precedent. It tells cybercriminals that targeting edtech platforms is profitable. The FBI has repeatedly warned that paying ransoms doesn’t guarantee threat actors won’t sell stolen data to other criminals or attempt to extort victims again. This deal might stop the immediate leak, but the long-term risk remains. **Technical breakdown** ShinyHunters exploited multiple cross-site scripting (XSS) vulnerabilities in Canvas’s Free-for-Teacher environment. This is a free, limited version of Canvas designed for individual educators. The attackers injected malicious JavaScript to exploit XSS flaws in user-generated content features. This allowed them to obtain authenticated admin sessions and perform privileged actions they shouldn’t have had access to. Even more concerning: ShinyHunters hacked Instructure again on May 7 using the same vulnerability. That’s a clear sign that the initial fix was either incomplete or ineffective. **What should be done** Instructure has temporarily shut down Free-For-Teacher accounts while it works to resolve these security issues. The company recommends that customers “continue normal monitoring of their Canvas environments, integrations, and administrative activity.” For schools and universities using Canvas, now is the time to review access controls, enable multi-factor authentication, and monitor for unusual admin activity. Don’t rely on Instructure’s word alone—verify your own security posture. **Why this matters in the bigger cybersecurity landscape** This breach is part of a worrying trend. ShinyHunters has recently claimed attacks on Google, Cisco, PornHub, the European Commission, Match Group, Rockstar Games, ADT, Vimeo, McGraw-Hill, Medtronic, and Zara. The targeting of edtech platforms is particularly alarming. Schools and universities hold sensitive data on millions of students, including personal information, academic records, and sometimes financial details. These institutions often have limited cybersecurity budgets and expertise. When a company like Instructure pays off attackers, it sends a signal that educational data is a lucrative target. The May 13 webinar where Instructure promises to share more details will be worth watching—but don’t expect full transparency.

General Motors just got slapped with a record $12.75 million fine for selling your driving data without asking. California officials caught the automaker quietly collecting location and driving behavior through its OnStar “Smart Driver” system, then handing that data to brokers like Verisk and LexisNexis. If you drive a Chevy, GMC, Cadillac, or Buick, your car may have been spying on you for years. The settlement is a wake-up call for every connected vehicle owner—your car knows where you go, how you drive, and who you are. And until now, it could sell that story to the highest bidder.

**What exactly happened** California Attorney General Rob Bonta announced a $12.75 million settlement with General Motors over violations of the California Consumer Privacy Act (CCPA). The case centers on GM’s collection and sale of driving data from millions of vehicles between 2020 and 2024. The data came from GM’s OnStar subsidiary and its “Smart Driver” system. This program was marketed as a way to improve driving habits, but it secretly fed driver behavior and precise location data to data brokers Verisk Analytics and LexisNexis Risk Solutions. **Who is affected and how** Anyone who drove a GM vehicle—including brands like GMC, Cadillac, Chevrolet, and Buick—during those four years could have had their data sold without consent. The investigation started after media reports in 2024 revealed automakers were sharing driver behavior with insurance companies. California officials found that GM failed to properly notify drivers or obtain their permission. The company even made reassuring statements that it wouldn’t sell the data, while quietly doing exactly that. Nationwide, GM made $20 million from these data sales. **The real-world impact and consequences** This isn’t just a privacy violation—it’s a betrayal of trust. GM collected intimate details about drivers’ everyday habits and movements. Where you live, work, shop, and visit became a product sold to data brokers. The good news? California law prohibits insurers from using driving data to set rates, so drivers likely didn’t see higher premiums. But the potential for harm was enormous. Other states don’t have the same protections, leaving drivers elsewhere vulnerable. **Technical breakdown** The “Smart Driver” system was designed to score driving behavior—things like hard braking, rapid acceleration, and speeding. It collected precise GPS location data tied to each trip. This data was then packaged and sold to Verisk and LexisNexis, who repackage it for insurance scoring products. GM retained the data longer than necessary, violating data minimization rules. The company also failed to get explicit consent, which is a core requirement under CCPA. This case marks the first enforcement action focused specifically on data minimization under California law. **What should be done — mitigation and recommendations** The settlement requires GM to stop selling driving data to consumer reporting agencies and brokers for five years. They must delete retained data within 180 days unless consumers explicitly consent to keeping it. GM also has to ask LexisNexis and Verisk to delete all previously received data. A stronger privacy compliance program is now mandatory, with regular assessments submitted to regulators. For drivers, the lesson is clear: check your vehicle’s privacy settings, disable data-sharing features if possible, and stay informed about what your car is collecting. **Why this matters in the bigger cybersecurity landscape** This case sets a critical precedent. Connected vehicles are essentially smartphones on wheels, collecting massive amounts of personal data. The $12.75 million fine is a record for California, signaling that regulators are serious about enforcing data privacy in the automotive industry. The FTC already banned GM from selling driving data for five years. Now, California’s action shows that state-level enforcement can fill gaps where federal regulation falls short. For every automaker watching, the message is clear: your customers’ data isn’t yours to sell.

Your Jenkins pipeline just got a whole lot less trustworthy. Checkmarx revealed over the weekend that a malicious version of its popular Jenkins AST plugin was published on the official Jenkins Marketplace—and it’s packing credential-stealing malware. This isn’t a random hack. The notorious TeamPCP group is behind it, the same crew that pulled off the Trivy vulnerability scanner breach and the Shai-Hulud npm campaigns. If you’re using Checkmarx’s plugin for security scanning in your CI/CD pipeline, you need to stop and check your version right now.

**What exactly happened** A rogue version of the Checkmarx Jenkins AST plugin—tagged 2026.5.09—appeared on repo.jenkins-ci.org on May 9. It wasn’t part of the official release pipeline. No git tag. No GitHub release. Just a suspicious upload that screamed “backdoor.” TeamPCP claimed responsibility, leaving a cheeky message in the plugin’s about section: “Checkmarx fails to rotate secrets again. With love - TeamPCP.” The group had been inside Checkmarx’s GitHub repositories for at least a month, thanks to credentials stolen during the Trivy supply-chain attack in March. **Who is affected and how** Anyone running the malicious plugin version on their Jenkins server is at risk. Jenkins is a cornerstone of CI/CD pipelines worldwide—used for building, testing, and deploying code. If you integrated Checkmarx AST for automated security scans, your plugin might have just become the weakest link. The malware is an infostealer. It harvests credentials from developer environments. That means API keys, cloud tokens, database passwords—everything your pipeline touches could be compromised. **The real-world impact and consequences** This is the third supply-chain attack on Checkmarx since late March. First came the Trivy breach, then the KICS tool compromise on Docker and VSCode, and now the Jenkins plugin. The pattern is clear: once attackers get a foothold, they reuse stolen secrets to spread. For organizations, the fallout is severe. A compromised CI/CD pipeline can lead to lateral movement across your infrastructure. Attackers could inject malicious code into your builds, steal intellectual property, or pivot to production systems. Checkmarx insists its GitHub repos are isolated from customer environments, but that’s cold comfort if your Jenkins server is now a backdoor. **Technical breakdown—the “how” explained simply** TeamPCP didn’t hack Checkmarx directly. They used credentials stolen from the earlier Trivy attack to log into Checkmarx’s GitHub repositories. Once inside, they published a modified version of the Jenkins AST plugin that included info-stealing code. The rogue version was uploaded outside the normal release pipeline. It didn’t follow Checkmarx’s date style scheme, lacked a git tag, and had no corresponding GitHub release. These red flags were visible to anyone paying attention. But in the chaos of a busy CI/CD environment, many teams might have auto-updated without a second glance. **What should be done—mitigation and recommendations** First, check your Jenkins plugin version immediately. The safe version is 2.0.13-829.vc72453fa_1c16, published on December 17, 2025, or any older version. If you’re running 2026.5.09, assume compromise. Rotate all secrets immediately—API keys, SSH keys, cloud provider credentials, database passwords. Then investigate for lateral movement or persistence. Checkmarx has published a set of malicious artifacts as indicators of compromise (IoCs) for defenders to scan their environments. **Why this matters in the bigger cybersecurity landscape** This isn’t just about one plugin. It’s a textbook supply-chain attack that exploits trust in automated tools. Jenkins plugins, npm packages, Docker images—they’re all vectors for attackers who know developers rarely question what runs in their pipelines. The TeamPCP group is proving that credential reuse is still the gift that keeps on giving. One breach leads to another, and another. For security teams, the lesson is brutal: rotate secrets obsessively, monitor your CI/CD artifacts for anomalies, and never assume your trusted tools are actually trustworthy.

Microsoft’s GetProcessHandleFromHwnd API has a hidden flaw that’s been quietly handing attackers a backdoor into your system. It was supposed to be a harmless helper for grabbing process handles from windows—but researchers found it bypasses security checks, letting low-privilege code hijack higher-privilege processes. If you’re running Windows 11 (especially pre-24H2), your system might be at risk. The bug affects anyone using UIAccess apps like Quick Assist, and it’s already been weaponized in a publicly disclosed UAC bypass. This isn’t just a theoretical threat—it’s a live wire waiting to be tripped.

**What exactly happened** A security researcher uncovered that GetProcessHandleFromHwnd—a Windows API meant to simplify getting a process handle from a window handle—has a dangerous flaw. The API’s documentation claims it uses window hooks and requires UIAccess, but the reality is messier. In Windows 11, the function directly opens a process handle in kernel mode, bypassing key protections. **Who is affected and how** Any Windows 11 system before version 24H2 is vulnerable, especially those running UIAccess applications like Quick Assist. Attackers can exploit this to elevate privileges from a low-integrity process to a medium-integrity one, or even higher if they target the right app. The Quick Assist UAC bypass, publicly disclosed earlier, is a prime example—it lets malware sneak past User Account Control without triggering alerts. **The real-world impact and consequences** This isn’t just a bug; it’s a privilege escalation highway. Once an attacker gains a process handle, they can inject code, read memory, or manipulate the target process. For enterprises, this means a single compromised user account could lead to full system takeover. For home users, it’s a silent door for ransomware or spyware to slip through. **Technical breakdown** The API’s implementation in Windows 11 (pre-24H2) uses a kernel function called `xxxGetProcessHandleFromHwnd`. It calls `ObOpenObjectByPointer` directly, skipping the usual security checks. The documentation says it needs UIAccess and same-user status, but the kernel version doesn’t enforce integrity level checks or protected process restrictions. In older Windows versions, the API used window hooks, which at least required matching integrity levels. The kernel rewrite removed that safeguard, making it easier to abuse. **What should be done** Microsoft fixed this in Windows 11 24H2 by adding proper checks for protected processes and integrity levels. If you’re on an older version, apply the latest security patches immediately. For IT admins, disable UIAccess for non-essential apps and monitor for suspicious use of the API via tools like Sysmon. Developers should avoid relying on this API for security-critical operations—it’s a ticking time bomb. **Why this matters in the bigger cybersecurity landscape** This flaw highlights a recurring theme: APIs designed for convenience often sacrifice security. The kernel-mode rewrite without proper validation is a classic case of “move fast, break security.” As Windows evolves, so do attack surfaces. The fix in 24H2 shows Microsoft is tightening UIPI (User Interface Privilege Isolation), but the lesson is clear—every API needs a security audit, not just a feature update.

Windows just got a major security upgrade called Administrator Protection, but it turns out the new shield had some gaping holes before it even launched. Security researcher found nine ways to bypass this feature before it hit public release. Five of those bypasses share a common root cause: a long-standing vulnerability in how Windows handles UI Access that Microsoft has finally been forced to address. If you're a Windows user running anything above a standard user account, this matters to you. The bypasses could let attackers sneak past your defenses and gain administrator-level control without you ever knowing.

**What exactly happened** A security researcher discovered nine distinct bypass techniques for Microsoft's new Administrator Protection feature, which was designed to create a real security boundary where User Account Control (UAC) previously failed. Five of these bypasses trace back to a single, decades-old architectural weakness: how Windows handles UI Access for processes running at different privilege levels on the same desktop. **Who is affected and how** Any Windows user who relies on UAC or Administrator Protection for security is potentially exposed. The bypasses work by exploiting the way Windows allows lower-privilege processes to interact with windows created by higher-privilege processes. This isn't just a theoretical risk. Attackers who already have limited access to a system can use these techniques to elevate their privileges silently, without triggering any security prompts. **The real-world impact and consequences** The consequences are severe. An attacker who successfully exploits these bypasses can gain administrator-level control over a system, allowing them to install malware, steal data, or move laterally across a network. The real kicker? These bypasses don't require any user interaction. They operate entirely in the background, making them ideal for stealthy attacks that security software might miss. **Technical breakdown explained simply** Remember the old "Shatter Attacks" from Windows Vista days? They worked because any process could send messages to any window on the desktop, even if that window belonged to a higher-privilege process like SYSTEM. Microsoft introduced User Interface Privacy Isolation (UIPI) to fix this, using integrity levels to block lower-privilege processes from interacting with higher-privilege windows. But the fix had a loophole: processes with "UI Access" status could bypass these restrictions. The researcher found that Administrator Protection's implementation didn't properly account for how UI Access processes could still interact with privileged windows. By carefully crafting window messages, an attacker could trick the system into performing privileged actions on their behalf. **What should be done — mitigation and recommendations** Microsoft has already patched all nine bypasses in the latest Windows updates. If you're running a supported version of Windows, make sure you've installed the most recent security patches. For administrators managing enterprise environments, consider testing Administrator Protection in a controlled setting before broad deployment. The feature shows promise, but its security boundary needs real-world validation. **Why this matters in the bigger cybersecurity landscape** This research highlights a fundamental challenge in Windows security: legacy features designed for one era often create vulnerabilities in new security models. The UI Access mechanism was created to solve a specific problem, but its existence created a systemic weakness that affected multiple security features. Microsoft's decision to redesign how UI Access works for Administrator Protection shows they're finally treating this as a structural issue, not just a patch. The takeaway for security professionals is clear: new security features need rigorous testing against existing system behaviors, not just against known attack patterns. The nine bypasses found here were all discovered before public release, which is exactly when they should be found. But the fact that five share a common root cause suggests Microsoft's testing process could be more thorough.

Microsoft just rolled out a shiny new security feature for Windows 11 called Administrator Protection—and a researcher promptly found nine ways to bypass it. One of those vulnerabilities could let an attacker silently grab full admin rights without triggering a single warning. The feature has now been disabled by Microsoft while they sort out compatibility issues. If you’re running Windows 11, this matters because it shows that even Microsoft’s latest attempt to lock down admin privileges isn’t bulletproof. The clock is ticking for a real fix.

**What exactly happened** A security researcher dug into Windows 11’s new Administrator Protection feature—designed to replace the aging User Account Control (UAC) system. The goal was noble: let users access admin rights only when absolutely needed, without leaving the door wide open. But the researcher uncovered nine separate vulnerabilities that could silently bypass the entire protection. One of them allowed an attacker to escalate from a limited user to full administrator without any user interaction or pop-up warning. Microsoft has since fixed all nine issues, either before the feature’s official release or in subsequent security bulletins. However, as of December 1, 2025, Microsoft disabled Administrator Protection entirely due to an unrelated application compatibility problem. **Who is affected and how** Anyone running Windows 11 with Administrator Protection enabled was potentially at risk. The bypasses didn’t require physical access—just the ability to run code on the machine, which malware or a remote attacker could achieve. The most dangerous part? The vulnerabilities worked silently. No UAC-style prompts, no blue shields, no warnings. Just a quiet escalation to full admin rights. **The real-world impact and consequences** This isn’t just a theoretical flaw. If exploited in the wild, an attacker could install malware, steal data, disable security tools, or pivot to other systems on the network—all while appearing as a legitimate admin. The fact that Microsoft had to disable the feature entirely shows how serious the issue was. It also highlights the challenge of replacing a decades-old system like UAC with something truly secure. **Technical breakdown (the “how” explained simply)** Administrator Protection was supposed to work by creating a separate, isolated token for admin tasks. When a user needed elevated privileges, the system would temporarily grant them through a secure mechanism—not the old UAC prompt. But the researcher found that the new system still relied on underlying Windows components that weren’t properly hardened. One bypass involved manipulating how the system handled certain process creation requests. By sending a specially crafted call, the attacker could trick the system into granting admin rights without going through the intended security check. Think of it like a bank vault with a new high-tech lock—but the walls around it are made of cardboard. The researcher simply went around the lock. **What should be done — mitigation and recommendations** For now, Microsoft has disabled Administrator Protection, so the immediate risk is low. But once it’s re-enabled, users should apply all available Windows updates immediately. The safest approach remains the same as always: never run your daily account as an administrator. Use a standard user account for everyday work, and only elevate when absolutely necessary. Organizations should also monitor for any Microsoft advisories about the feature’s return and test it thoroughly before enabling it broadly. **Why this matters in the bigger cybersecurity landscape** This discovery is a reminder that security features are only as strong as their weakest link. Microsoft tried to fix UAC’s fundamental flaw—that it wasn’t a true security boundary—but the new system still had cracks. The bigger lesson? No single feature can replace good security hygiene. Administrator Protection is a step forward, but it’s not a silver bullet. The best defense is still a combination of least privilege, regular updates, and user awareness. And as this case shows, even Microsoft’s best efforts need rigorous third-party testing before they can be trusted.