A new info-stealing malware named Infinity Stealer is targeting macOS systems with a Python payload packaged as an executable using the open-source Nuitka compiler.

The attack uses the ClickFix technique, presenting a fake CAPTCHA that mimics Cloudflare’s human verification check to trick users into executing malicious code.

Researchers at Malwarebytes say this is the first documented macOS campaign combining ClickFix delivery with a Python-based infostealer compiled using Nuitka.

Because Nuitka produces a native binary by compiling the Python script into C code, the resulting executable is more resistant to static analysis.

Compared to PyInstaller, which bundles Python with bytecode, it’s more evasive because it produces a real native binary with no obvious bytecode layer, making reverse engineering much harder.

“The final payload is written in Python and compiled with Nuitka, producing a native macOS binary. That makes it harder to analyze and detect than typical Python-based malware,” Malwarebystes says.

Attack chain

The attack begins with a ClickFix lure on the domain update-check[.]com, posing as a human verification step from Cloudflare and asking the user to complete the challenge by pasting a base64-obfuscated curl command into the macOS Terminal, bypassing OS-level defenses.


ClickFix step used in Infinity attacks | Source: Malwarebytes

The command decodes a Bash script that writes the stage-2 (Nuitka loader) to /tmp, then removes the quarantine flag, and executes it via ‘nohup.’ Finally, it passes the command-and-control (C2) and token via environment variables and then deletes itself and closes the Terminal window.

The Nuitka loader is an 8.6 MB Mach-O binary that contains a 35MB zstd-compressed archive, containing the stage-3 (UpdateHelper.bin), which is the Infinity Stealer malware.


The malware's disassembly view | Source: Malwarebytes

Before starting to collect sensitive data, the malware performs anti-analysis checks to determine whether it is running in a virtualized/sandboxed environment.

Malwarebytes’ analysis of the Python 3.11 payload uncovered that the info-stealer can take screenshots and harvest the following data:

   • Credentials from Chromium‑based browsers and Firefox

   • macOS Keychain entries

   • Cryptocurrency wallets

   • Plaintext secrets in developer files, such as .env

All stolen data is exfiltrated via HTTP POST requests to the C2, and a Telegram notification is sent to the threat actors upon completion of the operation.

Malwarebytes underlines that the appearance of malware like Infinity Stealer is proof that threats to macOS users are only getting more advanced and targeted.

Users should never paste into Terminal commands they find online and don’t fully understand.

source

Dell, HP, Lenovo (and other OEMs…)

Enterprise and consumer oriented PC and laptop vendors (including also Acer, ASUS, Dynabook, etc.) generally did better, but even they had:

   • staggered rollouts

   • inconsistent BIOS/UEFI update timing

   • some systems that required multiple reboots to apply DBX changes

As I looked at read forum posts at answers.microsoft.com, TenForums.com, ElevenForum.com, and TechPowerUp.com, I saw hundreds upon hundreds of forum threads that sought help in dealing with Secure Boot issues. Many involved laptops, and many more involved desktops, particularly DIY home-brew builds or those from boutique builders who assemble best-of-breed commercial parts to build bespoke PCs for well-heeled buyers (see next section).

Custom‑built PCs

Motherboards from the same vendor might behave differently depending on:

   • actual chipsets installed

   • firmware branch

   • release year

   • OEM vs retail SKU

Overall, the lack of standardization has been obvious. The Secure Boot problems users encountered have been all over the place. Some have ultimately yielded to Windows Update or manual changes. Others have stubbornly resisted all attempts at repair or correction. I’ve personally been all over this problem space, with failures recently overtaken by successes (but failures, nonetheless).

What users can do if Secure Boot updates fail


Checking the System Information (msinfo32) utility is the quickest way to verify if Windows recognizes your Secure Boot state as active.

There are all kinds of ways in which Secure Boot can fail. Windows update may report success, but the DBX (revocations list) never changes. Firmware may report that Secure Boot is “enabled,” but it isn’t being enforced (the PowerShell confirm-SecureBootUEFI will report false in that case).

