UPDATE 2026-02-15:

This issue has been dealt with and is now closed. Some of the information below may now be outdated, but we will not be making any further changes to it.

LineageOS for microG: December 2025 security issues

At 09:25GMT on Monday 8th December 2025, the project was informed, by XDA Forums user j4nn, in an XDA Forums Private Message, about a security issue affecting the project, and its download server (which also serves the front page of the project website).

TL:DR

The project had a security problem - project private keys were visible in a publicly visible online git repository. This issue potentially

• affected the reliability and integrity of the download server and the files it made available for download and OTA update
• allowed an attacker to make a build and sign it with compromised signing keys, so that the build would appear to have been made by the project.

1. Potential unauthorised access to the download server

As soon as we were able, we stopped the server from serving content for downloads and OTA update, removed existing files, revoked the compromised rsync key, and installed a new one. The website is now being served from a new server and the old server has been taken offline. The server is still online, serving the website.

We do not believe that the server was ever actually compromised, but we cannot guarantee that. So we are in the process of building from scratch and testing a new server, which we will know to be trustworthy. Once this comes online, we can be confident that files made available on the new server can be trusted. We believe that the actions we have taken, and plan to take in the future, are proportionate to the scale of - and the potential threats posed by - the problem, and sufficient to ensure that users can safely install the files that will be made available on the new server.

Please read this section of the wiki for more information on this possible risk

2. Potential malicious builds signed with project keys

An attacker could have made a malicious build, and signed it using the compromised signing keys, so he the malicious build would effectively be signed with the project keys, and therefore be trustworthy. We are no aware of any such builds

1. being uploaded to the download server
2. being circulated elsewhere

Please read this section of the wiki for more information on this possible risk

Is my phone compromised?

In the view of the project maintainers, if you installed the build from the download server (either manually or via OTA), then almost certainly not. For tht to happen, an attacker would have to

1. Make a build malicious build.
2. Sign it with the compromised signing keys.
3. Use the compromised `rsync' key to upload the malicious build to the download server, and hope that an unexpected upload, spearate from the monthly official build run, would not be noticed. They could reduce the chance of the malicious build being detected, by making their build for device at roughly the same time as the official build.

Has this happened?

• For the most recent builds (dated from 1st September: our logs show that the compromised rsync key was only used to access the download server by authorided users - the project maintainers and our download servers. So there is no evidence that an attacker did try step 3. However, it is theoretically possible that an attacker could have used another exploit - one unknown to us and to the Debian distribution maintainers - to elevate the provileges of the rsync user, allowing them to manipulate the log files in such way as to hide the unauthorised access. In the view of the project maintainers, while this is possible, we firmly believe that it is extremely unliklely, and did not actually happen.
• For builds made before 10th January 2025, the keys were not publicly visible and had not been compromised, we can be confident hat these builds are not compromised.
• For builds made between those dates, we no longer have access to the access logs, so a malicious build could have been made and uploaded. If your phone was running a build made in this period please contact use via GitHub, XDA or email (The email address in this link was changed on Wed 17 December 2025 at 22:20 GMT)

Questions and clarifications

The project maintainers do not have the 'bandwidth' to engage in online discussion about this issue. We will however

• monitor any questions and comments about it in our communication channels (primarily the XDA Forum thread and this issue in our github issue tracker, but also on the IodéOS community forums, and the microG Matrix room #microG:matrix.org );
• periodically update this document, answering any questions and requests for clarification that have come up in those channels;
• post notifications in those channels of changes to this document and any other relevant events.

Details

The issue was that some of the project's private keys were available in a publicly visible online git repository, and had been since January 2025. The compromised keys fall into two groups:

1. A key used to upload build artefacts from our build server to the download server using rsync. (Referred to in our docs and discussions as 'the rsync key). Using this key, an attacker could:
   1. use this key to upload content to our download server ('unauthorised upload'). The rsync user on the download server is an un-privileged user;
   2. use an as yet unknown and unreported vulnerability in the server OS, to escalate the privilege of the rsync user, allowing root-level access to the whole server ('unauthorised access').
2. Sets of keys used in our build process to sign the builds ('the signing keys`). One set was used to sign our offical LineageOS for microg ('L4M') and unofficial LineageOS 'LOS' builds. The other set was used to sign the unofficial builds of IodéOS, for Sony and other devices, made on the project's build server, and served for download on our download server. The unofficial builds made for Google Pixel and other devices, on a different build machine, were not signed with these keys. These keys would allow an attacker to make and sign builds which would appear to come from the original author of those builds (unauthorised builds).

