Since XProtect Remediator (XPR) went live during the summer of 2022, it has run daily sets of checks for known malware in macOS Catalina and later using its scanning modules. Those have been sufficiently regular and reliable that some of my apps, including Skint and SilentKnight, check that they’re occurring and report normal and healthy results. Just over a month ago, I provided a detailed account of XPR’s different types of scan, and how they are scheduled and dispatched in XPR version 149. Last week in XPR version 151, Apple changed all that, and Skint, SilentKnight and XProCheck may now show few scans and frequent warnings.

As Apple has never provided anything other than the vaguest of information about XPR, I have no idea whether this is the new normal, or the result of bugs. As XPR scans now vary greatly between different Macs, and run least on those with large numbers of Time Machine backups accessible, I’m inclined to suspect at least some of this is unintended behaviour.

XPR scans

There are still three types of timed scan:

• a fast scan, com.apple.XProtect.PluginService.agent.fast.scan, performed at intervals of 6 hours (21600 seconds), and run when on battery;
• a standard scan, com.apple.XProtect.PluginService.agent.scan, performed at intervals of 24 hours (86400 seconds), but not run when on battery;
• a slow scan, com.apple.XProtect.PluginService.agent.slow.scan, performed at intervals of 7 days (604800 seconds), but not run when on battery.

In the standard scan, each of the scanning modules is run in turn, once using the agent version running as the current user, normally 501, and once using the daemon version as root, user 0.

Fast scans do run every six hours, but don’t currently include any of the scanning modules, so leave little trace in the log. They are also run soon after starting up and logging in as a user, where they’re referred to as a startup scan when run as root, and a login scan when run as the current user, usually 501.

As a slow scan is only run once a week, I still haven’t been able to observe one.

With XPR version 151 installed, you’re likely to see the following sets of scans after user login:

• Paired startup and login scans, no scanning modules used, taking about 46 seconds for root and 9 seconds for user 501.
• Timed low priority scans as root and user, using just the Eicar scanning module, and taking about 2 and 1 seconds respectively.
• Timed standard scans as root and user using all the scanning modules, and taking around 175 seconds for root, and up to 600 seconds as user. These may be cancelled by the XP Timer firing, which kills the current scanning module and terminates that set of scans, leaving them incomplete.

Thereafter, every six hours a fresh fast scan is performed, and every 24 hours a standard scan is attempted, although the latter may be terminated without completing any scanning modules at all.

XP Timer termination

At varying times after the start of a standard scan running its sequence of scanning modules, they may be interrupted by the firing of the XP Timer, and you’ll see a sequence of entries in the log describing how that not only kills the current scanning module, but terminates the whole of that set of scans:
16.438 com.apple.XProtectFramework 34294 XP Timer fired, killing activity
16.438 com.apple.XProtectFramework 34784 Received SIGTERM, canceling running plugins then exiting
16.439 XProtectRemediatorAdload Cancellation handler called for reason: Dispatch recieved SIGTERM
16.442 XProtectRemediatorAdload {"caused_by"[], "execution_duration":0.0002809762954711914, "status_message":"PluginCanceled", "status_code":30}

It’s that status_message and status_code that is detected by XProCheck, SilentKnight and Skint, and reported there as a warning.

16.450 com.apple.XProtectFramework Finished system scan, ran as 501
16.451 com.apple.duetactivityscheduler COMPLETED <_DASActivity: "501:com.apple.XProtect.PluginService.agent.scan:BD32B7", Utility, 60s, [09/03/2025, 07:39:13 - 10/03/2025, 07:39:13], Started at 09/03/2025, 19:52:35, Group: com.apple.dasd.default, Intensive: CPU Disk, PID: 2254>
16.453 com.apple.xpc.activity Rescheduling: com.apple.XProtect.PluginService.agent.scan (0x653344140)
16.457 com.apple.duetactivityscheduler Completed <private>, ran for 9.7 mins, total runtime 9.7 mins

The next daily standard set of scans are then submitted to DAS for rescheduling, to be run in about 24 hours:
16.465 com.apple.duetactivityscheduler Submitted: 501:com.apple.XProtect.PluginService.agent.scan:15B497 at priority 30 with interval 86400 (Mon Mar 10 07:52:34 2025 - Tue Mar 11 07:39:13 2025)

Although referred to as the XP Timer, times when it will fire range widely, from a few seconds to nearly ten minutes, and there’s no indication of how that is determined.

Effects

XPR checks now differ greatly between Macs. Most basic systems running from their internal SSD with a minimum of external storage, with just a modest set of Time Machine backups, still appear to complete standard scans normally, as they did in previous versions of XPR.

