Security of an 8th gen pixel with many unpatched RCE and EOP out of the box

Watermelon

Gr4 Unless you believe you're actively targeted by someone, and as long as you feel it'd be less safe to connect the phone to cellular network/internet than to your computer, I suggest you to do this:

When you get the phone, the first thing you need to do is boot it into Fastboot mode, from there enter Recovery mode, and from there sideload the latest OTA update:
https://developers.google.com/android/ota#husky
Using these instructions (skip steps 1 and 4):
https://developers.google.com/android/ota#instructions

(Edit: And don't put any SIM card in the phone before this!)

After this, follow the GrapheneOS installation guide:
https://grapheneos.org/install/

Gr4

@23Sha-ger @de0u @Watermelon Thank you for taking the time to answer. However, I wasn't asking about best practices on GOS in general, I have read a lot about these. I am well aware about RCEs and EOPs being a part of life and on the importance of getting the latest updates.

Let me rephrase my question, sorry for being unclear previously, English isn't my primary language.

I must go trough these steps:

Unbox the phone (on August 2023 patch level out of the box IIRC)
Stock OS and firmware updated to the latest version
Flash Graphene OS

How to go from step 1 to step 2 safely or without being so badly compromised to the point that step 3 is affected ?

23Sha-ger Nobody will target your phone without a SIM card inside it, simply because at this stage it's impossible to know who the user is. That's science fiction.

The phone still connects to cell towers without a SIM, both talking and listening. I have concerns about the IMEI being used for this purpose (pixels are uncommon here). Maybe all these RCEs absolutely need a SIM to work but that's what's unclear to me, the CVE reports being too vague for non technical users to understand.

de0u Here is a summary (source):

Yes, I've seen this summary however i do not understand the consequences of this privilege escalation. Does this allow to "just" compromise the system, read all the phone data etc or does this allow an adversary to give me the real GOS verified boot hash while i installed a compromised version ?

de0u This is addressed by standard best practices, including locking the bootloader, not connecting to random PCs, and upgrading the firmware.

Yes, but I need to unlock the bootloader and connect it to my compromised PC in order to flash GOS. If the Stock OS gets compromised when i try to update it, how can i trust that it correctly upgraded the firmware and/or OS before trying to flash GOS ?

"But we told you, flashing is safe anyways even if the device was previously compromised". This post from @GrapheneOS clearly says it's best to update the stock os first to "protect the device against the computer being used to flash it and avoids having unpatched known vulnerabilities in verified boot which could impact the initial verification via the verified boot key shown at boot"

I guess my real questions are "Am i misunderstanding things or is there such a known AVB vulnerabiliy affecting the pixel 8 pro (and others) out of the box?" and "can I safely update the stock OS despite all these known cellulars and WiFi vulnerabilities or should i save to get a pixel 11 day one"? Slightly higher threat model.

Thank you for your help and sorry for the confusion.

userofgos

Gr4 How to go from step 1 to step 2 safely or without being so badly compromised to the point that step 3 is affected ?

Did you read 23Sha-ger reply carefully?

23Sha-ger Nobody will target your phone without a SIM card inside it, simply because at this stage it's impossible to know who the user is. That's science fiction.

Plus, the process of flashing GOS wipes the device twice as long as you follow the instructions fully

Gr4 I need to unlock the bootloader and connect it to my compromised PC in order to flash GOS.

If you are so worried about using your "compromised" PC, use another device. If you have an old phone laying around or can borrow a friends phone then use that instead.

NetRunner88

Gr4

Y u not use airplane mode ?

Then wifi to do the update and unlock bootloader

Then flash GOS

I do that all the time

Watermelon

Gr4 I wasn't asking about best practices on GOS in general

That's not what I gave you. I gave you very specific and practical instructions.

Gr4 I must go trough these steps:

Unbox the phone (on August 2023 patch level out of the box IIRC)
Stock OS and firmware updated to the latest version
Flash Graphene OS

How to go from step 1 to step 2 safely or without being so badly compromised to the point that step 3 is affected ?

I'm not sure what you're looking for, magic? You only have two options to update the device, either using the OTA updater within the stock OS with connectivity (cellular/Wi-Fi) enabled, or using the recovery mode to sideload Google's latest OTA update file from a computer as I suggested. There's another good option I haven't thought about, which is installing GrapheneOS with the WebUSB-based installer from another, up-to-date Android phone, which would also update the firmware to the latest version as a byproduct.

Theoretically, vulnerabilities could lead to compromise of (for example) the secure element. Theoretically, it might also be possible to persistently compromise them. There is no known way to bypass verified boot currently: if you hold the power button for about 30 seconds, it should forcibly (using a hardware mechanism) reboot the device, which should also power cycle the secure element (which has its own internal verified boot process). Still, you can reduce the doubt in your device by updating it safely, as quickly as possible. Your only options to do it are listed above.

After installing GrapheneOS, you can use the power button trick and then immediately boot into Fastboot mode, from there enter recovery mode, stop on the verified boot key fingerprint screen, compare it to what you can see on GrapheneOS's website, resume the boot into recovery mode, open the recovery mode menu, and check that the GrapheneOS version written at the top is up-to-date. (You don't need a security preview release to have the up-to-date firmware. The security previews have fixes for Android OS vulnerabilities. The latest Pixel firmware is part of the security patch level which is up-to-date in the non-preview releases.) This should give you a baseline assurance that you installed the authentic GrapheneOS on the device with the up-to-date Pixel firmware that they always bundle in it. I also recommend setting up the Auditor app and checking its result, but not instead of this.

