I have a game made with Unity published on the Google Play platform. Some time ago, I received an email warning about CVE-2025-59489. Following Unity’s official upgrade recommendations, I have already upgraded the game development engine to 2022.3.62f2 and rebuilt a new version that was published to all tracks on Google Play. After waiting for some time following the release, the email feedback indicates that the issue still persists. How can this problem be resolved?
I also encountered the same problem~~!!!
The application built on 2022.3.62f2 , is not recognized by Google Play.
In that case, will Google modify this detection rule?
Hi folks, can you DM me your bundle ids? I will reach out to Google and inquire what’s going on there.
Another thing to double check - did you patch every active application track (including closed or open testing)? Google will consider the application vulnerable if any of the tracks are unpatched.
We are remediating CVE-2025-59489 for our Android game.
Environment & Actions Taken
- We have applied the official runtime patch diff: 2022.3.62f1.diff and verified the fix on test builds.
- ABI: arm64-v8a (sometimes also armeabi-v7a).
- Runtime validation: Injecting a fake -xrsdk-pre-init-library via Unity intent extra does not trigger any attempt to load a forged .so, indicating that the vulnerable argument path is blocked in the Editor-patched build.
- Static scan observation: In the Editor-patched APK, libunity.so still contains the literal xrsdk-pre-init-library and no 8rsdk… markers. When we run the Unity Application Patcher, it rewrites the relevant strings in both libunity.so and boot.config to 8rsdk-pre-init-library and re-signs the APK, as described in Unity’s remediation guide.
Observation on Version Fingerprint
After applying 2022.3.62f1.diff, the APK’s internal fingerprint still parses as Unity 2022.3.60f1 (from strings in globalgamemanagers, unity_builtin_extra, etc.).
Questions
- Application Patcher Behavior: On Android, even if an Editor-patched build has already blocked the vulnerable path, does the Application Patcher always rewrite xrsdk… to 8rsdk… by design (i.e., never become a no-op)?
- Official Android Compliance Verification: What is Unity’s official compliance acceptance checklist for verifying Android builds remediated for CVE-2025-59489?
- Editor Patch Sufficiency: Is rebuilding with the Editor patch alone (where the vulnerable path is blocked) considered sufficient, even if xrsdk… literals remain in the binary?
- App Store Scanner Expectations: To satisfy app store static scanners, is it expected that 8rsdk… markers appear in libunity.so / boot.config (i.e., the result of running the Application Patcher)?
- Concise Verification Guide: Can Unity provide a short “Android Verification Steps” checklist—for example:
- 8rsdk… must be present,
- xrsdk… must not appear,
- handling of 32-bit Mono overrideMonoSearchPath, etc.—so that developers and app store reviewers can align on a consistent reference?
Is the patching process by Editor not mature enough to meet Google’s requirements for listing? Can the Editor patch be further revised to a new version?
That is expected due to the way that it doesn’t try to detect whether the application is actually vulnerable (which it would need to run the application in order to figure out). So if it finds that string, it replaces it regardless of the version the app was built with. This is okay because the string replacement does not have any other side effects.
We don’t have an official checklist. We’ve been telling people to use Unity Application Patcher to verify whether the application is patched. Internally when testing patched builds and the patcher, we do try to exploit the vulnerability using the command line arguments mentioned in the developer remediation guide.
Yes, but it is best practice to bump the version number on your side so there’s no confusion whether your build was patched or not. We couldn’t include that part in the diff files because everyone has their own version number.
It really depends on the store. Given you talked about Android, I will inquire with Google to see if they can share it.
It should be - we were able to submit test applications from all patched versions of the editors we released.
also upgraded 2022.3.62f2 and close all the test channel in google play . still has the warinig
Same here, just did a recent release of update from 2022.3.62f2 and still has the warning. Will come back here if it will disappear after couple of hours.
[Update]: After around 2 days, the policy warning is gone.
I’ve been waiting for several days now and the warning still hasn’t disappeared. I’ve checked both libunity.so and the data files - there are no problems with either.
We also encountered the same problem~~!!!
It showed question version was 2.6.1 and 2.6.2,but we built new version 2.6.3 and 2.6.4 with unity 2022.3.62f2 and inactived 2.6.1 and 2.6.2.Warning was still there,question version was 2.6.1 and 2.6.2.
Hello, I have built the app with Unity 2022.3.62f2 and 2022.3.63f2 which have the security issue patched, got mail from google a few days ago for 3 of my apps with the device and network abuse policy warning, when I try to update the app I am again being flagged for the same. Requesting your guidance regarding the same.
Hello, did you remove all the other tracks (like testing) from your app?