Macs with multiple external disks and long series of Time Machine backups may now complete few if any standard scans. Instead, most or all of them are terminated prematurely by the XP Timer, so triggering warnings in XProCheck, SilentKnight and Skint.

If you wish to run a set of XPR scans manually, then you still can, either in XProCheck or by running the XProtect app yourself. Those are run as the current user, not as root, but may be sufficient to restore your confidence in XPR’s protection.

This leaves me with a dilemma: should those apps suppress those warnings and tell you that everything is fine with XPR’s checks, or should they continue to report them? Given all the problems with XProtect updates in Sequoia, would it be simplest just to abandon my attempts to check anything in macOS security? Are these bugs, and should they be reported to Apple, or is this the new normal we have to look forward to for the future?

Over the last nine years, few of my articles here have been about XProtect, other than those announcing its updates. Until September 2024 and the release of macOS 15 Sequoia. This is now the tenth article I have written about the problems brought by XProtect updates in Sequoia over those six months, when there have been just 13 updates. The result of the last, on 4 March, was that for two days afterwards, many Macs running Sequoia were still using its data from 26 February rather than that in the new version 5289.

This not only affects XProtect, but the other front-line tool in macOS to detect and remove malicious software, XProtect Remediator (XPR). Earlier this year, I reported that at least 17 of the 24 scanning modules in XPR now use Yara definitions provided by XProtect’s data. All those Macs still running the superseded version of XProtect would also have had XPR scans run using that old version of the Yara rules.

XPR is a recent addition to these tools, introduced just three years ago, but XProtect goes way back before Yosemite in 2014. Although there have been occasional brief glitches in delivery of its updates, they have almost invariably completed quickly and reliably, leaving very few Macs stuck with an outdated version 24 hours after an update.

I have now come to dread XProtect updates because of the problems we encounter, and the latest update to 5289 was a good example. There’s a flurry of comments and emails from those whose Macs had failed to complete the update, previously a rare exception. For XProtect 5287 on 5 February, for example, there were 33, including my responses. For version 2184 exactly a year earlier there’s not one comment about that XProtect update.

Sole documentation provided about XProtect’s updates in Sequoia is the man file for its command tool, xprotect, which refers only to updates provided via iCloud, and doesn’t explain how those delivered via the traditional mechanism in softwareupdate might be involved. Yet we know there is a relation: the latest update has still not been supplied via iCloud, not even four days later, but relied instead on XProtectUpdateService working with an update obtained via softwareupdate. Previously that could be invoked using the xprotect update command, but that no longer works, leaving users with two versions of XProtect data, of which the copy used by XProtect and XPR is the older.

Late last year, when xprotect update appeared to be working as expected, I decided that my app SilentKnight would need to use that command in order to download and install updates. As that requires elevated privileges, I have been looking at how to implement a privileged helper app to perform that. With the latest update, that approach would have failed until the version in iCloud had been brought up to date. Instead we’re now reduced to restarting our Macs and hoping that, some time in the next day or two, they might update.

There’s a further problem emerging with the updates of 4 March. Many users have noticed subsequent XPR scans being terminated before completion. Although in most cases that fault appears to go away in later scans, in some Macs it prematurely terminates every set of XPR scans, leaving several of its scanning modules unused.

For example, this iMac Pro has failed to scan using ten of its 24 modules. This occurs because XPR apparently runs a timer, and when a round of scans is deemed to be taking too long, that timer fires and brings XPR to an abrupt halt. Indications are this is most likely when there are many Time Machine backups accessible; as those are all immutable snapshots and haven’t changed since they were made months ago, this is strange behaviour, and hadn’t occurred prior to the updates of 4 March.

Six months ago, if anyone had told me that macOS security protection in Sequoia was going to become less reliable, I wouldn’t have believed them. The truth is that, for many, it now has. As things stand in 15.3.1, a Mac is now more likely to be using an out of date version of XProtect’s detection rules, and for XPR scans to detect and remove malware. And there’s nothing you can do about that until Apple returns to using an update mechanism that’s both timely and reliable. Is that really too much to expect of this front-line security protection?

Selected previous articles:

What is happening with XProtect updates?
XProtect tormentor
How XProtect has changed in macOS Sequoia
A simple guide to how XProtect installs and updates in Sequoia
XProtect has changed again in macOS Sequoia 15.2
What happened with XProtect?
What has happened to XProtect in Sequoia?

Apple has just released updates to XProtect for all supported versions of macOS, bringing it to version 5289, and to XProtect Remediator for all macOS from Catalina onwards, to version 151. As usual, Apple doesn’t release information about what security issues these updates might add or change.

Yara definitions in this version of XProtect add two new rules for MACOS.TAILGATOR.RST.CT and MACOS.TEPIDTEA.

XProtect Remediator doesn’t change the list of scanner modules.

