GrapheneOS security preview releases

GrapheneOS

Our security preview releases provide early access to Android Security Bulletin patches prior to the official disclosure. Our current security preview releases provide the current revision of the November 2025 and December 2025 patches for the Android Open Source Project. We recommend enabling this.

The only difference between our regular releases and security preview releases are the future Android Security Bulletin patches being applied with any conflicts resolved. The downside of security preview releases is we cannot provide the sources for the patches until the official disclosure date.

The delay for being able to publish the sources is why we're now going through the significant effort of building 2 variants of each release. Our most recent 3 releases have both a regular and security preview variant:

2025092500 and 2025092501
2025092700 and 2025092701
2025100300 and 2025100301

You can enable security preview releases via Settings > System > System update > Receive security preview releases.

Our plan is to keep it off-by-default with a new page added to the Setup Wizard which will have it toggled on as a recommendation. We'll prompt users on existing installs to choose.

We're maintaining the upcoming Android security patches in a private repository where we've resolved the conflicts. Each of our security preview releases is tagged in this private repository. Our plan is to publish what we used once the embargo ends, so it will still be open source, but delayed.

The new security update Android is using provides around 3 months of early access to OEMs with permission to make binary-only releases from the beginning. As far as we know, GrapheneOS is the first to take advantage of this and ship the patches early. Even the stock Pixel OS isn't doing this yet.

During the initial month, many patches are added or changed. By around the end of the month, the patches are finalized with nothing else being added or changed. Our 2025092500 release was made on the day the December 2025 patches were finalized, but we plan to ship the March 2026 patches earlier.

Previously, Android had monthly security patches with a 1 month embargo not permitting early releases. For GrapheneOS users enabling security preview releases, you'll get patches significantly earlier than before. We'd greatly prefer 3 day embargoes over 3 month embargoes but it's not our decision.

Android Security Bulletin (ASB) for October 2025 is empty:

https://source.android.com/docs/security/bulletin/2025-10-01

However, you can see Samsung has a list of ASB patches for their October 2025 release exclusive to flagships:

https://security.samsungmobile.com/securityUpdate.smsb

It's a small subset of the December 2025 patches.

Android now discloses patches around 3 months prior to their inclusion in a bulletin requiring them to raise the Android security patch level. However, OEMs are allowed to ship the patches as soon as they're receive. We're doing this in our security preview release, but with the full set of patches.

Our initial security preview release on September 25th with the November/December patches included 1 Critical severity patch and 54 High severity patches, which is the full subset applicable to Android 16. In the past couple days, 5 patches applicable to Android 16 were added and 1 was retracted.

December 2025 patches from the past couple days have been included and the January 2026 preview is now available.

Our next release coming today provides a choice to use our security preview releases in the initial setup wizard with a notification for existing users. Opting into it is recommended.

https://discuss.grapheneos.org/d/27068-grapheneos-security-preview-releases provides more information on our security preview releases. The reason we're providing both regular and security preview releases is because we're required to wait to the embargo end date to publish the source code for the patches in the future bulletins.

userofgos

GrapheneOS As far as we know, GrapheneOS is the first to take advantage of this and ship the patches early. Even the stock Pixel OS isn't doing this yet.

Incredible work! Appreciate your dedication to the security of our devices.

NetRunner88

GrapheneOS
A-W-E-S-O-M-E

ryrona

GrapheneOS Our plan is to publish what we used once the embargo ends, so it will still be open source, but delayed.

Does this mean it will be published in such a way that the release can be reproduced, like regular reproducible builds? Because being able to confirm the binary release corresponds to source code 3 months late is still way way better than not being able to confirm it at all.

GrapheneOS If people reverse engineer exactly what a patch does and publicly post about it, then that's public information not under an embargo. If people write a patch to fix it, that can be included.

I tried asking a few times in the alpha testing channel on Matrix, but I try here too:

Are we legally permitted to reverse engineer the OS images containing the embargoed patches? Ie are you legally allowed to allow reverse engineering of the OS images containing the embargoed patches, or the license terms for the embargoed patches that prohibit you from publishing them in source form also forces you to prohibit reverse engineering the binary releases of them?

Are you able to provide the exact terms you have been granted access to the embargoed patches under and are able to publish them in binary form under? So we can verify the legality if reverse engineering them, both for our own sake, and for GrapheneOS sake? Or are the terms also under NDA?

raccoondad

GrapheneOS your commitment to user choice and open source software is not overlooked, thank you GOS!

Vuraze

I was told that the embargo may end soon if someone was able to reverse engineer the security patches and release it with the source code, effectively showing Google how silly this whole thing is. Is that true, and has anyone done that yet?

userofgos

Vuraze This post from GrapheneOS on X maybe insightful: https://xcancel.com/GrapheneOS/status/1964754118653952027

