/e/OS and security updates

Although /e/OS is not a hardened-security mobile OS, Murena is taking security issues seriously. Therefore we have decided to comment about /e/OS security updates practices and also to answer misleading claims that are posted on the web about /e/OS security.

Industry practices

First of all, let’s consider security updates policy in the mobile industry: when a security issue is discovered, it is unveiled in an AOSP security bulletin, along with a source-code fix.

Then, this fix is integrated by each mobile OS publisher, to reduce the risks of exploit. Depending on the threat, integration and publishing can take from 1 day to several weeks. In some case, what is called “0-day” exploit, an urgent fix is needed and can trigger a specific build with an urgent roll-out.

The time of integration of these security patches and its subsequent roll-out can vary from an OS publisher to another one. Here is a matrix of well-known vendors and associated security practices:

Security update practices of major Android vendors

Vendor Nominal patch cadence Typical lag from Google’s monthly Android Security Bulletin (ASB) to first public OTA Emergency/0‑day handling
Google Pixel (stock) Monthly 1 – 3 days (e.g., July 2025 patch hit Pixels on Jul 8, one day after ASB) Same‑day hot‑fix builds if a bug is exploited in the wild
Samsung Galaxy (One UI / Knox) Monthly (flagships), quarterly or bi‑annual (budget) 3 – 14 days. Korea & unlocked receive patches first. 2-4 weeks for carrier-branded. “Maintenance Release” hot‑fixes land but usually rolled into next monthly OTA
OnePlus (OxygenOS) Monthly for flagships, quarterly for others 3 – 6 weeks full roll-out (region‑staged, carriers last) Rare — most fixes wait for next scheduled build
OPPO Find / ColorOS Monthly on high-end, quarterly on midrange 1 – 3 weeks, 1 - 3 months mid-range. Critical patches can ship on Beta to Stable inside a week
Xiaomi / Redmi / POCO (HyperOS) “Monthly or quarterly” (flagship vs. others) 2 – 4 weeks on flagships, 1 – 3 months on mid‑range. Hot‑fixes uncommon; folded into next cycle
Huawei (EMUI / HarmonyOS) Monthly for handful of flagships, quarterly for most 4 – 8 weeks. Rollouts often slip into next month or later. Ad‑hoc. Rarely day‑zero outside China

/e/OS security updates practices

Since /e/OS is not a security-hardened mobile OS, it is targeting standard industry practices. Therefore, for a given release on month N, our current work-flow is to integrate Android security patches from month N-1. As a result, in the worst case, it will take up to 9 weeks to roll out the latest available security updates.In most cases, it will be much sooner.

An exception is made for 0-day exploits: in this case our policy is to build and roll out a patched version of /e/OS as soon as possible.

As a recent example, regarding the specific case of the Murena Fairphone 6 with /e/OS:

  • the Fairphone 6 + /e/OS 3.0.1 has been delivered in June with May SPLs

/e/OS 3.0.4, which was under deployment around July 17th, includes two urgent 0-day webview fixes - released a few days ago - as well as June SPLs

What to expect with /e/OS?

Murena is taking security issues seriously, and our policy about integration of security patches in /e/OS is very comparable to or even better in some cases than many of mobile OS vendors in the smartphone industry.

However, as part of our ongoing efforts to continuously improve we have decided to reduce the integration time of monthly security updates in /e/OS.

Therefore we’ll progressively update our build infrastructure to allow the roll-out of latest security updates following the days after they have been released.

Murena will continue to deploy urgent /e/OS builds for 0-day security fixes

Answering misleading claims about /e/OS

Although we generally do not comment about incorrect statements that are regularly posted on some discussion forums, we wanted to provide an update about several points related to the security of /e/OS:

Claim Truth‑check
Fairphone Gen 6 devices running /e/OS apparently lag “very far behind” on updates and “disables or cripples” important privacy & security protections. FP6 / e/OS v3.0.1 shipped May 2025 SPL in June; v3.0.4 (mid‑July) adds June SPL + Chromium 0‑day fixes. /e/OS keeps AOSP hardening (SELinux enforcing, MEMTAG, scudo) intact and adds Advanced Privacy.
“Lack of secure‑element throttling for disk encryption means unlocking a 6‑digit PIN for the vast majority of users is trivial.” Qualcomm SPU rate‑limits Gatekeeper attempts. Recovering the correct 6-digit PIN would stretch to years. Also users can raise entropy with alphanumeric passphrases.
/e/OS hides the true security patch level by ignoring certain vendor patches. /e/OS exposes both AOSP and vendor SPL fields exactly like stock Android (Settings ▸ About phone). Nothing is hidden.
/e/OS has “major issues” providing browser/WebView updates and still uses various Google services. v3.0.4 has been triggered to deliver upstream Chromium/WebView 0‑day patches. Default connectivity checks, NTP, DNS, search, maps, cloud & push hit Murena / FOSS endpoints; microG reaches Google FCM using anonymized accounts. FCM calls can be disabled. UnifiedPush has been integrated in /e/OS as an alternatives for push notifications.
/e/OS dramatically reduces privacy & security compared to the stock OS and doesn’t keep important standard protections intact. All AOSP hardening stays enabled (ASLR, verified boot, FBE, SELinux enforcing, kernel mitigations). On top we add tracker firewall, Tor‑based IP hiding, location spoofing and open‑source App privacy ratings.
/e/OS has privileged integration for Android Auto and microG similar to privileged Play Services. microG lives in /system to spoof Google signature; it is open‑source, audited, and can be disabled. No Google account is needed.

Murena is committed to transparency and responsible security practices, consistently meeting or exceeding industry standards in timely patch delivery.
While /e/OS is not a hardened-security operating system, our proactive approach ensures robust protection against emerging threats, including swift responses to 0-day vulnerabilities.
We remain dedicated to continuously enhancing our security processes, empowering our users with privacy-centric features, and openly addressing misconceptions to build greater trust and clarity within our community.


Regain your privacy! Adopt /e/OS the deGoogled mobile OS and online servicesphone

48 Likes

you should use permanent gitlab links using the commit hash, otherwise the url fragment will quickly point at the wrong line with only branch refs.

3 Likes

While this is Hardware related, not /e/OS related, what about 4-digit PINs?

I am no expert, but I believe this is not what the criticism was aimed at.
While the patch date might be visible it was claimed that not all patched usually(or by extension) associated with a certain patch date are not always included.

Hence if only, say, 90% of all DD-MM-YYYY patch day patches are included in a certain update it should instead show the previous DD-MM-YYYY of which 100% of the patches are included or include a note etc.

4 Likes

It would be good to have an understanding of current designation policy for these cases, I agree.

Transparency on contents would be great.

2 Likes

I think it’s a very good approach to have the devs of the /e/OS project drop by the forum from time to time to contribute their insights.

6 Likes

While this is Hardware related, not /e/OS related, what about 4-digit PINs?

Response from the development team:

it is possible today for anyone to set a 6-digit PINs. We are considering making it the default option.

7 Likes

Response from the developers:

We apply all patches, hence the security update date available in settings is always the real one. By using vanir tool on the latest /e/OS v3.0.4 build for FP6, we detected that we miss CVE-2025-22435, published in April 2025-04 Android Security Bulletin. We are working on fixing this issue for our next /e/OS release (/e/OS v3.1, expected early August).

8 Likes

The developers would not be coming on the forum as we would prefer to have them focus on the development, debug and issue resolution. The way to get in touch with them is through the Gitlab where issues get responses from them when debugging.

7 Likes

Getting feedback from developers on specific issues means that /e/ promoters (like me) don’t bullshit users who are going to or have switched to /e/… May be next stage for me would be to spend more time into gitlab…

I’m sure we had it discussed before, but I can’t find it anymore - this quite often quoted android ROM overview https://eylenburg.github.io/android_comparison.htm still lists /e/OS as not providing proper verified boot.

w/ test keys; excl. system app updates

Should that be requested to be changed? Or is it still true for some devices?

If the latter, is there an overview?

1 Like

the device selector gives an overview of relockable AVB devices.

The criticism w/ test keys applied to FP3 afaik (more devices?). You’d need to go through the official images which ones are signed with /e/OS owned keys and to address the second point on “excl. system app updates” - where firmware partitions are distributed with system (I guess most more current store-sold devices).

@eDevelopersBlog |’m also wondering about vendor security patches provided by the device manufacturer.

  • Are these vendor patches being provided for /e/OS-supported devices?

  • Are they provided separately, or are they integrated into /e/OS? There has been some misunderstandings about it.

I’ve seen some concerns that vendor patch levels are ~a year behind (and if I understand all of the above, the displayed vendor patch level is the correct one), even when Android patch levels are up to date.

Could someone from the team clarify how /e/OS handles this?

1 Like

Vendor provided security patches where provided goes out for all devices. The process of applying and the lag is explained in the initial post.. If you can cite an example where they are a year old I can have the team look into it and respond.

1 Like

I checked with the build team. The response was that for the FP4, we tried to update using the latest vendor patch but that resulted in some bugs with the calling code. For example VoWifi stopped working. The team is working on a resolution for this. Will update when we have any progress on this.

6 Likes

Thanks. It wasn’t clear to me whether it was android patches or vendor patches.
My specific example is Fairphone 5: Vendor Security Patch Level (SPL) in Fairphone 5 and this is another one: Vendor Security Patch Level (SPL) in Fairphone 5 - #10 by BeMiGro