From Mullvad: "In contrast, #GrapheneOS, a security-focused Android-based OS, quickly [already] patched the issue in its codebase."

Mullvad VPN

Any app on recent Android versions can leak certain traffic | Mullvad VPN

A recently discovered bug in Android 16 allows any app to leak traffic outside the VPN tunnel.

Apple and Google are gradually expanding their use of hardware-based attestation. They're convincing a growing number of services to adopt it. Google's Play Integrity API and Apple's App Attest API are very similar. Apple brought it to the web via Privacy Pass, which Google intends on doing too. Google's Play Integrity API requires hardware attestation for the strong integrity level and is gradually phasing in requiring it for the more commonly used device integrity level. Apple already has it as a requirement. Over the long term, this will increasingly lock out hardware and OS competition. The purpose of these systems is disallowing people from using hardware and software not approved by Apple or Google. This is wrongly presented as being a security feature. Banks and government services are the main ones adopting it but Apple and Google are encouraging every service to use it. Apple's Privacy Pass brought hardware attestation to the web to help with passing captchas on their own hardware. Many people saw that as harmless since few sites would be willing to lock out non-Apple-hardware users. Apple and Google are both likely to bring broader hardware attestation to the web. Google's reCAPTCHA is planning an approach where they use Privacy Pass on Apple hardware, their own approach on Google Mobile Services Android devices and a QR code scanning system to require an iOS or Google certified Android device for Windows and other systems:

Troubleshoot reCAPTCHA Mobile Verification - reCAPTCHA Help

  Important: Mobile verification for Google Cloud Fraud Defense is an experimental challenge type in Preview. Visual and a

Banking and government services increasingly require using a mobile app where they can use attestation to force using an Apple or Google approved device and OS. Apple's privacy pass, Google's 'cancelled' Web Environment Integrity and now reCAPTCHA Mobile Verification are bringing this to the web. Current media coverage for reCAPTCHA Mobile Verification misunderstands it and the impact of it. They're bringing a hardware attestation requirement to Windows, desktop Linux, OpenBSD, etc. by requiring a QR scan from a certified smartphone to pass reCAPTCHA in some cases. They could expand it more. Control over reCAPTCHA puts Google in a position where they can require having either iOS or a certified Android device to use an enormous amount of the web. Google defines certification requirements for Android which includes forcing bundling Google Chrome, etc. It's enormously anti-competitive. Google's Play Integrity API bans using GrapheneOS despite it being far more secure than anything they permit. It also bans using any other alternative. This isn't somehow specific to an AOSP-based OS. You can't avoid this by using a mobile OS based on Linux or FreeBSD instead. You'll just be more locked out. Google's Play Integrity API permits devices with no security patches for 10 years. The device integrity level can be bypassed via spoofing but they can detect it quite well and block it once it starts being done at scale. The strong integrity level requires leaked keys from TEEs/SEs to bypass it. It doesn't provide a useful security feature, but it does lock out competition very well. Services requiring Apple App Attest or Google Play Integrity are primarily helping to lock in Apple and Google having a duopoly for mobile devices. Play Integrity is more relevant due to AOSP being open source. Governments are increasingly mandating using Apple's App Attest and Google's Play Integrity for not only their own services but also commercial services. The EU is leading the charge of making these requirements for digital payments, ID, age verification, etc. Many EU government apps require them. Instead of governments stopping Apple and Google from engaging in egregiously anti-competitive behavior, they're directly participating in locking out competition via their own services. Requiring people to have an Apple device or Google-certified Android device is anti-competition, not security. reCAPTCHA Mobile Verification will currently work with sandboxed Google Play on GrapheneOS but it clearly exists to provide a way for them to start using hardware attestation on systems without it. People without an iOS or Android device will be locked out when this is required even without that. This isn't about security or any missing functionality. GrapheneOS can be verified via hardware attestation. Google bans using GrapheneOS for Play Integrity because we don't license Google Mobile Services and conform to anti-competitive rules already found to be illegal in South Korea and elsewhere.

This week, we patched a VPN leak in Android that was reported to Google but was ignored. Here is some coverage about that:

CyberInsider

GrapheneOS fixes Android VPN leak Google refused to patch

GrapheneOS has released a new update that fixes a recently disclosed Android VPN bypass flaw capable of leaking a user’s real IP address.

Here is the original vulnerability report:

The Tiny UDP Cannon: An Android VPN Bypass

An unprivileged Android app can leak the user