Gr4 The phone still connects to cell towers without a SIM, both talking and listening

I doubt that it happens in Fastboot and recovery modes.

Gr4 does this allow an adversary to give me the real GOS verified boot hash while i installed a compromised version ?

The only way I can see something like this occurring is either an attacker finds a way to exploit the component that checks the next component as/before it completes the check, or the check is completed but the OS is compromised post-boot somehow. The latter makes verified boot meaningless for that version of GrapheneOS in that boot mode (with the option to restore the verified boot assurance — if you install an updated version of GrapheneOS that fixes the vulnerability exploited to achieve this). The former would be extremely difficult, is believed to be impossible to achieve currently, and there's the aforementioned power button trick that lets you 100% ensure that the verified boot checks are restarted properly.

Gr4 Yes, but I need to unlock the bootloader and connect it to my compromised PC in order to flash GOS. If the Stock OS gets compromised when i try to update it, how can i trust that it correctly upgraded the firmware and/or OS before trying to flash GOS ?

If you don't suspect it can persistently bypass verified boot on the device, you can do what I suggested above to do after installing GrapheneOS, because GrapheneOS always bundles the latest Pixel firmware in it, and has extended checks to check that the latest firmware is installed, as they claim on the features page. (“Enable bootloader, radio, and boot partition version / fingerprint checks.”)

If you refuse to use another Android device because that's “bad opsec” (whatever that means), your computer is compromised, and you don't want to use wireless connectivity in the booted OS to update, then there's nothing you can do.

Gr4 is there such a known AVB vulnerabiliy

Verified boot is a process/method, not a specific program/executable/code. You should define what you mean by a “verified boot vulnerability” as that's a vague term. Also consider that verified boot is also a psychological feature because it gives you the assurance of the validity and authenticity of the operating system and firmware on your device. The question is, when can this assurance be broken, how, and is it possible to reassure it or is it persistently broken. See above.

de0u

Gr4 I must go trough these steps:

Unbox the phone (on August 2023 patch level out of the box IIRC)

Stock OS and firmware updated to the latest version

Flash Graphene OS

How to go from step 1 to step 2 safely or without being so badly compromised to the point that step 3 is affected ?

Step 2 is not a strict requirement.

