Unequipped tools don’t run code, unless I’m missing something. What reason would you have to keep the scripts of unequipped tools running? Doesn’t make sense to me.
1 Like
I’m not sure what you mean by this, unequipped tools in backpack do run code both scripts and localscripts, and I can think of a lot of reasons:
- Using the Equipped and Unequipped events
- Cooldowns
- Altering the character
I’m sure there are a lot more usecases but these are the few I can come up with now anyway.
5 Likes
Can Roblox not offer a way to cleanse infected places?
- I don’t know how to manually edit a published game.
- I tried the plugin mentioned, but one of my games is too large to be scanned by it.
1 Like
It will scan, just takes time. You can also lower the scan delay chance if you have a decent CPU. (It will increase lag the lower the delay chance gets)
3 Likes
I’m sure I clarified what I meant when I said that. In either case, this answers my use case question. Disabling the creation of Backpack tools, as Dekkonot suggested, would probably be ideal then.
1 Like
wish I would’ve known this technique earlier with the script, I had a malicious plugin once. It’s all good now but one of my games was breached and I had to close it down. 
2 Likes
The button to show hidden services should only show them if you are searching for them or if the service has children. A fix could also be to potentially alert the user when a script is parented from a plugin to one of those services for the first time.
5 Likes
Check all your plugins, and check their authors. If it’s some really reputable name (i.e. Quenty, Crazyman32, etc.), then keep it; else, check their profile. See if they have some kind of developer role in a group or are in the Dev Forum Community group.
Look up the name of the plugins from authors you’re not exactly sure of on the library, especially ones you got off the first few pages of the library. If there’s duplicates, there may be a chance that you got an illegitimate copy that’s a duplicate of the original except with backdoor code injected into it. Remove those plugins and install the originals.
If you want to take a look at the source code yourself, check the Plugins folder, go up a folder on the file tree, then check InstalledPlugins. You can find every plugin you have installed and their source code in .rbxm format. You can import these into Studio to check the source code. It’d be smart to run Chris’s scanner on these or check for any script that looks suspicious and/or contains obfuscated or suspicious code. Uninstall these as well.
I was stuck with some backdoor prompting model purchases for a solid week until I read somewhere here that I should try inspecting plugin code by hand. You probably should to; you’d be surprised by how many times people (myself included) install malicious duplicates of popular plugins.
4 Likes
This vulnerability is now patched. Scripts which were executing only because they were parented to a Backpack in some obscure location will no longer execute. The fix applies to both Studio and live games.
36 Likes
Thank you for the speedy fix. I’ll be sure to update tonight.
Can you mark this post as a solution to the OP?
Done.
3 Likes
Can you offer a way to remove the hidden script in Studio? I can see the malicious script when I export my game to XML, but I don’t know how to remove it from my live game.
The detector plugin they linked can do that for you, or you can just delete it via the XML
This has broken the game Lava Tumble. Backpack objects were used as a kind of organizational unit. This was done long before the folder object became a thing. You should know that this change is not backward compatible. This breaking change could stand to be made more visible.
1 Like
We are adding a setting to see all objects in the Explorer which will enable you to do this.
6 Likes
I’ve been trying to find out why there was zero setting for this. I remember before there being an option to see every service, regardless of being able to even edit or rename it. Hopefully this comes soon, I’ve accidently been using a backdoor plugin for a long time, and I believe studio should just automatically clear all the children in the still invisible CSGService service. Knowing that it’s already patched from using scripts on backpacks, the file is still there and useless.
We considered automatically removing unexpected children from CSGDictionaryService but decided against it because it might not have been the only container affected and once the patch went out, those instances do no harm.
Thank you for the heads up! I’ve recently been using plugins; luckily I never come across the issue, appreciate you looking into the vulnerability and making us all aware.
2 Likes