The operational priority is now clear: stop active exposure without overstating what the evidence proves. James puts internet-facing Switchvox, SMA1000, and PaperCut systems into immediate isolation, alongside the Teams/RMM endpoint and its user, RMM, and WinRM paths. Volatile state, process trees, connections, authentication and PowerShell records, package hashes, web logs, and PaperCut’s server.log should then be preserved before patching. That sequence is intended to balance containment with evidence retention, but the exact timing matters because isolation itself can alter or destroy volatile evidence.
The same confidence discipline applies across the other cases. The 13 malicious Composer themes and their delivery chain can be quarantined as confirmed malicious infrastructure, but there is still no basis for calling visitors infected. In Serbia, one Pegasus infection is forensically confirmed; the 14-plus notifications remain evidence of targeting and leads for investigation, not proof of compromise. For PaperCut, non-allowlisted pc-app.exe child processes combined with loss or truncation of server.log are a hunting hypothesis. Because the false-positive rate is unknown, that logic should support investigation before it drives broad paging.
Over the following four hours, the focus shifts to enterprise-wide scoping of the Teams sequence—external contact, approved RMM, PowerShell, MSI or Node.js staging, and WinRM—while revoking only credentials or secrets shown to be exposed. Switchvox and SMA fixes should be staged and validated, with unpatched appliances remaining isolated, and confirmed malicious themes removed while potentially exposed application secrets are scoped.
The next question is whether Switchvox truly belongs at the very front of that containment queue. We now need to test James’s call against the actual exploit preconditions for CVE-2026-9586 and determine whether immediate isolation before evidence capture is proportionate to the demonstrated risk.