Regardless, in order to install GrapheneOS and place some amount of trust in it, it will be necessary for to place some trust in something. For example, it will be necessary to assume that the P8P you have doesn't contain a previously unknown special version of the secure element that deliberately transmits the secret half of Weaver keys via UWB or something. And after GrapheneOS is installed it will be necessary to trust that there isn't deliberate key-exfiltration code hidden somewhere in the truly gigantic code base. And except for people who are in a position to diff each new release and audit the code it will be necessary to trust more and more code over time, since both the old version of something and the new version might have leaked something.

It might be possible to borrow a Faraday cage from a nearby cellular-phone repair shop, to unbox the P8P inside the Faraday cage and, while it's protected from cellular and Wi-Fi and Bluetooth attacks, plug in a USB-C Ethernet dongle with the cable running outside the Faraday cage to a wired router. Pretty fancy opsec... but what if there is a vulnerability in the wired Ethernet stack that can be chained to a vulnerability in the secure element that would permanently compromise it?

If one starts by assuming exploits that are powerful enough to overcome every anti-exploit measure that the hardware has, then there won't be any way to prove that the device is in a secure state.

So, to turn the question around... what things are you willing to assume are working as described?

Gr4

userofgos Did you read 23Sha-ger reply carefully?

Yes, and I linked a relevant quote from GrapheneOS implying that it's not that simple. For the Sim card thing, as previously mentioned, the only pixel 8 pro in the area is obviously mine (part of the IMEI is unique to the model).

userofgos If you are so worried about using your "compromised" PC, use another device. If you have an old phone laying around or can borrow a friends phone then use that instead.

It would be bad opsec. As for mine, it's not supported for flashing GOS.

NetRunner88 Y u not use airplane mode ?

Then wifi to do the update and unlock bootloader

Then flash GOS

I do that all the time

That is the plan, though I am concerned about the initial setup before I can enable airplane mode. Then, I must enable the WiFi anyway which is full of unpatched known vulnerabilities out of the box. Unless these vulnerabilities are somehow impossible to chain together, it seems that I am relying entirely on the August 2023 AVB not having any known vulnerabilities, which is exactly what I am unable to clarify.

userofgos

Gr4 Yes, and I linked a relevant quote from GrapheneOS implying that it's not that simple.

I read the quote in it's entirely from the linked thread: https://discuss.grapheneos.org/d/21057-flashing-gos-without-updating-android-on-device-first/7

The reason it's considered best practice to update it first is so that you have the latest fastboot firmware for when you start the flashing process. This minimizes the chance of encountering incompatibilities or bugs. Regardless of whether you do it, it will flash the latest firmware as the first step of installing, then switch to using it, so you'll have the latest firmware right away before it begins flashing the OS. Having it in advance reduces the chance you run into any issues with the start of the install process due to having the latest firmware patches including any fastboot mode bug fixes that are available.

I think there might be a misunderstanding on what is meant here by what a "compromised" computer can actually do during the process of both 1. flashing the latest StockOS OTA, and 2. Flashing GrapheneOS

From what I understand, your current Pixel 8 Pro with August 2023 patch level may be vulnerable to a fastboot exploit due to it not having the latest version, and in theory a compromised PC could in fact exploit that vulnerability during the first phase of the flashing process of the latest StockOS OTA update, but then as far as I understand, that exploit would be eradicated after the OTA update flashes since:

it will flash the latest firmware as the first step of installing, then switch to using it, so you'll have the latest firmware right away before it begins flashing the OS.

So the fastboot exploit becomes null because it was overwritten by the updated/patched fastboot which is now currently running (all this happens before flashing the OS). So it seems to me that there but a blink of time that the vulnerability could be exploited during this first step.

Now we move on to the second step: Flashing GrapheneOS, which effectively does the same thing. You boot your Pixel 8 Pro into fastboot, the Web-install UI starts by flashing the latest fastboot version, switches to using it, then proceeds to flashing the OS.

