In June 2024, Google disclosed CVE-2024-49728, a critical vulnerability affecting Android’s Bluetooth file sharing (OBEX) functionality. The bug allows apps on a “non-owner” profile (like a guest user or a child profile) to quietly access and exfiltrate media files owned by a different user on the same device. Neither user interaction nor special permissions are needed to pull off this attack. In this post, I’ll break down how the vulnerability works, show you the relevant code, explain how it can be exploited, and point you to official resources for further reading.

What’s The Problem?

Android supports multiple user profiles on a single device for privacy, but certain system services act with higher privileges than the calling app. “Confused deputy” vulnerabilities happen when a less-privileged caller tricks a more-privileged component into doing something dangerous. Here, BluetoothOppSendFileInfo—a part of Android's Bluetooth file sender—can be exploited to read media files that should be off-limits to the attacker’s user profile.

Impact:
Any app running in a restricted/secondary profile can steal files (photos, music, videos, etc.) from the primary user by tricking the Bluetooth sharing service into reading those files on its behalf and sending them out.

Severity:
Local Information Disclosure
Interactiveness:
No user interaction needed
Privileges required:
None (just running as a secondary Android user)

How The Vulnerability Works

At the heart of this bug is the function generateFileInfo() inside BluetoothOppSendFileInfo.java. This method handles prepping files for sending over Bluetooth. When a Bluetooth file transfer request comes in, it tries to open the requested URI and package up info about the file. Critically, it does this as the Bluetooth service user, which may be your primary profile, not the app’s own user.

An attacker on, say, a “guest” profile, can craft an Intent instructing the Bluetooth sharing service to send a file from /storage/emulated//DCIM/Camera/private.jpg—a file owned by the primary user, which the attacker app shouldn’t normally read. Because the Bluetooth service is a “deputy” running with higher privileges, Android’s content resolver allows it to access the file, which it then happily packs up for sending.

Show Me The Code

Here’s the simplified relevant code from BluetoothOppSendFileInfo.java:

public static BluetoothOppSendFileInfo generateFileInfo(Context context, Uri uri, boolean isHandover) {
    ContentResolver resolver = context.getContentResolver();
    InputStream inputStream;
    String fileName = null;
    long fileLength = -1;
    String mimeType = null;

    try {
        inputStream = resolver.openInputStream(uri);
        AssetFileDescriptor afd = resolver.openAssetFileDescriptor(uri, "r");
        if (afd != null) {
            fileLength = afd.getLength();
        }
        // ...Code continues, extracting fileName, mimeType, etc...
    } catch (FileNotFoundException e) {
        Log.e(TAG, "File not found: " + uri.toString());
        return BluetoothOppSendFileInfo.SEND_FILEINFO_ERROR;
    }

    // ...More code to build file info for Bluetooth sending
}

Notice how it just opens the file using its own resolver as the system service. It does not check whether the caller (the app) should have access to that file!

Exploiting CVE-2024-49728: Step By Step

Step 1: Attacker prepares a malicious app on a secondary Android user profile. No special permissions needed.

Step 2: The malicious app crafts an Intent to send a Bluetooth file transfer request via Android’s standard Bluetooth sharing mechanism, with a file Uri pointing to a file owned by another user (e.g. the primary user's photos).

Step 3: Bluetooth service receives the request and runs generateFileInfo(). Because it is running as its own privileged service user, it can bypass normal user boundary checks.

Step 4: The target file is opened and prepared for sending–giving the attacker access to metadata, size, and potentially exfiltration via Bluetooth.

All of this can happen without the victim’s knowledge or any permission prompt.

Example Exploit Code

Disclaimer: For educational purposes only. Do not use these techniques to attack actual devices without permission.

Intent intent = new Intent(Intent.ACTION_SEND);
intent.setType("image/jpeg");
intent.putExtra(Intent.EXTRA_STREAM, 
    Uri.parse("file:///storage/emulated//DCIM/Camera/private.jpg"));
intent.setPackage("com.android.bluetooth");
// Trigger the Bluetooth sharing activity
startActivity(intent);

Even if this app runs in a restricted user profile, the Bluetooth sharing service will process this intent as itself, not as the app’s user, and so can access private files from the owner or other users.

Who Is Vulnerable?

This bug affects Android devices where multiple user profiles are enabled, and that run unpatched Android sources prior to the security update. It was fixed in June 2024 via permission checks in the affected service.

Protection:

Apply Android’s June 2024 security patches (or newer)

- Limit use of guest/child profiles if device is shared

References

- Google CVE-2024-49728 Security Bulletin
- Android Issue Tracker #326925937
- NIST NVD for CVE-2024-49728
- BluetoothOppSendFileInfo.java on Android Open Source Project

Conclusion

CVE-2024-49728 is a strong reminder that Android’s user separation is only as strong as its core system apps and services. If you share your phone, always keep it patched. Developers should always think about the confused deputy problem when designing code that bridges caller and callee with different privileges.

If you want to check whether your device is safe, look for June 2024 (or newer) security updates in your Android settings.

Stay safe, and share this post to spread awareness of the risks of unpatched device-sharing features!

Timeline

Published on: 09/02/2025 23:15:32 UTC
Last modified on: 09/04/2025 16:40:12 UTC