The Print Spooler Is Still Running: PrintNightmare, Point and Print, and the RCE You Forgot to Turn Off

Ask a room of Windows admins whether they have printers on their domain controllers and you will get a laugh. Ask them whether the Print Spooler service is running on those same domain controllers, and the laughter stops. The service (spoolsv.exe, service name Spooler) is enabled by default on virtually every Windows install — servers, workstations, VMs, jump boxes — regardless of whether a printer will ever be attached. It has been one of the most productive attack surfaces on Windows for years, and it is still running on machines it has no business running on.

Why a print service became a remote-code-execution problem

The Spooler is not a dumb queue. It is a privileged service running as SYSTEM that loads printer driver code, exposes RPC interfaces (MS-RPRN, MS-PAR) reachable over the network, and can be told to fetch and install drivers from a remote path. That combination — SYSTEM privileges plus attacker-influenced driver loading — is exactly the recipe for both privilege escalation and remote code execution.

PrintNightmare is the umbrella name for a cluster of these flaws. The most notorious, CVE-2021-34527 (with its sibling CVE-2021-1675), let an authenticated user coerce the Spooler into loading a malicious driver DLL and running it as SYSTEM — locally for privilege escalation, or remotely against a machine whose Spooler was reachable. It was not an isolated bug: the print subsystem has produced a steady drip of spooler and driver CVEs before and since. The pattern matters more than any single CVE number, because the pattern keeps recurring.

The dangerous Spooler is the one nobody remembers is running: on a domain controller, a database server, a build agent, a kiosk — anywhere that will never print, yet still answers print RPC as SYSTEM.

The Point and Print trap

Even fully patched, the Spooler can be left dangerously permissive by Point and Print — the convenience feature that lets a client automatically download and install a printer driver from a print server. When Point and Print is configured to install drivers without an administrator prompt, a standard user (or an attacker who has a foothold as one) can point the machine at a hostile print server and have driver code installed and executed with elevated rights. Two registry values decide how much this hurts:

Get-ItemProperty "HKLM:\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint" `
  -Name NoWarningNoElevationOnInstall, UpdatePromptSettings -ErrorAction SilentlyContinue

NoWarningNoElevationOnInstall = 1 is the setting you do not want: it suppresses the elevation prompt entirely. The hardened state is to require administrator approval for both new installs and driver updates, and to restrict which servers a machine will accept drivers from.

The hardening decision tree

Work through this in order. The first branch removes the entire attack class for most machines; the rest are for the minority that genuinely need to print.

1. If the machine never prints, disable the Spooler outright

This is the single highest-leverage control and it is Microsoft's own guidance for domain controllers and most servers. No service, no attack surface:

Stop-Service -Name Spooler -Force
Set-Service -Name Spooler -StartupType Disabled

Verify it stays down after a reboot — a disabled service that a later "fix" re-enables is worse than one you never touched, because you have stopped watching it.

2. If it must run, keep it from listening for remote print jobs

A workstation that prints to a local or nearby printer rarely needs to accept inbound remote print connections. The RegisterSpoolerRemoteRpcEndPoint policy stops the Spooler from acting as a network print server while still letting the machine print outbound:

Set-ItemProperty "HKLM:\Software\Policies\Microsoft\Windows NT\Printers" `
  -Name RegisterSpoolerRemoteRpcEndPoint -Value 2

3. Lock down Point and Print and driver installation

Require elevation for driver installs and updates, and restrict driver installation to administrators via the "Limits print driver installation to Administrators" policy (RestrictDriverInstallationToAdministrators = 1). Combined, these turn the Point and Print convenience path back into an administrative decision instead of a user-triggered code-execution primitive.

4. Patch, and keep patching

Disabling and restricting are defense in depth, not a substitute for updates. The spooler CVE stream has not stopped; a machine that must run the service must also stay current on cumulative updates. Treat "Spooler running" and "patch level" as linked facts about the same host.

Auditing it once is easy — proving it stayed off is the hard part

Any competent admin can disable a service on a Tuesday. The failure mode is drift: a printer gets added six months later and someone re-enables the Spooler "just for now," a GPO gets loosened, a golden image ships with Point and Print wide open, or a new server joins with defaults nobody reviewed. Hardening that is not re-verified quietly rots, and the Spooler is a classic example because re-enabling it feels harmless.

On a single machine you do not need a subscription or a fleet to stay honest. WinSentinel is free and runs at full power on one box — all 33 modules, no limits — so one command tells you whether the Spooler is running, whether it accepts remote print RPC, how Point and Print is configured, and how that rolls into your overall posture score:

winsentinel audit
winsentinel score

The service-posture and configuration checks flag a listening Spooler, a permissive NoWarningNoElevationOnInstall, and missing driver-installation restrictions the same way a reviewer would — but every run, not once. Re-run after any change and the score moves the moment you regress.

When one machine becomes fifty

Across an org the math changes. Manually re-checking the Spooler on 50 or 100 endpoints is where good intentions die, and a single re-enabled spooler on a domain controller is all an attacker needs to escalate. That continuous, centralized assurance is what WinSentinel Pro exists for: lightweight agents report each machine's posture to a central node, so a host that re-enables the Spooler or loosens Point and Print surfaces as a drift alert instead of an incident. Pro rolls the same per-machine findings up into fleet-wide compliance evidence — the depth of each machine's audit is identical to the free single-machine scan; Pro adds the orchestration, history, and alerting you need to trust dozens of machines at once.

The takeaway

PrintNightmare was never really about one CVE — it was about a privileged, network-reachable service running everywhere by default, loading code it should not, long after anyone needed it to print. The fix is boring and the regressions are silent: turn the Spooler off where it is not needed, stop it listening where it is, require elevation for drivers, and keep patching. Then make the check continuous — free on the machine in front of you, fleet-wide with Pro when one machine becomes many. The scary part of the Print Spooler is not the exploit. It is that it is still running, and nobody is looking.