Lambing dates remain one of life’s great mysteries. Here in the UK, farmers in the north usually lamb earliest, often only just after Christmas when it’s usually bitter cold and snowy up there. Down here in the balmy south, lambs are born three months or more later, typically in April, when they’re often struggling to keep cool in the sunshine. Last week we saw the first of this year’s lambs, and Apple’s Spring OS fest, including Sequoia 15.4.

Size

That update was large, but that isn’t exactly unusual:

• 7 March 2024, Sonoma 14.4 was 3.6 GB (Apple silicon) with 64 vulnerabilities fixed, “the most substantial update of this cycle so far”;
• 27 March 2023, Ventura 13.3 was 4.5 GB with 49 vulnerabilities fixed, being “substantial, and brings many improvements and fixes”;
• 14 March 2022, Monterey 12.3 was 5.3 GB with 45 vulnerabilities fixed, being “very substantial, introducing major new features like Universal Control and Spatial Audio, changing several bundled apps, and fixing many bugs”;
• 26 April 2021, Big Sur 11.3 was 6.62 GB with over 50 vulnerabilities fixed, “the largest update to macOS since Mojave, and quite possibly the largest ever”.

(Figures and quotations from links here.)

Although the 15.4 update wasn’t quite as large as 11.3, at 6.2 GB for Apple silicon, it has comfortably surpassed it in the number of vulnerabilities fixed, 131 in all, and came close to the size of the 15.0 upgrade at 6.6 GB. What’s most disappointing is that, while the first release of Sequoia merited long and detailed accounts of much of what had changed, for 15.4 there’s precious little information beyond its lengthy security release notes.

A stroll through the version numbers of its bundled apps and /System/Library confirms the extent of changes. There was no point in my trying to compile an article listing them, as it might have been briefer to report what hasn’t changed. What’s more to the point is what’s new in 15.4, what are its Spring lambs?

Novelties

Among the new kernel extensions is the first version of AppleProcessorTrace, and there’s a brace to support hardware in Apple silicon chips including a T6020 and T8103 for PCIe, and a T6032. Those appear to be for M2 Pro, M1 and M3 Ultra chips, respectively. There are two new public frameworks, one named CLLogEntry that is presumably for Core Location log entries, the other tantalisingly named SecurityUI. Neither seems to align to anything in Apple’s developer documentation, so might be preparing the ground for what we’ll hear about in early June at WWDC, when the lambs have grown a bit.

I keep a track of the total number of bundles in several of the folders in /System/Library. Since the release of Sequoia 15.0, that containing Private Frameworks has grown from 4,255 to 4,398. Because of their layout, this total overestimates the real change in numbers, and that probably represents a true growth of around 70 Private Frameworks in Sequoia so far.

These Private Frameworks contain code features used privately by Apple’s apps, but not exposed to third-party developers. Although much is of little or no use or advantage, they also contain much that supports changing features in macOS. Using Private Frameworks is a sure way to madness, and something explicitly forbidden in the App Store, but, like the unaffordable car or boat we like to gloat at, there’s no harm in wondering what they will bring in the future.

The list of new Private Frameworks in Sequoia 15.4 is long, and includes: AUSettings, Bosporus, ComputationalGraph, CoreAudioOrchestration, CryptexKit, CryptexServer, DailyBriefing, DeepVideoProcessingCore, Dyld, ExclaveFDRDecode, FPFS, FindMyPairing, various GameServices, GenerativePlaygroundUI, MCCFoundation, MLIR_ML, MobileAssetExclaveServices, Morpheus, MorpheusExtensions, an OnDeviceStorage group, OpenAPIRuntimeInternal, OpenAPIURLSessionInternal, PIRGeoProtos, RapidResourceDelivery, SecureVoiceTriggerAssets, SecurityUICore, and VideoEffect.

While many of those names can inform speculation about what we’re about to see in macOS 16, three merit a little more decoding.

Cryptexes are secure disk images loaded during boot that currently deliver Safari and its supporting components, and the dynamic libraries for all those frameworks, public and private. Accessing them from user-level code isn’t something you’d expect to happen, so those two Private Frameworks, CryptexKit and CryptexServer, hint at further expansion in their use and support.

Bosporus

The Bosporus Strait in Turkey connects the Black Sea to the Sea of Marmara, thence through the Dardanelles to the eastern Mediterranean. It’s a busy thoroughfare formerly used heavily by ships carrying grain and other bulk cargoes from Ukraine and Russia.

View of Constantinople and the Bosphorus (1856) is one of many views that Ivan Aivazovsky made of this great city, which he visited on many occasions. The artist kept his studio in Crimea, on the opposite (northern) shore of the Black Sea.

Morpheus

Morpheus is the god of dreams, whose name is the source of the word morphine. Although usually distinct from Hypnos, god of sleep, he’s sometimes associated with Nyx, goddess of the night, most famously in reference to a passage from Virgil’s Aeneid, painted below by Evelyn De Morgan.

She pairs Nyx with Morpheus in her Night and Sleep, from 1878. The further figure is a young woman wearing long red robes, her eyes closed, clutching a large brown cloak with her right hand, and most likely Nyx. Her left arm is intertwined with a young man’s right arm. He also has his eyes closed, and is most probably Morpheus. He clutches a large bunch of poppies to his chest with his left arm, while his right scatters them, so they fall to the ground below.

Virgil’s lines in Book 4, line 486 read:
hinc mihi Massylae gentis monstrata sacerdos,
Hesperidum templi custos, epulasque draconi
quae dabat et sacros servabat in arbore ramos,
spargens umida mella soporiferumque papaver.
haec se carminibus promittit solvere mentes
quas velit, ast aliis duras immittere curas…

Translated (at Perseus at Tufts University), this reads:
From thence is come
a witch, a priestess, a Numidian crone,
who guards the shrine of the Hesperides
and feeds the dragon; she protects the fruit
of that enchanting tree, and scatters there
her slumb’rous poppies mixed with honey-dew.
Her spells and magic promise to set free
what hearts she will, or visit cruel woes
on men afar.

Spargens umida mella soporiferumque papaver, one of Virgil’s greatest lines, is conventionally translated as “scattering moist honey and sleep-inducing poppy”, and describes well the effects of the opiate drugs derived from opium poppies, including morphine.

I look forward to watching the lambs grow up through the coming summer, and learning about those lambs that came with Sequoia 15.4 at WWDC.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5292. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version removes the macos_toydrop_b rule for MACOS.ADLOAD, and amends the rules for MACOS.ADLOAD.I, MACOS.BUNDLORE.MDPLST and MACOS.ADLOAD.IN.

