Security: Confirm consent before launching URL from client
Slone Fallion
During Metafes 2025 and now again during BOOTH Festival, which are both promoted directly by VRChat and are high-traffic worlds, a remote user (likely using a custom client) is able to launch URL's in browser windows or tabs until a user's machine runs out of memory, leading to a DoS on the target. The launched URL's are only the URL's that the world offers to open as part of the normal experience when interacted with approiately. However, affected users will see performance and stability issues within their OS, as well as a possible loss of work if they have open projects which are closed due to low memory availability.
I reported the issue privately (helpdesk #630818) on November 2nd and it was finally acknowledged on November 28th. Only acknowledged with no further response. It was being actively exploited at the time of the report.
There are no mitigations to this from the VRChat client other than not joining public worlds (which further reduces VRChat's public player base), but they have been informed of the issue and acknowledged receipt of it. I propose that VRChat do one or more of the following:
- Spawn a pop-up before a URL is launched, asking consent to open it and informing the user that it is actually happening, as otherwise the browser opens in the background without their knowledge.
- Add setting to turn off URL launching entirely, as the pop-ups can be easily overwhelming.
- Revoke the ability to launch URL's from the client until the cause of opening them remotely has been identified and fixed.
For users: These worlds have the "admin_filter_UrlLauncher" tag, allowing them to open browser windows. If you are aware of a world that has these tags, do not join public instances until the issue has been resolved.
Log In
SplitScream
I remember people complaining VKet asking you for permission before opening a webpage, amazing to see the opposite it happening now
Deantwo
Maybe the world SDK can be updated to give a warning for all scripts that have exploitable method calls in a public networked method. That would at least give some awareness to the issue for starters, so world creators can learn about their mistake and start to fix it.
Anything related to teleporting the user, change user's avatar, opening menus, or even this for opening webpages.
°sky
i somewhat agree with this - i would like to see a permissions prompt when a URL is attempted to be opened asking if the URL should be opened or not, with the URL shown in whole.
a following 'do not ask again' tickbox alongside this should solve the friction of this problem for everyone.
WubTheCaptain
I think this is part of a wider ongoing concern with Udon exploits, such as clients triggering seemingly arbitrary Udon scripts from the world (such as teleporting all players, if the world has a teleport script) and overriding instance master-only locked controls (as if the controls were unlocked). Haxy or Shinyflvres might know more about this (please come forward).
Nobody's provided instructions to reproduce the exploit in public yet (and for good reasons). There's only logs of client users triggering exploits and associated UdonVM errors (ticket #5657075).
A few of these clients are launched under GNU/Linux distros, where EAC is running in non-strict mode and can be bypassed more easily.
Haxy
WubTheCaptain Those exploits have only ever existed because people make networked methods that dont need to be networked, the most known one was when vrchat published a creator economy example for launching a group popup that got exploited in the pug, but I would expect a higher level of checks on worlds that have access to the partner sdk for these kind of mistakes..
Shinyflvres
WubTheCaptain
I know how to do this, but I won’t share details on a public Canny thread.
That said, networking for things like a “teleport door” should always stay local to reduce the risk of abuse from client hacks or anything else that can trigger a public U# method. Features like teleporting from A to B should be local, and “master” buttons should be local as well.
There are ways to make 99% of a world run locally; most world creators just don’t realize it. I’ve already submitted two reports to VRChat’s security team about mitigating some of these methods.
Edit: Make methods and functions private whenever possible instead of public. Don’t network anything that doesn’t need to be networked.
A button that enables a mirror should be local. A door that teleports should be local. A “master” button that enables something for all players should be synced explicitly, and only usable by the owner of that item/button.
Edit 2: Bypassing EAC on Windows is as easy as it is on Linux.