IT weekly review: QNAP fixes, Exchange guidance and SSMS diagnostics

This review covers October 18, 18:00, through October 25, 2026, 18:00, Europe/Berlin. Three developments matter for local infrastructure: QNAP firmware fixes, clarified Exchange patching guidance and a SQL Server Management Studio maintenance release. Storage exposure deserves immediate attention; mail availability and usable database diagnostics need their own checks. The actions below are operational recommendations. They distinguish a vendor's dated announcement from the evidence an administrator should collect before closing a change. Previously covered October patches are included only where this week brought material new guidance.

QNAP published QSA-26-18 on October 22 and recorded firmware fixes in its October 24 revision. PHP2Shell, CVE-2026-109618 and CVE-2026-109619, can permit unauthenticated remote code execution. Affected branches include QTS 5.2.11 and earlier and QuTS hero h5.2.11 and earlier. Their fixed versions are QTS 5.2.11.3661 and QuTS hero h5.2.11.3661, both build 20261023. Other firmware branches have separate targets in the advisory. Several applications still await fixes; QuMagie appears among affected products without a fixed-version table entry. A firmware update therefore does not establish that every installed application is repaired.

Start with an inventory of each appliance, its firmware branch, installed applications and reachable management interfaces. QNAP recommends removing direct internet exposure and restricting access to trusted networks. For systems holding production shares or backup data, I would record dependent jobs, available recovery copies and an owner for the maintenance window before updating. Select the model's matching firmware rather than treating a higher version number as sufficient. After restart, verify the installed build, share access with an ordinary account and one representative backup followed by an isolated restore. Track unresolved applications separately. Closing the firmware change should require a recorded test result; remaining application exposure needs its own restriction and follow-up date.

The Exchange Team added an FAQ on October 20 to its October 16 incident post. That is the new development beyond last week's warning: administrators can create the documented registry setting before installing October Windows updates, and Microsoft advises against delaying or uninstalling those security updates. The FAQ says no follow-up release is imminent. The incident affects on-premises Exchange 2016, 2019 and Subscription Edition; Windows release health lists Server 2016, 2019, 2022 and 2025. These lists do not make every Exchange and Windows combination supported. The registry measure remains a mitigation, not a newly released permanent fix.

For the next mail-server window, review Microsoft's current EpmapSavedContextCap instructions with the person responsible for Exchange. Plan the required restart and subsequent observation explicitly. I recommend recording the original setting, Windows build and update time so later symptoms can be correlated with the change. Test webmail login, internal and external message delivery and mailbox operations; compare queue growth with the pre-change baseline. A quiet first login is insufficient acceptance evidence. Agree who monitors the server after the window and when a recurrence must reach Microsoft Support. Keep the mitigation in the change register for reassessment rather than presenting the October 20 clarification as incident closure.

SQL Server Management Studio (SSMS) 22.11.1 was released on October 20. It fixes invalid XML filenames that prevented viewing captured Extended Events data, and updates the bundled MSOLEDBSQL MSI to 19.4.3 and Visual Studio to 18.11.1. Extended Events capture diagnostic information about database activity. A broken viewer can obstruct an investigation even when the database service is available. This is a management-tool release; it does not supply a new SQL Server engine patch. Last week's engine security updates remain separate maintenance items.

Inventory the SSMS installations actually used during incidents, including administrator workstations and jump hosts. Update a representative installation first. I would then open an existing event capture and repeat the team's normal capture-and-review workflow against a permitted test instance. Check connection authentication and any locally required components before extending the change to other workstations. Preserve a known diagnostic sample with the acceptance record so another administrator can reproduce the check. Record the installed SSMS version independently of the SQL engine build. This keeps a repaired diagnostic client from being mistaken for evidence that the database servers themselves received their required updates.

For the coming week, assign three owners and three concrete outcomes: a verified storage firmware state with unresolved applications listed, a tested Exchange update and mitigation sequence, and an SSMS installation that can open the team's diagnostic data. Keep failed checks visible instead of marking a maintenance ticket complete after an installer exits. Recovery access and a usable evidence trail belong in each record. These changes affect different layers, so one successful reboot cannot stand in for acceptance of storage access, mail delivery and database troubleshooting.