CVE-2026-43735 · Apple WebKit Same-Origin Policy Bypass Leading to Cross-Origin Data…

01 · The Real Story

Like a hotel master key that only works if the guest opens the door first

CVE-2026-43735 is a same-origin policy (SOP) bypass in Apple's WebKit engine that allows a malicious webpage to exfiltrate data from other origins — effectively reading cookies, tokens, and page content that should be walled off. It affects Safari < 26.5.2, iOS/iPadOS < 26.5.2 (and the legacy branch < 18.7.10), macOS Tahoe < 26.5.2, tvOS < 26.6, visionOS < 26.6, and watchOS < 26.6. Because Apple mandates WebKit for all browsers on iOS/iPadOS, *every* browser on those platforms is affected, not just Safari.

Apple rates this HIGH at 8.1, and the CVSS vector claims both C:H and I:H. That's inflated. Apple's own description says the impact is data exfiltration — a confidentiality problem — yet the vector scores Integrity as High, which implies cross-origin state mutation (classic CSRF). The CWE-352 label reinforces the mismatch: this walks and talks like CWE-346 (Origin Validation Error), not CSRF. If you score the vector with I:N instead of I:H, the CVSS drops to 6.5. Combine that with zero wild exploitation, zero public PoC, an EPSS of 0.23%, and the fact that every chain starts with the user clicking a link — and HIGH is an overstatement for patch-queue prioritization.

"WebKit SOP bypass lets a malicious page read cross-origin data, but user click required and no wild exploitation."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Attacker crafts malicious page with SOP bypass payload

The attacker builds a webpage that exploits the insufficient checks in WebKit's cross-origin enforcement. The page contains JavaScript that leverages the flaw to read data from a victim origin (e.g., bank.example.com). No special tooling is publicly available — the attacker needs to reverse-engineer or independently discover the specific WebKit code path from the diff of the Safari 26.5.2 patch.

Conditions required:

Knowledge of the specific WebKit code path vulnerable to SOP bypass
Hosting infrastructure for the malicious page

Where this breaks in practice:

No public PoC exists — attacker must develop the exploit from scratch or from diff analysis
WebKit bugs in the SOP enforcement layer are notoriously browser-version-specific; minor version differences break reliability

STEP 02

Victim visits the malicious URL

The attacker delivers the link via phishing email, malvertising, watering-hole compromise, or a redirect chain from a compromised ad network. The victim must actively navigate to or be redirected to the attacker-controlled page. No interaction beyond the initial page load is required once the user arrives.

Conditions required:

Victim uses an unpatched Safari/WebKit browser
Victim clicks a link or loads a page containing the exploit

Where this breaks in practice:

Enterprise email gateways (Proofpoint, Mimecast, Microsoft Defender for O365) filter known phishing domains
Secure Web Gateways and DNS filtering (Zscaler, Umbrella) block categorized malicious URLs
User awareness training reduces click-through rates on suspicious links
Apple's Intelligent Tracking Prevention and fraud warnings add friction

Detection/coverage: Email gateway logs, SWG/proxy logs, and DNS query logs all provide visibility into the delivery phase.

STEP 03

WebKit processes content and bypasses SOP

When the victim's browser renders the malicious page, WebKit fails to enforce same-origin checks correctly. The attacker's JavaScript can now read response bodies, cookies, or DOM content from a different origin loaded in the same browsing context. This is silent — no crash, no prompt, no visible indicator to the user.

Conditions required:

Victim has an active authenticated session on the target origin in the same browser
WebKit version is unpatched (< 26.5.2 on Tahoe, < 18.7.10 on legacy branch)

Where this breaks in practice:

SameSite=Strict cookies on the target origin block cross-origin cookie attachment
Content Security Policy (frame-ancestors, sandbox) on the target origin can prevent framing
CORS preflight on the target API may limit readable responses depending on the bypass mechanism

Detection/coverage: No native browser telemetry flags SOP bypass at runtime. EDR on macOS (CrowdStrike, SentinelOne) may detect anomalous WebKit child-process network connections to exfiltration endpoints.

STEP 04

Exfiltrated data sent to attacker C2

The stolen cross-origin data — session tokens, CSRF tokens, PII, page content — is transmitted to an attacker-controlled server via fetch, XMLHttpRequest, or image-beacon exfiltration. The attacker can then replay session tokens for account takeover on the target origin.

Conditions required:

Outbound HTTPS from the victim browser to the attacker's collection endpoint is not blocked

Where this breaks in practice:

DLP and CASB solutions inspecting outbound traffic may flag anomalous data transfers
Network segmentation and egress filtering can block connections to uncategorized domains

Detection/coverage: Network monitoring (NGFW, proxy logs) can detect connections to newly registered or low-reputation domains. UEBA may flag unusual data volumes from browser processes.

03 · Compensating Control

MEDIUM 5.5→LOW 3.1

SEVERITY REDUCED