https://discuss.grapheneos.org/d/21057-flashing-gos-without-updating-android-on-device-first/8

It also protects the device against the computer being used to flash it and avoids having unpatched known vulnerabilities in verified boot which could impact the initial verification via the verified boot key shown at boot. The end result of flashing GrapheneOS is the same regardless, since it flashes all the firmware itself, at least if the computer you used to flash it wasn't compromised.

From my understanding of this, the process of flashing the latest StockOS OTA update is what protects you against the compromised PC being the one to flash the infected fastboot version that is pretending to be the updated version that would have been flashed by the GrapheneOS install.

So unless I am misunderstanding something (which is possible, so please inform me), that vulnerability could have only been exploitable for a short time before being wiped. And I don't think its public what this vulnerability can even do/allow when it's exploited. So there's a lot of speculation involved as to it's capacity.

That doesn't even go into explaining why you'd even be exploited in this way. It would have to be a highly sophisticated threat actor and targeted attack against you specifically.

The attacker would have to know that you bought the Pixel with the intend to flash GOS, would have to know how to not just compromise your PC (get remote/physical access) and would have to also know that you would use that PC to flash GOS, develop an exploit specifically for use of infiltrating the flashing process, persist across the first flash of the StockOS OTA update AND persist across flashing GOS.

If someone is going to that length to target you specifically, I think you have much bigger things to worry about.

Gr4

userofgos Hi,

Thank you for your detailed reply which is actually engaging with my issue.
Still, I didn't understand why a compromised flashing device would exploit a fastboot vulnerability giving it total control over the most trusted part of the phone and then, just continue the installation normally and allow itself to be wiped away instead of flashing its own counterfeit firmware and OS.

userofgos it will flash the latest firmware as the first step of installing, then switch to using it, so you'll have the latest firmware right away before it begins flashing the OS.

It seems to me that this part is basically about user comfort, telling that you won't have to first flash GOS and then manually have to update your firmware or encounter incompatibilities due to your firmware being too old for the os or something. For security, the relevant post is actually post#8 (which is the one I intended to link, my bad) and tells you must be on the latest Stock OS version for protection against a compromised flashing device.

userofgos The attacker would have to know that you bought the Pixel with the intend to flash GOS, would have to know how to not just compromise your PC (get remote/physical access) and would have to also know that you would use that PC to flash GOS, develop an exploit specifically for use of infiltrating the flashing process, persist across the first flash of the StockOS OTA update AND persist across flashing GOS.

The PC in question is a way past EOL piece of trash with 0 firmware protection that I also used with poor security practices. Now at least I keep the OS updated and don't store sensitive data on it but compromising it probably wasn't hard (due to user errors). My intent to buy a pixel has been obvious for a while already and my limited options for flashing as well. As for attacking it, we aren't talking about using 0-days but known vulnerabilities, already publicly reported and patched...unless your device has been sitting in a box for the last 2 years.

Gr4

Watermelon That is indeed not what you gave me, I mentioned you for the thank you part and actually forgot to reply to your post while answering the first 2. Sorry for that.

Watermelon I'm not sure what you're looking for, magic? You only have two options to update the device, either using the OTA updater within the stock OS with connectivity (cellular/Wi-Fi) enabled, or using the recovery mode to sideload Google's latest OTA update file from a computer as I suggested.

No, I didn't know about the sideloading thing and tried to give it some consideration without closing the door to other solutions I might have overlooked. I am basically struggling to evaluate whether it would be better to use Wifi, cellular or sideloading from my compromised pc.

Watermelon There is no known way to bypass verified boot currently: if you hold the power button for about 30 seconds, it should forcibly (using a hardware mechanism) reboot the device, which should also power cycle the secure element (which has its own internal verified boot process). Still, you can reduce the doubt in your device by updating it safely, as quickly as possible. Your only options to do it are listed above.

