Same-Origin Policy Bypass in Safari and In-App Web Views
Same-Origin Policy Bypass in Safari and In-App Web Views
- 60% of MD5 Password Hashes Can Be Cracked in Under an Hour with a Single GPU
- Dirty Frag: Root Access on Every Major Linux Distribution — No Patch, No Warning
- Ubuntu 26.04 LTS (Resolute Raccoon): The Most Ambitious Ubuntu LTS in a Decade
- Proton Mail: Data Transferred to FBI Again!
- How Close Are Quantum Computers to Breaking RSA-2048?
- How to Prevent Ransomware Infection Risks?
- What is the best alternative to Microsoft Office?
Security Report · Apple Platforms · April 2026
The Vulnerability That Exposed a Bigger Problem
CVE-2026-20643 is real — but the panic circulating online is not. Here is what the flaw actually does, what it doesn’t, and why it matters for the future of authentication.
CVE-2026-20643 · WebKit · Navigation API
Same-Origin Policy Bypass in Safari and In-App Web Views
A cross-origin flaw in WebKit’s Navigation API, patched by Apple in March 2026 via Background Security Improvements.
§ 01 — What Actually Happened
A Real Flaw, Amplified Into Fiction
In mid-March 2026, Apple quietly deployed its first Background Security Improvements update — a lightweight patch mechanism introduced in iOS 26.1 that fixes individual components like WebKit between full software releases. The fix addressed CVE-2026-20643, a genuine security flaw in how WebKit handles cross-origin navigation.
Shortly after, a piece of viral content began circulating — particularly across Chinese social media and messaging apps — dramatically claiming this vulnerability allowed hackers to steal every password in iCloud Keychain simply by sending someone a link they didn’t even need to click. The post was vivid, specific, and largely false.
❌ What the viral post claimed
That CVE-2026-20643 lets attackers silently steal all iCloud Keychain passwords — including WeChat, Alipay, Apple ID, and banking apps — just by sending a delivery notification or bank alert link. It also claimed hackers could remotely lock your device for ransom.
✅ What the vulnerability actually does
CVE-2026-20643 is a Same-Origin Policy bypass in WebKit’s Navigation API. It allows maliciously crafted web content to potentially access data from another open website in the same browser session — a genuine but limited form of cross-site data exposure. It does not provide direct access to Keychain, does not work silently from a link preview, and was not observed being actively exploited.
§ 02 — Claim-by-Claim Fact Check
Separating Signal From Noise
| Claim | Verdict | Reality |
|---|---|---|
| CVE-2026-20643 exists and affects Apple devices | True | Confirmed by Apple’s advisory, NVD, and independent security researchers. |
| You don’t need to click a link — just previewing it gets you hacked | False | Exploitation requires the browser to actively process maliciously crafted web content. A passive link preview does not execute WebKit. User interaction is required per Apple’s advisory. |
| All iCloud Keychain passwords can be stolen | False | The flaw is a cross-origin browser boundary issue, not a Keychain extraction exploit. A separate Keychain-related CVE (2026-28864) requires physical device access, not a remote attack. |
| Hackers can remotely lock your device for ransom | False | Nothing in CVE-2026-20643’s technical description enables remote device locking. This claim has no basis in the official advisory or any credible security reporting. |
| Older OS devices are primarily at risk | Partial | Older devices running iOS 18 are also affected and patched separately (iOS 18.7.7). However, the vulnerability was not confirmed as actively exploited on any platform. |
| Apple’s password leak checker doesn’t store your passwords | True | Apple uses Privacy Set Intersection technology. Passwords are hashed locally; Apple never sees plaintext. The comparison is performed on-device. The “15 bits” figure in the viral post is unverified but the general mechanism is correct. |
| Passkey eliminates phishing and is more secure than passwords | True | Passkey’s public-private key mechanism means phishing sites cannot steal credentials, as the private key never leaves the device’s secure enclave. |
§ 03 — Timeline
How This Unfolded
March 17, 2026
Apple publishes Background Security Improvements for iOS/iPadOS 26.3.1 and macOS 26.3.1/26.3.2, fixing CVE-2026-20643. Security researcher Thomas Espach is credited.
March 25, 2026
9to5Mac’s Security Bite analyses the patch. Notes it is not listed as actively exploited, while flagging a more serious local Keychain issue in the same batch (CVE-2026-28864).
Late March 2026
Viral content citing CVE-2026-20643 spreads widely, substantially exaggerating the flaw’s capabilities and conflating it with unrelated Keychain vulnerabilities.
April 8, 2026
Apple releases iOS 26.4, which bundles additional fixes including CVE-2026-20643 for devices not yet receiving Background Security Improvements, plus seven further CVEs.
April 13, 2026
This article. CVE-2026-20643 is patched on all current Apple platforms. No active exploitation confirmed.
§ 04 — The Bigger Picture
Three Tiers of Login Security
The viral post was wrong about CVE-2026-20643’s capabilities, but right about a more fundamental issue: in 2026, many users still protect critical accounts with nothing more than a reused string of characters. Understanding the three tiers of modern authentication is useful regardless of any specific vulnerability.
Tier 1 · Most Vulnerable
Plaintext Password
The browser remembers it, autofills it, and if the password database of any site you use is breached, every other account using the same password is immediately at risk. Chain-reaction compromise is the norm, not the exception.
Tier 2 · Better, Not Safe
Password + 2FA
A verification code on top of your password raises the bar significantly. However, SMS codes can be intercepted via SIM-swapping attacks. Authenticator app codes (TOTP) are stronger. Neither is immune to sophisticated phishing.
Tier 3 · Current Gold Standard
Passkey
Replaces the password with a public-private key pair. The private key never leaves your device’s secure enclave. Phishing is structurally impossible — Passkeys are bound to the exact domain and refuse to authenticate on impersonator sites.
§ 05 — Outlook
Are Passwords Nearly Dead?
The viral post declared the era of plaintext passwords is “nearing its end.” That’s directionally true over the long arc but significantly premature as an immediate forecast.
Passkeys and passwords will coexist for at least another decade — the transition is a slow erosion, not a cliff edge.
Apple, Google, and Microsoft all support Passkeys. Major platforms — Google, GitHub, Amazon, PayPal — have adopted them. The FIDO Alliance, the standards body behind Passkeys, continues to push broad adoption. But real-world friction remains substantial:
- The vast majority of websites — particularly smaller, legacy, or regional services — still only support passwords and have no near-term plans to change.
- Passkeys are device-dependent, creating genuine anxiety about what happens if a phone is lost. Cross-device sync through iCloud Keychain or Google Password Manager mitigates this but adds complexity.
- Enterprise adoption is slow. Corporate IT environments often take years to roll out new authentication standards across internal systems.
- User understanding is low. Many people don’t know what a Passkey is, which creates support burden and adoption resistance.
The realistic near-term future is a hybrid world: Passkeys as the default wherever supported, passwords as a persistent fallback everywhere else — for years to come.
§ 06 — Action Items
What You Should Actually Do
⚠️ Immediate Steps
Update your device. If you’re on iOS 26.x, go to Settings → Privacy & Security → Background Security Improvements and verify it’s applied. If you’re on iOS 18.x, update to iOS 18.7.7 or later. If you’ve updated to iOS 26.4, you’re covered.
Enable automatic Background Security Improvements. This ensures future lightweight security patches are installed without waiting for major updates.
- Check Settings → Passwords → Security Recommendations on your iPhone. Act on any red warnings — those accounts have appeared in known breach databases.
- Use a password manager (Apple Keychain, 1Password, Bitwarden) and generate a unique password for every site. Reuse is the single biggest practical risk.
- Enable Passkeys wherever offered — Google, Apple ID, GitHub, and PayPal all support it today. The setup takes under a minute.
- Prefer authenticator-app 2FA over SMS where Passkeys aren’t yet available. Apps like Authenticator generate codes locally without the SIM-swap risk.
- Be skeptical of security-adjacent viral content. If a claim involves a CVE number and dramatic consequences, look the CVE up at nvd.nist.gov or cve.org before sharing.