Systems may boot but fail compliance checks (see Garlin Scripts section later in this story for more details). Bootloaders may not match DB entries, or systems may boot only reluctantly or not at all after updates (as happened on my ASRock B550 Extreme4 system). There’s a lot going on here, so there are lots of things to try should one need to fix them. Let’s march through a list of possibly poignant causes and related fixes.

Mismatched Keys (PK/KEK/DB/DBX)

If the PK or KEK is outdated, firmware may reject database updates into the list of valid credentials and values (DB) or its list of revoked items (DBX). If that happens, it’s worth trying one or all of these fixes:

• Reset to factory or default keys (usually available as a selectable action in UEFI, when Secure Boot is in Custom mode)

• Re-enroll Microsoft keys (usually requires re-applying a Microsoft update, which entails an uninstall/reinstall maneuver, possibly via DISM—WU offers time-limited rollback)

Firmware Ignores DB or DBX Updates

On some PCs and laptops, UEFI won’t apply DB or DBX updates except under certain conditions. Secure Boot may need to be disabled. The Compatibility Support Module (CSM, which enables “dual boot” into either BIOS or UEFI modes; modern PCs are UEFI-only, but older models often go both ways) must be turned off. Sometimes, Secure Boot keys must be cleared (another UEFI option) must be cleared before updates will take. Experimentation may be needed to see what’s what; if you’re lucky, you’ll find info from other intrepid explorers who’ve already seen and solved your particular problem.

Outdated Bootloaders

Older Windows install media or repair/recovery disks may incorporate bootloaders that are too old to work with Secure Boot. Indeed, this mismatch will accelerate later in 2026 after Microsoft gets more deeply into revoking CA-2011 (which is what most older bootloaders incorporate). If a bootloader is too old, DBX may block it. Fixes are fairly straightforward because bootloaders don’t interact with firmware (UEFI). Try any of the following repairs in this case:

• Run Windows Update: it may replace an outdated bootloader with a current one

• Rebuild boot files using the bcdboot utility

• Make sure the EFI partition is healthy (and rebuild it if it isn’t)

Firmware Bugs or Oddities

Especially on older PCs, it’s a good idea to update (flash) the UEFI before getting into Secure Boot. For old enough PCs, though, updates into 2023 and newer may simply not exist. But for systems that require multiple reboots, specific firmware versions, or manual Secure Boot database (DB, DBX) imports, a few techniques will be helpful:

• Update the firmware to the latest stable version (consider beta versions only if all other options have failed: you don’t want to trade one cause of instability for another)

• Wherever available, use vendor-supplied capsules or updates to apply Secure Boot database changes (e.g., my MSI MAG Tomahawk didn’t work properly until I’d flashed its UEFI, which included Secure Boot and CA-2023 elements built right in)

• Let Windows Update do its thing only AFTER the firmware is current: new updates and old firmware make for a volatile and issue-prone environment, as I learned on the ASRock B550 Extreme4 build

All in all, if users attempt Secure Boot compliance work from firmware updates to Windows updates, and only get into manual UEFI operations if necessary, they’re far less likely to get stuck in some pothole along that road.

How the scripts help solve Secure Boot update issues

Some of the most interesting developments during the CA-2023 rollout has been the emergence of community-driven tooling and diagnostics. In particular, Eleven Forum VIP and Guru user Garlin has provided a 50-page+ thread with useful PowerShell scripts, and backed them up with incredibly useful support and discussion. His scripts do the following:

   • enumerate Secure Boot keys

   • validate DB/DBX entries

   • detect mismatches

   • identify outdated bootloaders

   • verify enforcement status

   • generate detailed reports

For many users, Garlin’s scripts were the first clear window into what their firmware was actually doing. As an illustration of what the Garlin scripts illuminate, Figure 1 shows the output of his script named Check_UEFI-CA2023.ps1, captured from my recently rebuilt MSI MAG Tomahawk B550 desktop:


Output from Check_UEFI-CA2023.ps1 on the MSI MAG B550 desktop PC

Careful examination of the screenshot above shows the PC has both CA 2011 and CA 2023 Key Exchange Keys (KEKs) installed, with DB certs for UEFI CA 2011, Windows PCA 2011, and three flavors of CA 2023. The DBX certs list is empty (if you look below, you’ll see that CA 2011 hasn’t yet been revoked; once that happens, those entries should move here).