This is exactly the kind of stuff I was looking for!!! It seems that whatever I choose, I will be forced to rely on (august 2023) verified boot anyways but perhaps it would be harder to break it remotely than connected to my PC. However if what you said here is accurate, then that completely solves my issue regardless . I am just worried about the phrasing.

Watermelon After installing GrapheneOS, you can use the power button trick and then immediately boot into Fastboot mode, from there enter recovery mode, stop on the verified boot key fingerprint screen, compare it to what you can see on GrapheneOS's website, resume the boot into recovery mode, open the recovery mode menu, and check that the GrapheneOS version written at the top is up-to-date. (You don't need a security preview release to have the up-to-date firmware. The security previews have fixes for Android OS vulnerabilities. The latest Pixel firmware is part of the security patch level which is up-to-date in the non-preview releases.) This should give you a baseline assurance that you installed the authentic GrapheneOS on the device with the up-to-date Pixel firmware that they always bundle in it. I also recommend setting up the Auditor app and checking its result, but not instead of this.

This is again exactly one of the answers I was looking for. In the hypothetical of a compromised Stock OS during the Stock OS update but of verified boot still holding, I was worried the OS would just lie about having updated the firmware and OS (kinda like it can fake a factory reset if you don't use the hardware buttons and go trough recovery) and then pwn me when I try flashing because some fastboot vulnerability was only exploitable trough USB. But just to clarify, doesn't fastboot/recovery mode get the version number because it is what the OS told it?

Watermelon I doubt that it happens in Fastboot and recovery modes.

Indeed, I was more worried about the device setup phase you get when you boot the phone for the first time.

Watermelon The only way I can see something like this occurring is either an attacker finds a way to exploit the component that checks the next component as/before it completes the check, or the check is completed but the OS is compromised post-boot somehow. The latter makes verified boot meaningless for that version of GrapheneOS in that boot mode (with the option to restore the verified boot assurance — if you install an updated version of GrapheneOS that fixes the vulnerability exploited to achieve this). The former would be extremely difficult, is believed to be impossible to achieve currently, and there's the aforementioned power button trick that lets you 100% ensure that the verified boot checks are restarted properly.

Again, highly relevant. Thank you. I will think about it during the next few hours.

Watermelon If you refuse to use another Android device because that's “bad opsec” (whatever that means)

Iphone users and would rather not risk infection of devices which do not belong to me/involve others.

Watermelon Verified boot is a process/method, not a specific program/executable/code. You should define what you mean by a “verified boot vulnerability” as that's a vague term. Also consider that verified boot is also a psychological feature because it gives you the assurance of the validity and authenticity of the operating system and firmware on your device. The question is, when can this assurance be broken, how, and is it possible to reassure it or is it persistently broken. See above.

I am calling AVB vulnerability anything that would allow persistent compromise of the firmware, the Stock OS (inability to factory reset or carry over from out of the box Stock OS to latest version stock OS) or anything that would allow to flash a fake GOS and give me the right GOS key hash. This also obviously include the secure element vulnerability scenario you mentioned.

I said I was worried about the phrasing. Here is what I meant:

I have no doubt verified boot on an up to date pixel works as intended. But if there ever was a verified boot vulnerability (following the definition I provided just above), found and patched between August 2023 and now, I would be vulnerable to it and therefore, cooked. I tried to go trough both the android and pixel security bulletin but not having a computer stuff background, I am unable to determine the answer. I NEVER asked about 0-days and hypotheticals, just if there has been one such vulnerability already found and reported from august 2023 up til now.

Thanks a lot for your really helpful answers.

Gr4

de0u

de0u Step 2 is not a strict requirement.

Indeed, but it is an official recommendation from the GrapheneOS project.

de0u Regardless, in order to install GrapheneOS and place some amount of trust in it, it will be necessary for to place some trust in something. For example, it will be necessary to assume that the P8P you have doesn't contain a previously unknown special version of the secure element that deliberately transmits the secret half of Weaver keys via UWB or something. And after GrapheneOS is installed it will be necessary to trust that there isn't deliberate key-exfiltration code hidden somewhere in the truly gigantic code base. And except for people who are in a position to diff each new release and audit the code it will be necessary to trust more and more code over time, since both the old version of something and the new version might have leaked something.

I am well aware of that. I think it is always good to mention it again in case somebody in the future finds this thread. However, I never assumed hardware backdoors from google or anything shady from GrapheneOS. As implied by my previous posts, I even trust an UP TO DATE stock OS to be safe, though of course I would much rather be on GOS.

de0u If one starts by assuming exploits that are powerful enough to overcome every anti-exploit measure that the hardware has, then there won't be any way to prove that the device is in a secure state.

I am not assuming hypotheticals, neither an all powerful adversary. This is why I have only asked about known, already public and patched (unless your device has been sitting in a box for the last 2 years) vulnerabilities.

de0u So, to turn the question around... what things are you willing to assume are working as described?

I am willing to trust GOS and a Pixel as much as GOS trusts it. I've read this post from them hinting at the possibility of some fastboot exploit that could successfully tamper with the flashing. I am trying to understand if this is the case for the pixel 8 pro (and others) or just some hypotheticals.

When I read the Android security bulletin and the pixel security bulletin, I am unable to determine if the pixel 8 pro could be exploited in this way by a motivated adversary. I simply lack the knowledge to understand a CVE report well enough to make an informed decision.

You may think "there is obviously no way to chain this baseband/wifi exploit with this EOP one".
You may think "yes these could be chained together but don't allow to break deep enough so no worries".
you may think "after 3 months the android code has changed so much that these newer exploits cannot apply to a 3 months old version".
You may think "yes but the code to get an update is as close to bulletproof as it can get so don't open chrome before updating and you are fine".
Or you may think "your ( nonexistent) user data will be deeply compromised but AVB has got your back"

What may be obvious to more technical users is absolutely not obvious to me, i might have been spot on with all of these, a few of these or none of these. Hence why I am asking for help.

Nobody

23Sha-ger

23Sha-ger Regardless, it's absolutely safe to flash GOS on any Pixel device, even if you believe it was previously compromised.
The bootloader cannot be modified, and after a full wipe you will end up with a clean OS.

While data and apps are wiped firmware and Android Ver OS updates persist. So while a new from from the factory would be highly likely to be safe short of gov high corp level targeted attack a used market phone could be a Pandoras box. Unlikely yes but still quite possible. Again without a target its low risk event but buying used with no idea of the past owner/s....... Point being a factory reset is not a return to virgin software regardless.

userofgos

Gr4 As for attacking it, we aren't talking about using 0-days but known vulnerabilities, already publicly reported and patched

I'm aware of that. However, I don't believe it would be fair to say that this mostly-hypothetical targeted attack would only require exploiting the vulnerabilities mentioned in your OP, but in fact would more likey require a sophisticated chain of exploits (not just the ones mentioned) and may even require 0-day vulnerabilities to be exploited as well.

Again as you said, their isn't much public information about these CVE's and their capabilities, and what was needed to be patched, so it's hard to say for certain if it's a non issue for this scenario or a major issue.

Watermelon

Gr4 But just to clarify, doesn't fastboot/recovery mode get the version number because it is what the OS told it?

Recovery mode reports the OS version as it's set either in code or in data in the system partition(s) which are covered by verified boot. Recovery mode itself has a very limited attack surface because it's not the full OS. So even if it's a vulnerable version, you can probably trust the value it reports to be truthful, at least.

Fastboot mode doesn't report the OS version, as far as I remember (it does report the bootloader version, but that's not part of the OS). But it's where you enter recovery mode from. Recovery mode is an alternative boot mode of the OS, so when you enter it you'll see the verified boot key fingerprint warning just as when booting normally. It's also clear that it's part of GrapheneOS because it reports the GrapheneOS version, so obviously they (lightly) modified it.