Unauthorised access and upload risk, and actions

After discussing the scope of the vulnerability, and the risks - real and theoretical - caused by it, j4nn, we decided that the issues cause by the compromised rsync key were the most serious. We immediately started taking the folowing steps to mitigate the risks.

1. Remove the compromised keys from the online repository, and make the repo private. (We know that this is definitely locking the stable door well after the horse has gone).
2. Stop the download server serving ROM files for download or OTA update, removing all content that were previously available.
3. Add a README.md file in the top-level download directory saying that the server is down for maintenance.
4. Create and provision a new download server, using a new compute instance and a new rsynckey. This process is till ongoing: we hope to have it completed in the next 24 hours.
5. Created a private GitHub project to manage and document our response to the issue.

Unauthorised builds risk, and actions

We are not aware of any builds made by third parties using the compromised signing keys.

We could not find any files available on the compromised server that were not built by either our own build servers or by the project maintainers. But - due to the 'unauthorsed access' problem identified above - we cannot guarantee that no such files exist or existed in the past.

Since we have secured access to the new download server, we are confident that any files made available in future for download or OTA updates from that server have been made by us, and can be safely installed.

Immediate / current actions

The following actions are either already done, or in progress.

1. (Done) Prevent the upload of unauthorised builds to the download server.
2. (Done) Remove old content from the download server (Done)

Future actions

The following actions will be taken as soon as practical:

1. Create new signing keys;

2. Use the new signing keys to make a complete set of 'known good' new builds, signed with the new signing keys. These builds will

   1. be available for manual installation only, not as OTA updates;
   2. immediately useable in a 'clean flash` i.e. after performing factory reset / format data from recovery;
   3. not be useable for 'dirty flash` over an an exiting installation, preserving user-installed apps and data. Since the update is signed with different keys than the version being upgraded, the device will not boot after such a 'dirty flash' That turns out not to be the case: these builds can be 'dirty flashed' without loss of data.