You can check whether this update has 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 this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5292.

Sequoia systems only

This update has now 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 5292 but your Mac still reports an older version is installed, you can force the update using
sudo xprotect update

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

By anyone’s standards, the macOS log contains a great many entries, and being able to filter out the noise is essential. This is accomplished by applying predicates to determine which entries are extracted and shown in a log browser like LogUI. However, using predicates requires knowledge about the log and its entries, and forms the greatest barrier for most users. This new version of LogUI improves features to help you use predicates to make the log more accessible.

This all happens in the toolbar of its browser window.

The section at the left of the lower row of tools now provides two methods to apply your own predicates: a one-off predicate editor, and an editor for custom entries in its popup menu.

One-off predicates

Click on the Set button to open the one-off predicate editor.

Here you can compose and paste in your own custom predicates that will extract only the log entries that you’re interested in. In this example, only entries whose subsystem is com.apple.duetactivityscheduler, or contains com.apple.xpc, will be gathered and displayed. Those tell you what’s going on with DAS and CTS scheduling and dispatch of background activities.

LogUI keeps that one-off predicate, even after a restart, as it’s automatically written to its preference file.

Once you’ve clicked Save, selecting the [ … ] item in the predicate menu will apply that predicate to each log extract you obtain.

There’s also an additional standard predicate using the senderImagePath.

Custom menu predicates

Predicates listed in that menu below blowhole are custom predicates saved to LogUI’s preferences using its new Predicate tab in its Settings. This editor is very basic at the moment, and its use a little awkward. This is because SwiftUI much prefers menu contents to be static, so adding items to the predicate menu doesn’t go down too well. This editor allows you to add one predicate at a time, in plain text format.

Click on the Append button here and there’ll be a new predicate named XProtect Remediator with the predicate shown. You can only add one new predicate, then need to quit the app before adding another. I’m sorry that’s so laborious, but once you have set up your custom predicates you can return to using LogUI fully.

The Settings General pane now contains a button to Reset Predicates back to their defaults.

Predicates

A basic predicate is composed of a log field name, like subsystem, followed by an operator such as == (equals) or CONTAINS[c] (case-insensitive contains), and a filter term, usually a string like "com.apple.xpc". So the predicate
subsystem CONTAINS[c] "com.apple.xpc"
will return all log entries with their subsystem containing the text com.apple.xpc. You can combine those basic elements into a more selective predicate using combinators such as AND and OR, so
subsystem == "com.apple.duetactivityscheduler" OR subsystem CONTAINS|c] "com.apple.xpc"
returns entries with a subsystem of precisely com.apple.duetactivityscheduler together with those whose subsystem contains the text com.apple.xpc.

Some years ago I wrote a primer here, and you’ll find some useful predicates in the Further Information section in the Help book for Mints. I’ll be writing more here to help you get the best out of LogUI.

There are a couple of oddities with predicates. SwiftUI tends to like using typographic double-quotation marks, but the macOS predicate builder doesn’t accept them as a substitute for straight marks. So LogUI changes all styled marks to straight ones automatically for you, to ensure those shouldn’t cause a problem. However, when it encounters errors it can behave erratically; while I’m trying to make this more robust, I apologise in advance if using a broken predicate upsets LogUI. It’s worth being careful to check your predicates before trying to use them.

LogUI version 1.0 build 37 is now available from here: logui137

My next task is to improve editing and saving predicates to its preferences, to make them accessible as menu customisations.

Apple has just released the update to macOS Sequoia to bring it to version 15.4, and security updates for 14.7.5 and 13.7.5.

The Sequoia update for Apple silicon Macs is about 6.2 GB in size, and 3.9 GB for Intel models, making it one of the largest intermediate updates for some years. For Apple silicon Macs, the update to 14.7.5 is about 3.7 GB, and to 13.7.5 about 3.3 GB.

Among the changes listed by Apple for 15.4 are:

• Adds Memory movies in Photos using AI.
• Adds a Sketch Style option in Image Playground, in AI.
• Adds Mail Categorisation.
• Apple silicon Macs with an internal SD card reader now support SDUC cards larger than 2TB.
• This should resolve problems with some M4 Macs being unable to launch Virtual Machines.
• Content filter extensions correctly receive non-TCP/UDP network protocol traffic.
• Finder no longer fails to copy some dataless files from SMB file shares.

Enterprise release notes are here.

Software Update settings will be automatically changed to enable future macOS updates to be downloaded and installed automatically: if you don’t want that, you’ll need to change that setting once your Mac boots in 15.4.

Security release notes are available for Sequoia, Sonoma and Ventura updates. There are a total of 131 vulnerabilities fixed in 15.4, which must be a record. None is reported as being suspected of exploitation in the wild, and the security updates for Sonoma and Ventura are almost as numerous.

Firmware updates include iBoot (Apple silicon) to version 11881.101.1, and T2 Macs to 2075.101.2.0.0 (iBridge 22.16.14248.0.0,0). The macOS build number is 24E248.

The new version of Safari in 15.4 is 18.4 (20621.1.15.11.10). APFS is updated to version 2332.101.1.

As so much has changed, I won’t be posting a separate article listing significant changes: it looks like pretty well everything has!

Just for reference, the Sequoia 15.0 major version upgrade from Sonoma was 6.6 GB for Apple silicon, and 4.9 GB for Intel – those aren’t that much larger than this ‘minor version update’.

Those intending to update Apple silicon Virtual Machines currently running 15.3.2 should be prepared for the 15.4 update to fail. I’ve tried with two VMs now, one with a fresh copy of 15.3.2, and both have failed early during installation with a kernel panic. However, 15.4 does install correctly from the latest IPSW image file. Older VMs with 14.7.4 and 13.7.4 do update correctly to 14.7.5 and 13.7.5 respectively.

[Last updated 1715 GMT 1 April 2025.]

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5291. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version amends the Yara rule for MACOS.PIRRIT.OBF.DROPPER, but doesn’t add any new rules.

You can check whether this update has 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 this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5291.

Sequoia systems only

This update has also 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 5291 but your Mac still reports an older version is installed, you can force the update using
sudo xprotect update

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

With Mac OS X came a new tool for installing and updating the system, quite different from what had been used in Classic Mac OS. The Mac OS X Installer app uses packages (.pkg), and metapackages (.mpkg) containing multiple packages to be installed together. Apple thus provided installations and updates as metapackages that could either be downloaded from its update servers using Software Update, or from the update’s web page. The same method was used until Big Sur, when updates changed again.

A system update in Mac OS X 10.1.3 in March 2002 was installed by the Installer app following authentication.

