Unity Platform Protection: Developer Remediation Guide

Overview

A critical security vulnerability has been identified affecting games and applications built with Unity 2017.1 and later for Android, Windows, and macOS. This vulnerability may allow malicious actors with local access to execute arbitrary code within your application’s context, potentially leading to data exposure or privilege escalation.

This vulnerability originates from command-line arguments that allow Unity applications to load and execute arbitrary code. The impact of this vulnerability varies across host platforms. To understand how the vulnerability affects your target platforms, refer to Platform-specific technical notes.

Important: If your project was built with any Unity version from 2017 up to today’s patched releases, it may be affected. All developers with affected projects must take action.

Remediation options

A security vulnerability has been identified affecting games and applications built with Unity 2017.1 and later for Android, Windows, macOS, and Linux. There is no evidence of any exploitation of the vulnerability, nor has there been any impact on users or customers. This vulnerability originates from command-line arguments that allow Unity applications to load and execute native and managed extensions. To understand how the vulnerability could affect your target platforms, refer to Platform-specific technical notes.

Important: If your project was built with any Unity version from 2017 up to today’s patched releases, it might be affected. All developers with affected projects must take action.

1. Rebuild with a patched Unity Editor (Recommended)

Patched releases of each affected Unity Editor version are available to download. You can download a patched Unity Editor, then rebuild your application.

To rebuild your application with a patched Unity Editor version:

1. Download the latest release of the Unity Editor that matches the Unity version your application was built with (e.g. Unity 6.1, Unity 2022.2, etc):
   1. Unity Hub
   2. Unity Download Archive
2. Open your project in the updated Editor.
3. Rebuild and retest your application.
4. Republish to your distribution channels.

2. Patch built applications

If you cannot rebuild from source (or would like to deploy a hotfix while rebuilding your app), use the Unity Application Patcher to update your existing Android, Windows, or macOS builds.

To use the Unity Application Patcher:

1. Download the Unity Application Patcher: Get the Tool
2. Review the license agreement, usage guide and advanced options. Refer to the Patcher Documentation for more information.
3. Run the patcher tool on your existing build (requires an internet connection to patch Windows or macOS builds).
4. Test your application post-patching to ensure functionality.
5. Republish to your distribution channels.

To understand how the Unity Application Patcher works for different platforms, refer to Platform-specific technical notes.

Notes:

• The patcher is not compatible with builds protected by some tamper-proofing or anti-cheat solutions.
• Always verify the integrity and functionality of your application after patching.
• The Unity Application Patcher tool was developed with Unity 6.0 and so the corresponding Windows or macOS system requirements apply to running the tool.

Platform-specific technical notes

The following sections outline how the security vulnerability affects Android, Windows, and macOS applications, and how the Unity Application Patcher works on each platform.

Some beta and patch releases in the release stream may be affected. See the full list of affected versions if you shipped on a non-final release.

Note: Additional OS-level measures have been deployed by Google, Meta, and Microsoft to further secure their platforms. However, you must still patch or rebuild your Unity applications to be fully secure.

Android

Note: There is no evidence of any exploitation of the vulnerability, nor has there been any impact on users or customers.

On Android, you need to take action if your Unity app was built with Unity 2019.1 or later, regardless of any special permissions or settings.

Additionally, if your app was built with Unity 2017 or later and uses the Mono runtime (32-bit only), it may be vulnerable. See the full list of affected versions if you shipped on a non-final release.

• On Android, applications are generally isolated from one another, and code injection is not typically possible between apps without exploiting a vulnerability or misconfiguration.
• The vulnerability could allow other apps on the device to launch your Unity app and inject a malicious native library via specially crafted intents and the xrsdk-pre-init-library command-line argument, or the overrideMonoSearchPath for 32-bit apps built with mono.
• Android apps are not vulnerable to the datafolder or monoProfiler command-line arguments.

Breaking changes on Android

There are no breaking changes associated with addressing this vulnerability on Android.

Unity Application Patcher for Android

On Android, the Unity Application Patcher unpacks your APK or AAB and locally modifies libunity.so and boot.config to block the vulnerable code path, then repackages and re-signs your APK or AAB.

The Unity Application Patcher changes the xrsdk-pre-init-library string to 8rsdk-pre-init-library in both libunity.so and boot.config to block the vulnerable code path. This prevents it being used as a command-line argument (or an intent extra on android) because of the way the arguments are parsed. It can still function as a boot.config setting, so any usage within the boot.config file is also patched.

The Unity Application Patcher also disables the overrideMonoSearchPath argument for 32-bit builds with mono by replacing the first character of the overrideMonoSearchPath string in the libunity.so with an invalid unicode character 0xC0.

Windows

Note: There is no evidence of any exploitation of the vulnerability, nor has there been any impact on users or customers.

On desktop platforms like Windows, there are various ways to inject code into a running process. However, these methods are usually limited by system privilege levels and security boundaries. In most cases, you can only inject code into processes you started yourself, and doing so doesn’t grant you any additional capabilities beyond what your own process already has.

However, in this situation, your Unity app could be vulnerable to privilege escalation if it is registered as a custom URL schema handler. This registration could be performed by your application (for example, to support deep linking or launching from a browser), or by other applications (such as third party game launchers or store fronts).

As there is no way to prevent - or even discover - that a third party application has registered your application as a schema handler, Unity recommends you patch all Unity Windows applications as a precaution.

• With a registered URL scheme, an attacker running code at a lower integrity level (such as from a sandboxed or less-privileged process) could exploit this Unity vulnerability to launch your app and inject a DLL, causing your application to run attacker-supplied code with higher privileges than would otherwise be possible.
• Injection could occur via any of the vulnerable command-line arguments outlined above.

