A public proof of concept called worse_query lets an iPhone app read other apps' private files. Apple's November 9 updates do not list a fix, despite claims spreading online that they do. Here is what the flaw actually reaches, what it cannot touch, and who should act now.
Updated November 12, 2026, 12:05 a.m. New York time (EST).
If you updated your iPhone to iOS 27.2.1 this week and assumed that closed the "worse_query" hole crypto exchanges have been warning about, you should not. Apple's security notes for iOS 27.2.1 and iOS 26.7.3, both released on November 9, list nine and eight fixes respectively, and none of them is a sandbox escape. The researcher who published worse_query said on November 10 that it is "*not* patched in iOS 27.2.1 and 27.3 beta 1," a post seen more than 56,000 times on X.
That matters because worse_query attacks the most basic promise of iPhone security: that one app cannot read another app's data. The practical risk to most people is narrower than the alarm suggests, but it is real, it is unfixed, and the code is already being packaged into installable apps.
What worse_query is
Every iOS app lives in a sandbox, a set of kernel rules that confine it to its own folder, called a container. When an app legitimately needs to reach somewhere else, a system service can hand it a sandbox extension: a token that widens its access to one specific path.
worse_query, published on GitHub on November 8 by a developer who posts as forcequit, with a second researcher credited as 0xjohnny, abuses that hand-off. According to the project's README and source code, an app with an App Group (a shared container Apple lets apps from one developer use) deletes its own group's Library/Caches folder and replaces it with a symbolic link pointing wherever it likes. It then asks containermanagerd, the system service that manages containers, for an extension to its own Caches folder. The service follows the link and issues a token for the target instead. The app consumes the token, and the sandbox lets it in.
The researcher describes it as a logic bug rather than memory corruption. In plain terms, nothing crashes and nothing is overwritten; a trusted system service is simply tricked into granting access it should refuse.
The README lists it as working on iOS 26.0 through 26.7.2 and on iOS 27.2. The paths it can open include the data containers of every installed app, app extensions, internal system daemons and shared App Group folders, plus some system containers on iOS 27. The README is emphatic on one point: "This is not relevant to a jailbreak and never will be." It reads and modifies files; it does not take over the phone.
Why "just update" is the wrong advice this week
Much of the confusion comes from timing. The code went public on November 8 and Apple shipped updates the next day, so many readers, and at least one wallet maker according to CyberSIXT's reporting, concluded the updates were the fix. Apple's own iOS 27.2.1 security notes do not support that. The entries cover AirPlay, Bluetooth and CoreUtils pairing, brotli, rapportd, two iMessage group-chat flaws and one App Intents issue described as "An app may be able to access sensitive user data." That last entry (CVE-2026-113963) is credited to a different researcher, László Várady. Apple files it under App Intents and describes it as an authorization issue; nothing in the entry refers to containers or sandbox extensions.
Apple has published no advisory, CVE or statement about worse_query. The researcher says they reported it to Apple on October 20, that Apple did not review the report until November 9, and that they published only after someone else demonstrated the technique publicly. Apple has not commented on that account, so it should be read as the researcher's version of events.
Updating is still worth doing. iOS 27.2.1 fixes a flaw that could let a remote attacker join an iMessage group chat and receive its messages, and several Bluetooth pairing bugs. It just does not close this one.
There is a precedent for how long a fix might take. worse_query is the successor to bad_query, a similar escape by the same developer that covered iOS 26.0 to 26.6.1 and an iOS 27 beta. CyberSIXT reports that bad_query went public in early August and was patched in the iOS 26.7 release candidate roughly a month later. That is a pattern, not a promise.
What it can reach, and what the Keychain still protects
The most useful distinction for ordinary users is one most coverage has skipped. iOS keeps app data in two very different places.
App containers are ordinary folders: databases, caches, downloaded files, saved web sessions, chat histories and settings files. These are exactly what worse_query opens. If an app stores something sensitive there in readable form, a malicious app using this technique can read it, and the PoC can modify files too.
The Keychain is separate. Apple's Platform Security guide says it is a single encrypted database managed by the securityd daemon, which decides which items each app may read based on its code-signed entitlements. Each secret is encrypted with a per-row key that "always requires a round trip through the Secure Enclave," the phone's separate security chip. The Keychain is not among the paths worse_query's README lists, and even raw access to its database file would yield encrypted secrets rather than readable passwords.
That is why the realistic damage depends on how each app was built. An app that keeps login tokens and private keys in the Keychain, the mechanism Apple provides for exactly that purpose, keeps them out of this bug's direct reach. An app that writes a seed phrase, an API token or a session cookie into a plain file or a web view cache does not. Blockchain security firm SlowMist made the same point in its alert, according to CyberSIXT, telling wallet developers to stop storing sensitive data in plaintext. Some wallet makers have publicly said their storage is encrypted; VibeCodAI has not tested any app's storage, and readers should treat vendor assurances as claims.
Note also that iOS file encryption is designed to protect a locked phone in a thief's hands. It is not designed to stop software already running on an unlocked phone that the system has wrongly granted access.
Who is actually at risk
worse_query is local. Someone has to get code using it running on your phone, inside an app that has an App Group. The researcher's README calls it a proof of concept that "isn't useful by itself." That leaves three realistic paths.
1. Sideloaded apps
This is the clearest risk today. Tools such as AltStore and SideStore, and paid signing services, install apps outside the App Store, and they create the required App Group automatically, according to security firm Ostorlab and developer Christoph Kolbicz, quoted by BankInfoSecurity. Within two days of release, developers had shipped worse_query-based file managers and the tweak tool Erosion 0.3. Those are tools people install deliberately. The danger is a lookalike, or a cracked game or "free premium" app, doing the same thing quietly.
2. A malicious App Store app
The researcher has warned that worse_query "would absolutely be exploitable from an App Store app. An attacker using it would just have to pass App Review." Apple's review rules allow only public APIs, and the PoC calls private, undocumented system functions, so a malicious app would have to slip past that check. The researcher pointed to FomoPeek, an app they say shipped several known exploits through the App Store, as evidence that review can miss such code. In a later reply, the same researcher noted that "an update to a previously fine App Store app" could also be dangerous, while adding that it is "realistically not worth worrying about."
3. Chained attacks
The researcher also noted that an attacker who already had a separate bug giving code execution inside a third-party app with an App Group could use worse_query to reach everything else. That is the scenario that would matter to targeted surveillance, and it is the strongest argument for Apple to fix this quickly rather than treat it as a sideloading problem.
No attacks or thefts using worse_query have been reported; none of the warnings from Binance, SlowMist or the researcher describes one. No CVE has been assigned, so it does not appear in the US Cybersecurity and Infrastructure Security Agency's catalog of known exploited vulnerabilities.
What to do now
- Delete apps you did not get from the App Store unless you trust their source completely. Removing an app stops future access; it does not undo anything it already read.
- Update to iOS 27.2.1 or 26.7.3 anyway. They fix other real flaws, including the iMessage group-chat bug.
- Check Settings, General, VPN and Device Management and remove profiles you cannot account for.
- If you keep a software crypto wallet on a phone that has run an untrusted app, follow the exchanges' advice: create a new wallet on a clean device, move funds, and sign out of active sessions. Large holdings are safer in a hardware wallet regardless.
- Do not rely on version lists in exchange warnings. Binance named iOS 26.7.1, 27.0.1 and 27.2. The researcher's range is wider: every iOS 26 release from 26.0 to 26.7.2, plus 27.2.
What to watch
The signal that matters is an Apple security note that names a sandbox or containermanagerd fix, ideally crediting forcequit and 0xjohnny, and an update to the worse_query README narrowing its supported versions. The researcher has said they will update it when Apple patches the bug. Until then, the honest summary is this: nothing published so far shows worse_query reaching the Keychain, but the iPhone's app-to-app wall has a known hole, and the only thing guarding that hole this week is what you choose to install.