MEDIUM 6.5

CVE-2026-43713: Apple Safari & iOS Permissions Flaw Leaks Sensitive Data

Apple has patched a permissions flaw that could allow website visits to leak sensitive user data. The vulnerability affects Safari, iOS, iPadOS, and macOS. An attacker does not need special privileges—only the ability to host a website and trick a user into visiting it. Once a victim lands on the malicious page, the flaw can expose confidential information. The fix involves tightening permission checks to prevent unauthorized data access.

Source data · NVD / CISA · public domain

CVSS
3.1 · 6.5 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
Weaknesses (CWE)
CWE-284
Affected products
4 configuration(s)
Published / Modified
2026-06-29 / 2026-07-27

NVD description (verbatim)

A permissions issue was addressed with additional restrictions. This issue is fixed in Safari 26.5.2, iOS 26.5.2 and iPadOS 26.5.2, macOS Tahoe 26.5.2, tvOS 26.6, visionOS 26.6, watchOS 26.6. Visiting a website may leak sensitive data.

6 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-43713 is a permissions enforcement issue (CWE-284) in Apple's WebKit engine and platform permissions model. The vulnerability allows arbitrary websites to bypass intended restrictions on sensitive data access, resulting in information disclosure. The attack vector is network-based with low complexity; exploitation requires only user interaction (visiting a compromised or attacker-controlled site). No elevation of privilege is needed. The flaw has been remediated across Safari, iOS, iPadOS, and macOS by implementing additional authorization checks at the WebKit or platform layer to prevent unauthorized access to protected resources.

Business impact

Organizations managing fleets of Apple devices face elevated risk of user credential, authentication token, or other sensitive data exfiltration through drive-by web visits. This is particularly concerning for enterprises where employees access corporate applications from Safari or WebKit-based browsers. Data breaches stemming from this vulnerability could compromise authentication chains, API keys, or session tokens, leading to downstream lateral movement or account takeovers. Compliance obligations around PII and PHI protection may be triggered if user data is extracted via this vector.

Affected systems

Safari (version prior to 26.5.2), iOS (prior to 26.5.2), iPadOS (prior to 26.5.2), macOS Tahoe (prior to 26.5.2), tvOS (prior to 26.6), visionOS (prior to 26.6), and watchOS (prior to 26.6). The vulnerability spans Apple's entire ecosystem where WebKit is the rendering engine. Organizations relying on Safari as a primary browser or allowing user device access to corporate web applications should prioritize patching across all affected platforms.

Exploitability

Exploitation is straightforward: an attacker controls a website or compromises an existing high-traffic site, then waits for users to visit. No malware installation, code execution, or privilege escalation is required. The user interaction barrier is minimal—a simple visit triggers the vulnerability. However, the attacker must first identify what sensitive data is accessible and craft a webpage capable of extracting it. Real-world attack campaigns would likely target high-value victims or use watering-hole techniques. The fact that this flaw is not yet in the CISA KEV catalog suggests active exploitation in the wild is not confirmed, but the low technical bar and high-impact data disclosure make it an attractive target for opportunistic attackers.

Remediation

Update to Safari 26.5.2, iOS 26.5.2, iPadOS 26.5.2, macOS Tahoe 26.5.2, tvOS 26.6, visionOS 26.6, and watchOS 26.6 or later. Prioritize iOS and iPadOS devices in mobile-first environments, and Safari on macOS for desktop users. Verify patch deployment using device management tools (MDM/EMM) to confirm no devices are running vulnerable versions. For organizations unable to update immediately, restrict user access to untrusted websites and educate users against clicking links from unknown sources—though this is a weak mitigation given the attack surface.

Patch guidance

Apple has released coordinated patches across its product line. Verify the exact version numbers against Apple's security updates portal before deployment. iOS and iPadOS updates are typically delivered over-the-air; ensure automatic updates are enabled or push updates via MDM. macOS Tahoe 26.5.2 and tvOS/visionOS/watchOS 26.6 should be deployed systematically. Test patches in a limited pilot on representative devices before enterprise rollout to confirm no application compatibility regressions. Monitor Apple's security advisories page for any follow-up patches, as permissions issues sometimes require iterative fixes.

