The Zero Day Initiative has published ZDI-26-610, disclosing a use-after-free vulnerability in Apple Safari's JavaScriptCore engine — specifically in the B3 JIT compiler's ReduceStrength optimization phase. Tracked as CVE-2026-64715 with a CVSS score of 8.8 (High), the flaw allows a remote, unauthenticated attacker to execute arbitrary code in the context of the browser process. The only prerequisite is user interaction: the target must visit a malicious webpage or open a malicious file.
If you manage a macOS or iOS-adjacent fleet, this is a browser-based drive-by RCE in the default rendering engine for the Apple ecosystem. JavaScriptCore (JSC) is not just Safari — it underpins WebKit, which means every third-party browser on iOS and every app embedding WKWebView inherits exposure to this class of bug. On macOS, successful exploitation lands code execution inside the renderer, and history shows us that renderer RCE is routinely chained with a sandbox escape to achieve full compromise. Treat this as a patch-now item for any environment where Safari is present.
Technical Analysis
Affected Component and Root Cause
The vulnerability resides in JavaScriptCore's B3 (Bare Bones Backend) JIT compiler, within the ReduceStrength optimization phase. B3 is the low-level optimizing backend of JSC's FTL (Faster Than Light) tier — the pipeline that compiles hot JavaScript functions down to machine code. ReduceStrength is a peephole optimization pass that rewrites expensive operations into cheaper equivalents (strength reduction).
The defect is a classic lifetime-management failure: during strength reduction, the optimization pass can free or reallocate an object (typically a value node or associated metadata) while a dangling reference to it is retained elsewhere in the compilation graph. When the compiler — or later, the generated code — dereferences that stale pointer, it operates on reclaimed heap memory. An attacker who can groom the JSC heap (via controlled JavaScript allocations) can reclaim the freed slot with attacker-influenced data, turning the UAF into controlled type confusion, and from there into arbitrary read/write primitives and code execution.
Attack Chain from a Defender's Perspective
- Delivery: Victim is lured to a malicious page (phishing, malvertising, watering hole, compromised legitimate site) or opens a malicious local file rendered by WebKit.
- Heap grooming: Attacker JavaScript triggers JIT compilation of a crafted function, forcing B3 into the ReduceStrength path and priming heap layouts with predictable allocations.
- Trigger: The optimizer frees the object and the dangling reference is reused, giving the attacker a type-confused object or controlled pointer dereference.
- Primitive escalation: Standard JSC exploitation technique — fake objects, addrof/fakeobj primitives, arbitrary read/write.
- Code execution: Shellcode or JIT-sprayed payloads execute within the WebContent (renderer) process. From there, a motivated actor chains a sandbox escape to reach the host.
Exploitation Requirements and Status
- Authentication: None required.
- User interaction: Required — target must visit a malicious page or open a malicious file.
- CVSS: 8.8 (High) per ZDI.
- Exploitation status: As of the ZDI advisory, this is a coordinated disclosure. There is no public confirmation of in-the-wild exploitation or CISA KEV listing at time of writing, but browser UAFs with public technical detail have a historically short time-to-weaponization. Apple ecosystem bugs of this class are prized by commercial spyware vendors and APT actors alike. Do not wait for a KEV entry to act.
Why This Matters Beyond Safari
On iOS and iPadOS, all browsers are required to use WebKit/JavaScriptCore under the hood — so Chrome, Firefox, and Edge on iOS share this engine's exposure profile. On macOS, any application embedding WKWebView (mail clients, collaboration tools, Electron wrappers with native bridges) may render attacker-controlled content through the same vulnerable code path. Scoping your response to "Safari users only" understates the blast radius.
Detection & Response
This is a renderer-side memory corruption bug, so there is no signature for the crash itself that is practical for network detection. Defensive value comes from hunting the post-exploitation behaviors: the WebContent/renderer process spawning unexpected children, unexpected script interpreter execution following browsing activity, and persistence dropped after a drive-by. These are high-fidelity, low-noise detections on macOS endpoints.
SIGMA Rules
---
title: macOS WebContent Renderer Spawning Shell or Script Interpreter
id: 4b7e2f91-3c8a-4d5e-9f01-6a2b8c3d4e5f
status: experimental
description: Detects Safari/WebKit WebContent or renderer processes spawning shells or script interpreters, consistent with post-exploitation activity following browser compromise such as CVE-2026-64715 JavaScriptCore exploitation.
references:
- http://www.zerodayinitiative.com/advisories/ZDI-26-610/
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/02/10
tags:
- attack.execution
- attack.t1059
- attack.initial_access
- attack.t1189
logsource:
category: process_creation
product: macos
detection:
selection_parent:
ParentImage|contains:
- 'com.apple.WebKit.WebContent'
- '/Safari.app/'
selection_child:
Image|endswith:
- '/zsh'
- '/bash'
- '/sh'
- '/python'
- '/python3'
- '/osascript'
- '/curl'
- '/bash'
condition: selection_parent and selection_child
falsepositives:
- Rare; legitimate WebContent processes do not normally spawn shells. Developer tooling with embedded WebKit may trigger on osascript.
level: high
---
title: macOS Suspicious Persistence Item Installed Following Browser Activity
id: 8c1f3a52-7d4e-4b6a-8e12-9f3d5a7b1c2d
status: experimental
description: Detects creation of LaunchAgents or LaunchDaemons plist files in user or system library paths, a common persistence step after browser-based compromise including drive-by exploitation of WebKit/JavaScriptCore flaws such as CVE-2026-64715.
references:
- http://www.zerodayinitiative.com/advisories/ZDI-26-610/
- https://attack.mitre.org/techniques/T1543/001/
author: Security Arsenal
date: 2026/02/10
tags:
- attack.persistence
- attack.t1543.001
logsource:
category: file_event
product: macos
detection:
selection:
TargetFilename|contains:
- '/Library/LaunchAgents/'
- '/Library/LaunchDaemons/'
filter_known_good:
Image|contains:
- 'Installer'
- 'softwareupdated'
- 'Munki'
- 'Jamf'
condition: selection and not filter_known_good
falsepositives:
- Legitimate software installs and MDM tooling. Filter for your sanctioned deployment agents.
level: medium
KQL — Microsoft Sentinel / Defender
For organizations ingesting macOS endpoints via Microsoft Defender for Endpoint (MDE on macOS is fully supported) or via Syslog/CEF from an EDR, hunt renderer-spawned child processes and suspicious downloads executed shortly after browsing activity.
// Hunt: WebKit renderer spawning shells or script interpreters (post-exploitation behavior for CVE-2026-64715 class bugs)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName has_any ("com.apple.WebKit.WebContent", "Safari")
or InitiatingProcessFolderPath has "WebKit"
| where FileName in~ ("zsh", "bash", "sh", "python", "python3", "osascript", "curl", "wget", "base64")
| project TimeGenerated, DeviceName, AccountName,
InitiatingProcessFileName, InitiatingProcessCommandLine,
FileName, ProcessCommandLine, SHA256
| order by TimeGenerated desc
// Hunt: LaunchAgents/LaunchDaemons plist creation on macOS endpoints (persistence after drive-by compromise)
DeviceFileEvents
| where TimeGenerated > ago(7d)
| where FolderPath has_any ("/Library/LaunchAgents/", "/Library/LaunchDaemons/", "~/Library/LaunchAgents/")
| where ActionType == "FileCreated"
| where InitiatingProcessFileName !in~ ("Installer", "softwareupdated", "jamf", "Munki")
| project TimeGenerated, DeviceName, FolderPath, FileName,
InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256
| order by TimeGenerated desc
Velociraptor VQL
Use this hunt across macOS endpoints to enumerate renderer child processes and recently created persistence plists in a single sweep.
-- Hunt for WebKit/Safari renderer child processes and new LaunchAgents persistence
-- Relevant to post-exploitation triage for browser UAF bugs such as CVE-2026-64715
LET procs = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ 'zsh|bash|osascript|python|curl'
OR Exe =~ '/bin/(z|ba)?sh|osascript|python'
LET persistence = SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=['/Library/LaunchAgents/*.plist',
'/Library/LaunchDaemons/*.plist',
'/Users/*/Library/LaunchAgents/*.plist'])
WHERE Mtime > now() - 604800
SELECT * FROM procs
Run the persistence query as a separate hunt or join against process telemetry in your notebook. Any plist modified within the last 7 days that does not map to a known software deployment warrants triage.
Remediation
Immediate Actions
- Patch Safari and the OS. Apple delivers JavaScriptCore/WebKit fixes through Safari updates on macOS and through iOS/iPadOS point releases. Apply the latest Safari update and the current macOS/iOS security release from Apple as soon as it is available for your supported versions. Check System Settings > General > Software Update, and verify against Apple's security releases page: https://support.apple.com/en-us/HT201222
- Enable Rapid Security Responses on all managed Apple devices — Apple's out-of-band mechanism exists precisely for engine-level WebKit bugs like this.
- Confirm ZDI advisory details at the source: http://www.zerodayinitiative.com/advisories/ZDI-26-610/
Verification and Hardening Script (macOS Fleet)
#!/bin/bash
# CVE-2026-64715 Safari/JavaScriptCore verification script for macOS endpoints
# Run via MDM (Jamf, Kandji, Mosyle) or manually. Checks Safari/macOS build and Rapid Security Response status.
echo "=== Safari Version ==="
SAFARI_VER=$(/usr/bin/defaults read /Applications/Safari.app/Contents/Info.plist CFBundleShortVersionString 2>/dev/null)
SAFARI_BUILD=$(/usr/bin/defaults read /Applications/Safari.app/Contents/Info.plist CFBundleVersion 2>/dev/null)
echo "Safari: ${SAFARI_VER} (build ${SAFARI_BUILD})"
echo "=== macOS Version ==="
/usr/bin/sw_vers
echo "=== Rapid Security Response Status ==="
/usr/bin/defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist 2>/dev/null | grep -i -E "RapidSecurity|CriticalUpdate" || echo "RSR preference not found - verify MDM profile enforcement"
echo "=== Pending Software Updates ==="
/usr/sbin/softwareupdate -l 2>/dev/null | grep -i -E "safari|macOS|security" || echo "No pending security updates listed"
echo "=== Recent LaunchAgents (last 7 days) - persistence check ==="
/usr/bin/find /Library/LaunchAgents /Library/LaunchDaemons ~/Library/LaunchAgents -name "*.plist" -mtime -7 2>/dev/null
echo ""
echo "ACTION: Compare Safari build against Apple's security releases page:"
echo "https://support.apple.com/en-us/HT201222"
echo "If a Safari/WebKit update is pending, install immediately and reboot if required."
Compensating Controls While Patching
- Restrict untrusted browsing on high-risk users (executives, developers with prod access) to a hardened alternate browser or isolated browsing session until the fleet is patched.
- Enforce DNS/web filtering to block newly registered and uncategorized domains — the most common delivery vector for drive-by exploit pages.
- MDM enforcement: Push a configuration profile preventing deferral of Safari/OS security updates beyond 72 hours for managed devices.
- Disable JavaScript in high-sensitivity contexts (e.g., mail preview panes, embedded viewers) where operationally feasible — a blunt instrument, but it neutralizes JIT-reachable bugs entirely for that surface.
- Monitor for the detections above for 14+ days post-patch across any device that browsed externally before remediation, since exploitation leaves no reliable crash artifact on the endpoint itself.
Vulnerability Management Notes
Add CVE-2026-64715 to your scanner's watch list for macOS Safari version detection, and track remediation SLA as High / 72 hours consistent with a CVSS 8.8 remote code execution requiring only user interaction. Browser engine CVEs should be treated with the same urgency as network-facing services — the "user interaction required" qualifier has never stopped a phishing lure.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.