Full Report
To support debugging applications written in Unity, the Android library adds a handler for the intent containing unity data onto a UnityPlayerAcivity. Android does manage feature flags it does not prevent the execution of intents. The unity field contained a lot of extra flags. While reverse engineering the library they found that xrsdk-pre-init-library could be used as an argument to dlopen to load arbitrary libraries. This gives the threat of an RCE in the application! A malicious Android application can trigger the intent with their own created library. By doing this, the application would have the same permissions as the Unity application. Exploitation from the browser is somewhat nebulous though. Because dlopen needs a local file path, we need to trick the user to downloading a file. By good design on Android, SELinux prevents the usage of dlopen for files in the downloads directory. Nice protection! This isn't full-proof though. dlopen doesn't require a file to have the .so extension. Since /data is allowed, if an application writes arbitrary data to storage on the device then this can be used as a malicious library. Good find!
Analysis Summary
# Vulnerability: Arbitrary Code Execution in Unity Runtime via Intent Handling
## CVE Details
- CVE ID: CVE-2025-59489
- CVSS Score: Not explicitly provided, but described as **Arbitrary Code Execution (RCE)**, indicating High severity.
- CWE: Likely related to Improper Input Validation and OS Command Injection/Arbitrary Code Execution based on function call control.
## Affected Systems
- Products: Unity Runtime (Used in games/applications built with Unity)
- Versions: Unity 2017.1 and later. Patches are available for versions starting from **Unity 2019.1**.
- Configurations: Affected on **Android** platforms. Requires the Unity application to handle specific intents containing `unity` data via its exported `UnityPlayerActivity` or `UnityPlayerGameActivity`.
## Vulnerability Description
The Unity Android library registers a handler for intents containing `unity` data onto the `UnityPlayerActivity` to support debugging. This handler improperly processes flags contained within this intent. Through reverse engineering, it was found that the argument specified for `xrsdk-pre-init-library` could be used as an argument to the `dlopen()` function, allowing an attacker to load an arbitrary shared library (`.so` file).
This grants the attacker's malicious application the same permissions as the targeted Unity application. While exploitation requires the attacker to reliably place a malicious library file on storage accessible to `dlopen`, SELinux protections usually restrict this usage to the Downloads directory. However, if the victim application writes attacker-controlled data to its private storage (e.g., via caching mechanisms), and if that data is loaded without proper validation, exploitation becomes possible.
## Exploitation
- Status: **Local exploitation is possible** for any Unity application. Remote exploitation is possible if specific application configurations exist (e.g., exposing the activity via `BROWSABLE` category, or writing arbitrary data to private storage).
- Complexity: **Medium**. Local attack requires a second malicious app on the device. Remote attack requires specific application design flaws in the targeted Unity app.
- Attack Vector: Primarily **Local/Adjacent** (malicious app installed on the device). Remote exploitation via browser is context-dependent.
## Impact
- Confidentiality: **High** (Can read/exfiltrate data accessible to the compromised Unity application).
- Integrity: **High** (Arbitrary code execution allows modification of application state and data).
- Availability: **High** (Possibility of application disruption or denial of service).
## Remediation
### Patches
Unity has addressed this issue. Developers must update their Unity version, recompile their application, and republish:
- Patches are available for **Unity versions 2019.1 and later**.
- A **Unity Binary Patch tool** was also released to apply fixes to existing binaries.
### Workarounds
- Unity strongly encourages developers to download updated Unity versions, recompile, and republish immediately.
- **Note on SELinux:** While SELinux helps by blocking `dlopen` calls on files in the Downloads directory, this protection is bypassed if the application writes malicious data directly to an allowed storage location (like private application storage) and uses that file path for `dlopen`.
## Detection
- **Indicators of Compromise (IoCs):** Observing system calls, specifically `dlopen()` being called with paths pointing to non-standard or attacker-controlled shared object files, particularly those leveraging arguments passed via launch intents.
- **Detection Methods and Tools:** Monitoring application launch intents for suspicious `unity` extras, and inspecting library loading routines within the running Unity process memory space.
## References
- Vendor Advisory: hxxps://unity.com/security/sept-2025-01
- Original Research: hxxps://flatt.tech/en/research/posts/arbitrary-code-execution-in-unity-runtime