The issue was addressed with improved checks

CVE-2026-43735 is a CWE-352 Cross-Site Request Forgery in an Apple web-facing component, disclosed 2026-06-29 and patched in the latest Safari/iOS/iPadOS security train. The CVSS vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N) describes the classic CSRF shape: a remote attacker hosts a malicious page, an already-authenticated victim visits it, and the browser submits state-changing requests on their behalf — yielding high confidentiality and integrity impact on the victim's session but no availability impact and no scope change.

Apple's HIGH (8.1) rating is mechanically correct under CVSS math but overstates field risk. CVSS does not model the user-interaction tax, the requirement that the victim be concurrently authenticated, or the fact that EPSS sits at 0.00168 (bottom quartile) with no KEV listing and no public PoC chain. For a fleet defender, this is a real bug that warrants a patch cycle — not a fire drill.

Why this verdict

• User-interaction tax: UI:R means the victim must visit attacker-controlled content while concurrently authenticated — a meaningful friction point that CVSS bakes in only partially.
• Scope unchanged + A:N: the chain ends at the victim's own account; there is no pivot to other users, no DoS, and no server-side compromise.
• No exploitation signal: EPSS 0.00168, not on KEV, no public PoC two days post-disclosure — the realistic 90-day exploitation probability is low.
• Role multiplier: the affected component is an Apple consumer/client web surface (Safari / iCloud / Apple ID), NOT a high-value-role component in the noisgate catalog (no IdP, hypervisor, CA, PAM, backup, kernel-mode agent, or network edge). The blast-radius floor therefore stays at MEDIUM — no role exists where this chain ends in fleet, domain, or supply-chain compromise.
• Vendor patch ships in the standard train: mitigation is a routine Safari/iOS update, not an out-of-band fix — consistent with vendor's own internal triage being closer to MEDIUM than CRITICAL.

Why not higher?

Not HIGH because there is no role multiplier and no compounding factor: this is a single-victim, single-session CSRF with no scope escape and no current exploitation. To reach HIGH it would need either active exploitation (it has none) or a chain that pivots to fleet/identity scale (it does not).

Why not lower?

Not LOW because CSRF with C:H/I:H against an Apple ID-adjacent surface can plausibly mutate account state (recovery email, trusted devices) leading to downstream account takeover. That class of outcome is a real-world MEDIUM, not negligible.

1. Roll the June 2026 Safari / iOS / iPadOS / macOS security train through MDM — This is the actual fix. Push via Jamf / Intune / Workspace ONE with a staged ring (pilot → broad) and complete within the noisgate remediation SLA of ≤ 365 days for MEDIUM — but in practice align to your normal monthly Apple patch cadence, which is far inside that window.
2. Enforce 'Prevent cross-site tracking' and block third-party cookies in managed Safari profiles — Configuration Profile key BlockPopups + WebKitPreferences knobs reduce cross-site request surface and break many CSRF chains that rely on third-party cookie attachment. Deploy alongside the patch wave.
3. Tighten phishing controls on the email gateway — Because the chain requires luring an authenticated victim to a malicious page, robust URL detonation and brand-impersonation rules at Proofpoint / Mimecast / Defender for O365 directly snap step 2 of the kill chain. No mitigation SLA applies at MEDIUM — treat as standard hygiene.
4. Reduce Apple ID session lifetime for managed users and require re-auth for sensitive changes — Shorter session windows shrink the time during which a victim is 'concurrently authenticated', which is the precondition for CSRF success.

Run on each managed macOS endpoint (or via MDM script runner) as a standard user — no root required. Invoke as bash check-CVE-2026-43735.sh. The script checks installed Safari and macOS build numbers against the June 2026 fix train. For iOS/iPadOS, use your MDM's OS-version compliance report instead.

#!/usr/bin/env bash
# noisgate verification — CVE-2026-43735 (Apple CSRF, June 2026 train)
# Exit 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
set -u

FIXED_SAFARI_MAJOR=26
FIXED_SAFARI_MINOR=2   # 26.2 or later carries the June 2026 fix
FIXED_MACOS_BUILD_PREFIX="26."  # macOS Tahoe 26.x train

if ! command -v sw_vers >/dev/null 2>&1; then
  echo "UNKNOWN: not a macOS host"; exit 2
fi

MACOS_VER=$(sw_vers -productVersion 2>/dev/null || echo "")
SAFARI_PLIST="/Applications/Safari.app/Contents/Info.plist"

if [[ ! -f "$SAFARI_PLIST" ]]; then
  echo "UNKNOWN: Safari not installed at expected path"; exit 2
fi

SAFARI_VER=$(/usr/bin/defaults read "$SAFARI_PLIST" CFBundleShortVersionString 2>/dev/null || echo "")
if [[ -z "$SAFARI_VER" ]]; then
  echo "UNKNOWN: could not read Safari version"; exit 2
fi

IFS='.' read -r SMAJ SMIN _ <<<"$SAFARI_VER"
SMAJ=${SMAJ:-0}; SMIN=${SMIN:-0}

if (( SMAJ > FIXED_SAFARI_MAJOR )) || { (( SMAJ == FIXED_SAFARI_MAJOR )) && (( SMIN >= FIXED_SAFARI_MINOR )); }; then
  SAFARI_OK=1
else
  SAFARI_OK=0
fi

if [[ "$MACOS_VER" == ${FIXED_MACOS_BUILD_PREFIX}* ]]; then
  MACOS_OK=1
else
  MACOS_OK=0
fi

echo "Safari: $SAFARI_VER  macOS: $MACOS_VER"
if (( SAFARI_OK == 1 && MACOS_OK == 1 )); then
  echo "PATCHED"; exit 0
else
  echo "VULNERABLE"; exit 1
fi

Sources

1. Apple — About the security content of Safari 26.2
2. Apple — About the security content of iOS 26.2 and iPadOS 26.2
3. Apple — About the security content of macOS Tahoe 26.2
4. Apple security releases index
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS model
7. OWASP — Cross-Site Request Forgery (CSRF)
8. MDN — SameSite cookies