worse_query is a proof-of-concept sandbox escape affecting iOS 26.0–26.7.2 and 27.2, letting an app reach App Group and application container paths, intended for developer and defensive research.
| Tool | forcequitOS/worse_query — a proof-of-concept sandbox escape for iOS 26.0–26.7.2 and 27.2 exposing container paths via an App Group container |
| Category | iOS sandbox escape proof-of-concept, written in Objective-C |
| Primary Use | Understanding how a mis-scoped App Group container on iOS can be leveraged to reach paths under /var/mobile/Containers/ during authorized research |
| Safe Use | Educational, documentary analysis for developers and authorized security researchers validating iOS sandbox boundaries in their own test environments; the README itself states the PoC is for developers and isn't useful by itself |
| Telemetry Note | On managed or instrumented test devices, access attempts against App Group and system container paths are visible to MDM monitoring, sandbox violation logging, and filesystem audit tooling, giving defenders a direct signal if the pattern is ever weaponized |
worse_query is a compact proof-of-concept from forcequitOS that demonstrates a sandbox escape on iOS versions 26.0 through 26.7.2, plus 27.2. Written in Objective-C and released under GPL-3.0, the project sits squarely in the tradition of platform-boundary research: it does not deliver remote code execution or persistence, but it breaks one of the core assumptions of the iOS security model, namely that an application's sandbox confines it strictly to its own container and explicitly shared extensions. The repository has accumulated 511 stars, which is a strong signal of community interest for a niche platform-research project of this size.
The README is candid about scope, stating plainly that the code is a proof-of-concept for developers and isn't useful by itself. That framing matters for how the tool should be read: it is a boundary-testing artifact, closer to a regression test for the operating system than to an attack chain component. The author explicitly positions it as the direct successor to bad_query, an earlier PoC from the same forcequitOS organization, and says worse_query essentially replaces it. The lineage suggests the underlying weakness was believed patched or narrowed after bad_query, and that the new project demonstrates the class of issue persists into the 26.x and 27.x release trains.
Mechanically, the setup requirement described in the README is minimal but telling: to use worse_query, you have to set up an App Group container for your app. App Group containers are the legitimate iOS mechanism that lets multiple apps from the same developer team, or an app and its extensions, share data through a common directory under /var/mobile/Containers/Shared/AppGroup/. The PoC apparently leverages the entitlement or path semantics around that shared container to step outside the boundaries the sandbox profile should enforce. In other words, the interesting engineering is in how a container that is supposed to be an exception to isolation becomes a bridge into paths the app was never granted.
The README enumerates exactly which filesystem locations worse_query can access, and the list is worth reading carefully because it spans both user and system territory. On the user side, it covers /var/mobile/Containers/Data/Application/*, /var/mobile/Containers/Data/InternalDaemon/*, and /var/mobile/Containers/Data/PluginKitPlugin/*, which correspond to third-party app data, internal daemon data, and extension plug-in data respectively. It also reaches /var/mobile/Containers/Shared/AppGroup/*, and on iOS 27, an additional /var/mobile/Containers/Shared/AppGroup path. On the system side, iOS 27 targets include /var/containers/Data/System and /var/containers/Shared/SystemGroup/*. The difference in path prefixes between the two versions hints at filesystem layout changes in the 27.x release train, which the author has evidently accounted for in the PoC's path logic.
The ability to enumerate and read sibling application containers is the most consequential aspect from a defensive standpoint. Each directory under /var/mobile/Containers/Data/Application/ belongs to a different app and can hold preferences, caches, databases, tokens, and other data that developers assumed was protected by per-app sandbox boundaries. A container-traversal primitive of this kind therefore functions as a data-exposure class of issue: even without code execution elsewhere, crossing into a neighbor's container can leak sensitive state. The PluginKitPlugin and InternalDaemon paths extend that exposure to extension-hosted and system-service data, broadening the blast radius beyond ordinary third-party apps.
The author includes a footnote that deserves emphasis because it preemptively counters a common misreading: the repository states this is not relevant to a jailbreak and never will be, and asks readers not to mislead people into believing otherwise. This is an important boundary in the iOS research community, where any sandbox escape tends to get hyped as a jailbreak component. worse_query does not disable code signing, does not provide kernel privileges, and does not survive the constraints that make jailbreaking hard. It is a single-layer escape from an app sandbox into container paths, which is a genuine security defect but a categorically different thing from a full jailbreak chain.
From an authorized-research workflow perspective, the value of worse_query is as a reproducible reference for a specific containment failure. A developer building apps that rely on App Group sharing can study how the shared-container mechanism interacts with sandbox profiles, and a platform-security researcher can use the PoC to validate whether a particular build still exhibits the traversal. The explicit setup step, creating an App Group container, means the demonstration runs entirely within the researcher's own developer environment and test devices, which is exactly the authorized context this kind of artifact is meant for. It is not a tool you point at someone else's device; it is a tool you compile into your own app to test the platform's response.
For defenders and mobile security engineers, the telemetry angle is worth thinking through. Accesses to container paths outside a process's own sandbox are the kind of behavior that sandbox violation reporting, MDM-managed device monitoring, and forensic tools can surface, so if the pattern were ever folded into malicious apps, the file-access signature against /var/mobile/Containers/Data/Application/ siblings would be the observable. Apple's response cadence to container-traversal issues of this class typically arrives in a minor release, so teams running managed iOS fleets should track whether their minimum-OS policies cover patched builds beyond the affected versions listed here.
The choice of Objective-C fits the project's nature: this is native platform code exercising filesystem and entitlement behavior close to the frameworks, not a scripted convenience tool, and there is no package-manager install story to speak of beyond cloning the repository for study. The default branch is main, and the repository carries no topic tags, consistent with a focused single-purpose research artifact rather than a productized toolkit. Readers should treat the GPL-3.0 license as relevant if they incorporate any of the code into their own test harnesses.
In summary, worse_query is best understood as documentation-by-code of a persistent weakness class in how App Group containers interact with iOS sandbox enforcement across the 26.x and 27.2 releases. Its honest README, explicit non-jailbreak disclaimer, and enumerated target paths make it a useful case study for developers reasoning about container boundaries and for defenders building detection around unauthorized cross-container file access. As with all sandbox-escape PoCs, the appropriate posture is study and patch-tracking in authorized environments, not field use against devices you do not own.
forcequitOS/worse_query.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.