I spend so much of my day talking up PowerShell that, at times, I forget that it is man-made and susceptible to the same exploits any other software is. I am facing that reality today, as there is a remote code execution vulnerability impacting PowerShell 7.
I focus on PowerShell because that is what I am using daily. Since this vulnerability is in .NET 5.0, .NET core 3.1, and .NET core 2.1, there are other things you might want to check out. Almost everything using System.Text.Encodings.Web needs to be updated ASAP. I say “almost everything” because while Visual Studio has this package, it is not vulnerable to this exploit.
If you have PowerShell 7.0 or 7.1 anywhere in your environment, you will want to upgrade those to 7.0.6 and 7.1.3. PDQ Inventory can help you track which machines need to be updated. Create a dynamic collection with the following filters and you should have every machine that needs to be patched:
PDQ Deploy offers a pre-built package that you can deploy to that collection. Please ignore that it says “core.” It is actually PowerShell 7 that you will be deploying.
Before implementation, contact your developers to see if any of your internal apps are using the following versions of this package:
|Affected versions||Patched versions|
|>= 4.0.0, < 4.5.1||4.5.1|
|>= 4.6.0, < 4.7.2||4.7.2|
They will want to check and update all internal software that needs it so you can, once again, automate your job with the peace of mind that your environment is safe and secure.
Jordan had spent his life wondering why tasks he didn’t like to do had no options to complete themselves. Eventually he had to make that happen on his own. It turned out that he enjoyed making tasks complete themselves, and PDQ thought that is something he should talk about on the internet while drinking most Thursdays on the PDQ webcast.