Android: Bypassing the Credential Provider's security measures when using hardware keys

This is a security bug I've found while debugging a Passchain issue.

This article could be interesting for users of hardware security key who want to take precautions, and, more generally, for anyone who would like to understand some Android features.

Android contains many protections to prevent applications from accessing unauthorized resources.

When dealing with hardware security keys (like Yubikeys), the system prevents malicious apps from connecting to arbitrary websites with 2 measures:

• First, by preventing unwanted direct communication with the hardware key:
  • When an application is in the background, it can't talk to the hardware key directly, via NFC or USB.
  • And when and app is in the foreground (visible), it needs a user interaction (a dialog to accept, or tapping the NFC key) to talk to the key.
• Secondly, applications aren't able to request the Credential Provider (e.g. Passchain, Authnkey or the Play Services) to log in to arbitrary websites:
  • Websites have to publish Digital Asset Links files (assetlinks.json), to enable credential providers to securely share credentials between an app and the website.
  • Browsers are considered privileged applications that are able to request credentials for any website. In order to process that privileged request, the credential provider must provide an allowlist of privileged browsers/apps that it trusts (CallingAppInfo#getOrigin)

The assetlinks.json hosted on the website looks like this:

[
    {
    "relation" : [
        "<array_of_permissions_granted_to_app>"
    ],
    "target" : {
        "namespace" : "android_app",
        "package_name" : "<android_application_package_name>",
        "sha256_cert_fingerprints" : [
            "<sha256_certificate_fingerprint_of_signing_key>"
]
    }
}
]

With the 2 protections combined, users can use their hardware passkeys with their Credential Provider safely:

• A random application is not authorized to log in to arbitrary websites (for example CredPoc isn't able to log in to https://webauthn.io)
• When the credential provider is in the foreground, the calling application can't talk directly to the key.

At least it shouldn't be able to. And that's where the bug is: the calling application, even behind the credential provider, is able to talk directly to the hardware key, and to bypass the protection preventing log in to arbitrary websites.

Proof-of-concepts

NFC

For example, I made an app (CredPoc) that is able to log in to https://webauthn.io with a NFC key, even if the application isn't allowed by the website's assetlinks.json:

If you're used to hardware keys, it's good to know that using a key with NFC gives the User Verification flag. That's why you don't need to touch the center of your key with an NFC authentication.

USB

The proof of concept (POC) works with USB too.

A dialog is shown to the user to ask to "Allow CredPoc to access Yubikey FIDO+CCID". The dialog may easily be interpreted as to allow the credential provider to use the USB security key for the calling app.

Unlike the NFC POC, this doesn't give the User Verification automatically. A website that requires User Verification is then less exposed.

Timeline

• 21-05-2026: Report to Google, with a POC, disclosure planned for 21-08-2026
• 20-07-2026: Report to GrapheneOS, so they can fix it before disclosure if it isn't fixed on AOSP
• 02-08-2026: Vuln acknowledged by GrapheneOS
• 06-08-2026: GrapheneOS made a patch for the NFC-related issue for the Play Services on their system
• 08-08-2026: Suggestion to GrapheneOS for a patch for the NFC-related issue for all Credential Providers
• 13-08-2026: Fix for NFC-related issue released by GrapheneOS (2026081300)
• 17-08-2026: Extra time before disclosure requested by Google, for triage. New disclosure planned for 21-09-2026
• 27-08-2026: Fix fox NFC-related issue released for Passchain (1.1.0)
• 19-09-2026: Vuln acknowledged by Google, rated as Moderate severity
• 23-09-2026: Bug shared to microG, and fixed
• 24-09-2026: This post is published

Conclusion

A malicious app could use this bug to log in to arbitrary websites, by sending a legit-looking login request.

If you're using an USB security key, stay careful with the application you're giving access to the key. You should allow your Credential Provider only.

If you're using a NFC security key:

• If you're on GrapheneOS, no matter your Credential Provider, you should be safe from this bug.
• If you're using Passchain, or microG (>0.3.17), this bug is not exploited either.
• Else, AOSP is supposed to fix it in the future. Until then, stay careful and avoid logging in with a security key from an unreliable application.

I think it would be good to have an additional permission to use an USB security key, like android.permission.CAMERA is used to access camera devices.

Last word

Finally, as mimi89999, developer of Authnkey, said:

But a malicious app could fake entirely the credential manager flow UI 🤔

Even with the patch, stay careful, and don't install unknown apps!