grapheneos
grapheneos on Hacker News
The issue is assigned CVE-2026-58882, has Critical severity and is part of the November 2026 security patch level. OEMs received the patch in July 2026 and have been allowed to ship it since then. That's how the patch system now works for Android. GrapheneOS has access to the security preview patches so we got it patched for our users in July 2026.
Android's public issue tracker isn't the real issue tracker. They create internal issues for what's reported there. That means the discussion about it doesn't happen there. Security bug reports are mainly treated as a request for a bounty and little communication happens beyond what's related to receiving a bounty for it. If someone else filed it then it gets closed and no further info is provided. If someone external filed the first report, they hardly get any updates themselves beyond eventually being informed which Android Security Bulletin included it months after it was disclosed to OEMs and allowed to be patched.
Google committed a fix on June 15th and it was shipped in the security preview patches in mid-July. GrapheneOS shipped it in our security preview releases in July. It's in the upcoming November security bulletin but a patch was pushed to AOSP in October:
https://android.googlesource.com/platform/frameworks/opt/tel...
It's assigned CVE-2026-58882 and a Critical severity in the November 2026 Android Security Bulletin. We've had it listed as one of the patches included in our security preview releases since our 2026072901 release which you can see in the release notes:
https://grapheneos.org/releases#2026072900
Google mishandled the issue report. There was likely an internal miscommunication and they handled the report incorrectly. It's possible the issue was already filed internally and they meant to close it as a duplicate instead of WONTFIX. Closing it at all may have been an error.
Google committed a fix on June 15th and it was shipped in the security preview patches in mid-July. GrapheneOS shipped it in our security preview releases in July. It's in the upcoming November security bulletin but a patch was pushed to AOSP in October:
https://android.googlesource.com/platform/frameworks/opt/tel...
It's assigned CVE-2026-58882 and a Critical severity in the November 2026 Android Security Bulletin. We've had it listed as one of the patches included in our security preview releases since our 2026072901 release which you can see in the release notes:
https://grapheneos.org/releases#2026072900
Google mishandled the issue report. There was likely an internal miscommunication and they handled the report incorrectly. It's possible the issue was already filed internally and they meant to close it as a duplicate instead of WONTFIX. Closing it at all may have been an error.
Google committed a fix on June 15th and it was shipped in the security preview patches in mid-July. GrapheneOS shipped it in our security preview releases in July. It's in the upcoming November security bulletin but a patch was pushed to AOSP in October:
https://android.googlesource.com/platform/frameworks/opt/tel...
It's assigned CVE-2026-58882 and a Critical severity in the November 2026 Android Security Bulletin. We've had it listed as one of the patches included in our security preview releases since our 2026072901 release which you can see in the release notes:
https://grapheneos.org/releases#2026072900
Google mishandled the issue report. There was likely an internal miscommunication and they handled the report incorrectly. It's possible the issue was already filed internally and they meant to close it as a duplicate instead of WONTFIX. Closing it at all may have been an error.
Google committed a fix on June 15th and it was shipped in the security preview patches in mid-July. GrapheneOS shipped it in our security preview releases in July. It's in the upcoming November security bulletin but a patch was pushed to AOSP in October:
https://android.googlesource.com/platform/frameworks/opt/tel...
It's assigned CVE-2026-58882 and a Critical severity in the November 2026 Android Security Bulletin. We've had it listed as one of the patches included in our security preview releases since our 2026072901 release which you can see in the release notes:
https://grapheneos.org/releases#2026072900
Google mishandled the issue report. There was likely an internal miscommunication and they handled the report incorrectly. It's possible the issue was already filed internally and they meant to close it as a duplicate instead of WONTFIX. Closing it at all may have been an error.
Google committed a fix on June 15th and it was shipped in the security preview patches in mid-July. GrapheneOS shipped it in our security preview releases in July. It's in the upcoming November security bulletin but a patch was pushed to AOSP in October:
https://android.googlesource.com/platform/frameworks/opt/tel...
It's assigned CVE-2026-58882 and a Critical severity in the November 2026 Android Security Bulletin. We've had it listed as one of the patches included in our security preview releases since our 2026072901 release which you can see in the release notes:
https://grapheneos.org/releases#2026072900
Google mishandled the issue report. There was likely an internal miscommunication and they handled the report incorrectly. It's possible the issue was already filed internally and they meant to close it as a duplicate instead of WONTFIX. Closing it at all may have been an error.
It's ludicrous to claim software with signed releases isn't open source. Having private keys used to generate the signatures for APKs, updates and the vbmeta image doesn't somehow make it not open source. Every APK is signed and the software isn't somehow not open source because the signature requires the private keys. There are standard tools to compare APKs with different signing keys to ensure the build is reproducible and the same thing exists for the OS as a whole which contains many signed APKs and a signed vbmeta image with verified boot metadata.
The signatures enable the update client to verify the releases and the firmware to verify the OS with the public key flashed by the user as part of installing the OS. Signed updates and verified boot fully work with any build of GrapheneOS following our build instructions. Auditor and AttestationServer also work once they're rebuilt with the new verified boot hash included.
Software doesn't stop being open source because the releases are signed to be able to verify those. Any OS can be installed on the supported device. The verified boot key hash shown at boot will be different for an unofficial build and so will a query to the hardware asking it to provide it. Auditor and AttestationServer are open source. Those work fine with unofficial builds and forks of GrapheneOS after making builds of those with the correct key.
GrapheneOS is open source with reproducible builds. Android key attestation isn't specific to GrapheneOS and is OS independent. It mainly exists to check that a key was generated in a hardware keystore. There's no pass or fail based on having an official or unofficial build of GrapheneOS. The hardware can sign public key certificates with metadata on device security including verified boot state (green, yellow or orange), verified boot key hash, verified boot hash (hash of the core OS) and patch levels. That's not nefarious and is useful to end users. Our Auditor app uses it to help users protect their devices. GrapheneOS doesn't use it to require people to use an official build for any purpose. Some banks have regulations requiring them to verify the hardware, OS and app which means they need to specifically allow each non-Google-certified OS. There are only around 3 banking apps are known to permit GrapheneOS that way and without it they'd ban using any non-Google-certified OS.
LineageOS doesn't keep up with very important standard privacy/security patches and protections. This post is a clear example where it took until October 2026 to ship crucial privacy/security patches and protections from June 2026.
GrapheneOS greatly improves upon the increasingly inadequate privacy and security provided by Android. It fixes many privacy and security vulnerabilities along with adding important missing privacy and security protections.
Traditional cell phones lack any form of secure communication and are entirely dependent on cellular. Those lack basic updates and security protections in practice too. Those are the opposite of a more private and secure device. A smartphone with GrapheneOS or iOS is far more private and secure than any traditional desktop/laptop computer at a hardware, firmware and software level.
There's nothing illegal about using GrapheneOS.
There will be both the option to install GrapheneOS on a device sold without it and to buy a device with it preinstalled. Devices sold with it preinstalled are coming after the initial launch of support. Details cannot be provided yet.
Permissively licensed open source code is open source code. Firmware on a secure element can be open source without it being possible to replace it without the signing key on a production device.
German courts are not bound by precedent in the same way as US courts and you're referring to a specific case in Germany which cannot be broadly applied.
AOSP ships a lot of GPLv2 code (Linux kernel and OpenJDK libraries among other components) but doesn't use GPLv3 for multiple reasons.
AOSP used to use a lot of GPLv3 code as part of the toolchain for building AOSP but that was replaced with LLVM, ToyBox and other permissively licensed projects.
We try to convince them not to do it at all, but if they insist on doing it then we point them to our signed list of verified boot key fingerprints and Google's library for key attestation verification. We have a page with a guide on allowing GrapheneOS this way for apps using the Play Integrity API. We keep a list of a small subset of apps using the Play Integrity API to ban GrapheneOS there for users to pressure them to allow GrapheneOS too. We definitely don't encourage adopting it for apps not using the Play Integrity API already but rather it's a compromise to get support for the official releases of GrapheneOS and other operating systems with verified boot and the app sandbox intact for apps otherwise banning them.
Yes, we very actively engaged in discussion with the EU Commission. It hasn't resulted in any major actions against Google in this area yet. The people we've talked to seem to understand what we've told them but it's not more broadly understood. They focus on easier to understand and less technical things where Google can't fool them with misleading claims and misdirection as easily such as forcing them to allow alternatives to the Play Store and Google AI.
Play Integrity API is disguised as a security feature and is aligned with governments wanting to crack down on people freely using arbitrary software and hardware which makes it hard to convince governments to stop it.
Our point is that GrapheneOS will be an officially supported OS on Motorola devices and will be sold with it officially installed but will still be banned. It's likely it can have green verified boot state eventually but it will still be banned.
We're in contact with people at Revolut since after we posted about it and think it's going to keep working on GrapheneOS now. It remains to be seen.
https://x.com/search?q=from%3A%40grapheneos%20play%20integri...Many of our posts about it heavily criticize apps limiting which operating systems and hardware can be used in addition to the Play Integrity API itself. Our focus is mainly on the Play Integrity API because it's the only relevant system resulting in compatibility issues in practice. We don't have to worry about Apple's App Attest API and we aren't aware of any app banning GrapheneOS with the Android key attestation API.
We've convinced dozens of apps to drop using attestation with user pressure. We've also convinced a much smaller number of apps to at least permit GrapheneOS and other alternatives chosen by them with the Android key attestation API instead of only permitting Google-certified operating systems. We aren't aware of any app using the Android key attestation API in a way which reduces compatibility since apps generally only use the Play Integrity API and have to be convinced to either drop it or at least use an alternative where they can permit non-stock operating systems based on verified boot key hash and non-Google roots of trust.
Revolut currently works on GrapheneOS though.
We plan on having improved compatibility with banking and government apps rather than most banning using GrapheneOS. Those apps aren't banning it for any actual reason. We don't have to convince them to stop doing what they are but rather to add a bit of code to support alternatives meeting underspecified requirements.
Providing root access to a huge portion of the OS with a way for apps to obtain it goes against the privacy and security focus. It's never a reasonable way to implement the features provided by those kinds of apps. It's an insecure shortcut being taken to implement features poorly and insecurely without proper integration. Providing root access to end users is a much different thing than giving it to a huge portion of the OS with a way for apps to request it.
We wouldn't mind providing a 2nd set of releases with user root access but those would have separate signing keys for privacy and security reasons. It would not be accessible to large portions of the OS to apps. We don't do it because it would double the number of builds and would be a massive amount of additional work for managing and testing it. It would take immense resources to create a variant of the OS which we'd recommend against almost anyone using mainly to provide a novelty. We have much better uses for our resources. Resources are always limited and doubling the number of OS releases for a 2nd time would have a huge cost.
Certain MDM apps support using the Play Integrity API to ban using non-Google-certified devices. Some MDM apps simply don't know how to successfully create a functional work profile without Google Play being automatically installed in it which can be worked around and we can provide an easier way to deal with it. Work devices should really be separate devices provided by the company instead of them managing a work profile on your personal device though.
It's worth noting AOSP and GrapheneOS have both drastically changed since Android 13 on the Pixel 4. GrapheneOS is based on Android 17 since June 2026 and soon Android 17 QPR2 in December 2026.
It isn't clear what your response is referring to.
Their main concern is malware not capable of exploiting OS vulnerabilities. They focus on protecting against malicious clones or modifications of their apps along with enforcing having a mandatory app sandbox and not running non-approved accessibility services, non-approved keyboards, etc.
Most of the banks don't require not being months or years behind on bare minimum Android security patches let alone requiring anything close to proper security patches. That may rapidly change in the near future due to AI accelerated exploit development making exploits far more accessible and broadly deployed.
Nearly all these apps aren't banning GrapheneOS on purpose but rather because they're doing the least possible work to implement weak anti-tampering measures. Play Integrity device or strong integrity levels are an easy way to do it. They can use strong integrity if they're willing to forbid extraordinarily insecure devices failing to meet a very low bar for security. Most banks aren't willing to do that since it would mean blocking the majority of Android devices so they use device integrity which barely does anything more than enforcing licensing Google Mobile Services to reinforce Google's monopolies. Even the strong integrity level doesn't enforce much more than that, it's mostly just much harder to bypass at scale.
Basic integrity requires being logged into an account. You can create a throwaway account and you'll pass. You may need a VoIP number if you're using a VPN to meet the phone number requirement for IPs without a good reputation.
GrapheneOS will have official support on multiple devices from Motorola and will likely eventually have green verified boot state on the subset of their devices with support for it. This won't help with the Play Integrity API banning using it. Apps aren't banning non-stock operating systems but rather non-Google-certified operating systems.
Google certification isn't open to us due to requiring licensing Google Mobile Services and agreeing to an enormous amount of anti-competitive terms including banning many of the privacy and security features we provide. It would also be incompatible with providing updates without unacceptable delays.
EU regulations require banks to require confirmation in an app with device and app integrity verification. They don't specify what that means but they have to do it. SMS 2FA is temporarily allowed for the transition period.
Apps are not required to use the Play Integrity API or a similar attestation API. The details of what they're required to do are unspecified and open ended. Many are interpreting it as meaning they use the Play Integrity API and we have to convince each one to permit GrapheneOS via the Android attestation API. It's not good and we would greatly prefer if this wasn't happening even if we were managing to convince most apps to permit GrapheneOS.
Yes, they're required to move to apps with device and app integrity checks. SMS 2FA is temporarily permitted for the transition period.
The EU has regulations requiring banks to move to an app with device and app integrity checks. SMS 2FA is temporarily permitted for backwards compatibility but is explicitly considered a legacy approach that's being phased out due to being insecure.
It's being phased in due to regulations. They're allowed to offer insecure SMS 2FA to confirm transfers, etc. as an alternative but are supposed to move away from it.
The same functionality available through a web app on a laptop is available on a GrapheneOS phone through the same web app. Banks increasingly limit features such as sending transfers or depositing cheques to their iOS and Android apps. There are government regulations and industry standards being put in place which require using an app with device and app integrity checks to approve transfers. The EU has these kinds of regulations but temporarily allowed using insecure SMS 2FA for confirmation instead.