There is a new Bastion rule 13 for the behavioural version of XProtect (Ventura and later). This watches for execution of PasswordManagerBrowserExtensionHelper in CoreServices, in the App Cryptex, and makes an immediate report with the Signature Name of macOS.PasswordExtension.Exec if that occurs.

You can check whether these updates have been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.

If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-151 and XProtectPlistConfigData_10_15-5289.

Sequoia systems only

This update hasn’t yet been released for Sequoia via iCloud. If you want to check that manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5289 but your Mac still reports an older version is installed, you can force the update using
sudo xprotect update

This version is currently only available via Software Update, softwareupdate, or in SilentKnight, and not via iCloud. If your Mac is running Sequoia and you download it that way, the xprotect update command might take a while to use that downloaded version to update your Mac properly. As a result, the version of XProtect shown may remain at 5288, but should later change to 5299.

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

Updated 1720 GMT 5 March 2025 following a ‘spontaneous’ update at 1631, although sudo xprotect check is still reporting the old version.

Exactly two weeks after we had dutifully updated to Sequoia 15.3, and its parallel security updates for Sonoma and Ventura, we were going through the process again for 15.3.1, 14.7.4 and 13.7.4. Those were unscheduled security updates, with the only information from Apple being that they include “important security fixes”. Even Apple’s security release notes reports for each that “this update has no published CVE entries”.

Having scoured Apple’s site and many others, I have drawn a complete blank as to what those updates fixed. I even watched nearly ten minutes of HalfManHalfTech, who claimed to show “some key highlights, New Features and New Changes in macOS 15.3.1 Sequoia”, but I remained none the wiser, and could count those promised new features and new changes on the thumbs of one foot.

My own analysis, based on comparing version and build numbers for bundled apps and the whole contents of /System/Library, was almost as barren. Apple silicon Macs had a firmware update, taking iBoot from version 11881.81.2 to 11881.81.4. Safari remains at version 18.3 (20620.2.4.11.5), and the only change apparent is that Messages had single minor build increment, from 14.0 (1402.400.131.1.2) to 14.0 (1402.400.131.1.3), which eluded even HalfManHalfTech.

The absence of CVE entries doesn’t mean that these updates didn’t fix any vulnerabilities, though. The Common Vulnerabilities and Exposures (CVE) scheme sets out to identify and monitor publicly known vulnerabilities and exposures, particularly those discovered and reported by third-party researchers. There’s no obligation or expectation that Apple should assign CVEs to vulnerabilities that it discovers in-house, and apparently don’t come to the attention of anyone outside.

In the past, Apple used to assign CVEs to many vulnerabilities discovered by its engineers. Looking back at previous security release notes, I noticed those for OS X Yosemite 10.10.3 of 8 April 2015, listing a total of 79 CVEs that were addressed. Of those, 36 were in open source components, leaving 43 in OS X itself. Apple credited its own engineers for reporting 6 of those, and in a further 4 no credit was given in the release notes at the time.

Over the last few years, precious few entries in macOS security release notes have cited CVE entries credited to Apple. This implies that either Apple’s engineers are now detecting very few vulnerabilities, or that those they detect are seldom being entered as CVEs. I’m inclined to believe the latter, and the release of 15.3.1, 14.7.4 and 13.7.4 updates confirms that suspicion. It may be that in the coming weeks, Apple does release more details as to what has been fixed in these security updates. It’s not unusual for it to issue revised release notes some time afterwards, providing information that it decided not to make public at the time of the update.

There’s currently a lot of attention focussed on Apple’s responses to two families of attacks that abuse speculative features of the CPU cores in M-series chips. Almost a year ago a team of seven researchers made public GoFetch, shown to be capable of revealing encryption keys, but not those kept inside the Secure Enclave. Late last month a team from Georgia Tech and Ruhr University Bochum published details and demonstrations of SLAP and FLOP enabling memory leakage in M2 and M3 chips.

There’s no evidence at present that any of those has been exploited in malicious software, and it’s also far from clear whether they’ll ever be used against us. Although a triumph of security research, in the pragmatic world of the attacker, they’re several orders of magnitude more difficult than deceiving the human, the weakest link. While I’m looking forward to Apple addressing GoFetch, SLAP and FLOP, we should remain more concerned with those mundane vulnerabilities that are already both popular and effective. If you’re unsure what those are, Patrick Wardle’s analysis of new macOS malware of 2024 is a worthwhile reference.

Does it matter whether Apple lists them as CVEs in release notes? In practice, relatively little, as the message remains the same: keep macOS up to date and never drop your guard. Some of the most important fixes are released in these ‘minor’ updates, and we may well have another month to go before the next macOS updates are released. If you haven’t updated yet to 15.3.1, 14.7.4 or 13.7.4, please do so today.