Gr4 Iphone users and would rather not risk infection of devices which do not belong to me/involve others.

That's considerate of you :)

Gr4 I am not assuming hypotheticals, neither an all powerful adversary. This is why I have only asked about known, already public and patched (unless your device has been sitting in a box for the last 2 years) vulnerabilities.

I must say, this is a very good question. As far as I'm aware, I haven't heard of a known defect that can allow bypassing verified boot.

It should be mentioned that in September 2025, Google patched what seems to be a vulnerability in the secure element (CVE-2025-36899):
https://source.android.com/docs/security/bulletin/pixel/2025-09-01#pixel
(GrapheneOS version 2025090800 bundles the patched secure element firmware. Since the secure element has its own internal verified boot process, I believe once you have this version of GrapheneOS booted once, it's impossible to downgrade the secure element to a previous version of its internal firmware even though this version of GrapheneOS didn't yet raise the claimed security patch level.) And it seems to me that this was the first time since mid-2022 that a vulnerability was patched in Google's secure element chips. Now, there's nothing to suggest that this vulnerability could allow persistently breaking security guarantees inside the secure element after forcing a reboot with the power button trick. But it's still a serious vulnerability in a critical component. The secure element plays a big role in verified boot in GrapheneOS as it holds the verified boot key and other stuff.

