iOS Sandbox Escape PoC Exposes Crypto Wallet Keys on iOS 26/27 — Binance Warning, Detection and Mitigation Guide

On November 2026, Binance issued a public warning after a working iOS sandbox escape was published on GitHub by a researcher known as forcequit, in collaboration with 0xjohnny. The proof-of-concept demonstrates that an application running inside Apple's iOS sandbox can read files belonging to other applications on devices running iOS 26 and iOS 27. For any organization or individual holding cryptocurrency on a mobile device, this is a worst-case primitive: the sandbox is the control that keeps a malicious or compromised app away from your wallet's seed phrases, private keys, and stored session credentials.

Critically, Apple's updates for iOS 26 and 27 released yesterday do not list a fix for this issue. As of this writing, no CVE identifier has been publicly assigned, no patch is confirmed, and a functional PoC is publicly available. That combination — public exploit code, no vendor fix, and direct path to high-value financial secrets — means defenders must treat this as an active exposure window and compensate with policy, detection, and architectural controls immediately.

This is not a theoretical jailbreak scenario requiring physical access. The threat model is a malicious app — sideloaded, distributed via a rogue enterprise certificate, or smuggled through App Review — that abuses the sandbox escape to enumerate and read other applications' container data.

Technical Analysis

What the sandbox is supposed to guarantee

Every third-party iOS app executes inside a per-app sandbox enforced by the kernel's Sandbox kernel extension (seatbelt profiles) and mediated by daemons such as sandboxd and tccd (TCC — Transparency, Consent, and Control). An app's file access is scoped to its own container under /private/var/mobile/Containers/Data/Application/<UUID>/ and its bundle container. Cross-app reads of another app's Documents/, Library/, or Keychain items are denied by design.

What the escape breaks

The published PoC demonstrates that an app can escape that confinement and read files outside its own container — specifically other apps' data directories. From a defender's perspective, the exploitation chain looks like this:

1. Delivery: A malicious app lands on the device. Likely vectors given current iOS threat tradecraft: sideloading via enterprise developer certificates, alternative marketplaces (EU DMA context), TestFlight abuse, malicious configuration profiles, or a trojanized legitimate app.
2. Execution: The app runs with normal user-level entitlements — no jailbreak, no kernel code execution, no physical access required.
3. Escape: The app exercises the sandbox escape primitive to break file-system confinement.
4. Collection: It enumerates /private/var/mobile/Containers/Data/Application/*/ and reads high-value artifacts:
   • Wallet app data: seed phrase backups, unencrypted or weakly protected keystore files, private keys cached by poorly designed wallet apps
   • Session tokens, cookies, and credentials stored by exchange apps (Binance, Coinbase, etc.)
   • Authentication app databases (TOTP seeds in some authenticator implementations)
5. Exfiltration: Standard network egress from the app — indistinguishable from legitimate app traffic without content inspection.

Affected platforms and status

• Affected: iPhones running iOS 26 and iOS 27 (iPadOS equivalents should be assumed affected until Apple states otherwise)
• CVE: None publicly assigned at time of writing. Do not trust any third-party sources claiming a CVE number until Apple or NVD publishes one.
• CVSS: Not scored. Given no privileges required beyond a running app and direct confidentiality impact on other apps' data, expect a High severity rating if and when scored.
• Exploitation status: Public proof-of-concept on GitHub. No confirmed in-the-wild malicious campaign has been attributed yet, and it is not in CISA KEV — but PoC-to-weaponization timelines for mobile primitives are measured in days to weeks, especially with cryptocurrency theft as the payoff. Treat as imminently weaponizable.
• Patch status: The latest iOS 26/27 updates do not address it. No fix confirmed by Apple.

Why crypto wallets are the canary

Binance's warning is well-founded but the blast radius is broader. Any app storing secrets in its container is exposed: password managers with local vault caches, enterprise apps with embedded API keys, MDM-enrolled apps holding derived credentials, and messaging apps with local databases. Crypto wallets are simply where the monetization is fastest — a stolen seed phrase is irrevocable and instantly launderable.

Detection & Response

Honest assessment first: iOS is a closed telemetry environment. There is no EDR agent with kernel visibility on a non-jailbroken iPhone, and Velociraptor does not run on iOS — endpoint VQL hunting is not applicable here, and I will not hand you a rule that pretends otherwise. Detection must happen at three realistic layers: (1) MDM/MTD telemetry (device posture, sideloading indicators, jailbreak artifacts), (2) iOS unified/syslog forwarding where sandbox violation records surface, and (3) network egress from managed devices.

The highest-fidelity detective signal for this specific technique is the sandboxd violation record. When an app attempts a denied cross-container read, sandboxd logs a deny(1) file-read-data entry naming the offending process and target path. A successful escape may suppress denials, but attempted or partial exploitation, and exploitation on patched-but-similar paths, generates these records. Forward iOS logs via your MTD (Lookout, Zimperium, Microsoft Defender for Endpoint on iOS) or Apple Business Manager declarative management into your SIEM.

Sigma Rules

These rules assume iOS unified log / MDM telemetry ingested into a Sigma-capable pipeline. Adjust logsource to your MTD vendor's normalized schema.

---
title: iOS Sandbox Violation - Cross-App Container Read Attempt
id: 3f9c2a71-8b44-4e5d-9a01-7c2d5e6f8a9b
status: experimental
description: Detects sandboxd denial records where an iOS process attempts file-read access into another application's container directory, consistent with sandbox escape exploitation attempts such as the forcequit/0xjohnny PoC targeting iOS 26/27.
references:
  - https://thehackernews.com/2026/11/binance-warns-of-ios-sandbox-escape.html
  - https://attack.mitre.org/techniques/T1430/
author: Security Arsenal
date: 2026/11/14
tags:
  - attack.privilege_escalation
  - attack.credential_access
  - attack.t1430
logsource:
  product: ios
  service: syslog
detection:
  selection_process:
    process: 'sandboxd'
    message|contains: 'deny(1) file-read-data'
  selection_target:
    message|contains:
      - '/private/var/mobile/Containers/Data/Application/'
      - '/private/var/mobile/Containers/Shared/AppGroup/'
  condition: all of selection_*
falsepositives:
  - Rare; legitimate inter-app communication uses App Groups with explicit entitlements and should not generate deny records
level: high
---
title: iOS Enterprise Certificate Sideloading or Unknown Provisioning Profile
id: 8e1d4b62-5c93-4f7a-b2d8-1a3e6c9d0f24
status: experimental
description: Detects MDM telemetry indicating installation of applications signed with enterprise/developer certificates outside the managed App Store channel, or installation of unapproved configuration profiles - primary delivery vectors for malicious apps that would carry the sandbox escape exploit.
references:
  - https://thehackernews.com/2026/11/binance-warns-of-ios-sandbox-escape.html
  - https://attack.mitre.org/techniques/T1476/
author: Security Arsenal
date: 2026/11/14
tags:
  - attack.initial_access
  - attack.t1476
logsource:
  product: ios
  service: mdm
detection:
  selection:
    event_type:
      - 'enterprise_app_installed'
      - 'provisioning_profile_installed'
      - 'configuration_profile_installed'
    profile_approved: false
  condition: selection
falsepositives:
  - Internally developed line-of-business apps distributed via Apple Business Manager - maintain an allowlist of approved team IDs
level: medium
---
title: iOS Wallet or Exchange App Container Accessed by Non-System Process
id: 6b2f8e19-4d71-4a3c-95e2-0d8c7b1a5f63
status: experimental
description: Detects file access events referencing known cryptocurrency wallet or exchange application container paths initiated by processes other than the owning application or legitimate Apple system daemons, per MDM/MTD file-access telemetry.
references:
  - https://thehackernews.com/2026/11/binance-warns-of-ios-sandbox-escape.html
  - https://attack.mitre.org/techniques/T1533/
author: Security Arsenal
date: 2026/11/14
tags:
  - attack.collection
  - attack.credential_access
  - attack.t1533
logsource:
  product: ios
  service: mtd
detection:
  selection_path:
    target_path|contains:
      - 'Containers/Data/Application/'
  selection_keyword:
    event_detail|contains:
      - 'wallet'
      - 'keystore'
      - 'seed'
      - 'binance'
      - 'coinbase'
  filter_owner:
    accessor_is_owner: true
  filter_system:
    accessor_process:
      - 'mediaserverd'
      - 'backupd'
      - 'mobileactivationd'
  condition: all of selection_* and not 1 of filter_*
falsepositives:
  - iCloud backup and device migration operations; scope detection to business hours and unmanaged processes to reduce volume
level: high

KQL — Microsoft Sentinel Hunt

Assumes iOS syslog/MTD telemetry ingested via a data connector into Syslog or CommonSecurityLog, plus DeviceInfo from Defender for Endpoint on iOS for posture correlation. This query hunts sandbox denial records involving cross-container reads and joins against devices running the affected OS versions.

let AffectedOS = dynamic(["iOS 26", "iOS 27", "iPadOS 26", "iPadOS 27"]);
let SandboxViolations =
    Syslog
    | where ProcessName =~ "sandboxd"
    | where SyslogMessage has "deny(1) file-read-data"
    | where SyslogMessage has "/private/var/mobile/Containers/Data/Application/"
    | project TimeGenerated, Computer, HostIP, SyslogMessage
    | extend TargetPath = extract(@"(/private/var/mobile/Containers/Data/Application/[A-Fa-f0-9\-]+/[^\s\"]+)", 1, SyslogMessage)
    | extend OffendingApp = extract(@"deny\(1\) file-read-data.*?(\S+)\)", 0, SyslogMessage);
SandboxViolations
| join kind=leftouter (
    DeviceInfo
    | summarize arg_max(Timestamp, *) by DeviceName
    | where OSPlatform has_any (AffectedOS)
    | project DeviceName, OSPlatform, OSVersion, LoggedOnUsers
) on $left.Computer == $right.DeviceName
| summarize ViolationCount = count(), DistinctTargets = dcount(TargetPath), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by Computer, OSPlatform, OffendingApp
| where ViolationCount > 5 or DistinctTargets > 3
| sort by ViolationCount desc;

The threshold (>5 violations or >3 distinct target containers) is deliberate: a single deny record can be an app bug; systematic enumeration of multiple app containers is the exploitation signature. Tune upward, never downward, if you see noise from managed devices.

Endpoint Forensics Note

Velociraptor does not support iOS endpoints, and no credible VQL artifact exists for this threat — do not deploy one. For suspected-compromised devices, the correct forensic path is: capture an Apple sysdiagnose archive, acquire the device via a mobile forensics platform (Cellebrite, Magnet AXIOM, or open-source libimobiledevice tooling for supervised devices), and examine sandboxd denial logs, app installation receipts, and provisioning profile history.

MDM Posture Verification Script

With no patch available, your primary control is knowing exactly which devices are exposed and what is installed on them. This PowerShell script queries Microsoft Graph / Intune for iOS and iPadOS devices on affected versions and flags sideloading-risk posture. Adapt the API calls for Workspace ONE, Jamf, or Mosyle as needed.

# Audit Intune-managed iOS/iPadOS devices exposed to the sandbox escape (iOS 26/27, unpatched)
# Requires: Microsoft.Graph.DeviceManagement module, DeviceManagementManagedDevices.Read.All

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All","DeviceManagementApps.Read.All"

# Enumerate all managed iOS/iPadOS devices and flag affected OS builds
$devices = Get-MgDeviceManagementManagedDevice -All | Where-Object {
    $_.OperatingSystem -in @("iOS","iPadOS") -and
    ($_.OsVersion -match "^(26|27)\.")
}

$report = foreach ($d in $devices) {
    # Pull detected apps to identify sideloaded / non-store installs
    $apps = Get-MgDeviceManagementManagedDeviceDetectedApp -ManagedDeviceId $d.Id -All
    $sideloaded = $apps | Where-Object { $_.DisplayName -notmatch "^(com\.apple\.)" -and $_.Version -eq "" }

    [PSCustomObject]@{
        DeviceName        = $d.DeviceName
        User              = $d.UserPrincipalName
        OS                = "$($d.OperatingSystem) $($d.OsVersion)"
        ComplianceState   = $d.ComplianceState
        Jailbroken        = $d.JailBroken          # Intune reports "True"/"False" string
        LastSync          = $d.LastSyncDateTime
        TotalApps         = $apps.Count
        SuspiciousAppCnt  = ($sideloaded | Measure-Object).Count
        Risk              = if ($d.JailBroken -eq "True" -or ($sideloaded | Measure-Object).Count -gt 0) { "HIGH" } else { "EXPOSED-UNPATCHED" }
    }
}

$report | Sort-Object Risk, SuspiciousAppCnt -Descending |
    Export-Csv -Path ".\iOS_SandboxEscape_Exposure_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

$report | Where-Object Risk -eq "HIGH" | Format-Table -AutoSize
Write-Host "`nAffected devices: $($report.Count) | High-risk (jailbreak/sideload indicators): $(($report | Where-Object Risk -eq 'HIGH').Count)"

Remediation

There is no patch. Every control below is compensating — prioritize by asset criticality.

Immediate (0-24 hours):

1. Move crypto assets off iOS hot wallets on affected devices. This is Binance's implicit advice and it is correct. Rotate to hardware wallets (Ledger, Trezor, Coldcard) or a desktop wallet on a patched platform. Any seed phrase that has ever resided on an iOS 26/27 device that has run unvetted apps should be treated as potentially compromised — rotate the seed entirely by migrating funds to a newly generated wallet. Do not just re-encrypt; assume disclosure.
2. Freeze sideloading. Via MDM, block enterprise-certificate app installation, remove non-essential configuration profiles, and enforce App-Store-only install restrictions. In the EU, scrutinize alternative-marketplace installs explicitly.
3. Run the posture audit above. Identify every iOS 26/27 device, its compliance state, and its installed app inventory.

Short term (24-72 hours):

4. Deploy MTD if you haven't. Microsoft Defender for Endpoint on iOS, Lookout, or Zimperium provide on-device phishing and sideload detection plus the syslog telemetry the detections above depend on.
5. Enforce conditional access. Gate exchange and corporate app access behind device-compliance policies that fail closed on jailbreak detection or unapproved app sources.
6. Push app updates. Wallet vendors are already shipping mitigations (moving secrets into the Secure Enclave / Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly, removing on-disk seed caches). Force-update wallet, exchange, and authenticator apps fleet-wide.
7. Monitor Apple security releases daily. Subscribe to Apple's security-announce list and watch https://support.apple.com/en-us/100100 for the fix. When Apple ships the patch, treat deployment as emergency change — the public PoC guarantees exploitation attempts will follow.

Structural (this quarter):

8. Architect as if the sandbox will fail again, because it will: secrets in the Secure Enclave, not the file system; certificate pinning in financial apps; no seed phrases displayed or stored in plaintext at rest; transaction signing that requires a second factor off-device.
9. Add mobile to your tabletop scenarios. Your IR runbooks almost certainly underweight mobile-only compromise paths. This incident is the case study.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub