December Android updates fix critical zero-click RCE flaw

I guess we have to live on the edge once more. I really wonder what prevents FP to release these updates faster. Of course resources, skills, and testing are part of it. I would gladly donate to FP to improve this.



Personally I’m also curious what is forcing them to consistently be a month or two behind. They already receive the updates a month or so prior to them being released. So how can it take them two months? I don’t get it.

My only guess is that, once again, the external company behind the updates are showing that they just aren’t very good at this.


Google hasn’t released this security update neither.

The update goes first to beta testers. And this is only weeks later that the rest of owners get the update.
For example, I have the December patch on my FP3 for some days whereas somebody with a Pixel 7a is still waiting for it.


They announced the importance of the update. It will be available today for the general public.


I know. I am one of them for the FP4. And if you think we get them almost a month ahead of the rest of you, you’re in for a surprise. We get them a week earlier for the most part.

Currently there hasn’t been a new beta update for ages.


Easy (and fair) question, difficult answer :roll_eyes:

I will try to keep it grounded and simple, and here are the main reasons why monthly updates come sometimes “late” compared to other manufacturers:

  • Non-security changes: there are often changes and fixes released together with security updates that make the whole release process slower, as those changes need to be thoroughly verified and they sometimes disrupt the acceptance process with our partners.
    As you noticed, sometimes we consciously only deliver security updates to make sure the delivery is not at risk, but we often also need to prioritize fixes for issues that are impactful to you and, obviously, you expect a fix for.
  • Last-minute patch changes: although the security bulletins are available in advance, the related patches are not always available when the bulletin is released and it sometimes changes multiple times (or is even postponed) before the end of the month.
    The reason behind this is easy to catch: Android must work on dozens of different chipsets, with different hardware configurations and sometimes even different ARM architectures. Thus, the patch is sometimes stable for some, but very unstable for others.
  • 1st of the month vs 5th of the month: as you might have noticed, there are 2 different security patch levels - 1st of the month and 5th of the month.
    In very short, the 1st of the month patches only include framework changes (Android system layer) while the 5th of the month patches also include OEM-specific patches, chipset manufacturer patches, some kernel modules patches, etc.
    Although the difference sounds small, it is, in practice, very big: the Android framework layer is normally standard and kind of similar across different devices, thus is also more stable.
    Applying a patch to the framework is less risky (in terms of stability) than applying a patch to the kernel or the firmware(s).
    We decided, at some point, to aim for the 5th of the month to deliver you the best security possible in advance, but this decision comes with a little time price in terms of implementation and testing.
    Is this decision set in stone? Absolutely not, at some point we might change it, but for the time being this is the standard we follow.

There are of course also a bunch of other factors that can slow down the process, but the above points are the more constant ones.

I can tell you that the topic (make the security patches delivery more time-efficient) is definitely on our agenda for next year :slight_smile:


Awesome to get this detailed answer from FP, thanks! I’m not an Android dev, so forgive my ignorance :slight_smile: But doesn’t project Treble make it possible to separate the FP/OEM changes from the Android update? And thus make it easier to test and roll out updates faster? Or is this easier said than done?

Project Treble is a very ambitious goal but is yet to be completely achieved, unfortunately.

In general, Treble does help when it comes to integrating new software components (e.g. when we prepare an OS upgrade) but is not necessarily helpful during the security patches integration phase, where a lot of manual work is still required to correctly apply the patch, especially when it comes to drivers/firmwares where a very small change can have a disastrous impact on the stability of the system.


what do you mean “sometimes”

i can not remember any more when the fairphone security updates were current (give or take a few days) on a certain month.

hasnt happened for your now-current flagship FP5 ever since its release.
and hasnt happened for FP4 for like ever now?

i can remember exactly one release that was even quicker than google/android themselves like back a few years, was it FP2? FP3 some month that came early a week.

given that android (google) announces and pushes out information to its partners a month in advance to the actual official security day/release-date its all a shame

and you are not only not current, in the same month. you release the last month stage one month or so later into the game.

making it two months mostly of unpatched unaddressed security issues.

and who are you kidding exactly, as if there was ever just one single month over at the android folks where they DIDNT have CVEs and massive amounts of security problems just as the rest of the industry.

so this is by far not about cosmetic issues, this is about security issues. its a pity that or if android assembles security fixes with nonsecurity fixes. but it is just NOT true to my understanding that there is a single month that doesnt have security issues.

can you give us some facts exactly which month of this year or the past years that wouldnt have had any security issues in the core android OS?

i just dont understand this reasoning at all. or I am completely misguided. dont mean to be rude. thanks.

1 Like

following this news, would it be advisable to turn off bluetooth? tbh i am slightly more concerned about my ereader as it hardly gets any updates (android 11, the last patch from June) and I wonder how that bluetooth bug can be exploited - would I see that any external device is being connected?

It may mitigate the risk. I’m not sure if disabling Bluetooth will really solve it though. Location services sometimes enable Bluetooth as well. Not sure if that does the same. But if you find out the answer, make sure to post it here. Thanks!

1 Like

hello, thanks
I found some guidance suggesting disabling bluetooth. See the link below. But still puzzled how it could work in practice.

Disabling bluetooth would mean I can’t use my hearing aids with my phone.

I am not saying I am advising it. I will be using bluetooth on FP myself. I have disabled it on my ereader where it is likely I will not be getting any update any time soon.

It is a 11-years old bug and I find it hard to assess the chances of someone using it now plus am still puzzled how that could work… will it be not noticeable that an uknown device is paired?

I am not sure whether my message was clear :thinking:

Just a couple of considerations:

  • There is indeed always a security bulletin with vulnerabilities found across the source code of Android and other software components, which are both massive. The vulnerabilities are normally having low-medium severity, with rarely a critical bug being spotted. This can be seen negatively, but it is actually positive, in my opinion, that there is such a good interest in security that Android is constantly inspected for that purpose.
  • It is true that Android gives a preview of the security bulletin in advance to manufacturers, but that is, as the word says, a preview. A lot of vulnerabilities highlighted in the preview do not receive a corrective patch until the actual bulletin is released.
  • (almost) all the vulnerabilities contained within the security bulletins are under embargo until the bulletin is public, meaning that the general public will not know about the vulnerability (thus, potentially exploit it) until it is publicly announced.
  • The beauty of Android is its layered architecture, which makes very difficult (and most of the times impossible) to use a single vulnerability to actually reach a malicious goal; normally, a chain of vulnerabilities across different layers is necessary.

The above points are no excuse, just the reality :slight_smile:

I just checked the release schedule for FP4 and FP5 in the last months, and on average we released the SPL of a certain month around 7-8 days after that month has ended.
As I said, the speed-up of the SPL release pace is on our agenda for next year :slight_smile:


Well, in the last couple months the monthly security updates came around the 5th of the following month.
Speaking of which, when will we get the November patches?..

For the FP5 it’s there:


Thanks, saw that. I’m more interested about the FP4 I own.


The November SPL will be shipped along with the patch for the 5G random reboots, likely on Christmas Day.
I know, December SPL would have been better but we had some difficulties in also including those given the extra testing we needed for the random reboot patch.