Detection guidance

Monitor for successful visits to suspicious or attacker-controlled domains combined with subsequent unauthorized data access or exfiltration. Examine web proxy or firewall logs for user connections to known malicious sites or watering holes. Implement DNS sinkholing or content filtering to block known attack infrastructure. Use endpoint detection and response (EDR) tools to flag unusual process behavior or unexpected network communications from Safari/WebKit processes. Check for signs of credential compromise or session token abuse that may result from successful exploitation. Device inventory scans should confirm patch compliance and flag any systems still running pre-26.5.2/26.6 versions.

Why prioritize this

Medium severity score (6.5 CVSS) reflects high confidentiality impact but no code execution or system compromise. However, the attack's simplicity, low technical barriers, and direct path to sensitive data exposure warrant prompt patching. Organizations handling PII, financial data, or authentication credentials should prioritize this fix. The absence from KEV indicates either limited observed exploitation or a small exploitation window before patches became widely deployed—do not assume low priority based on KEV status alone.

Risk score, explained

CVSS 3.1 base score of 6.5 (MEDIUM) is calculated as: Network-based attack vector (AV:N), low attack complexity requiring no special tools (AC:L), no privilege requirements (PR:N), user interaction required to visit the site (UI:R), impact scoped to the user session (S:U), high confidentiality impact from data leakage (C:H), no integrity impact (I:N), and no availability impact (A:N). The score appropriately reflects a serious but not critical threat—the data disclosure risk is significant, yet exploitation does not compromise system integrity or availability. Temporal factors (no active exploitation in KEV) do not modify the base score but should inform deployment urgency relative to other patches.

Frequently asked questions

Can this vulnerability steal passwords directly from a user's password manager or stored browser credentials?

The vulnerability leaks sensitive data accessible to the website context, which typically includes cookies, session tokens, local storage, and data the browser has explicit permission to share with that site. Direct exfiltration of password manager vaults depends on whether the user's password manager integration allows JavaScript access—most modern password managers restrict this. However, session cookies and authentication tokens are at significant risk, which can allow attackers to hijack authenticated sessions.

If a user simply visits a malicious site but does not interact with it (no clicks, no form submissions), can the vulnerability still be triggered?

Yes. The description and CVSS vector (UI:R) indicate that visiting the website itself is sufficient; the user need not actively interact. This makes the attack surface much broader than vulnerabilities requiring explicit user action like clicking a button or running a macro.

Do VPNs or browser privacy extensions mitigate this vulnerability?

Standard VPNs and privacy extensions do not directly mitigate a client-side permissions flaw in WebKit. They may reduce the attacker's visibility into the user's network, but the vulnerability lies in how Safari/WebKit enforces permissions on the user's device. Patching is the only reliable mitigation. Some extensions that block cookies or restrict site permissions may raise friction, but this is not a substitute for patching.

Should organizations block Safari or restrict its use until patches are deployed?

Outright blocking Safari may not be practical, especially on iOS/iPadOS where Safari is tightly integrated. Instead, enforce patching through MDM policies, restrict access to untrusted domains via network filtering, and educate users to avoid suspicious links. Interim network-based controls can reduce exposure while patches roll out, but patching remains the primary remediation.

This analysis is based on CVE-2026-43713 as published by Apple. Version numbers, affected products, and patch details should be verified against official Apple security advisories before deployment. SEC.co does not provide or endorse any exploit code or proof-of-concept. Organizations should test patches in a controlled environment before production rollout. The absence of CISA KEV listing does not indicate low severity or low attack likelihood; prioritize patching based on organizational risk and data sensitivity. For the latest details, consult Apple's security updates page and coordinated vulnerability disclosure statements. Source: NVD (public-domain), retrieved 2026-08-08. Analysis generated by SEC.co (claude-haiku-4-5).