Here's a snippet from that thread:

We can't break the embargo ourselves but if someone posted the patches publicly we would be able to ship them months early, as would others. The patches are broadly distributed to OEMs where most of their engineers have access. Companies like NSO can easily obtain access. It's not a safe system.

de0u

Vuraze I was told that the embargo may end soon if someone was able to reverse engineer the security patches and release it with the source code, effectively showing Google how silly this whole thing is. Is that true, and has anyone done that yet?

If that had already happened, then the post from the project account which began this thread would not have been necessary.

As for what Google might do if people are energetic enough about reverse engineering, that can be discovered only if somebody does.

GrapheneOS

Vuraze If people reverse engineer exactly what a patch does and publicly post about it, then that's public information not under an embargo. If people write a patch to fix it, that can be included.

We already fixed one issue in the regular releases because a patch was publicly available elsewhere. We plan to do more of that by checking the external projects.

Panda-na

Thank you for your hard work! I've enabled the Security Preview Release, having no issues.

One question though. With all of these longer embargoes, fewer people will be able to review the code. Can this be an easier way for Google to implement anti-privacy practices in Android? And also, is this maybe some sort of way to help law enforcement break into Android phones, since problably most Android phones out there (even new flagships) is not updated with the newest CVE's, but maybe Cellebrite can get a hold of the patches? Making their work substantially easier?

Are you checking the code of these CVE's to ensure that it is in our best interest? Maybe I'm completely wrong here, if so, I'm sorry, I'm just curious.

de0u

Panda-na One question though. With all of these longer embargoes, fewer people will be able to review the code.

Because code that to fix a vulnerability replaces a truly tiny fraction of the code base, the vast majorit of the code is continuously as reviewable as it ever was. Code that is temporarily non-generally-reviewable during each embargo period will be reviewable after the embargo is over. The net decrease in reviewability is tiny.

Panda-na Can this be an easier way for Google to implement anti-privacy practices in Android?

How?

Panda-na And also, is this maybe some sort of way to help law enforcement break into Android phones, since problably most Android phones out there (even new flagships) is not updated with the newest CVE's, but maybe Cellebrite can get a hold of the patches? Making their work substantially easier?

Cellebrite can already get into the vast majority of phones. It is genuinely quite likely that they are capable of analyzing binaries, especially since they seem to be pretty good at breaking into WhatsApp.

de0u

Panda-na Are you checking the code of these CVE's to ensure that it is in our best interest? Maybe I'm completely wrong here, if so, I'm sorry, I'm just curious.

I am having trouble following this line of questioning.

It is already the case that the GrapheneOS team ships firmware updates from Google for the cellular modem, Wi-Fi, Bluetooth, and the GPU. The firmware is in binary form. I don't expect the GrapheneOS team is frequently decompiling the firmware to determine what is being changed between releases.
Before the current "security preview" setup, the GrapheneOS team has been shipping truly gigantic amounts of AOSP code from Google, with truly sweeping changes in at least the quarterly updates. They have been taking some amount of care with this, but clearly not infinite care, because both Google and various external security researchers keep finding bugs that the GrapheneOS team hasn't found.

Given that imperfect situation, meaning a mixture of difficult-to-inspect binary blobs and impossible-to-fully-inspect source code, it's not clear why the new situation would present significant new concerns. Some of the "security preview" fixes will be in binary blobs, and some of them will be in source code. The ones that are in source code will be publicly disclosed at the end of each embargo period.

Honestly perhaps the biggest threat posed to GrapheneOS users by the new scheme is that the GrapheneOS team will be maintaining two versions of the OS at the same time, which plausibly will stretch the development team thinner.

Please note that I do not speak for the GrapheneOS project.

de0u

ryrona Are we legally permitted to reverse engineer the OS images containing the embargoed patches?

I think that may be a question for an attorney. For example, I believe I have heard that EU residents have reverse engineering rights that U.S. residents do not.

GrapheneOS

ryrona

Does this mean it will be published in such a way that the release can be reproduced, like regular reproducible builds? Because being able to confirm the binary release corresponds to source code 3 months late is still way way better than not being able to confirm it at all.

Yes, it will be possible to reproduce the builds after the fact as can be done with the regular releases at launch. We've implemented the security preview releases by using the same sources we used for the regular releases and running a script which applies patches we've saved in a repository for the preview patches with the conflicts resolved by us in advance and a script to apply them. It also patches it into being a security preview release by renaming the channel metadata. We're tagging the security preview releases in this repository, so we can make a public variant of the repository where we push the same stuff once the embargo ends.

Are we legally permitted to reverse engineer the OS images containing the embargoed patches? Ie are you legally allowed to allow reverse engineering of the OS images containing the embargoed patches, or the license terms for the embargoed patches that prohibit you from publishing them in source form also forces you to prohibit reverse engineering the binary releases of them?