EFI files show that the boot manager allows UEFI CA 2023, as does the registry, and the latest Secure Boot code integrity policy is in place. MS uses this policy to block vulnerable or rollback-susceptible boot-critical binaries, particularly for Virtualization Based Security (VBS, as mentioned in the second item in the script’s overall output).

Finally, the script output shows the older CA-2011 certification hasn’t yet been revoked. That’s deliberate: I’m waiting to see how and when Microsoft will handle this through Windows Update, as they’ve promised to do sometime in the second half of 2026. We’ll see how that turns out…

Why these Scripts matter

Vendors rarely expose a PC’s full Secure Boot state. Windows surface only part of this picture. Firmware UIs are inconsistent and often call the same things by different names. Garlin’s scripts show us what’s going on inside the Secure Boot sphere, and tell us what actions might need to be taken to complete the overall process of updating and catching up.

What to do when Secure Boot won’t apply updates

Here’s a practical, step-by-step recovery workflow.

Step 1: Verify Current State

Use PowerShell or Garlin’s scripts to check:

   • PK

   • KEK

   • DB

   • DBX

   • Enforcement status

   • Bootloader versions

Step 2: Update Firmware

Install the latest BIOS/UEFI update.

Step 3: Reset Keys to Factory Defaults

Disable Secure Boot, set Mode to Custom, then reset or install factory default keys (different UEFIs use varying terminology). Whatever they call it, this often clears mismatches.

Step 4: Re-enable Secure Boot

Ensure CSM is disabled (it often gets turned on when UEFI gets updated; it must be turned off for Secure Boot to be enabled).

Step 5: Apply DBX Update(s)

Use Windows Update or vendor capsule(s), as available. Check the system (or motherboard) vendor’s support pages to look for UEFI and related updates. That’s what did the trick for my MSI MAG Tomahawk B550 motherboard.

Step 6: Rebuild Boot Files (if needed)

You can use built-in commands to recreate your boot files by running the bcdboot C:\Windows /f UEFI command. Sometimes, it may be necessary to boot to a repair or rescue disk and run this from the Windows Recovery (WinRE) environment. It is always safer to take this approach, and it will get you past boot problems or secure boot policy blocks if and when they should pop up.

Step 7: Re-verify State

Confirm DBX contains CA 2023 entries. Indeed, this would be a good time to run Garlin’s Check_UEFI-CA2023.ps1 script. (Note: if you look inside the file’s Properties window and check the Unblock option, you can run this script in PowerShell without changing or bypassing local execution policy. This is depicted in the screenshot below)

IMO, the Secure Boot Ecosystem needs reform

The gradual rollout of CA 2023 and recent efforts to catch systems up to current Secure Boot compliance have been interesting. But it has also exposed a wide range of systemic issues and problems. For one thing, firmware vendors lack consistent implementations and terminology, so it falls on IT pros and other installers to make things work. To exacerbate things, documentation is often poor, and fails to address remediations when things break or don’t work properly.

Right now, update pipelines are fragile. One misstep (such as failing to set Secure Boot to Custom mode before seeking to reinstall default keys) can cause the update process to get stuck, and can interfere with normal boot behaviors. On one of my ASRock desktops, I couldn’t restart that PC normally, and could only use a deep, cold boot to get into UEFI or run through the boot cycle (this lasted two weeks before I switched motherboards to get things working normally again). This also drives my observation that OEMs and motherboard vendors vary widely in quality of Secure Boot implementation and handling. At the same time that the ASRock mobo was driving me bonkers, I had no problems with any of my Lenovo systems (some dating back to 2018), nor my Dell mini-PC or an ASUS Snapdragon laptop, either.

What I learned during this process is that Secure Boot is only as strong as its weakest link. Some systems, alas, have weak links. Many of those weak links turn what should be a routine update into a struggle. Some of them can require even more drastic measures, like a system replacement or motherboard swap.

What Microsoft, OEMs, and users must do

All the kids on this playground need to do certain things to improve the current Secure Boot morass. In my opinion, here’s how this shakes out across Microsoft, OEMs and the user community. To begin with, Microsoft should enforce stricter certification, with improved diagnostics and better tools (Garlin’s scripts are pretty straightforward in hindsight; there’s no reason why MS can’t offer more polished implementations to help things along).