This update required just 148 MB of disk space, and could readily be accommodated by any of these volumes of 11.5 GB capacity.

Most updates were concluded by a period ‘optimising system performance’, as determined by the post-install scripts in the package.

Here, Software Update is delivering Security Update 2004-05-03 to Mac OS X 10.3.3 Panther. Some system components like QuickTime were still supplied and installed separately, but the great majority of Mac OS X was integrated into a whole, and there were no options to install separate components.

Over this period, the system and user data shared a single boot volume, and updating the system mainly involved replacement of updated files. Installer packages contained those replacements together with scripts that were run to update the contents of the boot volume. For much of this, firmware updates were still supplied and installed separately, although later they were integrated into macOS updates.

Until the introduction of System Integrity Protection (SIP) in El Capitan, the only protection provided to system files and folders was in their permissions. Incomplete or incorrect installations and updates were therefore not uncommon, as despite its name, SIP didn’t have any means of verifying the integrity of system files. A procedure was introduced to verify directory structures and permissions against those listed in the Bill of Materials (BoM) for macOS updates, by repairing permissions, but that was still unable to verify the integrity of the files themselves.

Installer metapackages are highly portable, and were commonly downloaded to be installed on multiple Macs. To keep updates as small as possible, they were provided in two forms: a Delta update converted only the previous release, while a Combo update contained everything required to update the last major version and all intermediate minor versions in a single step.

The High Sierra 10.13 upgrade in September 2017 brought greatest change, with its inclusion of Apple’s new file system APFS. Macs that didn’t have a Fusion Drive had their system volume converted to APFS during the upgrade, although it was another year before the same happened to Fusion Drives.

Updates didn’t always work out right for everyone. This was a common problem with High Sierra Supplemental Update of 29 November 2017, for example.

This all changed with the first version of macOS to boot from a signed snapshot, Big Sur, in November 2020, to support the improved Secure Boot of Apple silicon Macs. This abandoned the use of Installer packages, relying instead on an Update Brain integrated into each installer app and downloaded update.

From then onwards, Apple has provided several different presentations of macOS installers and updates:

• Updates are only delivered through Software Update or its command tool equivalent softwareupdate, and have to be downloaded from Apple’s servers, or delivered through a local Content Caching Server.
• Full macOS installer apps are offered in the App Store then delivered through Software Update.
• Full macOS installer packages are available through softwareupdate or direct from Apple’s servers, and are named InstallAssistant. When installed, these create a full installer app.
• Full macOS installers are offered in Recovery, from where they’re downloaded from Apple’s servers.
• Full IPSW images containing firmware, Recovery and macOS partitions can be installed to restore Apple silicon Macs in DFU mode, using Apple Configurator 2 or later versions of the Finder. Those effectively reset that Mac to factory condition with that version of macOS pre-installed.

There are further complications to this. For instance, an older macOS Installer app can’t be run in a newer major version of macOS. The workaround for that is to create a bootable installer volume, and boot from that to run its older installer.

macOS updates are supplied compressed, and require up to 30 minutes preparation before they can be installed.

There are now no optional installations, as every copy of any given version of macOS is identical within its Signed System Volume (SSV).

The size of these new updates is considerably greater than those of older Installer packages, particularly in Big Sur, as engineering optimisations were being performed.

This chart shows cumulative sizes of updates to macOS on Intel Macs from 10.14 Mojave, with its traditional single boot volume, through to macOS Sonoma 14.6. Each point represents the cumulative sum of all updates to that major version of macOS required to reach that minor version. Thus the point for 14.2 is the total of update sizes for 14.1, 14.1.1, 14.1.2 and 14.2. Sizes used aren’t those reported by Software Update, but those of the download itself, as reported in articles here, indexed on this page. Lines shown are best fits by linear regression.

Update sizes rose markedly from Mojave, with its single boot volume, to Catalina, with its boot volume group, and again to a peak in Big Sur, with the SSV. They fell again as Monterey introduced greater efficiency, and Ventura and Sonoma have been almost identical, and smaller than Mojave.

Apple silicon Macs started with the huge updates of Big Sur, which were even larger than those for Intel models, and benefitted from the improved efficiency of Monterey and Ventura. Unlike Intel Macs, though, Sonoma has seen further reduction in update sizes, although in each update they remain significantly larger than those for Intel models.

macOS Ventura in 2022 experimented with Rapid Security Responses (RSRs), much smaller updates intended to provide urgent security fixes to Safari and some of its supporting components. These take advantage of cryptexes, cryptographically verified disk images stored on the hidden Preboot volume. Updating cryptexes alone is far quicker too, as the SSV is left untouched. Unfortunately, the second RSR resulted in serious problems with Safari so had to be replaced three days later. The last RSR was released on 12 July 2023, and they appear to have been abandoned since.

Upgrading to the first release of the next major version of macOS had required downloading its full installer app from the App Store. Apple broke from this in macOS Ventura in October 2022, when that new macOS was installed as an update instead. Although this reduced its size and installation time required, it caught many users on the hop, as Apple provided no warning of the change. This approach has since become standard with both Sonoma and Sequoia.

Installing and updating the Mac’s operating system has probably changed more over the last 41 years than any other feature.

This week’s new features in my lightweight log browser LogUI tackle two important areas: initial checks to confirm that the app can access the log, and improving the filtering of log entries using predicates.

LogUI has three key requirements:

• that the Mac is running macOS 14.6 or later, as enforced by macOS;
• that it’s run from an admin account, as that has the privileges required to access the log;
• that there are log records it can access in the path /var/db/diagnostics, as without those it hasn’t got anything to work with.

LogUI 1.0 build 31 now contains code to check the latter two, run soon after launch. If either fails, you’ll see an informative alert, and the app will quit when you click to dismiss that.

LogUI now has internal features to support a wide range of filters that can be applied when fetching log entries. These are an essential means of reducing the number of entries displayed, and of focussing your attention on what’s important.

This is reflected in its Settings, which now refer to Text rather than a Subsystem. The window toolbar now has a Predicate popup menu, and its text box is labelled text rather than Subsystem.

This menu offers the following options:

• none, which applies no filtering and displays all log entries;
• subsystem, which uses the text entered as the name of the subsystem whose entries are to be displayed, as in the previous builds;
• eventMessage, which shows only those log entries whose message contains the text entered;
• processImagePath, which shows only entries whose process name (or path) contains the text entered;
• [Edit], which in future will open an on-the-fly predicate editor, but currently doesn’t filter;
• TimeMachineBasic to blowhole, which use set predicates to display log entries for those features. The first two are different levels of detail for Time Machine backups, error finds entries with that word in their message, kernel finds entries with the kernel as their process, and blowhole finds entries made by my command tool for writing entries in the log.