I have to say that the suggestion by @de0u to rent a Chromebook is a pretty good one. As far as I know, ChromeOS has pretty tight security compared to other desktop computer OSs, and it should be the cheapest option. And I believe some public libraries have Chromebooks. This is a great suggestion.

Also consider an up-to-date Apple M1+ Mac maybe (ideally in a fresh factory reset state), as these have some form of verified boot, anti-root (System Integrity Protection), secure element (Secure Enclave), and other security features in them. (The GrapheneOS team has said that iPhones and Pixels are the only smartphones with a high-quality secure element, and I assume that the Secure Enclave of Macs is at least very similar, maybe even identical, to that of iPhones. They also said that iPhones are probably the next best option in terms of security after GrapheneOS. I assume there are many other similarities between Macs and iPhones, although iPhones are obviously still more secure than Macs.)

de0u

Gr4 I am willing to trust GOS and a Pixel as much as GOS trusts it. I've read this post from them hinting at the possibility of some fastboot exploit that could successfully tamper with the flashing. I am trying to understand if this is the case for the pixel 8 pro (and others) or just some hypotheticals.

I don't expect that post was hinting about a specific known vulnerability. To me it reads as a list of items supporting the best-practice recommendation.

Gr4 What may be obvious to more technical users is absolutely not obvious to me, i might have been spot on with all of these, a few of these or none of these. Hence why I am asking for help.

I think there is a case that the most reliable way to get the latest bootloader onto a device would be to leverage the stock OS on the device. Next I think there is at least a faint argument that using a USB-C Ethernet dongle would be the safest way for the stock OS to update itself -- I am aware of more cellular and Wi-Fi RCEs than USB Ethernet RCEs. If you are worried about somebody targeting you as likely to install an OS on a Pixel, you could mitigate that by plugging into an Ethernet port on a router belonging to a randomly selected friend or coworker.

Once the device has the latest bootloader installed, the feasibility of attacks on the bootloader is much lower. To be clear, I am unaware of reports of in-the-wild campaigns to infect Pixels during OS flashing; at present that seems like it would need to be a targeted attack by a national organization. If that level of concern is in play, honestly you might look into buying a cheap Chromebook, even a recent-ish used one -- they are more resistant than the average PC/laptop to infestations including firmware infestations.

Beyond that I'm not sure how to advise you about using a computer you believe to be compromised to the point that it might deploy a mostly-hypothetical attack that would be successful against an up-to-date Pixel bootloader. Can you rent a Chromebook?

userofgos