3. Investigate the possibility of implementing and testing a 'migration script' that would allow a dirty flash to succeed. We cannot gurantee that implementing such a script would possible, or achievable wthin a reasonable timescale. If users need to preserve their user-installed apps and data when installing a build signed with the new keys

   1. enable rooted debugging in the old build;
   2. backup up apps and data using the Android Backup & Restore project backup_apps.sh. The documentation says it needs root, but rooted debugging is sufficient;
   3. factory reset / format data in recovery;
   4. clean flash the new build;
   5. enable developer options and roted debugging on the newly flashed device;
   6. restore some or all of the backed up apps and data using the restore_apps.sh](https://github.com/AndDiSa/android_backup_project/blob/master/restore_apps.sh).

   In discussions with the j4nn, they identified a possible risk with dirty flashing with a migration script, and with backup and restore: if a user had previously installed a compromised build, it could have installed some form of malware, which would be preserved over a dirty flash or backup and restore. The project maintainers agree this is a possible risk, but in the absence of evidence that any compromised builds are in circulation, the actual risk is minimal. But these risk assessments are subjective: if you are in any doubt, the best option would be a clean installation of the new build.

4. Revisit the transcript of initial converstion with the j4nn, and check that all the issues raised there have been - or soon will - be addressed.

Root cause analysis

This issue, and the subsequent incovenience and possible risks to users, was caused by one simple mistake: one of the project maintainers uploaded private keys in a publicly accessible online git repository. At the root of the problem however, is the fact that the project has a very small team of maintainers, all of whom work on the project in the spare time they have away from their other commitments. At the time the error was made, the person who made it was the only active project contributor / maintainer. Since then, one other person has joined the project, but they too have only limited time to devote to the project.

Between us, we have to keep the process of making monthly builds for ~250 devices ticking over, as well as monitoring and responding to input from users in the communication channels mentioned above, and getting on with our lives IRL. This is not a new problem - the project has been struggling with it ever since it started several years (and several maintainers) ago. Now we at least have an open issue in our internal project issue tracker to track this problem, and to ~~kick~~~ encorage us into doing something about bringing more contributors on board. It won't happen overnight, but it will happen, and we hope it will reduce the likelihood of 'show-stopping` issues like this occurring in future, as well as making the project more sustainable in the longer term.

And finally...

.. we apologise

• for the original mistake, and the consequences it has caused - and will continue to cause for a while;
• for the inconvenience to users cause by the unavavilability of the download server and the updates / downloads published there;
• for the lack of timely information about what was going on, and why the download server has been unavailable. Communicatiing about the issue was always on the 'To do' list, but it took a back seat to the more pressing issue of fixing the issues and mitigating their effect.

Thank you j4nn for reporting it, for the manner in which they did so, and for their subsequent help with our response to it (though we take full responsibiliy for the actions we have taken to address it, and for those that we have not taken). And apologies for the tone of some of my initial responses: as you guessed, it was not news I was happy to hear, and my initial reponse was to minimse the threat and the work we would need to do to respond to it.

And to our users, thank you for your patience.

Update Mon 22 December: Resuming builds

We have now completed the tasks that were needed to recover from these security issues:

• our website and download server are running on a new cloud VM, rebuilt from scratch, with a new storage volume attached, and with access controlled by newly created and deployed ssh keys;
• our build servers are using a new set of package signing keys to sign the builds we make and publish.

We believe we are ready to start making new builds, and making them available for download. That will start after one more review by the team of what we have done so far.

Builds for all devices should appear over the coming days, as each build is made. Making builds for all the current officially supported devices (Lineage 23.0 and 22.3 branches) should take around 3 weeks, if all goes well. They will be followed by builds for 'legacy' devices (21.1, 20.0 and 18.1 branches), and we hope that a 'full set' of LineageOS for microG builds will be available in roughly one month's time.

These builds will appear as updates available in the Updater app. They can be downloaded in the Updater app, but when the download completes, a message will appear at the bottom of the screen sayng "Update verfication failed" due to the new build signing key. Additionally, if you manually download the update and attempt to install it using the Updater app, you will receive the message "Failed to import local update". In short, the new builds cannot be installed in the Updater app. If for any reason the Updater app does not prevent you from attempting to install using - even though we have not seen this in our testing - be warned that your data could be corrupted, making it necessary to factory reset / format data.

EDIT: 2026-02-15: We originally thought that these builds would not be possible to 'dirty flash' and that a clean install would be requred. I turns out we were wrong - they can be dirty flashed without loss of data.

Installing the new builds

Do not try to install the new build using the Updater app

We recommend installing these new builds by folowing these steps:

1. Take a backup, using SeedVault and / or Android Backup Project (if you have access to a Linux machine, real or virtual). This should not be necessary, but it's a useful step 'just in case'.
2. Download the new build zip file from the Download server or by by getting the download URL from the "3 dots --> Copy URL" option next to the newly advertised build in the Updater app.
3. Boot your device into recovery, and flash the new ROM zip file using adb sideload on your computer. Detailed instructions for these steps are available from the LineageOS installation instructions for your device (which can be found by following the links from their 'Devices' wiki page). The recovery will report "Signature verification failed: Install anyway?" Choose "Yes" as it is understood the new build uses a different signing key than the old builds.

Apex signing issue is not fixed

While working on these security issues, we looked at the possibility of fixing the previously reported Apex signing vulnerabilty. Unfortunately, fixing that issue would have taken significantly more time and effort, and would have involved further inconvenience for our users. We still believe that the risk to users of our ROMs from that issue in day to day usage of our ROMs is minimal, so we decided not to try to fix it alongside these issues. That issue is therefore still unresolved, and likely to remain so for some time.