These backdoors aren’t able to run their code while in Studio anyways - all they can do is drop the injector into ServerScriptService.
That’s why in my one post, I suggested that I create an anti-virus that can delete the tainted object. It’s simple to program, but I don’t have a large enough following to supply every developer.
An antivirus is simple to program
big if true.
Okay, maybe I don’t fully understand the issue but…
Disallow private plugins, or stop them from creating scripts during actual game run-time?
Rather than remove private modules as a whole.
On the topic finally this is being stopped, I had a huge forum post I was going to make on it but that appears pretty redundant now 
There’s no such thing as a “private plugin”. Plugins are open-source, as is all code on Roblox, except for private modules.
What I meant was, disallow private modules in plugins…
You cannot load private modules in plugins - they wouldn’t be private anymore (your computer has to run the Lua code). Also, as someone else said, the plugin maliciously injects code into the game (into StarterPlayerScripts/StarterCharacterScripts/ServerScriptService etc) that takes advantage of private modules.
There’s a lot of dirty tricks that can be done to hide that require(assetId) line. It is definitely not easy to detect that, the best way is to simply remove the attack vector altogether. That’s what this update is doing.
Whilst also removing the features some developers use
How exactly do they “inject private modules”
Hey @Avallex
I appreciate you may not completely understand the kill-chain used by plugins to inject private modules, that’s cool, we’ve all been there.
Private modules are not allowed in plugins already, because that would be impossible to hide the module in (since its on the users computer there’s a ton of ways they could read the module otherwise). What these plugiins have is a malicious piece of code that puts a Script in ServerScriptService (or somewhere else if they’re extra sneaky), this code waits until the game is on a live server (using RunService:IsStudio()) and then makes the require call to a private module. The plugin itself is just payload delivery in a sense.
Hope this helps! 
Could the same thing happen without private modules? Absolutely, but it would be much easier to identify what code has been delivered in the payload since it wouldn’t be able to hide behind a private module, instead relying on obfuscation and etc which with effort can be broken.
Oh, cheers for that.
So why not just stop the plugins from putting scripts in the game during run-time?..
Or am I “still not understanding”
The plugins don’t put the scripts in the game during run time, rather they insert the scripts while the game is in studio so they’re payload gets uploaded with the rest of the legitimate place.
As to why that can’t be stopped, many legitimate plugins insert code as part of their legitimate functionality, not least Rojo
And there is absolutely no other way that roblox could “limit the functionality” of plugins so they can’t do that prior to runtime, or would that remove to many features from plugins.
That would break pretty much all functionality of legitimate plugins, Rojo needs to include your scripts in your Roblox place as you write them on your Filesystem.
I have an idea for how the private module issue could be solved using a “proxy” object of sorts, but I’m still working on it, I’ll post it to the forum at some point
Fair enough, I support the removal of private modules, however, legitimate uses of the security private modules allowed for is gonna cause some issues with the way I develop for people, such as licensing proprietary scripts.
It’d be nice if roblox could allow for limitations on what developers can edit within a game (mainly for groups).
(Never really ran into any problems with plugins with backdoors hence my lack of understanding when it came to them).
I support the removal of private modules because the actual harm caused outweighs the intended benefit vastly, see [1] [2] [3]
The question now is how can we limit who reads scripts without malicious intent, cause that was a nice feature.
Since they are getting rid of private modules, which is one of the only ways to protect my code, are they going to be adding more ways of securing code?
Eyy ya took my advice. Spicy.