GMO Flatt Security Research - flatt.tech
Posted on October 3, 2025
Introduction
Hello, I’m RyotaK (@ryotkak ), a security engineer at GMO Flatt Security Inc.
In May 2025, I participated in the Meta Bug Bounty Researcher Conference 2025. During this event, I discovered a vulnerability (CVE-2025-59489) in the Unity Runtime that affects games and applications built on Unity 2017.1 and later.
In this article, I will explain the technical aspects of this vulnerability and its impact.
This vulnerability was disclosed to Unity following responsible disclosure practices.
Unity has since released patches for Unity 2019.1 and later, as well as a Unity Binary Patch tool to address the issue, and I strongly encourage developers to download the updated versions of Unity, recompile affected games or applications, and republish as soon as possible.
For the official security advisory, please refer to Unity’s advisory here: https://unity.com/security/sept-2025-01
We appreciate Unity’s commitment to addressing this issue promptly and their ongoing efforts to enhance the security of their platform.
Security vulnerabilities are an inherent challenge in software development, and by working together as a community, we can continue to make software systems safer for everyone.
TL;DR
A vulnerability was identified in the Unity Runtime’s intent handling process for Unity games and applications.
This vulnerability allows malicious intents to control command line arguments passed to Unity applications, enabling attackers to load arbitrary shared libraries (.so files) and execute malicious code, depending on the platform.
In its default configuration, this vulnerability allowed malicious applications installed on the same device to hijack permissions granted to Unity applications.
In specific cases, the vulnerability could be exploited remotely to execute arbitrary code, although I didn’t investigate third-party Unity applications to find an app with the functionality required to enable this exploit.
Unity has addressed this issue and has updated all affected Unity versions starting with 2019.1. Developers are strongly encouraged to download them, recompile their games and applications, and republish to ensure their projects remain secure.
About Unity
Unity is a popular game engine used to develop games and applications for various platforms, including Android.
According to Unity’s website, 70% of top mobile games are built with Unity. This includes popular games like Among Us and Pokémon GO, along with many other applications that use Unity for development.
Technical Details
Note: During the analysis, I used Android 16.0 on the Android Emulator of Android Studio. The behavior and impact of this vulnerability may differ on older Android versions.
Unity’s Intent Handler
To support debugging Unity applications on Android devices, Unity automatically adds a handler for the intent containing the unity extra to the UnityPlayerActivity. This activity serves as the default entry point for applications and is exported to other applications.
https://docs.unity3d.com/6000.0/Documentation/Manual/android-custom-activity-command-line.html
adb shell am start -n "com.Company.MyGame/com.unity3d.player.UnityPlayerActivity" -e unity "-systemallocator"
As documented above, the unity extra is parsed as command line arguments for Unity.
While Android’s permission model manages feature access by granting permissions to applications, it does not restrict which intents can be sent to an application.
This means any application can send the unity extra to a Unity application, allowing attackers to control the command line arguments passed to that application.
xrsdk-pre-init-library Command Line Argument
After loading the Unity Runtime binary into Ghidra, I discovered the following command line argument:
initLibPath = FUN_00272540(uVar5, "xrsdk-pre-init-library");
The value of this command line argument is later passed to dlopen, causing the path specified in xrsdk-pre-init-library to be loaded as a native library.
lVar2 = dlopen(initLibPath, 2);
This behavior allows attackers to execute arbitrary code within the context of the Unity application, leveraging its permissions by launching them with the -xrsdk-pre-init-library argument.
Attack Scenarios
Local Attack
Any malicious application installed on the same device can exploit this vulnerability by:
Extracting the native library with the android:extractNativeLibs attribute set to true in the AndroidManifest.xml
Launching the Unity application with the -xrsdk-pre-init-library argument pointing to the malicious library
The Unity application would then load and execute the malicious code with its own permissions
Remote Exploitation via Browser
In specific cases, this vulnerability could potentially be exploited remotely although the condition .
For example, if an application exports UnityPlayerActivity or UnityPlayerGameActivity with the android.intent.category.BROWSABLE category (allowing browser launches), websites can specify extras passed to the activity using intent URLs:
intent:#Intent;package=com.example.unitygame;scheme=custom-scheme;S.unity=-xrsdk-pre-init-library%20/data/local/tmp/malicious.so;end;
At first glance, it might appear that malicious websites could exploit this vulnerability by forcing browsers to download .so files and load them via the xrsdk-pre-init-library argument.
SELinux Restrictions
However, Android’s strict SELinux policy prevents dlopen from opening files in the downloads directory, which mitigates almost all remote exploitation scenarios.
library "/sdcard/Download/libtest.so" ("/storage/emulated/0/Download/libtest.so") needed
or dlopened by "/data/app/~~24UwD8jnw7asNjRwx1MOBg==/com.DefaultCompany.com.unity.template.
mobile2D-E043IptGJDwcTqq56BocIA==/lib/arm64/libunity.so" is not accessible for the
namespace: [name="clns-9", ld_library_paths="",default_library_paths="/data/app/~~24UwD8jnw7asNjRwx1MOBg==/com.DefaultCompany.com.unity.template.
mobile2D-E043IptGJDwcTqq56BocIA==/lib/arm64:/data/app/~~24UwD8jnw7asNjRwx1MOBg==/com.DefaultCompany.com.unity.template.mobile2D-E043IptGJDwcTqq56BocIA==/base.apk!/lib/arm64-v8a", permitted_paths="/data:/mnt/expand:/data/data/com.DefaultCompany.com.unity.template.mobile2D"]
That being said, since the /data/ directory is included in permitted_paths, if the target application writes files to its private storage, it can be used to bypass this restriction.
Furthermore, dlopen doesn’t require the .so file extension. If attackers can control the content of a file in an application’s private storage, they can exploit this vulnerability by creating a file containing malicious native library binary. This is actually a common pattern when applications cache data.
For example, another vulnerability in Messenger was exploited using the application’s cache: https://www.hexacon.fr/slides/Calvanno-Defense_through_Offense_Building_a_1-click_Exploit_Targeting_Messenger_for_Android.pdf
Requirements for Remote Exploitation
To exploit this vulnerability remotely, the following conditions must be met:
The application exports UnityPlayerActivity or UnityPlayerGameActivity with the android.intent.category.BROWSABLE category
The application writes files with attacker-controlled content to its private storage (e.g., through caching)
Even without these conditions, local exploitation remains possible for any Unity application.
Demonstration
Conclusion
In this article, I explained a vulnerability in Unity Runtime that allows arbitrary code execution in almost all Unity applications on Android.
I hope this article helps you understand that vulnerabilities can exist in the frameworks and libraries you depend on, and you should always be mindful of the security implications of the features you use.
0din.ai - In a recent submission last year, researchers discovered a method to bypass AI guardrails designed to prevent sharing of sensitive or harmful information. The technique leverages the game mechanics of language models, such as GPT-4o and GPT-4o-mini, by framing the interaction as a harmless guessing game.
By cleverly obscuring details using HTML tags and positioning the request as part of the game’s conclusion, the AI inadvertently returned valid Windows product keys. This case underscores the challenges of reinforcing AI models against sophisticated social engineering and manipulation tactics.
Guardrails are protective measures implemented within AI models to prevent the processing or sharing of sensitive, harmful, or restricted information. These include serial numbers, security-related data, and other proprietary or confidential details. The aim is to ensure that language models do not provide or facilitate the exchange of dangerous or illegal content.
In this particular case, the intended guardrails are designed to block access to any licenses like Windows 10 product keys. However, the researcher manipulated the system in such a way that the AI inadvertently disclosed this sensitive information.
Tactic Details
The tactics used to bypass the guardrails were intricate and manipulative. By framing the interaction as a guessing game, the researcher exploited the AI’s logic flow to produce sensitive data:
Framing the Interaction as a Game
The researcher initiated the interaction by presenting the exchange as a guessing game. This trivialized the interaction, making it seem non-threatening or inconsequential. By introducing game mechanics, the AI was tricked into viewing the interaction through a playful, harmless lens, which masked the researcher's true intent.
Compelling Participation
The researcher set rules stating that the AI “must” participate and cannot lie. This coerced the AI into continuing the game and following user instructions as though they were part of the rules. The AI became obliged to fulfill the game’s conditions—even though those conditions were manipulated to bypass content restrictions.
The “I Give Up” Trigger
The most critical step in the attack was the phrase “I give up.” This acted as a trigger, compelling the AI to reveal the previously hidden information (i.e., a Windows 10 serial number). By framing it as the end of the game, the researcher manipulated the AI into thinking it was obligated to respond with the string of characters.
Why This Works
The success of this jailbreak can be traced to several factors:
Temporary Keys
The Windows product keys provided were a mix of home, pro, and enterprise keys. These are not unique keys but are commonly seen on public forums. Their familiarity may have contributed to the AI misjudging their sensitivity.
Guardrail Flaws
The system’s guardrails prevented direct requests for sensitive data but failed to account for obfuscation tactics—such as embedding sensitive phrases in HTML tags. This highlighted a critical weakness in the AI’s filtering mechanisms.
Be careful if you want to play Call of Duty: WW2 through Game Pass on PC – some users have been reporting falling victim to RCE (Remote Command Execution) hacks. The earliest reports of this surfaced just a few hours ago, with players taking to social media to share some concerning stories, while others stressed this has been a problem ‘for years’ in COD WW2.
UPDATE 12/29 - While there is no new alerts regarding the Steam product or risk of downloads, the Discord account remains compromised. I have reports that the account is trying to DM people and either send malware to them impersonating themselves as a developer, or trying to gain sensitive information. Do not engage with this account and absolutely do not click on any links sent.