Microsoft is Actively Investigating PrintNightmare Vulnerability

Posted on July 2, 2021 by Paul Thurrott in Windows with 33 Comments

Microsoft last night acknowledged that a newly discovered vulnerability in “all versions of Windows” is being actively exploited. It’s called PrintNightmare, and it allows malicious actors to execute code remotely on Windows-based PCs. All Windows-based PCs.

“The code that contains the vulnerability is in all versions of Windows,” Microsoft says. “We are still investigating whether all versions are exploitable.”

In an interesting twist, the newly-discovered vulnerability is “similar but distinct from” a previous printing-related vulnerability that Microsoft patched earlier in June. The new vulnerability uses a different attack vector and was not discovered because of the previous vulnerability, Microsoft says, addressing an obvious question. “The vulnerability existed before the June 2021 security update” that fixed the previous vulnerability, it notes.

The new attack affects the Windows Print Spooler, which can be made to improperly perform privileged file operations. When successfully exploited, the attacker can run arbitrary code on the PC using system-level privileges. “An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights,” Microsoft adds.

To overcome this problem now, users and organizations should install the security updates that Microsoft released on June 8, 2021. And then read the FAQ and implement the workarounds that Microsoft provides here. The most obvious option, for now, is to stop and then disable the Print Spooler service.

Tagged with

Join the discussion!


Don't have a login but want to join the conversation? Become a Thurrott Premium or Basic User to participate

Comments (33)

33 responses to “Microsoft is Actively Investigating PrintNightmare Vulnerability”

  1. wright_is

    They key one is to disable the print spooler on all domain controllers (you shouldn't be printing from there or using it as a print server anyway!) and from any other servers that don't need direct printing.

    Disabling it on clients is a little more difficult. But as long as the PC or server isn't directly connected to the network, you should be okay.

    If you are surfing the net and somehow download a trojan or virus that can leverage this, then you have a problem. But it requires local access to the machine and an authenticated user - i.e. the malware has to run locally, this isn't a drive-by attack from the Internet. Once on a PC in the local domain, it could probably spring from machine to machine using the exploit, but it needs a signed in user to start its attack - or it needs a malicious user in your network.

    • waethorn

      It’s not hard to get an authenticated user to run something for you. If it were, ransomware wouldn’t be the bajillion dollar business that it is.

  2. wright_is

    So, we've set a group policy to block remote printing on any PC or server at work. I've done the same at home - all of our printers are network enabled and are their own print servers, so the PCs and servers only need to do local printing to the network printers, they con't need to manage jobs for other PCs.

  3. red.radar

    Would Windows 11 and it’s TPM requirements have protected users from this attack?

    • ivarh

      Seriously doubt this. Having a secure boot chain does not help if the signed OS component/application has flaws in it that allows escalation of privilege. This alone or combined with an application flaw that allows for remote code execution will make bob the hacker's uncle every time. IOS has had secure boot from day 1 and privilege escalation bugs allow for jailbreaking up until this day (As old bugs get discovered and patched new ones are constantly found).

  4. chrishilton1

    Also disable SMB v1.0, full of vulnerabilities which allow ransomware to propagate even on fully patched systems

  5. d_vickery

    Hmm, saw somewhere that this was mitigated on a domain by removing the Authenticated Users group from one of the legacy NT groups that aren't used any more, but can't find the tweet now.

    • wright_is

      That is correct. Why it is still standard in 2021 to add the pre-Windows 2000 group to a modern DC is a bigger question. I would guess 99.99% of all companies no longer require it.

  6. bluvg

    And now the msrc site is apparently down:

    "The servers are down for maintenance right now. Please save your work and try again later."

  7. Patrick3D

    So, you actually have to have access to the physical machine? Move along, nothing to see.

    • wright_is

      No, they an authenticated user on the network must be able to see the server or other PCs. Once malware gets onto one PC on the network, it can use this method to move to other PCs on the network, as long as the account has access to the PC - domain account or an identically named local account with the same password on another PC.

    • bluvg

      It's a remote code execution vulnerability, according to the linked post. "An attack must involve an authenticated user calling RpcAddPrinterDriverEx()", so you may be ok if you or your users (if applicable) wouldn't be tricked into doing that.

      • ivarh

        Depending on where the remote code execution sits you don't need to trick users into executing anything. All you have to do is have network access to the machine. If you don't have access to the machine over the net all you need to get the machine to access the code and trigger the bug that makes the machine execute it. There have been browser bugs that allow remote execution of code by just accessing a picture or an HTML file.

        Living under the misconception that you actively have to access something to get hacked is a misconception that can bite you hard in the proverbial behind.

        • bluvg

          That is a great point for anyone unaware how these things are triggered--not necessarily by deliberate action (and if you're already compromised, this is just another exploit that can be leveraged for taking over your domain).

          I don't think any drive-bys have been reported yet? That would make this ultra-ugly.

  8. ebraiter

    Hmmm. Maybe disable the print spooler should be by default on servers and then just enable it when setting up a print server.

  9. crunchyfrog

    Does this attack vector require a print job to be executed for the exploit to engage itself?

  10. lwetzel

    Would this affect shared printers on home peer networks either wifi, ethernet, or usb connected?

    • wright_is

      I just read the latest update on, turning off the print spooler stops the pc acting as a print server, but it can still print itself.

      • huntly

        Microsoft's announcement (as linked) says that disabling the spooler service (Option 1) stops local and remote printing. But setting the group policy to prevent client connections (Option 2) stops remote printing and still allows local printing. So I've done that.

    • wright_is

      It doesn't affect printers. It affects the print spooler service in Windows. Any Windows PC that prints is affected, or rather any PC or server that has the print spooler service turned on, so that its users can print, is affected.

      • lwetzel

        When I set the printer up it asked "spool print document so program finishes printing faster" or "Print directly to the printer".

        These choices are not affected?

        • wright_is

          From what I read, local printing is not affected, it should just be the pc acting as a print server for other pcs that is affected, but I am not currently at my pc to test it.

  11. bluvg

    This was patched today.

Leave a Reply