Next, the OEMs could do a lot to standardize firmware behavior and adopt consistent terminology. They can test their DB update more and more thoroughly, and provide more insight and clarity into Secure Boot state and values in their UEFI interfaces. A robust, automated rollback tool would also help undo incorrect or bad choices.

And finally, users should take security more seriously. This means updating firmware as new updates emerge, and resolving to use (not disable) Secure Boot except when installs, configuration changes, or updates demand it be turned off (temporarily). Users should also verify their Secure Boot databases periodically to make sure they’re current and correct, and make sure their EFI partitions are healthy and up-to-date.

If everybody does their part, Secure Boot can do its job of protecting systems from boot and root-level compromise and attack. That’s pretty important, so I think it’s worth doing.

Secure Boot still matters, but it needs work

Secure Boot remains an important defense mechanism in the Windows security model. But the CA 2023 saga shows that this ecosystem is fragile, inconsistent, and overdue for modernization. The good news is that the industry is learning. Firmware vendors are improving. Microsoft is tightening requirements. Community tools are filling gaps. But the lesson is clear: trust is no set-it-and-forget-it thing. Trust must be maintained, verified, and occasionally repaired. Secure Boot is no exception.

My closing advice is to watch the time ticking as you work to solve Secure Boot problems, should they present themselves. If a problem takes half a day to fix, that’s tolerable. Any longer than that, and it’s time to start thinking about alternatives, workarounds, and replacements. While you’re thinking, you can turn Secure Boot off: Windows still works without it. But you may, as I did, decide to replace balky, stuck hardware components rather than keep fighting, with no certain resolution in sight. It’s up to you! ■

source

Updated March 18: Following confirmation of an emergency, out-of-band, security update impacting Windows 11 versions 25H2, 24H2 and Windows 11 Enterprise LTSC 2024, this article has been updated with a statement by Microsoft in response to a request for clarification on the reasons for the update after the Patch Tuesday rollout which appeared to have already addressed the CVE-2026-25172, CVE-2026-25173 and CVE-2026-26111 Windows Routing and Remote Access Service vulnerabilities.

Patch Tuesday has been and gone, but the monthly security updates from Microsoft just keep on coming. The latest is an emergency, out-of-band, hotpatch for a subset of Windows 11 enterprise users that addresses a bunch of criticial security vulnerabilities impacting the Routing and Remote Access Service which could give attackers the ability to execute remote code and, potentially, take control of the impacted device. Here’s what we know about the Common Vulnerabilities and Exposures designated as CVE-2026-25172, CVE-2026-25173 and CVE-2026-26111, and the emergency update itself itself.

Microsoft Windows 11 Hotpatch Security Update—What The Enterprise Needs To Know

The latest out-of-band security update from Microsoft is, truth be told, something of an oddity. I say that as it is a fix for three critical vulnerabilities that had already been addressed by the March Patch Tuesday rollout.

The Microsoft security advisory stated: “This issue only applies to a limited set of scenarios involving Enterprise client devices running hotpatch updates and being used for remote server management." The three vulnerabilities all affect the Windows Routing and Remote Access Service management tool, and connecting to a malicious server could be all it takes to trigger the attack chain.

CVE-2026-25172, CVE-2026-25173 and CVE-2026-26111 are all remote code execution vulnerabilities, using access to a malicious server by way of the RRAS interface to start exploitation. The official description from the Microsoft Security Response Center is that of an “integer overflow or wraparound in Windows Routing and Remote Access Service (RRAS) allows an authorized attacker to execute code over a network”

In other words, and here’s the important bit, an attacker who is already authenticated on the domain could essentially trick a domain-joined user to send a request to the malicious server via the RRAS snap-in. Given that a patch had already been made available, you may be wondering why there’s a need for this emergency hotpatch. The answer lies with the fact that the Patch Tuesday fix requires a device reboot, and something running your critical applications or services isn’t open to rebooting on a whim, for obvious reasons.