These patches are under the Apache 2 license and other permissive licenses. We're not allowed to publish them until the embargo ends due to the required NDA. We're restricted by NDA, not software licensing. There's no special license applied to the preview patches. It's open source code but shipped under an NDA disallowing publishing it before Google does.

Are you able to provide the exact terms you have been granted access to the embargoed patches under and are able to publish them in binary form under? So we can verify the legality if reverse engineering them, both for our own sake, and for GrapheneOS sake? Or are the terms also under NDA?

The terms with our OEM partner are not really under NDA, and neither is which OEM we're working with, but we don't want to publish which OEM we're working with until an official announcement with them. We'd also prefer if they make the announcement and we spread it because it would look better.

dhhdjbd

I think this should be a pinned post please?

and i am wondering if default off is the correct approach / or if there is some option like a notification to inform users about this, considering 3 month late patches at worst seem significant

mmobder

dhhdjbd if default off is the correct approach

I second this - if GOS is about security, what's the negative impact on having it as an opt-out? Is it the frequency of releases, app optimizations, ...?

ryrona

de0u I think that may be a question for an attorney. For example, I believe I have heard that EU residents have reverse engineering rights that U.S. residents do not.

No, I do not have the capability to involve an attorney, and I am not interested in if there is rights I have that override contracts or license terms.

I am asking: What license is the GrapheneOS builds with the embargoed patches released under? Eg, if one of the patches were for a GPL-2 licensed component, those patches would also automatically be GPL-2 licensed, and reverse engineering them is expressively allowed, in fact, the publisher would have to give the patches to me. GrapheneOS account already confirmed no patch is for GPL-2 licensed code. If one of the patches is for a Apache-2.0 licensed component, the same is not true. If the component is purely compiled from Apache-2.0 licensed code, the binary is also licensed that way, but if some of the code is proprietary, so might the binary be.

So I am asking, what license are the patches provided as? Proprietary? What license does the binaries have? Proprietary? Who owns the proprietary code and thus binaries? Google? In that case, under what license terms are the patches or binaries provided? Same as stock OS builds? Special license for builds with embargoed code?

Upstate1618

Once we have early access to qpr, can we get an OS release earlier than aosp source release? Can we also get monthly aisp release?

GrapheneOS

ryrona The only GPL2 projects are external ones so we could use the upstream patches instead, which we already switched to doing for one of the patches and can potentially do for a few more. It's possible Android could share patches still not disclosed by external projects but it doesn't really happen in practice for GPLv2 code since there's hardly any of it beyond the Java standard libraries. The Linux kernel is out-of-scope for these patch previews since the kernel drivers are vendor patches and mainline patches are already public when they're included as things which must be fixed. The mainline patches are really meant to come from updating the LTS revision and Android has been moving towards requiring LTS revision updates but very slowly.

ryrona

GrapheneOS We're restricted by NDA, not software licensing. There's no special license applied to the preview patches. It's open source code but shipped under an NDA disallowing publishing it before Google does.

Okay. Thank you. That answers my question. I didn't sign any NDA, so the NDA doesn't apply to me. And Apache-2 license requires that any derivative work that is of different license terms must have this fact prominently displayed, which does not appear to be the case, so the compiled binaries are purely Apache-2 or other permissively licensed code, which expressively allows anyone to reproduce the work in source or binary form, which means reverse engineering is expressively permitted :)

linuxaki88

GrapheneOS
So GrapheneOS team can audit the code to see if something is "suspicious" and then implement it and forward it to security preview realeses! I'm saying that because of previous comments suggest that google can include some "spy" code!

ttmp12

GrapheneOS Yes, it will be possible to reproduce the builds after the fact as can be done with the regular releases at launch. We've implemented the security preview releases by using the same sources we used for the regular releases and running a script which applies patches we've saved in a repository for the preview patches with the conflicts resolved by us in advance and a script to apply them. It also patches it into being a security preview release by renaming the channel metadata. We're tagging the security preview releases in this repository, so we can make a public variant of the repository where we push the same stuff once the embargo ends.

This information is much appreciated! I had the same question. This should be added to the initial post.

yore

mmmm I understand you want to talk about it.

But I find GrapheneOS is usually quite transparent with things. So my understanding is if they chose to announce they have an OEM but not who, there's probably good reason for it.

Here's a quote from the project account:

GrapheneOS The terms with our OEM partner are not really under NDA, and neither is which OEM we're working with, but we don't want to publish which OEM we're working with until an official announcement with them. We'd also prefer if they make the announcement and we spread it because it would look better.

That is why I personally prefer not to speculate about it. It's probably best we wait it out until the project or the OEM releases any further information.