QuestStack gives original Meta Quest owners control
The project unlocks a Quest 1 bootloader on one specified firmware. It wipes data, can brick the headset, and does not yet provide an alternative OS.
QuestStack has released a way to unlock the original Meta Quest's bootloader on the final firmware specified by the project. It combines a temporary privilege-escalation chain called GhostLock with a 2021 Qualcomm bootloader flaw. The resulting unlock survives the session and allows the headset to attempt to boot software that Meta did not sign.¹
Compatibility is narrow. The README accepts only a Quest 1 running build 49845030443200410; Quest 2, Quest Pro, and every other headset are excluded. Unlocking wipes user data. An interrupted write to boot partitions can leave the device unable to start, and there is no supported recovery route if both boot slots are damaged.¹ ²
The repository does not supply a replacement operating system, open drivers for every component, or automatic independence from Meta's services.
The commercial cycle ended before the hardware did
The original Oculus Quest arrived in 2019 as a standalone VR headset. Facebook introduced Quest 2 as the next generation in September 2020, with shipments beginning October 13.⁶ The first model kept running compatible applications while new features and releases increasingly targeted its successors.
The support deadline came later. In an email to owners reproduced by specialist press, Meta said it would stop providing bug fixes and security updates for Quest 1 on August 31, 2024. Existing apps could remain available for as long as their developers supported them.⁷
A headset does not lose its displays, sensors, or processor on the day patches stop. It loses the team responsible for repairing vulnerabilities and keeping external dependencies current. When the manufacturer also controls boot signatures, owners have limited room to respond as the official software ages.
Temporary root and an open bootloader solve different problems
Root is elevated privilege inside the system currently running. It reaches areas that ordinary applications cannot, but the access may vanish after a reboot. In QuestStack, GhostLock provides that first foothold on the supported firmware.¹
The bootloader executes before Android and decides which images may start. A persistent unlocked state changes that decision on later reboots. The device can accept experiments with custom kernels or modified systems, bounded by the hardware and by software that someone still has to write.
QuestStack uses the first capability to obtain the second. Temporary root lets it place an old, vulnerable ABL, Qualcomm's Android Bootloader, in one boot slot. It then invokes CVE-2021-1931 to change the unlock authorization. The earlier research underpinning that stage identifies a Quest 1 ABL from May 2021 as vulnerable.¹ ³
The NVD describes CVE-2021-1931 as a possible buffer overflow caused by improper length validation while processing fastboot commands in Snapdragon products. Its published vector requires local access and high privilege.⁴ Qualcomm disclosed the flaw in its July 2021 security bulletin.⁵ It matters to the Quest because privileged access makes a temporary return to an older ABL possible within the project's chain.
The current firmware need not contain the CVE: privileged access can write an older boot stage that still contains the flaw to one slot.
Bootloader access opens space for systems that still need to be built
Temporary root can support research during one session. An unlocked bootloader remains available for later work. Developers can attempt their own images, replace system components, and study interfaces that signature verification previously kept out of reach.
QuestStack's repository contains no complete distribution that replaces Meta's software. It also lacks an independent, ready-to-use stack for tracking, controllers, audio, and displays. Removing the bootloader barrier is one project; porting and maintaining the rest is another.¹
Meta service dependencies do not disappear as a side effect of unlock. An alternative system would need its own setup, interface, application installation, and peripheral support. Store software remains subject to third-party licensing, servers, and compatibility. The owner gains a technical path toward another arrangement, without receiving that arrangement in the download.
The largest risk sits in the boot chain
The WebUSB implementation built from the earlier research uses the Quest's two boot slots and verifies the images it writes. It preserves the other slot as a safety net and backs up the partitions it changes.² Those measures reduce some failure modes, while power loss, disconnection, or an incomplete write can still make the affected slot unbootable.
Its README is direct: an interrupted write to xbl or abl can break a slot. A backup helps only while one side still starts and exposes a working system. If the boot chain on both slots is damaged, no shell remains to restore the images and there is no supported unbrick procedure. The unlock also triggers a user-data wipe on the next boot.²
That risk profile puts this outside the category of an ordinary software update. The project includes its own checks and confirmations, but it has no manufacturer's recovery infrastructure, warranty, or firmware distribution. Its supported scope remains one model and the declared firmware. The canonical README speculates about later models, then warns that the prospect of bricking them outweighs the benefit.¹
What Quest owners want from the opening
Owner discussion clusters around four uses. Preservation is the hope of returning working headsets to service. Setup without Meta servers reflects concern that an external dependency may eventually block reactivation. Alternative systems drives requests for community-maintained Android, Linux, and open VR runtimes.⁸
The fourth theme is performance, especially a hoped-for 90 Hz mode. That wish appears in the thread announcing the project, without evidence that QuestStack provides it.⁸ The same boundary applies to the other ambitions: bootloader access makes experimentation possible; it does not prove that drivers, cooling, the display, or a future system will support each proposal.
Sources
- QuestStack · GitHub · https://github.com/starseed12345/QuestStack · accessed Aug. 26, 2026
- Quest 1 Bootloader Unlocker (WebUSB) · GitHub · https://github.com/darknight1050/quest1-bootloader-unlocker-web · accessed Aug. 26, 2026
Show 6 more sourcesHide sources
- Quest Bootloader Unlocker · GitHub · https://github.com/darknight1050/quest-bootloader-unlocker · accessed Aug. 26, 2026
- CVE-2021-1931 Detail · National Vulnerability Database · https://nvd.nist.gov/vuln/detail/CVE-2021-1931 · updated June 16, 2026
- July 2021 Security Bulletin · Qualcomm Product Security · https://www.qualcomm.com/company/product-security/bulletins/july-2021-bulletin · July 2021
- Introducing Oculus Quest 2, the Next Generation of All-in-One VR · Meta · https://about.fb.com/news/2020/09/introducing-oculus-quest-2-the-next-generation-of-all-in-one-vr/ · Sept. 16, 2020
- Meta is Pulling the Plug on Quest 1 Security Patches Next Month · Road to VR · https://roadtovr.com/meta-is-pulling-the-plug-on-quest-1-security-patches-next-month/ · July 1, 2024
- The Quest 1 bootloader has now been unlocked on the latest firmware! · r/OculusQuest · https://www.reddit.com/r/OculusQuest/comments/1vsgznx/the_quest_1_bootloader_has_now_been_unlocked_on/ · Aug. 19, 2026
— Newsroom