Unencrypted world bundles still served alongside security variants
needs more information
ぽんぽこぽん
I'd like to report what appears to be a gap in the asset bundle encryption introduced last year.
The encrypted bundles are served as security variants, but the original unencrypted bundle still appears to be available from the plain file URL for the same asset. Any authenticated account can retrieve it — no modified client, no cache extraction, no EAC bypass involved. The encryption is not being defeated; the unencrypted copy is simply still reachable.
Two aggravating factors:
Older asset versions remain retrievable by version number, so content from before an update is still exposed even after the author replaces it.
Because this only requires a logged-in session, it is trivially automatable and userscripts doing exactly this are circulating publicly, including step-by-step instructions on ripping forums.
From a creator's perspective there is no mitigation available. Nothing done inside the world — obfuscation, splitting assets, runtime checks — addresses a bundle being downloaded whole from your CDN.
I'd like to know whether serving the non-variant bundle to non-owners is intentional, and if not, whether restricting it (and older versions) to the uploading account is being considered.
Log In
_
_tau_
updated the status to
needs more information
You can report security issues via our report form at https://vrch.at/support.
In this case, I don't see anything against our security model in your report. World data is only encrypted locally in your cache, the served files are always unencrypted. Avatars require a client session to download, worlds do not.
If there is something beyond that, please report it on the form I linked above.
ぽんぽこぽん
_tau_
Understood — thank you for the clarification. I had assumed the encryption applied to the served files rather than the local cache only, and that the security variant existed for worlds in the same way it does for avatars. That was my mistake, and I don't have anything further that falls outside your security model.
The clarification is useful on its own, though, and I'd like to raise the consequence as a feature request rather than a security report.
Since world bundles are served unencrypted and without requiring a client session, any string compiled into an Udon program should be treated as public. That includes the password fields in the access-control assets that are widely used today — a number of which are sold and distributed on the assumption that they provide meaningful gating.
I don't think creators generally understand this. Two things would help:
Documentation on creators.vrchat.com stating plainly that world assets are publicly retrievable and that secrets must not be embedded in Udon.
A supported way to verify a secret server-side, so gating doesn't require shipping the secret to the client at all.
I've written up the second as a separate feature request: https://feedback.vrchat.com/feature-requests/p/server-side-access-verification-so-worlds-dont-have-to-embed-secrets
Thanks again for taking the time to explain the model.