Act now:ScreenConnect CVE-2026-84869: Guest-to-Host File Execution. MSPs, help desks and IT teams using on-premises ScreenConnect below 26.6.5, or using any ScreenConnect deployment whose technicians still run old host clients, especially when supporting untrusted or consumer endpoints.
Act now:MikroTrick. Anyone running RouterOS 6 or 7, most urgently where SSH, WebFig or the bandwidth-test server is reachable from the internet or another untrusted network.
Check exposure:Chrome V8 Zero-Days CVE-2026-85046 and CVE-2026-87491. Admins of fleets where Chrome or Edge updates are pinned, deferred or broken, owners of kiosk and VDI images, and users of Chromium-based browsers whose vendor has not shipped a September 2026 or later V8 fix.
npm: 9 critical advisories (orval). Check with npm audit (or: npm ls <package>).
Go: 3 critical advisories (github.com/siyuan-note/siyuan/kernel). Check with govulncheck ./....
PyPI: 2 critical advisories (unstructured, python-jose). Check with pip-audit (or: pip show <package>).
None of it touches your stack? Then there is nothing to do today. That is a result, not a failure to read carefully.
If your technicians use a ScreenConnect client older than 26.6.5, a compromised machine they connect to can run code on theirs; upgrade on-premises servers and reinstall host clients now.
Must act: MSPs, help desks and IT teams using on-premises ScreenConnect below 26.6.5, or using any ScreenConnect deployment whose technicians still run old host clients, especially when supporting untrusted or consumer endpoints.
Can relax: ScreenConnect Cloud customers who have already reinstalled host clients and updated access agents after ConnectWise's automatic 26.6.5 upgrade; the ScreenConnect server itself is not affected.
Upgrade on-premises ScreenConnect servers to 26.6.5 or later; renew maintenance first if your license has lapsed.
Reinstall host clients on every technician machine and update access agents, on Cloud and on-premises alike.
Until that is done, remove the TransferFiles permission (TransferFilesInSession on older versions) from every role under Administration > Security > Roles.
If you run MikroTik routers, upgrade them now and check for an 'ops' admin account; an unauthenticated SSH chain to full admin was exploited a day before patches shipped.
Must act: Anyone running RouterOS 6 or 7, most urgently where SSH, WebFig or the bandwidth-test server is reachable from the internet or another untrusted network.
Can relax: Teams with no MikroTik gear; devices whose management services are reachable only over a management VPN still need the upgrade but are not on the reported attack path.
Inventory every RouterOS device, including cloud and lab instances, and record its version.
Upgrade to 7.24.3, 7.23.6 or 6.49.21 or later; devices moved to 7.24.2 or 7.23.4 in September need a second upgrade.
Restrict SSH, WebFig (www/www-ssl) and the bandwidth-test server to trusted management addresses or disable them; prefer a VPN for management.
Both were exploited zero-days, but Chrome and Edge fixed them in early September and auto-update has had six weeks to deliver the fix; the job now is finding browsers that did not update, not a scramble.
Must act: Admins of fleets where Chrome or Edge updates are pinned, deferred or broken, owners of kiosk and VDI images, and users of Chromium-based browsers whose vendor has not shipped a September 2026 or later V8 fix.
Can relax: Chrome users on 153.0.8010.36 or later and Edge users on 153.0.4234.32 or later, which includes anyone whose browser auto-updated and relaunched since mid-September.
Open chrome://settings/help (or edge://settings/help), relaunch if an update is pending, and confirm Chrome is at 153.0.8010.36 or later.
In managed fleets, report browser versions and flag any endpoint below Chrome 153.0.8010.36 or Edge 153.0.4234.32.
Remove policies that pin Chrome or Edge to an old version or defer updates indefinitely, and use RelaunchNotification policies so updates actually apply.