Breaking changes on Windows

• If your app uses the -datafolder command-line argument to relocate the datafolder, you will now need to pass the custom data folder as the second argument to the UnityMain function instead:
  • int UnityMain(HINSTANCE hInst, LPCWSTR customDataFolder, LPWSTR szCmdLine, int nCmdShow)
• If your app used xrsdk-pre-init-library as a command-line argument to switch between XR providers, Unity recommends switching to using OpenXR or providing separate builds.
• overrideMonoSearchPath is removed, it is suggested to either build separate apps, or include all scripts into the same build.

Unity Application Patcher for Windows

For Windows builds, the Unity Application Patcher tool downloads a patched UnityPlayer.dll (or .exe for applications built with Unity 2017.1) appropriate for your Unity version and swaps it in place of the vulnerable file in your built application.

Note: The Unity Application Patcher fetches pre‑patched binaries from Unity’s servers, ensuring they have been tested and verified before you receive them.

The UnityPlayer.dll was modified to skip the vulnerable command-line parameters.

xrsdk-pre-init-library still functions as a boot.config setting.

Important: If your app uses the -datafolder command-line argument to relocate the datafolder (introduced in Unity 2022.2), you need to adopt a new pattern outlined in the Breaking changes on Windows section.

macOS

Note: There is no evidence of any exploitation of the vulnerability, nor has there been any impact on users or customers.

On macOS, many privileges are managed on a per-application basis, such as access to the camera or to user document folders. macOS implements multiple mechanisms to prevent abuse of these privileges, including the Hardened Runtime feature. By default, apps built with the Hardened Runtime are blocked from loading any unsigned or differently-signed code. Use of the Hardened Runtime is a requirement for notarization and Mac App Store distribution.

However if your application was built with Unity 2017.1 or later (with Mono scripting backend) or Unity 2019.1 or later (with any scripting backend), is built with the Hardened Runtime, and has certain runtime exceptions enabled that weaken code injection protections, you have to take action. The exceptions that could make your app vulnerable are:

• Disable Library Validation (com.apple.security.cs.disable-library-validation) — allows loading of unsigned or differently signed plug-ins or frameworks. This can permit malicious native .dylib files to be loaded when using the xrsdk-pre-init-library or datafolder arguments.
• Allow execution of JIT-compiled code (com.apple.security.cs.allow-jit) — can enable execution of malicious managed code if the datafolder or overrideMonoSearchPath arguments are exploited. Note that granting this exception is a requirement for all use of the Mono scripting backend.
• Allow unsigned executable memory (com.apple.security.cs.allow-unsigned-executable-memory) — also enables malicious managed code execution if the datafolder argument is exploited.

The Hardened Runtime typically blocks common code injection methods, protecting applications from such attacks. In affected Unity apps with any of the above exceptions enabled, attackers may be able to inject code via the xrsdk-pre-init-library,datafolder or overrideMonoSearchPath command-line arguments.

This may allow an attacker to inject a malicious .dylib or managed assembly within your process. It cannot grant access to permissions the app itself does not have.

Breaking changes on macOS

• If your app uses the -datafolder command-line argument to relocate the datafolder, we recommend using symlinks instead.
• overrideMonoSearchPath is removed, it is suggested to either build separate apps, or include all scripts into the same build.

Unity Application Patcher for macOS

For macOS projects, the Unity Application Patcher tool downloads a patched UnityPlayer.dylib appropriate for your Unity version and swaps it in place of the vulnerable file in your built application. The boot.config variable xrsdk-pre-init-library was changed to 8rsdk-pre-init-library. This prevents it being used as a command-line argument because of the way the arguments are parsed. It can still function as a boot.config setting, so we also patch any usage within the boot.config.

Important: If your app uses the -datafolder command-line argument to relocate the datafolder (introduced in Unity 2023.2 for macOS), you will need to adopt a new pattern outlined in the breaking changes on macOS section.

The patcher re‑signs your .app using an ad‑hoc signature so it can run locally. If your application was previously signed with a Developer ID certificate and notarized by Apple, the patch process will invalidate that notarization. Follow the Apple recommendations for distributing software to release your application.

Linux

Note: There is no evidence of any exploitation of the vulnerability, nor has there been any impact on users or customers.

On Linux, the vulnerable Unity command‑line arguments function similarly to the LD_PRELOAD mechanism. Under the standard Linux security model, these arguments do not cross privilege boundaries and therefore do not introduce additional risk relative to what is possible with LD_PRELOAD.

In environments such as AppArmor, bubblewrap, Firejail, or SELinux, if a restricted process can launch a Unity application outside its confinement, arbitrary code execution is already possible and this vulnerability does not add further risk. In certain SELinux or AppArmor configurations, common injection methods (LD_PRELOAD, ptrace) may be blocked while still allowing Unity to be launched with arbitrary arguments. In this case, the vulnerable arguments could bypass policy restrictions and become a viable exploit path.

Mitigation

Due to the lower risk profile, Unity has not released a Linux version of the Unity Application Patcher. If desired, particularly in environments with strict access control policies, rebuild your Linux application with a patched Unity Editor to remove the vulnerable code paths.

Other platforms (iOS, consoles, etc.)

For all other Unity-supported platforms including iOS, there have been no findings to suggest that the vulnerability is exploitable. For maximum security, Unity recommends that you rebuild your app with the latest patched Unity Editor.

Resources

• Download Patched Unity Editors
• Download the Unity Application Patcher
• Unity Security Advisory
• CVE Details
• Unity Support Services

Your action is required to secure your applications and protect your users. For any questions or assistance, please contact Unity Support.