worse_query: iOS Sandbox Escape Exposes App Data

TL;DR

• A public proof of concept called worse_query escapes the iOS app sandbox and reaches other apps' data containers. An app that sets up an App Group container can ask the container manager for a sandbox extension to an arbitrary path.
• The proof of concept lists iOS 26.0 through 26.7.2 and iOS 27.2 as working. Apple released iOS 27.2.1 and iOS 26.7.3 on November 9, 2026, and neither security note mentions a sandbox fix.
• No CVE is assigned, and Apple has published no advisory or fixed version. Binance warned on November 10, 2026 that wallet secrets could be exposed; no attacks or thefts are reported. With no CVE, the flaw is not in CISA's Known Exploited Vulnerabilities (KEV) catalog as of November 10, 2026.
• Remove apps installed outside the App Store, restrict app installation on managed devices, and treat any iPhone that ran an untrusted sideloaded app as exposed. See "How do I fix it?".

Am I affected?

All of these must hold:

• You use an iPhone or iPad running a version the escape reaches. The proof of concept lists iOS 26.0 through 26.7.2 and iOS 27.2. Derivative tools claim iOS 27.2.1 as well.
• The device has an app installed outside the App Store, or an app the attacker controls, with an App Group container. The public proof of concept needs an App Group, and sideloading tools create one automatically.
• The app runs on the device. The demonstrated escape is local to the phone; it is not a remote network attack.

The public proof of concept reaches every app's data container and some system folders on iOS 27. Its README lists the paths it can open:

