This is a poisoned web page slipped under the door, not a skeleton key to your network
Important date/intel correction: your supplied title/CWE/CVSS/KEV status line up with the *RCE-flavored* record for CVE-2024-23222 that NVD and later Apple updates now carry. Apple’s January 22, 2024 release notes for iOS 17.3, Safari 17.3, macOS Sonoma 14.3, and tvOS 17.3 briefly described the same CVE as a WebKit logic issue causing unexpected cross-origin behavior; later Apple/NVD records describe it as a WebKit type confusion issue that may lead to arbitrary code execution and note possible exploitation. For patching, treat CVE-2024-23222 as the exploited WebKit bug fixed in Safari 17.3, iOS/iPadOS 17.3, iOS/iPadOS 16.7.5, iOS/iPadOS 15.8.7, macOS Monterey 12.7.3, macOS Ventura 13.6.4, macOS Sonoma 14.3, tvOS 17.3, and visionOS 1.0.2.
Vendor HIGH 8.8 is directionally fair, but not because this is internet-facing server RCE. The real risk driver is that CISA added it to KEV on January 23, 2024, meaning defenders should assume real exploitation happened. The main downward pressure is practical reach: exploitation starts with a victim rendering attacker-controlled web content, then still has to survive WebKit hardening and usually gains only renderer/browser-context execution unless paired with another bug. That keeps it out of CRITICAL for enterprise patch triage even with KEV status.
4 steps from start to impact.
Land the victim on attacker-controlled web content
WKWebView. The weaponized component is WebKit/JavaScriptCore on the endpoint, not a listening enterprise service.- Victim must browse to attacker-controlled content or open content rendered by WebKit
- Target device must still be on a vulnerable Apple branch
- Requires user interaction (UI:R) or an app/webview render path
- Enterprise web filtering, DNS controls, and mail/link rewriting reduce reach
- Many corporate iPhones/iPads run current branches via MDM
Trigger the WebKit bug in the renderer
- Precise browser/OS build targeting
- A working exploit for the target branch and architecture
- Modern browser exploit development against Apple platforms is non-trivial
- Patch-level drift across iOS/macOS branches breaks reliability
- No credible mass-market public PoC was easy to find
Gain browser-context code execution or same-origin bypass
- Exploit must succeed against the target build
- Victim must have interesting browser sessions or accessible web apps
- Safari/WebKit sandboxing constrains direct host impact
- Without follow-on bugs, blast radius may stay inside browser-accessible data
- Short-lived or MFA-bound sessions reduce payoff
Chain to broader device compromise if an escape exists
- A second exploit or bypass beyond the WebKit bug
- Targeted operator tradecraft and higher exploit maturity
- Multi-bug chains are scarce and burn quickly
- Apple platform mitigations raise exploit cost
- Most opportunistic actors stop at credential/session theft
The supporting signals.
| In-the-wild status | Yes. CISA added CVE-2024-23222 to KEV on 2024-01-23, which is the strongest practical signal here. |
|---|---|
| KEV timing | Date added 2024-01-23; federal due date 2024-02-13. |
| Proof-of-concept availability | No trustworthy public PoC/exploit repo stood out. That lowers copycat risk, but it does *not* outweigh KEV. |
| EPSS | 0.00618 from your intel block: low absolute score, which is exactly why KEV matters more than EPSS for this one. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H = remote delivery, no auth, but user interaction required; strong impact if landed. |
| Affected versions | Apple branches before Safari 17.3, iOS/iPadOS 17.3, iOS/iPadOS 16.7.5, iOS/iPadOS 15.8.7, macOS 12.7.3/13.6.4/14.3, tvOS 17.3, and visionOS 1.0.2. |
| Fixed versions | Safari 17.3, macOS Monterey 12.7.3, Ventura 13.6.4, Sonoma 14.3, iOS/iPadOS 15.8.7, 16.7.5, 17.3, tvOS 17.3, visionOS 1.0.2. These are effectively Apple backports across older supported branches. |
| Exposure census | Internet scanning is the wrong lens. Shodan/Censys/FOFA won’t meaningfully enumerate exposure because WebKit lives on endpoints, not on an admin port. Use MDM/EDR inventory instead. |
| Disclosure date | Publicly disclosed on 2024-01-23; Apple releases shipped on 2024-01-22 for major branches, with later documentation updates on 2024-06-03, 2024-06-12, and 2024-11-14. |
| Researcher / reporting | Apple did not consistently credit an external finder for this CVE in the main January advisories. The later Apple/NVD trail ties it to WebKit Bugzilla 267134 / 265812 depending on which revision you follow, which is part of the advisory inconsistency. |
noisgate verdict.
The decisive factor is verified real-world exploitation via KEV, which keeps this out of any comfortable backlog bucket. The biggest brake on severity is that this is still a client-side lure-dependent WebKit bug whose reachable population and blast radius are both narrower than a true unauthenticated server-side RCE.
Why this verdict
- KEV raises the floor: CISA put it in KEV on 2024-01-23, so this is not a hypothetical browser bug; observed exploitation keeps it firmly in HIGH.
- UI:R cuts mass reach: every attack path starts with the victim rendering malicious web content, which narrows exploitable population compared with always-on network services. That is the main reason I trim the vendor 8.8 slightly.
- Browser sandbox limits one-bug blast radius: a single WebKit bug often yields browser-context impact first, with full device takeover typically requiring a second bug or chain. That keeps this below CRITICAL for enterprise-wide patch ordering.
Why not higher?
This is not an unauthenticated service you can sweep across the internet. It depends on a lure or watering-hole condition, and Apple platform mitigations mean a single-bug compromise may stop at browser context, session theft, or same-origin bypass rather than immediate full-host control.
Why not lower?
KEV is the tie-breaker. Even with low EPSS and meaningful user-interaction friction, CISA’s exploited designation means defenders should assume at least some operators already solved the hard parts and used this in the wild.
What to do — in priority order.
- Force Apple OS/browser compliance — Use MDM to identify devices below the fixed Apple versions and push forced updates. Because this CVE is KEV-listed, do this immediately, within hours, not on the normal HIGH 30-day rhythm.
- Block risky web destinations fast — Push temporary DNS/SWG blocks for uncategorized, newly registered, or campaign-linked domains feeding Safari/WebKit content. This buys exposure reduction immediately, within hours while stragglers patch.
- Constrain embedded webviews — For managed macOS apps and enterprise mobile apps that rely on
WKWebView, review whether untrusted external content can be opened and restrict where possible. Apply these temporary guardrails immediately, within hours for high-risk populations like execs and admins. - Hunt for session theft — Prioritize detections for token reuse, impossible-travel auth, fresh device fingerprints, and anomalous access after suspicious link clicks. Run this monitoring immediately, within hours because successful exploitation may show up as account abuse before host artifacts.
- Perimeter vulnerability scanning doesn't help much because there is no server socket to find; this is an endpoint/browser exposure problem.
- WAF rules are mostly irrelevant unless you control the malicious site, which you don't.
- MFA alone does not erase risk; browser exploitation can target cookies, tokens, and already-authenticated sessions.
Crowdsourced verification payload.
Run this on a managed macOS endpoint or through your Mac fleet tooling, for example: bash verify_cve_2024_23222.sh. It needs only standard user rights to read OS and Safari version info; for iPhone/iPad/Apple TV/Vision Pro, use MDM inventory against the same fixed-version thresholds because you cannot run this script there.
#!/bin/bash
# verify_cve_2024_23222.sh
# Check likely exposure to CVE-2024-23222 on macOS/Safari.
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
ver_lt() {
# returns 0 if $1 < $2
[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ] && [ "$1" != "$2" ]
}
get_safari_version() {
local plist="/Applications/Safari.app/Contents/Info.plist"
if [ -f "$plist" ]; then
/usr/libexec/PlistBuddy -c 'Print :CFBundleShortVersionString' "$plist" 2>/dev/null || true
fi
}
OS_VER=$(sw_vers -productVersion 2>/dev/null || true)
if [ -z "$OS_VER" ]; then
echo "UNKNOWN - could not determine macOS version"
exit 2
fi
SAFARI_VER=$(get_safari_version)
MAJOR=$(echo "$OS_VER" | cut -d. -f1)
MINOR=$(echo "$OS_VER" | cut -d. -f2)
PATCH=$(echo "$OS_VER" | cut -d. -f3)
PATCH=${PATCH:-0}
# Fixed macOS versions carrying this CVE fix
FIXED_MONTEREY="12.7.3"
FIXED_VENTURA="13.6.4"
FIXED_SONOMA="14.3"
FIXED_SAFARI="17.3"
# Newer major branches are assumed patched because this bug was fixed in January 2024.
if [ "$MAJOR" -ge 15 ]; then
echo "PATCHED - macOS $OS_VER is newer than affected branches checked by this script"
exit 0
fi
# Older unsupported branches: can't confidently assert package state.
if [ "$MAJOR" -lt 12 ]; then
echo "UNKNOWN - macOS $OS_VER is outside supported Apple branches covered by this check"
exit 2
fi
# Safari-specific check matters most on Monterey/Ventura where Safari was also separately patched.
if [ -n "$SAFARI_VER" ] && ver_lt "$SAFARI_VER" "$FIXED_SAFARI"; then
echo "VULNERABLE - Safari $SAFARI_VER is older than fixed Safari $FIXED_SAFARI"
exit 1
fi
case "$MAJOR" in
12)
if ver_lt "$OS_VER" "$FIXED_MONTEREY"; then
echo "VULNERABLE - macOS Monterey $OS_VER is older than fixed $FIXED_MONTEREY"
exit 1
else
echo "PATCHED - macOS Monterey $OS_VER meets fixed level $FIXED_MONTEREY"
exit 0
fi
;;
13)
if ver_lt "$OS_VER" "$FIXED_VENTURA"; then
echo "VULNERABLE - macOS Ventura $OS_VER is older than fixed $FIXED_VENTURA"
exit 1
else
echo "PATCHED - macOS Ventura $OS_VER meets fixed level $FIXED_VENTURA"
exit 0
fi
;;
14)
if ver_lt "$OS_VER" "$FIXED_SONOMA"; then
echo "VULNERABLE - macOS Sonoma $OS_VER is older than fixed $FIXED_SONOMA"
exit 1
else
echo "PATCHED - macOS Sonoma $OS_VER meets fixed level $FIXED_SONOMA"
exit 0
fi
;;
*)
echo "UNKNOWN - unhandled macOS branch $OS_VER"
exit 2
;;
esac
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.