Which is where the hotpatch system comes into play, as it doesn’t require the reboot. A hotpatch will download and install in the background, deployed within the in-memory code of already running processes.

Microsoft has also confirmed that it will enable hotpatch security updates by default, through the Windows Autopatch enterprise service, with the release of the Windows security update in May for those managing devices using Intune and the Graph API.

“This change in approach patches devices significantly faster since they aren’t waiting for that restart. To see how this is working in the real world, we asked four different companies with 30-70K devices about their gains in the number of days to security compliance. They all reported achieving 90% patch compliance in half the previous time, without making any policy changes,” Microsoft said. “Today, there are over 10 million production devices enrolled in hotpatch updates,” the Microsoft announcement continued, “showing the level of adoption and trust companies like yours have in this capability.” Microsoft also teased that additional IT controls will be released in April for organizations not yet ready for this change.

Microsoft Issues Statement Providing Clarification On Windows 11 Out-Of-Band Hotpatch Security Update

“This hotpatch update is offered only to hotpatch‑enabled devices. No action is required for devices that receive standard Windows updates,” Microsoft said. According to Bleeping Computer, Microsoft had “previously released hotfixes for these flaws,” but re-released them to "ensure comprehensive coverage across all affected scenarios." What those scenarios were, and why the emergency hotpatch update was necessary, isn’t immediately clear.

I reached out to Microsoft for clarification, and a spokesperson provided the following statement: “We identified that the Routing and Remote Access Service (RRAS) vulnerability could affect Enterprise devices deploying Windows hotpatch updates on Windows 11, versions 24H2 and 25H2. To address this scenario, we released an out-of-band hotpatch update (KB5084597) for hotpatch-enabled devices, allowing rapid installation without requiring a restart. Currently, there is no indication of exploitation, and we recommend customers follow the updated CVE guidance to remain protected.”

source

When's the right time to do it

Safe mode helps you see if a buggy app is causing your Android phone to crash, freeze, or slow down.

Here's how.



If your Android phone starts crashing, freezing, or acting strangely, it could be for several reasons, but one common culprit is third-party apps.

Any app installed from the Google Play Store can cause problems due to bugs, compatibility issues, or poorly optimized updates. Thankfully, Android has a troubleshooting tool called "safe mode" that can help you figure out if that's indeed the issue.

Safe mode temporarily disables all third-party apps and runs only the core Android system and preinstalled software. That creates a clean environment so you can see whether the problem is a third-party app or perhaps something deeper, such as your hardware.

How to boot your Android phone into safe mode

Most Android phones support safe mode, including Google Pixel phones, Samsung Galaxy phones, and many others. For this guide, I'm using a Pixel phone, but the process is very similar across Android devices.

1. Open the power menu

The first step is accessing the power menu on your Android phone. Press and hold the Power button and Volume Up button together for a few seconds. This opens the power menu with options like Power off and Restart.


Elyse Betters Picaro / ZDNET

2. Enter Safe mode

Once the power menu appears, press and hold the Power off option instead of tapping it. After a moment, your Android phone will display a prompt asking if you want to reboot into safe mode. Tap OK to confirm.

Your phone will restart automatically.


Elyse Betters Picaro / ZDNET

3. Confirm you're in safe mode

After the phone restarts, check the bottom corner of the screen. You should see a small "safe mode" label.

You may also notice some apps appear grayed out or missing. That is normal. Safe mode disables all third-party apps that you downloaded from the Play Store, leaving only the system apps that came with the device.

Note: Safe mode also enables Airplane mode on your device, but you can turn that off.


Elyse Betters Picaro / ZDNET

4. Use your phone like normal

At this point, use your phone normally for a few minutes or even hours. If the crashing, freezing, or slowdown has stopped, there is a strong possibility that one of your installed apps was causing the issue.


Elyse Betters Picaro / ZDNET

5. Exit safe mode

Before you can track down problematic apps, you need to exit safe mode.

Simply restart your phone by pressing and holding the Power and Volume Up buttons and then tapping Restart. On some Android devices, you can tap the safe mode label to restart your phone and exit safe mode.

Your phone should boot back with all your apps available again.


Elyse Betters Picaro / ZDNET

6. Find the buggy app

