I think exploits allow scripts to run with an elevated privilege, allowing them to edit stuff like this.
1 Like
The client can change the RunContext to client… but as with any other local change that change will be well… local, and won’t replicate to the server, so the attacker won’t get anywhere that way 
17 Likes
Elevated execution privilege wouldn’t allow them to bypass network restrictions and replicate non-replicable changes. Even if they could, I’d presume there is no code which listens to RunContext changes in the engine to begin with - only in studio. Changing it at runtime wouldn’t achieve anything.
2 Likes
Allowing Localscripts to run in workspace without needing a player instance is honestly really cool. Great update!
3 Likes
Didn’t say it would allow them to get anywhere. I just said with elevated privileges you can change things that are normally not allowed to be changed.
Will RunContexted scripts run in hidden instances? If so, this could be utilised by malware plugins to hide backdoor or other malicious scripts in games.
See also: Script Injection Vulnerability
6 Likes
This update although is good is gonna make me get confused and take time for me to get used to why there is code running locally in the workspace or other place local scripts don’t normal go. I think there should be some better type of indication that it’s not just a normal local script.
3 Likes
I was referring to the client actually getting the scripts bytecode, which can be decompiled and converted back into normal Luau, allowing the attacker to read my Serverscripts and potentially be able reconstruct my codebase. I would never want anyway for clients to have access to that.
5 Likes
Your best action would be make it so the client never sees the scripts with services like ServerStorage and ServerScriptService. If the client can see the bytecode - which changing the RunContext locally shouldn’t affect since it shouldn’t force the server to give up the bytecode like that - your best bet is to make it so the client never has a chance to see it if it doesn’t need it.
6 Likes
This update negatively impacts my workflow as I am no longer able to search ‘LocalScript’ to get all scripts running on the clients context, may I ask how this makes the developer experience any better than just being able to run LocalScripts in Workspace and ReplicatedStorage, and making ServerScriptService basically useless (as ServerStorage can work for it too)?
Also, there seems to be no icon difference between the server and legacy RunContexts which is misleading as those scripts do have different runtime behaviours (one running in containers while the other one does not)
2 Likes
In the same way as how server scripts parented in non-server containers are still not accessible by exploits, I assume the same applies to RunContext changes also.
The bytecode is simply not replicated to the client.
1 Like
The icons will be receiving a further upgrade in the future to distinguish between scripts running in Legacy mode and scripts using the new RunContext options.
8 Likes
Does that not really then just defeat the whole purpose of the RunContext cuz you would never be running server code somewhere only local code can normally run meaning you would need them not to be in the same area in the end anyways.
Hopefully it should be like what @PysephDEV said or something like this.
2 Likes
This isn’t clear enough, the fact that this is only enabled in Studio is not communicated well enough and will cause issues if it isn’t made more clear.
1 Like
So if I set the script to client, it essentially becomes a LocalScript? If so, doesn’t that defeat the point of having LocalScripts?
Yes, except unlike a LocalScript, it will run anywhere, on all clients that can access the location where the script is located.
5 Likes
That isn’t true they DO have different icons. Client had the icon of a Local Script and Legacy and Server have the icon of a Script. Also Localscripts are not going to be removed (at least not now).
I cover it a bit in my original reply about self-contained free models that have local code. Previously, you needed to copy your code to every player’s PlayerGui in a ScreenGui with ResetOnSpawn set to false (or some equivalent) and copy to StarterPlayerScripts. Now I just need to put it in a container like ReplicatedStorage and I am done. I am sure other reasons exist. My guess is this is meant to deprecate LocalScript long-term and have a generic “Script” as the paradigm.
9 Likes
Could this cause issues where the localscript are parented to a player however, I’m assuming it will run on all clients which is definitely a problem for anyone migrating.
If you read my post, I was stating that server and legacy do not have different icons.