CVE-2026-0073 is a Critical severity Remote Code Execution (RCE) vulnerability included as the only vulnerability fixed in the May 2026 Android Security Bulletin. #GrapheneOS first shipped the patch in our 2026030501 security preview release early on March 5th. It also isn't nearly as severe as it sounds. This was a bypass for TLS client certificate authentication in the Android Debug Bridge (ADB) for the Wireless debugging feature. It's only relevant to users enabling developer options, enabling Android Debug Bridge and then enabling Wireless debugging. Wireless debugging is disabled on reboot. Our security preview releases are recommended in the initial setup wizard via a dedicated page with toggle that's enabled by default. Existing users who weren't shown the page received a notification at boot opening a similar page with a save button. It reappears until a choice is made either way.

GrapheneOS isn't vulnerable to the 3 recently disclosed Linux kernel vulnerabilities named Copy Fail, Copy Fail 2 and Dirty Frag. Current Android Open Source Project SELinux policies block exploiting all 3 bugs. Standard AOSP GKI kernel configuration also has 2/3 of the vulnerable features disabled. Attack surface reduction via fine-grained SELinux policy rules and stripping out unused kernel features via kernel configuration goes a long way to protecting against vulnerabilities. There's also seccomp-bpf for various standard sandboxes but most of the attack surface reduction is via SELinux. AOSP uses SELinux to allowlist ioctl commands for drivers, permitted socket types, etc. in a fine-grained way. It strictly controls a lot of functionality prone to vulnerabilities including user namespaces and io_uring which aren't allowed to be used by apps or nearly any of the base OS processes. These kinds of issues are rare and attack surface reduction is the best way to defend against them. #GrapheneOS does additional kernel attack surface reduction but in these 3 cases it's enough to have modern AOSP GKI kernel and SELinux policies. We also greatly improve generic exploit protections. Local privilege escalation vulnerabilities in the Linux kernel are very common. However, the vast majority are memory corruption bugs rather than these memory-related logic errors. We defend against the memory corruption bugs with hardware memory tagging, zero-on-free and similar generic defenses. Linux has a massive amount of code for the core kernel and drivers for the hardware. All of the code runs with full privileges with no isolation. In a microkernel, each of these 3 recent vulnerabilities would have been in isolated processes. Virtualization will have a major role in addressing this. Despite these not being traditional memory corruption, a memory safe language with a better type system would definitely help. Containing low-level handling of memory to a much smaller portion of the kernel and mostly using safe abstractions for networking, device drivers, etc. would help a lot. Linux has a relentless flood of severe memory corruption bugs being discovered. Nearly all exploit chains for Linux-based systems by commercial and government exploit developers use Linux kernel memory corruption bugs. It's a lot harder to make very portable and reliable exploits for those bugs. A lot can be done to further reduce Linux kernel attack surface in GrapheneOS and much better generic memory corruption exploit protections can also be developed. However, it clearly needs to be replaced. Hardware-based virtualization on smartphones keeps getting better and has a major role to play.

#GrapheneOS version 2026050600 released. This update adds the latest Pixel firmware upgrades. • update Pixel firmware, driver libraries, HALs and other components backported from Android 16 QPR3 from the initial March 2026 release to the May 2026 release (CP1A.260505.005.A1) • Contact Scopes: add missing handling for QUERY_DEFAULT_ACCOUNT_FOR_NEW_CONTACTS_METHOD was added in Android 16 • backport fix for stuck IME input from May 2026 Pixel update • bionic: avoid adding an extra guard page to the main thread's pthread_internal_t since it serves no purpose (the stack is in a dedicated mapping from the kernel and the stack guard is immediately before pthread_internal_t) and it causes a crash for incorrect anti-tampering code shared across many banking apps which reads /proc/self/maps to find the main thread's pthread_internal_t name and tries to access the internal libc data stored in it with no public ABI (these anti-tampering checks serve no valid security purpose, cause these apps to break on major Android releases and hinder OS security hardening due to compatibility issues with their incorrect code) • bionic: remove unnecessary extra naming for mappings to avoid 2 extra system calls for creating a thread • adevtool: fix update-carrier-settings command

Releases | GrapheneOS