This can take a bit of time, but it is the most reliable way to identify what is causing problems on your phone.

Once you have exited safe mode, start uninstalling recently installed or recently updated apps one at a time. After removing each app, restart your phone and check whether the issue returns. You can also try using your apps before deleting them. If one behaves strangely or you need to force stop it, you've likely found the offender.

You can find recently updated apps in the Google Play Store.

Tap your profile, go to Manage apps and device > Manage, and select Recently updated to sort apps by their most recent updates. You can also open an app listing to review its latest changes under What's new.


Elyse Betters Picaro / ZDNET



Q: What exactly does safe mode do on Android?

Safe mode itself doesn't fix your Android phone's problems. It simply helps you diagnose them.

Safe mode disables all third-party apps so only Android system software and preinstalled apps run. This then lets you determine whether issues like freezing, crashing, or slow performance are caused by an app. If your phone works normally in safe mode, you can usually narrow the cause down to a third-party app that was recently installed or updated.

Q: What if my phone still has problems in safe mode?

If your phone still has problems while in safe mode, the cause may be a deeper software issue or even a hardware problem. In that case, you may need to check for system updates to install, reset your device, or even contact the manufacturer for extra support.

You can also try clearing your Android phone's cache as the next troubleshooting step.

Q: Will safe mode delete my apps or data?

Safe mode primarily prevents third-party apps from running, but it does not delete them from your phone. Google warns that safe mode does remove some home-screen widgets. So, if you use widgets, it recommends taking a screenshot to help you put them back.

Q: Why does my phone run faster in safe mode?

With third-party apps disabled, your phone has fewer background processes to manage. If performance improves significantly, one of those apps may be using too many resources or crashing in the background, and you may want to delete it.

source

Chrome’s Gemini “Live in Chrome” panel (Gemini’s embedded, agent-style assistant mode within Chrome) had a high‑severity vulnerability tracked as CVE‑2026‑0628. The flaw let a low‑privilege extension inject code into the Gemini side panel and inherit its powerful capabilities, including local file access, screenshots, and camera/microphone control.

The vulnerability was patched in a January update. But the deeper story is that AI or agentic browsers are stepping outside long‑standing isolation boundaries, so extension abuse, prompt injection, and trusted‑UI phishing all become much more dangerous.

Chrome’s Gemini “Live in Chrome” panel runs the Gemini web app in a special, privileged side panel that can see what’s on screen and perform actions like reading local files, taking screenshots, and using the camera and microphone to automate tasks.

Researchers found that an extension using the declarativeNetRequest API (Application Programming Interface) could tamper with traffic to gemini.google.com/app when it loaded inside this side panel, not just in a normal tab.

As a result, a basic‑permission extension could inject JavaScript into a high‑privilege browser component and start camera and microphone without new consent prompts, enumerate local files and directories, take screenshots of any http site, and even turn the Gemini panel itself into a phishing UI.

Normally, extensions cannot control other extensions or core browser components, but due to this vulnerability, a low‑privilege extension could effectively drive a privileged AI assistant and inherit its powers.

And because the Gemini panel is a trusted part of the Chrome browser, users would not expect it to silently activate camera or microphone or scrape local files at an extension’s whim.

Therefore, it is good to be aware that agentic browsers, such as Gemini in Chrome, Copilot in Edge, Atlas, Comet, etc., embed an AI side panel that sees page content, keeps context, and can autonomously execute multi‑step actions like summarization, form‑filling, and automation.

These assistants need broad access to the web pages you’re looking at, including everything you see and interact with on the screen, sometimes local files, and in some designs even application data (emails, messages). That makes them an attractive “command broker” for attackers.

How to stay safe

After responsible disclosure, Google shipped fixes in early January 2026, so current versions are not vulnerable. Anything lagging that baseline is at risk and should be updated, especially if you’re using “Live in Chrome.”

Install as few extensions as possible, from vendors you can identify and contact. Prefer open‑sourced or well‑audited extensions for anything that touches sensitive workflows.

Be suspicious of sudden permission changes or unexplained new capabilities after updates.

Monitor for anomalies like cameras activating unexpectedly, unexplained screenshots, or Gemini‑related processes touching unusual file paths.

source