Website

Please provide a description of your bug or issue with the VRChat website.
Each post should be an individual issue!
Help Desk article "I can't see anyone's avatars" mistakenly states "users running the Mobile app cannot show (or wear) [Very Poor avatars]"
The following help desk article URL has an incorrect/outdated statement: https://help.vrchat.com/hc/en-us/articles/360062658133-I-can-t-see-anyone-s-avatars > Very Poor avatars are always performance blocked on VRChat Mobile. At this time, users running the Mobile app cannot show (or wear) them. This help desk article was last updated more than a year ago, and hasn't been updated since. Formerly it used to be that Very Poor avatars were blocked on mobile completely back in 2024 , but this restriction has been since relaxed. The statement is contrary to actual behavior in-app today (and in the past for a while now) and documented behavior in VRChat Creator documentation, which states Very Poor mobile avatars can be forcefully shown on mobile: https://creators.vrchat.com/avatars/avatar-performance-ranking-system/#mobile-default-performance-rank-blocking > For example, if a mobile avatar exceeds 20,000 triangles, it's "Very Poor" and users can't see it in VRChat. However, users can forcefully show "Very Poor" avatars by selecting the user and clicking "Show Avatar". Very Poor mobile avatars can also be worn. Only a few (3? 5?) Very Poor avatars will be shown at a time on mobile platforms currently. Suggested change: Update the help desk article to remove mentions of wearing Very Poor on mobile, update the article to mention the current restrictions on viewing [X] number of Very Poor avatars on mobile, and include the warning from VRChat Creator documentation about VRChat possibly removing "Very Poor" mobile avatars in the future.
4
·
Bug Report
·
complete
Missing permissions check on group public instance creation
There exists a method in which anybody can launch group public instances for any group, even if they do not belong to that group. This was confirmed to be the case with the permission turned off for the "Everyone" role. This does not require any tooling, external programs, direct access to the API, or changes to the VRChat client. This includes groups that are closed and invite-only. The only exception to this is if the member is already banned from the group. What does this actually mean for you? Malicious instances could be opened in opposition to a group's values. For example, a group supporting those who have PTSD from war would not want a group public instance opened in a warzone map. Groups that only open moderated instances by policy could have public unmoderated instances opened on their behalf without approval. Groups representing staff or brand ambassadors could have public instances opened on their behalf without approval. I initially informed VRChat of this on 09/11/2024 via the App/Website Security Exploit Report form under ticket #441683. Per the form: "We do not guarantee a response other than the automated "ticket received" notification." And that's all I've gotten. Unfortunately, this means that I have no way of knowing if VRChat is still actively aware of this exploit, if they plan to take ownership, or when a fix is expected. Precautions you can take as group owners: Monitor your instance lists. Also monitor your audit logs in Settings -> Logs via the group page on the VRChat website. I have intentionally left out the method, but it is trivial and only a matter of time before others figure it out, if they haven't already. Staff can check the ticket provided for the method.
15
·
Bug Report
·
complete
API may (incorrectly) respond HTTP/2 200 (200 OK) to the client when updating an invite message fails silently in the API server backend
There's an isolated issue with invm_95b3441b-308a-4083-bd26-e3b57dc61cf3 on my account usr_6fa4abc5-9952-4a0a-97de-b3598fbf6a5c which prevents one specific invite message (message slot 6, "Let's party!") from being updated, due to the June 8, 2025 API instability/outage incident . (Full details are available in the support ticket: #591843) ## Expected behavior on message slot 6 update (success scenario) The invite message is updated, canBeUpdated is set to "false", updatedAt date is updated, remainingCooldownMinutes is set to 60, and the API responds 200 OK. In the VRChat client, the message "Updated message text" should appear, and the message is expected to be updated. ## Alternative expected behavior on message slot 6 update (failure scenario) The API should respond with a HTTP response code 500 Internal Server error or similar, or returns an error message in the body JSON response. I don't expect the API to respond 200 OK in this scenario. ## Actual behavior on message slot 6 update (failure scenario) The invite message is not updated, canBeUpdated remains "true", updatedAt date is not updated (remains at old value "2025-06-08T01:12:29.649Z"), remainingCoolDownMinutes stays at its previous value 0, and the API responds 200 OK. In the VRChat client, the message "Updated message text" appears, and the message in the UI resets to the previous message from 2025-06-08T01:12:29.649Z (the old message received from the API). (Video: https://files.catbox.moe/co6xpw.mp4 ) --- Unofficial API reference: https://vrchat.community/openapi/get-invite-messages https://vrchat.community/openapi/update-invite-message https://vrchat.community/openapi/get-invite-message API requests and responses are attached as text files (with small redactions to personal data relating to login cookies and User-Agent identity for the public; unredacted versions are in the support ticket). Message slot 5 update ( 4 - Update message 5.txt ) is included for a demonstration of the expected PUT behavior. Message slot 6 update ( 5 - Update message 6.txt ) is included for a demonstration of the unexpected PUT behavior. 7 - Get Invite Message 6.txt contains the singular GET response from the API for message slot 6.
1
·
Bug Report
·
complete
Load More