Here are two actionable defensive playbooks for environments that cannot patch immediately.
Priority 1: CVE-2026-41089 — Netlogon RCE
The reality: This is currently being exploited in the wild. CVSS 9.8, unauthenticated, over UDP — no user interaction needed. Microsoft patched it May 12, but most enterprises can't patch all DCs simultaneously. Here's your 48-hour plan.
Network-Layer Mitigations (IMMEDIATE — first 4 hours)
| Control |
Implementation |
Notes |
| Perimeter UDP 389 block |
Firewall rule at edge |
Netlogon uses CLDAP (UDP 389). Block UDP 389 inbound from internet. Most orgs shouldn't have CLDAP exposed anyway — if you do, that's misconfiguration. |
| Inter-segment UDP 389 restrict |
East-west firewall rules |
Restrict UDP 389 between VLANs. Only DC-to-DC replication should need it. Workstations and member servers should not be sourcing CLDAP requests to DCs. |
| Port-level ACLs on DCs |
Windows Firewall or host ACL |
Block UDP 389 except from authorized replication partners and IT jump hosts. |
Detection Engineering (IMMEDIATE — deploy within 24 hours)
Based on the PoC analysis, look for these two indicators:
- CLDAP anomalies: Unusually long "User" attribute in CLDAP Locator Ping requests (UDP 389)
- LSASS crashes: Event ID 1000 with netlogon.dll as the faulting module
Splunk query (unknown FP rate — needs tuning):
index=* sourcetype=WinEventLog:System EventCode=1000 | search "netlogon.dll"
| stats count by ComputerName, Time
| where count > 1
Suricata/Snort equivalent: Look for UDP 389 with username field > 256 bytes. Unfortunately, no community-verified Sigma rule exists yet — I found no published detection signatures from Talos, ET, or SOCPrime specifically for this CVE.
Patching Sequence — Rolling vs. Simultaneous
Look, the "patch everything immediately" advice is vendor CYA. Most enterprises have 10–100+ DCs. You have three options:
Option A: Rolling patch (PREFERRED for most environments)
- Patch one DC at a time
- Allow 30 minutes for replication after each DC comes back up
- Risk: Low. The vulnerability is in the Netlogon service itself. Patching DC1 doesn't break replication to unpached DC2.
- Constraint: Sysvol replication might pause briefly during reboot, but no domain-level impact.
Option B: Simultaneous patch (SMALLEST environments only)
- Patch all DCs at once
- Risk: If the patch breaks something (and Netlogon patches have broken replication before — see 2020 Zerologon aftermath), you have no functional DCs.
- Only do this if you have tested in staging within the last 72 hours. Show me the test results or we're gambling.
Option C: Hybrid — PDCe first, then remaining
- Patch the Primary Domain Controller emulator first
- Wait for FSMO role stability
- Roll the rest
My recommendation: Option A with a 2-hour patch window per DC, staggered.
Priority 2: CVE-2026-0826 — HP Poly VoIP Phones
The reality: These devices are network-borne heaps of legacy C code that we pretend are "just phones." CVSS 9.2, root RCE via malicious SIP INVITE, no authentication required when ICE (Interactive Connectivity Establishment) is enabled.
Immediate Mitigations (FIRST 24 HOURS)
| Control |
Action |
Owner |
| Disable ICE |
Via Polycom/Poly management interface or provisioning server |
Voice/Network team |
| VLAN segmentation |
Move phones to isolated voice VLAN with no L3 access to corporate or DC subnets |
Network team |
| SIP INVITE inspection |
Block malformed SDP payloads at SBC or edge session border controller |
Telecom team |
Disable ICE: Real talk
Most enterprises use ICE for NAT traversal when phones are remote. Disabling ICE breaks remote worker softphones unless you have a VPN or SBC relay. Priority matrix:
- On-prem phones with no remote requirements: Disable ICE immediately
- Mixed environment: Segment — disable ICE on-prem fleet, monitor off-premises
The Enterprise Visibility Problem
Here's the uncomfortable truth: Most organizations cannot produce a list of their VoIP firmware versions within 72 hours. The tools that can help:
| Method |
Coverage |
Time to inventory |
| Poly Device Management (PDMS/Poly Lens) |
Managed Poly devices only |
1–4 hours if already deployed |
| DHCP fingerprinting + nmap scripts |
All network-connected phones |
4–12 hours to script and scan |
| CUCM/VoIP PBX device reports |
Registered phones only |
1–2 hours (pull from call manager) |
| Manual physical inspection |
Conference room devices |
Days—weeks |
Gap analysis: What about unmanaged phones purchased by departments? BYOD softphone instances? M&A inherited gear? This attack surface is partially blind.
What Persistent Access on a VoIP Phone Enables
This isn't "just a bug on a phone." Root on a Poly VVX/Trio gives an attacker:
- Line audio interception — Active call eavesdropping, around-the-room audio capture when phone is on-hook (Trio conference phones have sensitive microphones)
- Lateral movement bridge — The phone sits on a "trusted" VLAN. If you haven't segmented properly, it's a pivot point to the rest of the network
- Domain credential harvesting — Phones authenticate to CUCM, often using cached credentials or certificates. An attacker can extract these
- Persistent C2 — Phones rarely get EDR, rarely reboot, and traffic looks like legitimate VoIP. Ideal long-term foothold
- Meeting intelligence — Conference room phones (Trio 8800/8500/8300) are planted in executive boardrooms. Strategic intelligence goldmine
PRIORITY MATRIX — Both Vulnerabilities
| Priority |
Action |
Owner |
Deadline |
| CRITICAL |
Block UDP 389 at perimeter; enable CLDAP/LSASS crash detection on DCs |
Security/Network ops |
Today |
| CRITICAL |
Disable ICE on on-prem Poly devices with no remote requirement |
Voice ops |
Today |
| HIGH |
Begin rolling DC patch schedule; test patch KB5034441 in staging if not already done |
Windows infra |
48 hours |
| HIGH |
Conduct VoIP firmware inventory using PDMS/DHCP/CUCM data |
Network/Voice ops |
72 hours |
| HIGH |
Segment voice VLAN from corporate/DC networks |
Network team |
This week |
| MEDIUM |
Deploy enterprise VoIP MDM/provisioning for enforced firmware updates |
Voice engineering |
30 days |
Final word: The Netlogon fix is well-understood and patchable. The Poly issue is messier — most orgs lack visibility into their voice estate. If you can only do one thing today, block UDP 389 at the perimeter and disable ICE on at-risk phones. Everything else is catch-up.
When is your next DC maintenance window, and do you have Poly PDMS deployed for centralized management?