de0u Next I think there is at least a faint argument that using a USB-C Ethernet dongle would be the safest way for the stock OS to update itself

@Gr4 here is a list of USB-C Ethernet cables that have been community tested to work: https://discuss.grapheneos.org/d/96-usb-c-to-ethernet-adapter-compatibility-list/

Gr4

@de0u Seems to be sound advice.

de0u To be clear, I am unaware of reports of in-the-wild campaigns to infect Pixels during OS flashing; at present that seems like it would need to be a targeted attack by a national organization.

That is interesting. Not sure if you are talking about an up to date bootloader or not here. I was always under the impression that, sure , it would take something a bit above script kiddie level of sophistication to exploit known and reported unpatched vulnerabilities but that it wouldn't be nation state actors level only.

de0u If that level of concern is in play, honestly you might look into buying a cheap Chromebook, even a recent-ish used one

But wouldn't doing this also put me in the same predicament as now, only that I now need to rely on a more insecure device? I went with the pixel first precisely because I believe these devices to stand the best chance.

@userofgos Thank you for the link.

userofgos I'm aware of that. However, I don't believe it would be fair to say that this mostly-hypothetical targeted attack would only require exploiting the vulnerabilities mentioned in your OP, but in fact would more likey require a sophisticated chain of exploits (not just the ones mentioned) and may even require 0-day vulnerabilities to be exploited as well.

If this is true, then this means I would be fine as I do not expect my adversary to be capable of coming up with 0-days and in the case of one, it probably wouldn't be burned on me. Still, supposing I was also worried about 0-days, I would first have to be sure I am not vulnerable to 1(80)-days.

To be clear, I mentioned some in my posts as examples but I am talking about a very long list, 2 years worth of Pixel and of Android security bulletins. It seems to me that, by combining them, there is a path from any foothold established in the device to anywhere one might want to go, unless I misunderstand something of course.

userofgos Again as you said, their isn't much public information about these CVE's and their capabilities, and what was needed to be patched, so it's hard to say for certain if it's a non issue for this scenario or a major issue.

I suspect that by reading something like:
There is a possible escalation of privilege due to test/debugging code left in a production build. This could lead to physical escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. (CVE-2025-36899 mentioned by @Watermelon )

Really technical users could indeed understand something like "Oh this is the condition required to get exploited, up to this level but not that one, can be chained with this but not that, allowing for this but not that and recoverable from by following this procedure". All the info seems to be there, I am just unable to understand it due to my lack of deep knowledge.

@Watermelon Thank you for all the infos. I read somewhere in this forum (but can't find it anymore) that the bootloader is usually updated when a new android version comes out. I assume there was also an update this September when a vulnerability was found in it. I would be curious to know about how often the bootloader got updated during the last 2y. I think it would be helpful to answer my questions but I had no luck finding this info either.

I will think about my options. All seems to have their pros and cons and some seem harder/impossible to pull off. I remember some macbooks being pwned pretty bad so I will do more research and all chromebooks aren't built equal (ARM vs x86), right? I couldn't find one when I searched. I will try again but having to ID yourself to rent is still sub-optimal. I cannot buy one either due to budget constraints and it would probably be the same story as with the pixel anyways. Getting an answer to my question would still be great for peace of mind but I understand you guys tried to help me to the best of your abilities.

Thank you all.

Watermelon

Gr4 CVE-2025-36899

Gr4 All the info seems to be there

As far as I could see, details about this vulnerability aren't published yet. The info you quoted, as you quoted:

Gr4 There is a possible escalation of privilege due to test/debugging code left in a production build. This could lead to physical escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Is the only public info I could find about it. It's part of the severity assessment and classification of the vulnerability. The actual details aren't public yet, it seems. When they'd become public, the Pixel Update Bulletin in the link I provided should be updated with links to source code commits and such stuff. Beyond seeing the actual fix itself, you could see which source code file(s) were fixed, and the comment describing the fix.