Text entered is not case-sensitive.

Although it’s currently possible to change and extend those, that involves delicate surgery to LogUI’s preferences Property List, and I don’t intend you to hack that just yet. The next features will provide a proper editor in LogUI’s Settings, and the on-the-fly editor accessed through this menu.

Otherwise LogUI should work just the same as the last build. These new features are documented in its Help book, a separate copy of which is supplied in its Zip archive.

LogUI 1.0 build 31 is now available from here: logui131
and I will shortly be giving it an entry in my log browser Product Page, to make it easier to access. I’m also looking at building an auto-update mechanism into it.

Please let me know how you get on with this, and whether it proves useful to you. Enjoy!

Last week’s security updates to macOS have left some confusion over version numbers, and firmware for T2 Macs. This article attempts to clarify what happened, and where supported versions of macOS are going next.

Security updates 11 March 2025

Apple released:

• macOS 15.3.2 Sequoia
• Safari for macOS 14.7.4 Sonoma
• Safari for macOS 13.7.4 Ventura.

There were no security updates for Sonoma or Ventura other than their Safari updates.

There was also a firmware update included in the 15.3.2 update, changing the version of iBridge firmware in the T2 chip of Intel Macs from 22.16.13051.0.0,0 to 22.16.13060.0.0,0. There were no firmware updates for Apple silicon Macs, nor for Intel models without T2 chips, I understand.

Sequoia

If your Mac is running macOS Sequoia and has been updated, it should now be running 15.3.2 (build 24D81). If it has a T2 chip, it should have updated its firmware to read
EFI 2069.80.3.0.0 (iBridge: 22.16.13060.0.0,0)

Safari should be version 18.3.1 (20620.2.4.11.6).

Sonoma

If your Mac is running macOS Sonoma and has been updated, it should still be running 14.7.4 (build 23H420). If it has a T2 chip, its firmware should remain at
EFI 2069.80.3.0.0 (iBridge 22.16.13051.0.0,0)

Safari should have been updated to version 18.3.1 or 18.4 (19621.1.14.11.3, 19621).

Ventura

If your Mac is running macOS Ventura and has been updated, it should still be running 13.7.4 (build 22H420). If it has a T2 chip, its firmware should remain at
EFI 2069.80.3.0.0 (iBridge 22.16.13051.0.0,0)

Safari should have been updated to version 18.3.1 or 18.4 (18621.1.14.11.3, 18621).

SilentKnight

To keep a complex situation as simple as possible, SilentKnight only considers one firmware version to be current for each model of Mac. If it tried anything more complex, I’d not be able to cope. As there are presently two different ‘current’ and supported versions of T2 firmware in use, SilentKnight goes with the older one. That way it doesn’t complain, but politely remarks for Sequoia 15.3.2:
EFI version found 2069.80.3.0.0 (iBridge: 22.16.13060.0.0,0) ;
expected 2069.80.3.0.0 (iBridge 22.16.13051.0.0,0)

Please bear with me until Apple resyncs T2 firmware across the three supported versions of macOS. I’m sure that will return with the release of 15.4, 14.7.5 and 13.7.5. If not, we can all scream together.

Sonoma 14.7.5 and Ventura 13.7.5

Many have been reporting that their Macs have been updated to 14.7.5 or 13.7.5, and some have claimed that those versions have been released by Apple. They are in fact beta-releases of the next scheduled updates to Sonoma and Ventura, and haven’t yet been generally released. If your Mac is running one of those, you might like to check it against recent beta-releases:

• 21 February 2025 betas: Sonoma 14.7.5 (23H510), Ventura 13.7.5 (22H510)
• 10 March 2025 betas: Sonoma 14.7.5 (23H520), Ventura 13.7.5 (22H520)
• 17 March 2025 betas: Sonoma 14.7.5 (23H525), Ventura 13.7.5 (22H525)

App Store full installers

If you download a full installer from the App Store or elsewhere, the current releases are:

• Sequoia 15.3.2 (build 24D81)
• Sonoma 14.7.4 (build 23H420), which will then need Safari updated
• Ventura 13.7.4 (build 22H420), which will then need Safari updated.

How has this happened?

Normally, when the current version of macOS has a security update, the two older versions that are still supported have matching security updates. That would have brought 14.7.5 and 13.7.5 along with 15.3.2. However, in this case the patch to be applied could be supplied in a Safari update for the older two. As that’s much smaller and simpler than a full macOS update, Apple opted to supply those as Safari updates alone, which can’t of course be a new version of macOS.

This is possible because Safari and some of its supporting frameworks and components aren’t part of the Signed System Volume, so updating them doesn’t require the System volume to be rebuilt, turned into a snapshot, and installed as a new Signed System Volume.

However, firmware updates can only be supplied and installed as part of a full macOS update, so it was only possible to update T2 firmware in Sequoia systems being updated the long way to 15.3.2.

I hope this dispels any remaining confusion.

I’m grateful to ExcleX for pointing out that Safari versions can vary according to when you updated.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5290. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds a single new Yara rule for MACOS.SLEEPYSTEGOSAURUS.SYM.

You can check whether this update has 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 this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5290.

Sequoia systems only

This update has just 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 5290 but your Mac still reports an older version is installed, you can force the update using
sudo xprotect update

Hurrah!

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

Updated 1840 GMT 11 March 2025, announcing iCloud release!

Apple has just released an update for macOS Sequoia bringing it to version 15.3.2. There are also Safari updates available for Sonoma and Ventura.

The update for Apple silicon is about 1.45 GB in size, while that for Intel Macs is around 600 MB.

Security release notes are already available, and list a single WebKit vulnerability, that Apple states is a supplementary fix for an attack that was blocked in iOS 17.2, and in iOS had been exploited before it was fixed in iOS 17.2.

Updated with Safari info, 1930 GMT 11 March 2025.

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?

As those running macOS 15 Sequoia are only too painfully aware, the way that XProtect’s data is updated has changed from that still used in older versions of macOS. Instead of accessing that data in XProtect.bundle in the path /Library/Apple/System/Library/CoreServices, in Sequoia the data used is in /private/var/protected/xprotect. While the old location can still be updated using Software Update, SilentKnight and softwareupdate, the only way to update the copy in the new location is using the xprotect command tool, which normally obtains its updates through a connection to iCloud.

Updating in Sequoia

Since Sequoia 15.0, there has been a way to update data in the new location from XProtect.bundle in the old location, using the command
sudo xprotect update
If that finds a newer version of the bundle in the old location, it installs its contents in the new location, so updating XProtect in Sequoia. At least, it did until the release of Sequoia 15.3 or 15.3.1.

