Old phones stay hydrated.

I'll do my best to respond, but I'm not sure if this response will satisfy you.

By continuing to use an EOL device, you are conceding that there are bugs which are known and documented that have not been fixed on your device. The kernel for example (except for extremely recent devices) is very specific to your handset and will no longer receive updates. A bug in the kernel, if exploited, could potentially result in a total compromise of your device security.

Let's imagine that you're concerned about browser exploits. Your browser will be up to date, but let's imagine that there's a zero day that gets exploited. Now, an attacker can combine their brand new bug with an already known bug in your kernel that hasn't been updated yet to break out of the app sandbox and gain access to your device. This isn't terribly outlandish. It's common for attackers using a browser exploit to perform some analysis of the environment to select the next stage that is most appropriate for the device under attack. Because you ran older system software, you lowered the browser exploit bar by -1 exploit the attacker had to discover. Now, it's likely the exploit will be discovered and the browser patched quickly, but there is still a time window where you are more vulnerable than someone who has an up-to-date kernel, and there have been cases where bugs existed for many years before they were discovered.

Let's talk about exploits over RF. Your baseband might become very outdated and let's say there is a known security bug. An attacker runs a fake cell tower and steps onto your modem. Now, presumably if you're also running an old kernel, an attacker has documented issues that they could research and leverage for stepping from the modem into the kernel. When you are running old code, you make it easier for the attacker. They don't have to get as creative because they have a library of issues to choose from.

An exploit over the baseband would have to be tailored to your specific baseband and your specific kernel. It could theoretically happen, but the odds of this happening to you are quite small because it would have to be crafted to your specific setup. For most users, attackers would like to use an exploit that applies to a wide variety of targets. Most of the common software that would be targeted has become modular and easily updated. We hope that good design of Android means this attractive and wide-ranging exploit would be hard to pull off even if you are EOL.

There's no such thing as a perfectly secure device. Ultimately, it's about increasing the cost and difficulty for the attacker until targeting you is simply not worthwhile. When you use an EOL device you go from highly unlikely to unlikely. It's still unlikely. Does this matter for your use case? It might. I'm a security researcher, so it's not unthinkable that I might be specifically targeted. However, me being specifically targeted would be even more likely if I were a celebrity or a diplomat. In that case, it would be very important to me to force an attacker to discover new bugs just for me. Think of it like cryptography. There is no unbreakable encryption aside from the one-time pad. The objective is to drive up the cost so high that it's effectively unbreakable for practical purposes. Security is much the same way.

There's not going to be a straight answer to this. Are you a nobody or are you a valuable target? Would your attacker be dedicated or opportunistic? Are they well funded, or a script kid? Ultimately it comes down to how much risk you're willing to tolerate. Android is designed to try to give you a better deal even when your device is EOL. Quantifying how much of a difference it makes is not trivial. It really depends.

For what it's worth, I let my dad use a three-years outdated version of Android. He doesn't do banking on that phone. He doesn't care. It's a phone. No one is going to specifically target him for his precious browsing history. His device getting owned by a browser exploit is unlikely and in the event it does happen it is merely an inconvenience.

For myself as a security researcher? If my financial situation looks good, I want the security updates. I feel that I am at elevated risk, but it's still unlikely someone would go after me specifically. I wouldn't have severe heartache with being outdated for a little while even though it's still not advisable. For me and my father it would be an understood and accepted risk.

Backdoor in the sense of CVE i mean, not backdoor introduced by the government.

It’s a bit hard to find the details of the vulnerabilities let alone POCs.

I would assume the APIs provided by android use the underlying system libraries so if left unpatched then any app that makes use of the APIs could potentially be an attack surface? This is all my assumption and it would be nice for someone that specialises in Android security to comment.

That's good news, but GrapheneOS does not support older Pixel phones because they are insecure and cannot be made secure, so apparently the baseband isn't the only problem.

Unfortunately, they're not specific about which firmware poses a security threat unless updated. I was under the impression that the baseband firmware is the problem, but I must have been mistaken.