Enforce SameSite=Strict on all internal web application session cookies — SameSite=Strict prevents the browser from sending cookies on cross-origin requests initiated from a different site, which breaks the exfiltration chain even if the SOP bypass fires — the target origin's cookies won't attach to the attacker-initiated cross-origin read. Audit all internal web apps and enforce this via reverse proxy headers (e.g., Header edit Set-Cookie ^(.*)$ "$1; SameSite=Strict" in Apache/nginx). No noisgate mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window.

MEDIUM 5.5→MEDIUM 4.5

Deploy Content Security Policy frame-ancestors and X-Frame-Options on sensitive internal apps — Setting Content-Security-Policy: frame-ancestors 'self' and X-Frame-Options: SAMEORIGIN on internal web applications prevents them from being framed by an attacker's page, which blocks many SOP bypass exploitation techniques that rely on embedding the target in an iframe. Apply via reverse proxy or application config.

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Push MDM-managed OS and Safari updates to the fleet — Use your MDM (Jamf Pro, Microsoft Intune, Kandji, Mosyle) to enforce Safari 26.5.2+, iOS/iPadOS 26.5.2+ or 18.7.10+, and macOS Tahoe 26.5.2+. Create a compliance policy that flags non-compliant devices and restricts their access to sensitive apps via conditional access. This is the definitive remediation — target the 365-day noisgate remediation SLA for MEDIUM severity.

MEDIUM 5.5→LOW 3.5

SEVERITY REDUCED

Enable Secure Web Gateway URL filtering for uncategorized and newly registered domains — Most SOP bypass exploit delivery relies on attacker-controlled domains that are either newly registered or uncategorized. Blocking access to domains < 30 days old and uncategorized domains at the SWG/DNS layer (Zscaler, Cisco Umbrella, Palo Prisma Access) eliminates the majority of delivery vectors without impacting legitimate browsing.

What doesn't work

