A researcher has published a working iOS sandbox escape called worse_query, saying Apple was stalling on responding, and has given up any claim to a bounty by doing so. Apple’s latest iPhone updates make no mention of it, and Binance is now warning that wallet secrets on affected devices are at risk.
What happened
On Sunday 8 November 2026, a researcher who posts as forcequitOS, working with a collaborator known as 0xjohnny, put proof-of-concept code for worse_query on GitHub. It is a sandbox escape for iOS 26 and iOS 27. In plain terms, an app using it can look inside the private storage of other apps on the same iPhone. The researcher describes worse_query as the successor to an earlier technique of his called bad_query.
The release was not meant to happen this way. In a reply on X, quoted by The Cryptonomist, forcequitOS said “Apple was stalling on responding to me” and that people had begun showing off with the technique in public. Security Affairs notes that by publishing, he is giving up any bounty he might have been paid. In my experience, bounty programmes generally expect a finding to stay private until a fix ships, so releasing it early usually means losing any reward.
On 9 November Apple shipped iOS 27.2.1 and iOS 26.7.3. The iOS 27.2.1 security notes list nine CVEs, covering Messages, Bluetooth, AirPlay, brotli and several system services. None of them describes a sandbox escape, and worse_query is not named. Apple’s own advisory is dated 9 November, the day after the code went public.
On 10 November Binance told users the flaw could expose seed phrases, private keys and login credentials. It called it “an iOS-level issue, not unique to Binance”, according to Security Affairs. No source has reported any theft or attack.
The technical picture
Every app on an iPhone runs in a sandbox, which is its own storage container that other apps cannot read. A great deal of mobile security, from banking apps to corporate data containers, rests on that wall. worse_query breaks it. Reporting by The Hacker News and Bitcoin Magazine says the code can reach other apps’ data containers and, on iOS 27, some system folders too.
The limits matter. This is not a jailbreak and not a remote attack. The researcher says the code is aimed at developers and “isn’t useful by itself”. It has to be built into an app, and that app has to be installed. Outside the App Store, that means sideloading. Developer Christoph Kolbicz has already released a file manager called WQ Files that uses the technique. It goes on via AltStore, SideStore and similar sideloading tools, and reports say it can view, change and delete other apps’ data without a jailbreak.
The exact range of affected versions is unclear. Binance named iOS 26.7.1, 27.0.1 and 27.2, which are the builds WQ Files lists as tested. The researcher’s project notes claim wider coverage across iOS 26. Wallet security firm SlowMist made a point that applies to any app: the real exposure depends on whether an app keeps secrets such as recovery phrases or keystores in plain text on the device.
Why it matters for UK organisations
iPhones are widely used as corporate handsets across UK business and the public sector. Many mobile device management setups treat the iOS sandbox as one of their main controls. If a single sideloaded app can read another app’s container, then cached email, authentication tokens, files from collaboration apps and stored credentials are all exposed. With no confirmed fix, every iOS 26 and 27 device should be treated as potentially affected until Apple says otherwise.
Firms regulated by the FCA that offer mobile wallets or trading apps have a more specific question to ask. Does our app keep anything sensitive in plain files on the device, on the assumption that the sandbox will protect it? This disclosure is a good reason to check.
The disclosure side also matters here. In the UK, unauthorised security research can still fall foul of the Computer Misuse Act 1990. When a vendor goes quiet, researchers have few safe options, and early public release is what tends to follow.
Expert view
I do not endorse dropping working code before a fix exists. A public proof of concept turns a research finding into something anyone can use. The quick appearance of WQ Files shows how fast that happens. Even so, I understand the frustration. Coordinated disclosure only works if both sides communicate. A researcher who submits a serious finding and then hears nothing has very little leverage. Walking away from the bounty is the one move left, and here it was made in public.
In my experience, the real failure in these cases is rarely the bug. It is the communication. Vendors with large bounty programmes are swamped with reports, many of them now generated by AI. Triage teams are stretched. A credible researcher with a working sandbox escape should still get a human reply within days, not weeks. None of the sources reports any Apple comment on worse_query, and Apple’s stated policy is not to discuss security issues until it has investigated them and a fix is available. That policy protects users when it works. When the researcher thinks he is being ignored, it can backfire.
For organisations that run their own vulnerability disclosure programmes, the lesson is simple. Silence is a decision, and researchers will treat it as one. Acknowledge reports promptly, give realistic timelines and keep people updated, even when the update is only that the investigation is still going on.
What to do now
- Block sideloading on managed iPhones. Use your MDM to stop unmanaged app installation and alternative app marketplaces. This maps to the Cyber Essentials secure configuration control.
- Audit for sideloading tools. Look for AltStore, SideStore and enterprise-signed or developer-signed profiles on corporate devices, and remove anything without a business reason.
- Update to iOS 27.2.1 or 26.7.3. There is no evidence these builds block worse_query, but they fix other security flaws, including nine CVEs in iOS 27.2.1. Keep watching for a further release (Cyber Essentials: security update management).
- Review how your own apps store secrets. If you develop iOS apps, use the Keychain and Secure Enclave for credentials and keys, and not plain files in the app container.
- Rotate secrets where the risk is high. Where a device may have run untrusted apps, revoke sessions and rotate tokens. Move crypto holdings to a wallet created on a clean device, as Binance advises.
- Check your own disclosure process. Make sure your VDP commits to acknowledging reports within a set time, and check that it is being met.
Bottom line
worse_query is a contained risk for now, because exploiting it needs a sideloaded app, and locked-down corporate fleets can shut that route quickly. The bigger story is a breakdown in coordinated disclosure: a researcher gave up a bounty rather than keep waiting, and Apple has not said whether it has fixed the problem. UK organisations should close off sideloading, review how their apps store secrets and watch for Apple’s next release.
Sources
- Security Affairs: iOS Sandbox Escape Is Public, and Apple Hasn’t Confirmed a Fix
- The Hacker News: Binance Warns of iOS Sandbox Escape That Could Expose Crypto Wallet Keys, No Fix Confirmed
- Bitcoin Magazine: Binance Warns iOS Flaw Could Expose Wallet Seed Phrases
- The Cryptonomist: Binance warns an iOS sandbox escape vulnerability puts wallet secrets at risk
- Apple: About the security content of iOS 27.2.1 and iPadOS 27.2.1