When Apple released XProtect version 5288 on 26 February, it did so through both connections, and all versions of macOS were able to update promptly and successfully. That didn’t work with its successor 5289 on 4 March, though. Although the Software Update version was successfully updated in the old location to 5289, no iCloud update was made available, and sudo xprotect update proved unable to update from that to the new location.

This has left those running Sequoia 15.3.1 with version 5289 in the old location, but 5288 stuck in the new location. As Apple doesn’t tell us of these updates, nor of how XProtect is supposed to work in Sequoia or earlier, it’s impossible to tell whether this is intended, or an unintended failure.

Which rules does XProtect now use?

One potential explanation is that XProtect has returned to using its old location for the Yara rules, in /Library/Apple/System/Library/CoreServices/ XProtect.bundle/Contents/Resources/XProtect.yara. That’s fairly easy to check in the log, where it states the location of the rules it’s using to check an app for malware. The answer is
com.apple.xprotect Using XProtect rules location: /var/protected/xprotect/XProtect.bundle/Contents/Resources/XProtect.yara
that’s the new location for Sequoia, and hasn’t changed since 15.0.

How does macOS now update the correct rules?

By chance, a few minutes after I had started my Mac mini M4 Pro yesterday, I opened SilentKnight and discovered that XProtect had successfully been updated to version 5289, something it wouldn’t do the previous evening following its release. At that time:

• XProtect in its old location had been updated to 5289 the previous evening.
• SilentKnight now reported XProtect in its new location was 5289.
• sudo xprotect check reported the version in iCloud was still 5288.
• sudo xprotect update reported that it was already up to date.
• xprotect version reported that 5289 had just been installed, about 2.5 minutes after starting up.

This was an ideal opportunity to discover how XProtect had updated this time, by looking in the log with LogUI. That showed the update had been dispatched as a background activity by DAS, with ID com.apple.security.syspolicy.xprotect-update. That’s a scheduled background activity run every 24 hours, and in this case appears to have been dispatched because of the recent boot.

That activity connects to XProtectUpdateService, which then runs the check and updates as necessary, connecting to iCloud using CloudKit. On this occasion it ‘found’ the 5289 update, although maybe in its old location rather than in iCloud, and updated XProtect’s data in its new location.

How to keep XProtect up to date

From this experience, bearing in mind that everything might change again in the future, my advice is to:

• Check for updates as usual using SilentKnight, Software Update, or softwareupdate.
• When offered an update by any of those, install it gratefully.
• Run SilentKnight a few minutes later. If that update isn’t reflected in the version shown, restart your Mac and leave it for 10 minutes or so before checking again.
• If it still doesn’t update correctly, check again in about 24 hours, by which time DAS should have dispatched com.apple.security.syspolicy.xprotect-update with any luck.

I suppose that’s progress?

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.

‘Tis impossible to be sure of any thing but Death, Taxes and macOS updates.
(Modified with apology from the original, said by Toby Guzzle in Christopher Bullock’s play The Cobbler of Preston (1716), quoted in turn by Daniel Defoe and most famously by Benjamin Franklin in 1789.)

Last week my iMac Pro was updated against my wishes from macOS Sequoia 15.1.1 to 15.3.1. Although it wasn’t my intention, it proved a relief in two ways, first that my ageing iMac Pro survived the process without losing any data or dying completely, and second that I had at last caught a forced update red-handed. For some years I have been aware of many who suffered a similar fate, where they had been careful to avoid upgrading or updating macOS, but had eventually succumbed to it unwittingly. At last I was able to experience this at first hand, and capture log excerpts to discover just what happened.

Deceit

My conclusions were:

• Software update notifications tricked me into unwittingly agreeing to perform a macOS update.
• That update was expressly against my Software Update settings.
• I was given no second chance to confirm I intended the update to take place.
• The update was scheduled to be performed when my Mac was unattended.
• DAS scheduling and dispatch were unaware of the scheduled backups to be performed later that night, and dispatched the update at a time before those backups were scheduled. Had anything gone wrong in the update, I could have had to fall back on backups made nearly 24 hours earlier, and would have lost a whole day’s changes.

What I’d like to see is a change to the process initiated by opting to perform a delayed update, either later or that night. If the user opts for that, then Software Update should display a clear confirmation dialog, offering options to cancel the update or postpone it further. If the user does accept, then they should be offered a timeframe for the update to be performed, to allow it to be scheduled after any nightly backups.

Above all, the user should never be given a forced choice between updating now or later tonight, and there should always be a third option to defer further.

This has been a long-running flaw in the behaviour of macOS that has shocked and antagonised many users over several years. Although we’re all in favour of Apple encouraging and facilitating us to keep macOS up to date, there’s neither need nor excuse to do so by deceiving us by trickery. Deceit undermines confidence in both Apple and its products and is notoriously bad marketing and support.

This chart shows how I believe the process works, from the initial notification options to starting the update.

Opacity and persistence

During my investigation of how this unwanted update had occurred, I hadn’t expected to meet my old friend Duet Activity Scheduler (DAS). As I traced through the log extracts it became clear that, once the update had been scheduled by DAS, the only way to postpone or abort it would have been to shut the Mac down. Activities scheduled by DAS-CTS are hidden from the user, who has neither awareness nor control over them.

DAS and its linked XPC Activity subsystem, alias Centralised Task Scheduling or CTS, now manage over 500 background activities in macOS, including Time Machine backups and XProtect Remediator scans. They’re one of the few parts of the system that remains almost inaccessible. DAS manages lists of activities that can’t be inspected, and dispatches them according to opaque criteria. Once an activity is scheduled by DAS, there’s no way a user can remove it from its lists, so it will inexorably attain a score sufficient to pass that set by DAS as its threshold. For a few brief moments that activity will be visible among running processes, then vanish again into obscurity.

If I wanted to design persistent code that periodically harvests and send sensitive data to a remote server, DAS-CTS would be highly attractive. As there’s no way to inspect its scheduled activities, no security software could discover the existence of that activity, unless they were fortunate enough to catch it while it’s running briefly. Such activities don’t need a tell-tale LaunchDaemon or LaunchAgent, but can be arbitrary code in a completion handler within an apparently innocent app. They’re run using XPC, but without its formalities or restrictions.

DAS-CTS seems to rely largely on security through obscurity, and opening up inspection of its activity lists could be a valuable first step in preventing its abuse. It has enjoyed a decade since its release in 2014 apparently without being exploited, although its opacity makes it difficult to know that with any confidence. Perhaps it’s time for a reassessment.

Over the last few years, many have reported that their Macs spontaneously updated or even upgraded macOS when they didn’t expect them to, and often against their wishes. This can occur when Software Update in System Settings has Install macOS updates turned off. Explanations of how Apple appears to be able to override that setting have so far been lacking; this article explains how it happened overnight to my iMac Pro, when it updated itself from Sequoia 15.1.1 to 15.3.1.

Spontaneous macOS update

My story will be familiar to others who have suffered a similar forced update: I came down in the morning to discover my iMac Pro had shut down when I had left it running just seven hours earlier. A little detective work in its log revealed what had happened while I had been asleep.

Although I have kept this iMac Pro up to date with macOS since I first installed Mojave on it on 18 November 2018, it’s growing old and a bit creaky, and the update to Sequoia 15.1.1 on 19 November last year was slightly traumatic, with a series of shutdowns rather than restarts. I therefore decided to leave it running 15.1.1 until I had completed migrating to my Mac mini M4 Pro this Spring.

As a result, it had periodically notified me of updates to 15.2, 15.3, and most recently 15.3.1, each of which I had politely declined. Those notifications became more persistent, and one or two gave me either of two options, to update now, or later that night, and couldn’t otherwise be dismissed. I therefore chose to defer the update until the night, and nothing came of them.

One of those notifications, though, decided to end my procrastination and added a background activity named com.apple.SUOSUScheduler.tonight.install to the DAS-CTS scheduling system. In the small hours of the morning, DAS rescored its list of activities, and decided that it was time to dispatch that task, writing these entries in the log:
01:39:07.463 com.apple.duetactivityscheduler Rescoring all 499 activities [Entered SmartPowerNap]
01:39:07.490 com.apple.duetactivityscheduler 0:com.apple.SUOSUScheduler.tonight.install:3370CB:[{name: Thermal Policy, policyWeight: 5.000, response: {0, 0.20, }}, Decision: CP Score: 0.915843}
01:39:07.490 com.apple.duetactivityscheduler '0:com.apple.SUOSUScheduler.tonight.install:3370CB' CurrentScore: 0.915843, ThresholdScore: 0.162610 DecisionToRun:1
01:39:07.589 com.apple.xpc.activity Initiating: com.apple.SUOSUScheduler.tonight.install (0x7fd1d582a720)

That activated SoftwareUpdate, which ignored my user settings and proceeded to install the update:
01:39:07.589 com.apple.SoftwareUpdate SUOSUTonightObserver: Tonight activity fired!
01:39:07.590 com.apple.powerd Process softwareupdated.308 Created MaintenanceWake "com.apple.SoftwareUpdate.TonightActivityTrigger" age:00:00:00 id:55834610938 [System: SRPrevSleep kCPU]
01:39:07.590 com.apple.SoftwareUpdate SUOSUTonightObserver: Proceeding with updates
01:39:07.590 com.apple.SoftwareUpdate SUOSUServiceDaemon: Chose on-console client: SoftwareUpdateNotificationManager (type = sunm, pid = 698, uid = 501, path = /System/Library/PrivateFrameworks/SoftwareUpdate.framework/Versions/A/Resources/SoftwareUpdateNotificationManager.app/Contents/MacOS/SoftwareUpdateNotificationManager)

It turns out that these ‘DoItLater’ or ‘installTonight’ updates are already well provided for by SoftwareUpdate:
01:39:08.243 com.apple.SoftwareUpdate Successful call to startInstallingDoItLaterUpdates
01:39:08.244 com.apple.SoftwareUpdate SUOSUShimController: Start installing updates: {(<SUOSUProduct: MSU_UPDATE_24D70_patch_15.3.1_minor>)}, options: { DoInForeground = 0; DoItLater = 1; ForceRestart = 0; InitiatingClient = 2; MDMInitiated = 0;}
01:39:08.245 com.apple.SoftwareUpdate SUOSUMobileSoftwareUpdateController: Updating additionalUpdateMetricEventFields: {autoUpdate = false; buddy = false; commandLine = false; ddm = false; installTonight = true; mdm = false; notification = true; settings = false; }

The update process carefully avoided revealing what was about to happen:
01:39:08.362 com.apple.SoftwareUpdate MSU update already prepared, skip showing license agreement
01:39:08.396 com.apple.SoftwareUpdate Skipping showing the SLA
01:39:08.396 com.apple.SoftwareUpdate SUOSUShimController: Updates require post-install action (restart), installing now
01:39:08.396 com.apple.SoftwareUpdate SUOSUShimController: MSU update already prepared
01:39:08.396 com.apple.SoftwareUpdate SUOSUShimController: Download required: 0 (legacy=0, MSU=0)
01:39:08.396 com.apple.SoftwareUpdate SUOSUShimController: Notification manager client, proceeding with countdown notification flow without confirmation
01:39:08.397 com.apple.SoftwareUpdate SUOSUNotificationUpdateService: Install did begin for updates: ( "<SUOSUProduct: MSU_UPDATE_24D70_patch_15.3.1_minor>")

Local authentication was also disabled to ensure that nothing stood in the way of the imminent update:
01:39:08.443 com.apple.SoftwareUpdate SUAppStoreUpdateController: authorize
01:39:08.508 com.apple.SoftwareUpdate SUOSUAuthenticationManager: Disabling local authentication requirement
01:39:08.556 com.apple.SoftwareUpdate SUOSUMobileSoftwareUpdateController: Download finished: (null)
01:39:08.557 com.apple.SoftwareUpdate SUOSURestartCountdownOperation: Successful downloads, proceed to countdown (downloadOnly=0)
01:39:08.561 com.apple.SoftwareUpdate SUOSURestartCountdownOperation: Starting restart countdown
01:39:09.713 com.apple.SoftwareUpdate SUOSUCountdownNotification: seconds remaining: 60
01:40:08.570 com.apple.SoftwareUpdate SUOSUCountdownNotification: seconds remaining: 1
01:40:08.573 com.apple.SoftwareUpdate SUOSUUpdateController: Sending authorization to softwareupdated
01:40:08.598 com.apple.SoftwareUpdate SUOSUUpdateController: Successfully authorized with softwareupdated
01:40:08.953 com.apple.SoftwareUpdate Restarting for software update (forced=0)
01:40:10.958 com.apple.SoftwareUpdate Starting post-logout mode (skipConfirm = 1, reconnectMode = 0, shouldShutdown = 0)
01:40:10.958 com.apple.SoftwareUpdate SUOSUAuthenticationManager: Disabling local authentication requirement
01:40:11.523 com.apple.SoftwareUpdate SUOSUAuthorizationController: Non-interactive authorization succeeded for non-admin user
01:40:11.523 com.apple.SoftwareUpdate SUOSUUpdateController: Sending authorization to softwareupdated
01:40:11.562 com.apple.SoftwareUpdate SUOSUUpdateController: Successfully authorized with softwareupdated
01:40:42.389 com.apple.SoftwareUpdate SUHelper: Rebooting (success = 1, night install = 1, shutdown = 1)
01:40:42.396 com.apple.SoftwareUpdate SUHelper: Preparing for night install