Browser isolation (e.g., Menlo, Zscaler Browser Isolation) — while effective for many web threats, browser isolation that proxies full DOM rendering may still execute the SOP bypass in the remote browser instance and exfiltrate data if the user is authenticated to the target origin in the isolated session. Only pixel-streaming isolation fully contains this, but that breaks most enterprise web apps.
Network-level IDS/IPS signatures — the exploit payload is JavaScript executing in the browser context over HTTPS. There is no network-observable signature to write; TLS inspection sees the attacker's domain but not the exploit logic.
Disabling JavaScript — technically effective but operationally impossible for an enterprise fleet. Every modern web application requires JavaScript.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	None confirmed. Not listed in CISA KEV. No reports from Apple, Google TAG, or Citizen Lab of active exploitation. SSVC assessment: Exploitation = none, Automatable = no.
Proof of Concept	No public PoC found. Checked pocindex.io, GitHub (no repos named CVE-2026-43735), ExploitDB, and nuclei templates — all negative. The `SecureWithUmer/CVE-2026-PoCs` collection does not include this CVE.
EPSS	0.23% (approximately 22nd–26th percentile). Indicates very low predicted exploitation probability within 30 days.
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N` — Network-accessible, low complexity, no auth needed, but user interaction required. The I:H rating is questionable for a bug Apple describes purely as data exfiltration; with I:N the score drops to 6.5.
Affected Versions	Safari < 26.5.2, iOS < 26.5.2, iPadOS < 26.5.2, iOS < 18.7.10, iPadOS < 18.7.10, macOS Tahoe 26.0–26.5.1, tvOS < 26.6, visionOS < 26.6, watchOS < 26.6. On iOS/iPadOS, all browsers are affected (Chrome, Firefox, Edge all use WebKit).
Fixed Versions	Safari 26.5.2, iOS/iPadOS 26.5.2 and 18.7.10, macOS Tahoe 26.5.2, tvOS 26.6, visionOS 26.6, watchOS 26.6. Patches released June 29, 2026.
Scanning / Exposure	Not applicable to GreyNoise/Shodan/Censys — this is a client-side browser vulnerability, not a server-side service. Exposure is the count of unpatched Apple endpoints in your fleet, queryable via MDM (Jamf, Intune, Kandji).
Disclosure Date	2026-06-29 (coordinated disclosure with patch). Last NVD modification: 2026-08-17.
Credited Researchers	Gurpreet Shergill, Merrick Hare, Drinor Selmanaj (Sentry), Khai Tran, John Lussier, Rhyru9, Kwak Kiyong, Song Nuri. WebKit Bugzilla: 313357.
Patch Context	Part of a batch of 37 CVEs in the June 2026 Apple update cycle. ZDI noted 31 of 37 were WebKit/WebRTC bugs. This CVE is information-disclosure class, not among the kernel or sandbox-escape bugs ZDI flagged as top priority.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

User interaction gates every chain: The CVSS UI:R means every exploitation requires the victim to navigate to a malicious page. Enterprise email gateways, SWGs, and DNS filtering provide layered friction at the delivery stage. This is not a fire-and-forget network worm.
Zero weaponization signals: No public PoC, no KEV listing, no in-the-wild exploitation, EPSS at the 22nd percentile (0.23%). SSVC explicitly marks exploitation as *none* and automatable as *no*. The threat is theoretical today.
Integrity impact is overstated: Apple's own description says *exfiltrate data cross-origin* — a confidentiality issue. The CVSS vector scores I:H, but nothing in the advisory describes cross-origin state mutation. With I:N the base score drops to 6.5, which aligns with real-world impact.
Per-user, per-session blast radius: This is a client-side browser bug. Each successful exploit compromises one user's browsing session data. There is no lateral movement, no privilege escalation to system/kernel, no persistence, and no fleet-scale impact from a single exploit.
Role multiplier: WebKit is a client-side rendering engine and does not occupy any high-value infrastructure role (not an IdP, DC, hypervisor, CA, PAM, CI/CD system, backup, network edge, or SIEM). The worst plausible scenario is a privileged IT admin browsing to a malicious page while authenticated to a cloud console — yielding one admin's session token. This is a per-user outcome, not domain/fleet/supply-chain scale. No deployment-role floor applies.
Apple auto-update reduces dwell time: Consumer devices auto-update within days. MDM-managed enterprise fleets with deferred updates are the primary residual population, but these are queryable and patchable in bulk.

Why not higher?

There is no evidence of weaponization, active exploitation, or public PoC availability. The bug requires user interaction for every single exploitation attempt and yields per-user data theft — not system compromise, lateral movement, or fleet-scale impact. WebKit is not a high-value infrastructure component, so no deployment-role floor elevates the severity. The I:H in the vendor CVSS vector is unsupported by Apple's own impact description.

Why not lower?

Cross-origin data exfiltration from any origin is a genuine privacy and security risk — stolen session tokens enable account takeover. The attack complexity is Low and no privileges are required, meaning a working exploit would be reliable. Critically, on iOS/iPadOS, ALL browsers use WebKit, so the affected population is every unpatched Apple mobile device regardless of browser choice. The bug class (SOP bypass) has a strong history of eventual weaponization in WebKit.

06 · Verification

Crowdsourced verification payload.

Run on each macOS endpoint as any user (no elevated privileges needed). Example: bash check_cve_2026_43735.sh. For fleet-wide execution, push via MDM script payload (Jamf, Intune) or your RMM tool. On iOS/iPadOS, check the OS version via MDM compliance query instead.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/bin/bash
# CVE-2026-43735 - WebKit SOP Bypass Verification
# Checks Safari and macOS versions against patched releases.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

SAFARI_FIXED="26.5.2"
MACOS_TAHOE_FIXED="26.5.2"

version_gte() {
  # Returns 0 (true) if $1 >= $2 using sort -V
  printf '%s\n%s' "$2" "$1" | sort -V -C
}

RESULT="UNKNOWN"

# Detect platform
if ! command -v sw_vers &>/dev/null; then
  echo "UNKNOWN - Not a macOS system. For iOS/iPadOS, query OS version via MDM."
  exit 2
fi

MACOS_VER=$(sw_vers -productVersion 2>/dev/null)
MAJOR=$(echo "$MACOS_VER" | cut -d. -f1)

# Check Safari version
SAFARI_VER=$(/usr/bin/defaults read /Applications/Safari.app/Contents/Info.plist CFBundleShortVersionString 2>/dev/null)

if [ -z "$SAFARI_VER" ]; then
  echo "WARNING: Could not read Safari version."
else
  if version_gte "$SAFARI_VER" "$SAFARI_FIXED"; then
    echo "Safari $SAFARI_VER >= $SAFARI_FIXED — patched."
    RESULT="PATCHED"
  else
    echo "Safari $SAFARI_VER < $SAFARI_FIXED — VULNERABLE."
    RESULT="VULNERABLE"
  fi
fi

# Check macOS version (only Tahoe / 26.x is in scope)
if [ -n "$MACOS_VER" ]; then
  if [ "$MAJOR" -ge 26 ]; then
    if version_gte "$MACOS_VER" "$MACOS_TAHOE_FIXED"; then
      echo "macOS Tahoe $MACOS_VER >= $MACOS_TAHOE_FIXED — patched."
      [ "$RESULT" != "VULNERABLE" ] && RESULT="PATCHED"
    else
      echo "macOS Tahoe $MACOS_VER < $MACOS_TAHOE_FIXED — VULNERABLE."
      RESULT="VULNERABLE"
    fi
  else
    echo "macOS $MACOS_VER is pre-Tahoe. Check Safari version above; WebKit may receive standalone updates."
  fi
fi

echo "$RESULT"
case "$RESULT" in
  PATCHED)    exit 0 ;;
  VULNERABLE) exit 1 ;;
  *)          exit 2 ;;
esac