#GrapheneOS version 2026050400 released. This update implements a fix for a UDP VPN leak that Google did not choose to fix, support for lock screen widgets, and the latest security patch level. • full 2026-05-01 security patch level • disable registerQuicConnectionClosePayload optimization to fix VPN leak • Sandboxed Google Play compatibility layer: add shim for BluetoothAdapter ACTION_REQUEST_ENABLE • apply active Dynamic Code Loading restrictions for Java inside isolated processes • add app API for checking Dynamic Code Loading restriction states • fully enable lockscreen widget support by default to avoid the swipe gesture being missing for the Pixel 10a and the whole feature being missing for the emulator • enable standard secure NFC mode by default which can be changed via Settings > Connected devices > Connection preferences > NFC > Require device unlock for NFC (note this only disables card emulation while locked rather than all uses of NFC) • backport upstream fix for getBubblePackageForLogging() crash • kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.170 • kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.130 • kernel (6.12): update to latest GKI LTS branch revision • hardened_malloc: fix slightly non-uniform distribute of random u16 values used for randomizing slot selection, slab allocation quarantining and free slab quarantining • hardened_malloc: improve the robustness of disabling memory tagging against theoretical issues by making it fork-safe and adding more synchronization to avoid technically undefined parallel reads of the memory tagging state • hardened_malloc: improve handling of out-of-memory edge cases • hardened_malloc: improve sized deallocation hardening • libpng: backport fix for CVE-2026-33636 • App Store: update to version 36 • Vanadium: update to version 147.0.7727.111.0 • Vanadium: update to version 148.0.7778.49.0 • Vanadium: update to version 148.0.7778.60.0 • Vanadium: update to version 148.0.7778.60.1 • Vanadium: update to version 148.0.7778.96.0 • adevtool: add update-gservices-flag command for fetching gservices flags All of the Android 16 security patches from the current June 2026, July 2026, August 2026, September 2026, October 2026 and November 2026 Android Security Bulletins are included in the 2026050401 security preview release. List of additional fixed CVEs: • Critical: CVE-2026-0039, CVE-2026-0040, CVE-2026-0041, CVE-2026-0042, CVE-2026-0043, CVE-2026-0044, CVE-2026-0051, CVE-2026-0052, CVE-2026-0080, CVE-2026-0097, CVE-2026-21352, CVE-2026-21353, CVE-2026-27280, CVE-2026-28590, CVE-2026-28591 • High: CVE-2025-22424, CVE-2025-22426, CVE-2025-48600, CVE-2025-48612, CVE-2026-0008, CVE-2026-0016, CVE-2026-0036, CVE-2026-0048, CVE-2026-0050, CVE-2026-0053, CVE-2026-0054, CVE-2026-0055, CVE-2026-0056, CVE-2026-0059, CVE-2026-0060, CVE-2026-0061, CVE-2026-0062, CVE-2026-0063, CVE-2026-0065, CVE-2026-0067, CVE-2026-0070, CVE-2026-0074, CVE-2026-0075, CVE-2026-0076, CVE-2026-0077, CVE-2026-0078, CVE-2026-0079, CVE-2026-0084, CVE-2026-0085, CVE-2026-0086, CVE-2026-0087, CVE-2026-0088, CVE-2026-0089, CVE-2026-0091, CVE-2026-0093, CVE-2026-0094, CVE-2026-0095, CVE-2026-0096, CVE-2026-0098, CVE-2026-0099, CVE-2026-0100, CVE-2026-28572, CVE-2026-28574, CVE-2026-28577, CVE-2026-28578, CVE-2026-28580, CVE-2026-28581, CVE-2026-28582, CVE-2026-28583, CVE-2026-28585, CVE-2026-28586, CVE-2026-28588, CVE-2026-28594, CVE-2026-28596, CVE-2026-28602

Releases | GrapheneOS

The #GrapheneOS Gallery app is going to be replaced with a fork of ReFra. Here is how the app looks. It is far more complete and full of features than the original AOSP Gallery. I am sure you will like it.

I am now reachable through email, final at the GrapheneOS project domain name.

GrapheneOS is immune to the Copy Fail vulnerability due to the deep integration of SELinux in the Android Open Source Project (AOSP). AOSP only permits using specific types of sockets throughout the OS. It only permits the dumpstate process used to create bug report zips to access AF_ALG sockets. SELinux is based on explicitly listing out everything that's permitted and anything not listed isn't allowed. AOSP uses strict, fine-grained SELinux policies for the whole OS. Instead of simply permitting everything that's used in a fine-grained way, the rest of the OS is developed with it in mind. Android makes extensive use of neverallow rules to define and enforce the security goals for the SELinux. Since SELinux uses an allowlist approach, neverallow rules don't directly disallow anything at runtime but rather prevent creating rules violating the constraints. It does this for socket types. Here's where Android defines a neverallow for many types of sockets including AF_ALG for regular sandboxed apps:

private/app_neverallows.te - platform/system/sepolicy - Git at Google