What happened next was unexpected by macOS, though:
01:40:46.875 === system wallclock time adjusted
and that was the last entry in the log until the initial kernel boot entry over five hours later when I started the Mac up:
06:57:24.842 === system boot: 78F481CC-E26F-464C-BEB7-6E26E49DB8DC

At 03:15 and 04:15 that morning, full backups should have been made of the Data and another working volume. Because at that time the Mac was shut down in the middle of a possibly failed update, those backups were never made. Thankfully when it started up just before 07:00 it was able to complete the update and then resumed normal service.

Points of note

• Software update notifications tricked the user into unwittingly agreeing to perform a macOS update.
• That update was expressly against Software Update settings.
• The user was given no second chance to confirm they intended the update to take place.
• The update was scheduled to be performed when the Mac was unattended.
• DAS scheduling and dispatch were unaware of the scheduled backups to be performed later that night, and dispatched the update at a time before those backups were scheduled.
• As the update was scheduled to be performed unattended, no warning was given when it was about to start, and there was no opportunity to delay the update until after backups had been completed.
• Once the update had been scheduled by DAS, the only way to postpone or abort it would have been to shut the Mac down. Activities scheduled by DAS-CTS are hidden from the user, who has neither awareness nor control over them.
• The overall effect is that macOS enforces updates on the user against their express settings, without giving them the opportunity to postpone or abort the update.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5288. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds two new rules for MACOS.TAILGATOR.UPD and MACOS.TAILGATOR.INLASCLDR.

You can check whether this update has 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 this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5288.

Sequoia systems only

This update is also available for Sequoia via iCloud. If you want to check that manually, use the Terminal command
sudo xprotect check
then entering your admin password. If that returns version 5288 but your Mac still has an older version installed, you can force the update using
sudo xprotect update

This version is now available via Software Update, softwareupdate, or in SilentKnight as well. If your Mac is running Sequoia and you download it that way, rather than using iCloud, then once it’s installed you’ll need to run the update command for that to take correctly.

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

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.

Apple has just released a security update to macOS Sequoia to bring it to version 15.3.1, and security updates for 14.7.4 and 13.7.4. There don’t appear to be any associated updates to Safari.

Sequoia 15.3.1 update for Apple silicon is about 1.43 GB in size, and about 640 MB for Intel Macs.

Although these updates are listed on Apple’s security release notes page, they have no published entries, so there’s no information as to what they might address.

Apple silicon Macs have a firmware update, taking iBoot to version 11881.81.4, but there are no changes to firmware in Intel Macs.

The macOS build number is 24D70, and Safari remains at version 18.3 (20620.2.4.11.5). Messages has single minor build increment, but there are no other significant changes in bundled apps or in /System/Library.

Last updated at 1953 GMT 10 February 2025.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5287. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds two new rules for MACOS.FLUFFYFERRET.CT and MACOS.TAILGATOR, together with a complete set of UUIDs for all existing rules.

You can check whether this update has 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 this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5287.

Sequoia systems only

This update is now also available for Sequoia via iCloud. If you want to check that manually, use the Terminal command
sudo xprotect check
then entering your admin password. If that returns version 5287 but your Mac still has an older version installed, you can force the update using
sudo xprotect update

This version is now available via Software Update, softwareupdate, or in SilentKnight as well. If your Mac is running Sequoia and you download it that way, rather than using iCloud, then once it’s installed you’ll need to run the update command for that to take correctly.

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

Updated 2240 GMT 5 February 2025 with iCloud release.

For many who prefer to wait a little, the x.3 update is a popular time to upgrade to the next major version of macOS. By then, most of the major bugs should have been fixed, and some fine tuning performed on new features. So if you’ve just joined Sequoia from something older, you might now be wondering what on earth is going on with XProtect, which still baffles those of us who have been here since 15.0.

Which XProtect?

First allow me to dispel a common confusion: this article is about the XProtect we know of old, run on demand during Gatekeeper checks before macOS launches code. This isn’t the same as XProtect Remediator (XPR), a suite of scanning modules, that periodically searches your Mac to detect and remove known malware. Unlike XPR, XProtect leaves little trace in the logs, merely that it has checked code for malware and didn’t find any.

XProtect relies on a handful of configuration files in a bundle that doesn’t itself contain any code. Most important among them is a file containing a large and growing set of rules used to detect malicious code, the Yara rules. Every two weeks, Apple’s security engineers assemble the latest set of Yara rules into the bundle named XProtect.bundle and it’s distributed as an update from Apple’s servers.

Whichever earlier version of macOS your Mac has been running, it has downloaded those updates using Software Update, SilentKnight or a similar mechanism, installed that bundle into /Library/Apple/System/Library/CoreServices, and the next time that XProtect is run on demand it uses those updated rules to improve your Mac’s protection against malware.

Changes in Sequoia

In the past, XProtect has been something of a quiet backwater, and its Yara rules changed little and infrequently. That has changed dramatically over the last couple of years, and the rules have grown in number, size and sophistication. They have also become more responsive, to ensure XProtect’s checks keep up with the latest malware and its changes.

For Sequoia, Apple has changed the way that XProtect is updated, and where its Yara rules and other files are kept, to /var/protected/xprotect/XProtect.bundle, although previous versions of macOS continue to receive their updates as before. Updates for Sequoia can be delivered either via a connection to iCloud, or the established method to Apple’s Software Update servers.

Last week’s updates

Last week, the regular fortnightly update to XProtect 5286 was ready for release on 27 January, but macOS Sequoia 15.3, security updates, and updates to all the other OSes were released instead. They put a heavy load on the Software Update servers, so it appears the update to XProtect 5286 was delayed. That was a wise decision: Apple has previously tried releasing security data updates at the same time as OS updates, and it doesn’t work out well for anyone.

In the early hours (GMT) of 29 January, XProtect 5286 was released for download to macOS Sequoia via its iCloud connection. As this doesn’t use the servers responsible for macOS and other OS updates, that took advantage of this new feature in Sequoia. Most of the Macs running 15.0 or later were most probably updated to 5286 by the end of that day.