/var/containers/Data/System (iOS 27)
/var/containers/Shared/SystemGroup/* (iOS 27)
/var/mobile/Containers/Data/Application/*
/var/mobile/Containers/Data/InternalDaemon/*
/var/mobile/Containers/Data/PluginKitPlugin/*
/var/mobile/Containers/Shared/AppGroup/*

Check the installed version on the device under Settings, General, then About. The version is on the first screen.

For a managed fleet, list the devices and their OS versions from the mobile device management console. Then list the apps installed outside the managed catalog. An iPhone that only runs App Store apps is a different exposure case from one that runs sideloaded builds.

How do I fix it?

There is no fix. Apple has not published an advisory, a CVE or a patched iOS version for worse_query, and the November 9 updates do not list it. These steps reduce exposure until Apple ships a fix:

1. Remove apps installed outside the App Store, including builds installed with AltStore, SideStore or a signing service. Delete the app and its configuration profile.
2. On managed devices, block installation from outside the managed app catalog. On unmanaged devices, use Screen Time to prevent app installation where that is practical.
3. Update iOS to the latest release. It does not close this escape, but it closes the flaws Apple did fix on November 9.
4. For a wallet or account that stored secrets on the device, move the funds or the account to a new wallet on a clean device. Reset the active sessions, as Binance advised.
5. Review installed configuration profiles under Settings, General, VPN and Device Management, and remove any profile you cannot account for.

Deleting a sideloaded app removes the copy of the escape on that device. It does not undo access that already happened. If an untrusted app ran on the phone, treat the data in other apps' containers as potentially read.

What is the root cause?

The escape abuses the container manager's sandbox-extension API. An app can ask the container manager for access to a part of its App Group container. The manager follows a symlink the app controls and issues an extension for the link's target.

iOS isolates apps in sandboxes. A container holds an app's data, and an App Group lets several apps share one container. When an app needs access to a path, the container manager can issue a sandbox extension: a token the app consumes to extend its sandbox to that path.

The proof of concept calls the container manager's private query interface. It asks for class 7, the App Group class, and part 3, the group's Library/Caches directory:

query_set_class(query, 7); // appGroup
query_set_group_identifiers(query, identifier);
query_set_part(query, 3); // Library/Caches
...
void *result = query_get_single_result(query);
char *token = copy_sandbox_token(result);
int64_t handle = consume_extension(token);

Before the query, the app deletes its group's Library/Caches directory and recreates it as a symbolic link to the target path:

[files removeItemAtPath: caches error: nil];
[files createSymbolicLinkAtPath: caches withDestinationPath: target error: nil];

The query resolves the requested part through the filesystem. The container manager follows the symlink, decides that the resolved target is the path to authorize, and returns a sandbox extension for it. It does not check that the resolved path is still inside the App Group container. The app consumes the token and can then open the target path.

The proof of concept also includes pathleak, a helper that brute-forces inode numbers with fsgetpath() to recover the UUID-based paths of other containers. That turns a known target path into a list of every app container on the device.

How is it exploited?

A malicious or sideloaded app runs the escape locally, obtains a sandbox extension to a target directory, and then reads or modifies files that belong to other apps.

1. The victim installs an app outside the App Store, or installs an app the attacker controls. Sideloading tools create the App Group container the escape needs.
2. The app deletes its App Group's Library/Caches directory and replaces it with a symbolic link to a target path.
3. The app calls the container manager's query API for the App Group's Library/Caches part. The manager follows the link and issues a sandbox extension for the target.
4. The app consumes the extension with sandbox_extension_consume().
5. The app repeats the query for other paths. pathleak enumerates other apps' container directories by inode, and the app requests an extension for each one.
6. The app reads files such as app databases, documents, cookies and configuration. A file-manager build named WQ Files can also edit, delete and clear that data, according to its developer.

The escape does not need a jailbreak and does not use a kernel exploit. It is a logic flaw in how the container manager authorizes a path. The public proof of concept is written for developers; other developers have built installable apps on it.

Neither Binance nor the researcher reported attacks or thefts. Binance's warning names the classes of data at risk, not a compromised wallet or a victim count. The exchange did not name a wallet app as exposed, and neither did the researcher.

How does the attack flow?

A sideloaded app replaces its App Group cache directory with a symlink. The container manager issues a sandbox extension for the link's target, and the app uses it to read or change other apps' data.

What can an attacker do?

An attacker who gets a malicious app onto the phone can read and change files in other apps' containers, and some system folders on iOS 27. That can expose session cookies, documents, databases and any secret an app stores in its container.

The conditions are part of the impact:

• The attacker needs the victim to install an app outside the App Store, or to install a malicious app that has an App Group container. The public proof of concept does not show a remote install.
• The app must run on the device. The escape is local code execution inside the app sandbox, not a network service.
• The reach is the data other apps keep in their containers. Binance warns that seed phrases, private keys and login credentials can be exposed; the exchange did not identify a wallet app that stores them in a reachable path.
• The public proof of concept reads and enumerates. A derivative file manager also edits, deletes and clears data, according to its developer.
• No attacks or thefts are reported, and no App Store app is confirmed to use the escape.

The impact is bounded by iOS app data protection. Some files are encrypted with a key tied to the device passcode and are unreadable while the device is locked. The public write-ups do not measure which files remain readable in each lock state, so do not assume a locked phone protects every container.

Why does the fix work?

No fix exists, so nothing closes the escape yet. The missing check is the one a fix has to add. After resolving the requested path, the container manager must verify that the result is still inside the App Group container before it issues a sandbox extension.

The current code path authorizes the resolved target. The failing step is the validation of that target against the container root. A correct implementation would resolve the symlink, compare the canonical path with the container's canonical root, and refuse the request when the target is outside it. It would also need to handle a path that changes between the check and the use, which is the race the symlink creates.

Apple has not published a patch, so this section cannot quote one. The proof-of-concept repository and the security notes are the public record.

How do I check if I was compromised?

No indicators of compromise are published. Check what is installed on the device and whether an untrusted app had the chance to run.

• List the apps installed outside the App Store. Look for WQ Files, AltStore, SideStore and signing-service apps, and for apps you do not recognize.
• Review configuration profiles under Settings, General, VPN and Device Management. Remove profiles you cannot account for.
• On a managed fleet, compare the installed-app inventory with the managed catalog and flag every app that is not on it.
• If an untrusted app ran on the phone, assume the data in other apps' containers could be read. Change the passwords and session tokens for accounts used on the phone, and move wallet funds to a new wallet on a clean device.
• Preserve the device and its logs before wiping it if you need to investigate. iOS keeps limited app-file access logs, so the absence of a log entry does not prove the escape was not used.

Timeline

• 2026-11-08: The researcher forcequit publishes the worse_query proof of concept on GitHub.
• 2026-11-09: Apple releases iOS 27.2.1 and iOS 26.7.3. Neither security note mentions a sandbox escape or worse_query.
• 2026-11-10: Binance warns users that the escape could expose wallet secrets, and The Hacker News reports the warning.

FAQ

Is there a CVE for worse_query?

No. No CVE is assigned as of November 10, 2026, and Apple has not published an advisory. The proof-of-concept repository, the derivative tools and the exchange warning are the public record.

Does it need a jailbreak?

No. The escape uses the container manager's private query interface and a symlink. It does not use a kernel exploit, and the researcher says it is not relevant to a jailbreak.

Can an App Store app use it?

Not confirmed. The proof of concept needs an App Group container, which App Store apps can have with the right entitlement. No one involved has said whether an App Store app can reach the vulnerable path, and no App Store app is named. Treat the question as open.

Which iOS versions are affected?

The proof-of-concept README lists iOS 26.0 through 26.7.2 and iOS 27.2. A derivative tool lists iOS 27.2.1, and none of the public sources lists iOS 26.7.3. Apple has not confirmed a range.

Is it exploited in the wild?

No attacks or thefts are reported as of November 10, 2026. Binance warned about the risk and told users to remove untrusted apps and move funds if they suspect a compromise. A warning is not a report of a victim.

Does updating to iOS 27.2.1 or 26.7.3 fix it?

No. Apple released both on November 9, 2026, and their security notes list other fixes, not a sandbox escape. Check Apple's notes for a later release before assuming an update closes it.

References

• forcequitOS/worse_query repository, "A sandbox escape for iOS 26 and 27, again", created November 8, 2026, with the README version range, the accessible paths and the proof-of-concept source: https://github.com/forcequitOS/worse_query (checked November 10, 2026)
• The proof-of-concept implementation, worse_query/worse_query.m, the App Group query, the symlink and the sandbox-extension consume: https://github.com/forcequitOS/worse_query/blob/main/worse_query/worse_query.m (checked November 10, 2026)
• The path enumeration helper, worse_query/pathleak.m: https://github.com/forcequitOS/worse_query/blob/main/worse_query/pathleak.m (checked November 10, 2026)
• Apple, "About the security content of iOS 27.2.1 and iPadOS 27.2.1", released November 9, 2026, with no sandbox or worse_query entry: https://support.apple.com/en-us/149715 (checked November 10, 2026)
• Apple, "About the security content of iOS 26.7.3 and iPadOS 26.7.3", released November 9, 2026, with no sandbox or worse_query entry: https://support.apple.com/en-us/149716 (checked November 10, 2026)
• The Hacker News, "Binance Warns of iOS Sandbox Escape That Could Expose Crypto Wallet Keys, No Fix Confirmed", November 10, 2026, with Binance's guidance and the researcher's statement: https://thehackernews.com/2026/11/binance-warns-of-ios-sandbox-escape.html (checked November 10, 2026)