Android has a versioned app sandbox which gets stricter for new API levels. The versioned domains inherit from that untrusted_app_all domain. Android's usage of SELinux is drastically different from mainstream desktop and server Linux distributions where it's only lightly used in a very targeted way. This is a nice example showing how it massively reduces Linux kernel attack surface on AOSP-based operating systems including GrapheneOS. Android splits SELinux into system and vendor policies. Both of these must conform to the extensive neverallow rules. The vendor policies are defined as part of implementing hardware support for a device and permit what's required by the drivers. Most of the driver code is sandboxed userspace code. Android extended SELinux with support for ioctl command allowlists to reduce kernel attack surface. These ioctl command allowlists are used for sockets and many other core kernel devices to limit attack surface. It's also used with drivers in the vendor policies such as GPU ioctl command allowlists. The site for Copy Fail says it impacts every mainstream Linux distribution but that's not really the case. Mainstream mobile Linux is based on AOSP and doesn't have nearly as much kernel attack surface as desktop and server distributions combined with having much more hardening enabled. AOSP also doesn't permit setuid or setgid binaries which was the chosen attack vector for exploiting it in the proof of concept exploit. It similarly doesn't permit io_uring, user namespaces and a lot of other functionality outside of a few core processes for security reasons. Standard Android GKI kernels also have the userspace API for Linux kernel crypto disabled including CONFIG_CRYPTO_USER_API_AEAD being unset. Many Android vendors enable a lot more functionality in the kernels but probably haven't had an actual reason to enable this functionality.

Bitcoin Racing x GrapheneOS.

WIRED published an extremely inaccurate article about the history of GrapheneOS based on fabricated stories created by James Donaldson. We have published the original 50+ questions and answers provided to us. You can see for yourself what we provided and that it wasn't anywhere close to adequately incorporated into the article.

GrapheneOS Discussion Forum

Original GrapheneOS responses to WIRED fact checker - GrapheneOS Discussion Forum

GrapheneOS discussion forum

Privacy and security on computing devices need to become far stronger to protect people from pervasive violations of their rights. Users have their privacy pervasively violated by corporations, criminals and governments. There are endless privacy and security weaknesses in software with exploits of those happening on a large scale. Operating systems, browsers and other apps need to do a much better job protecting users. Enormous progress is needed on both privacy and security. #GrapheneOS provides a massive upgrade for privacy and security over the standard Android Open Source Project. GrapheneOS is nowhere near good enough and we have an enormous amount of work to do improving both. Our work is an ongoing process and doesn't have an end point. Privacy and security heavily involve competition between attackers and defenders. Most defenders are making little progress and falling increasingly far behind. Attackers continue improving their exploits of privacy and security weaknesses. Commercial exploit tools are increasingly widely deployed for broad attacks. Software has a very high density of privacy and security vulnerabilities. LLMs are accelerating both vulnerability discovery and exploit development. For most computing devices, defense is increasingly far behind offense. iOS and GrapheneOS are exceptional cases not representative of degrading privacy and security across computing devices. Growing numbers of internet connected devices are incorporated into botnets. This harms the privacy and security of the internet as a whole through heavily pushing it towards centralization behind services such as Cloudflare. Insecure devices without security patches harm the internet as a whole. It isn't only embedded devices but also desktops, mobile devices and servers being used as part of these botnets. It isn't only people with these insecure devices who are harmed. It can get much worse. We're building GrapheneOS to protect everyone's privacy and security. It's aimed at widespread adoption and is highly usable. It's compatible with the vast majority of Android apps. It has major privacy benefits for every user including stopping a lot of data collection by apps and services with a better permission model increasingly addressing being coerced to grant access. GrapheneOS has many users with little technical knowledge and isn't hard to install or use. We're continuing to work on improving privacy, security, usability and app compatibility for all of our users. Contact Scopes, Storage Scopes, per-app Sensors toggle, VPN leak protection and many other features we provde are very important privacy protections. We're building alternatives to the Camera, Microphone and other permissions too. Our major improvements to exploit protections are there to protect user privacy. Privacy depends on security and that's why we heavily work on security too. Contrary to what's often claimed, GrapheneOS is far more usable and requires far less sacrifice compared to other alternatives. Providing far better protection against sophisticated exploits isn't at the expense of that. Our opt-in sandboxed Google Play compatibility layer combines privacy and high usability. We're gradually making replacements for more Google services apps rely on. Location services, network-based location, geocoding and more has already been replaced and much more is coming.

The alignment on the app drawer is fixed now.

We need more apps with widgets. Can't make my home screen look good...