Apple’s malware signature engine has moved to build 5367, the third XProtect revision in under two weeks. The update landed on Macs over the past day, arriving through the normal background delivery channel rather than an operating system release.
The version bump comes with a narrow set of changes. Apple left the main YARA rule set untouched, so the broad detection logic that catches known macOS families is unchanged. All the movement sits in the Osascript scripts, which watch for malicious AppleScript behavior. One new rule joins the list, tagged for a family catalogued as MACOS.OSASCRIPT.ANJXLOOC, while an existing signature aimed at MACOS.ANGRYORB.JXDR was revised.
That AngryOrb entry is not new to security tooling. Earlier builds in this cycle already carried detection for it, so the tweak points to Apple refining how the rule fires rather than chasing a fresh campaign.
XProtect is the silent layer most Mac users never think about. It runs in the background, flags known malware, and ships updates without asking permission or prompting a restart. Because Apple publishes no notes with these releases, the rule names are the only public record of what changed.
Administrators who need the signature on systems that have not picked it up can force it with SilentKnight, where it appears under the label XProtectPlistConfigData_10_15-5367.
The rollout has not been frictionless. Users on macOS Sequoia report the manual path has become unreliable, with the xprotect command-line tool returning an update-check error instead of confirming the new build.
That gap matters for anyone who treats XProtect as auditable. If the command-line check fails silently, a Mac can look current in System Information while the underlying signature set lags behind. SilentKnight and SystHist read the installed data files directly, which sidesteps the broken check.