Twenty-four hours later, in the early hours (GMT) of 30 January, the same updated version of XProtect was released for download from Apple’s Software Update servers, enabling those still running older versions of macOS to install the update, as the load must have been reducing on those servers.

Although that seems clear and straightforward, what users saw often appeared puzzling if not incorrect. If you were running Sequoia, your XProtect data bundle with its Yara rules was probably updated silently during 29 January, but the following day (when your Mac was already enjoying the protection of the update) you were offered the 5286 update by Software Update, softwareupdate or SilentKnight, as if your Mac still had’t been updated. Some of you thought that was the real update, but it wasn’t, as that only updated the bundle stored at the old location, which isn’t used by XProtect in Sequoia.

How it worked

For the great majority of folk who don’t even know what XProtect is or does, this is all irrelevant, as their Macs continue to work as before, just improve their malware detection silently. For those of us who take an interest, or want to know what’s going on, it can appear profoundly confusing. To help clarify, here are two different ways that a Mac running Sequoia could successfully install XProtect 5286.

The preferred way is using the new iCloud connection, which doesn’t require that you have connected to iCloud, as it’s made outside your Apple Account or iCloud Drive. To start with, both copies of the XProtect bundle are version 5285. Then, probably on 29 January, that Mac connects to iCloud and downloads the update direct to its new location (red). Although the copy in the old location remains at version 5285, the copy used by XProtect is now using the updated rules in 5286.

Then, when the Software Update copy is installed the following day, both copies are brought up to 5286.

But Sequoia can still make use of the general release of the new version, as shown in this second diagram. Suppose that Mac running Sequoia didn’t have access to iCloud on 29 January, and the following day isn’t able to update to 5286 via iCloud. However, that update is still delivered from the Software Update servers. Over the next minutes or hours, macOS can then use that copy of the XProtect bundle to update the bundle now used by XProtect in Sequoia, as shown on the bottom line. If that doesn’t work, the user can run
sudo xprotect update
in Terminal, and that will force the local update.

Improvements

The benefits of this new system to the Sequoia user are therefore:

• updating 24 hours earlier, when Software Update servers were still heavily loaded;
• fall back to the traditional method if an iCloud update doesn’t occur, followed by local installation to the new location.

Now we can all return to trying out Genmoji. While they may be trivial by comparison, they bring a lot of fun to Messages, and we could all do with plenty of fun as well as better security.

Apple has overnight released an update to XProtect for all supported versions of macOS, bringing it to version 5286. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version removes the rule for MACOS.1afcb8b, and adds three new rules for MACOS.FROSTYFERRET.UI, MULTI.FROSTYFERRET.CMDCODES and MACOS.FRIENDLYFERRET.SECD. It seems the animal of the week is a ferret.

You can check whether this update has 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 this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5286.

Sequoia systems only

This update is also available for Sequoia only via iCloud. If you want to check that manually, use the Terminal command
sudo xprotect check
then entering your admin password. If that returns version 5286 but your Mac still has an older version installed, you can force the update using
sudo xprotect update

This version is now available via Software Update, softwareupdate, or in SilentKnight as well. If your Mac is running Sequoia and you download it that way, rather than using iCloud, then once it’s installed you’ll need to run the update command for that to take correctly.

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

Early today Apple released an update to XProtect for macOS Sequoia only bringing it to version 5286. As usual, Apple doesn’t release information about what security issues this update might add or change. Macs running earlier versions of macOS should still be using version 5285.

This version removes the rule for MACOS.1afcb8b, and adds three new rules for MACOS.FROSTYFERRET.UI, MULTI.FROSTYFERRET.CMDCODES and MACOS.FRIENDLYFERRET.SECD. It seems the animal of the week is a ferret.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

This update is now available for Sequoia only via iCloud. If you want to check that manually, use the Terminal command
sudo xprotect check
then entering your admin password. If that returns version 5286 but your Mac still has an older version installed, you can force the update using
sudo xprotect update
Currently, this new version isn’t available via Software Update, softwareupdate, or in SilentKnight, and is only available via iCloud connections to Macs running Sequoia.

The macOS 15.3 update introduces Genmoji creation in Messages and other apps on Apple silicon Macs, and improves notification summaries with an updated style and access from the Lock Screen (Apple silicon only). Notification summaries for News & Entertainment have been temporarily disabled while the engineers fix them. Those who don’t wish to use AI should ensure that they turn it off, as 15.3 now enables it by default when it’s supported.

Bugs fixed include improved stability for apps over VPN connections when using the built-in software firewall and content filter extensions, and successful AirPlay connections with the firewall and content filters. Brief release notes are here, and those for Enterprise are here. Security release notes are available here, and list 57 vulnerabilities, one of which is believed to have been actively exploited in iOS.

iBoot firmware on Apple silicon Macs is updated to version 11881.81.2, and T2 firmware to 2069.80.3.0.0 (iBridge: 22.16.13051.0.0,0). The macOS build number is 24D60, with kernel version 24.3.0.

Significant changes in bundled apps include:

• Contacts, build increment
• Freeform to version 3.3
• News to version 10.2.1
• Passwords to version 1.3
• Photos, build increment
• Safari to version 18.3 (20620.2.4.11.5)
• Stocks version 7.1.1
• Tips version 15.3.

Many of the usual public and private frameworks have build increments, particularly those involved in AI. However, this update appears to be more incremental bug-fixes and improvements, rather than anything more extensive or radical. Significant changes seen in /System/Library include:

• In CoreServices, Paired Devices.app to version 6.4.0
• Many AGX kernel extensions to version 324.6
• APFS is updated to version 2317.81.2.

Apple has just released the update to bring macOS Sequoia to version 15.3, together with security updates 14.7.3 and 13.7.3 for those using Sonoma or Ventura, who should also update to Safari 18.3 separately.

In Sequoia, this introduces Genmoji in Messages and other apps (Apple silicon only), and brings improvements in AI on Apple silicon Macs, although notification summaries for News & Entertainment are temporarily unavailable while they’re being sorted out.

Security release notes for Sequoia 15.3 are here, and list some 57 vulnerabilities that have been addressed, of which one is believed to have been actively exploited in iOS. Notes for Sonoma’s 38 fixes are here, and those for Ventura’s 30 are here.

Firmware on Apple silicon Macs (iBoot) is updated to version 11881.81.2, Safari to version 18.3 (20620.2.4.11.5), and the macOS build number is 24D60.

The 15.3 update is around 2.54 GB to download for Apple silicon Macs, and 1.93 GB for Intel models.

There’s also a separate update to XProtect imminent. I’ll post details about that separately.

Updated 1908 GMT on 27 January 2025.