Microsoft's follow-up Excel KB concedes paste can still fail on conditional formatting

KB5002665 is where the useful sentence sits. As quoted in the dev.to post "Stop Patching Blind", it reads: "If the workbook contains conditional formatting, paste operations might continue to fail." ^[3] "Contains" puts the trigger in the file, so nothing about the user's action selects the broken path. "Might continue" describes behavior that outlived the follow-up.

That wording also tells you what a reproduction needs: a workbook fixture carrying at least one conditional formatting rule over the target range. A paste test on a default sheet passes. The failure appeared in Excel 2016, Office 2019, Office 2021 LTSC, Office 2024 LTSC and Microsoft 365 Apps ^[1], five product lines on separate servicing trains ^[5]. One shared code path patched in all five at once would explain that spread. AutoFill failed in the same update ^[2]. The suspect narrows to something both paste and fill call.

The failure mode explains the detection lag. Paste failed silently ^[1], so a dead paste looks the same as a keystroke that never registered. Reports arrived as symptoms instead: cells stuck mid-selection, borders that kept blinking, an Escape key that stopped working, more than a hundred replies deep on Microsoft's own Q&A forum before a real fix shipped ^[4].

The post reads the incident as a coverage failure. "There was no test to run, because there had never been one, and a security hotfix isn't the moment anyone stops to write the first test a decades old module has ever had," it said ^[7], arguing that automated testing was not standard practice when much of that code was written ^[6]. The coverage claim is the author's inference. The KB sentence establishes the trigger and says nothing about the state of Microsoft's test suite. The post cites no coverage data for the Excel paste path.

The post's remedies hold even if its cause claim does not. A codebase with no seams forces every change to touch the original untested logic directly, so a narrow fix for a security hole can reach into clipboard handling ^[15]. The remedies follow from that: treat any code without tests as legacy code, on Michael Feathers' definition, however recently it was edited ^[8]; write a characterization test that records current behavior before anything near the module changes ^[9]; find a seam and route the patch through it ^[10]; scope the edit to the hole and keep incidental cleanup out of the same commit ^[11].

Rollback is the other half. The post argues rollback becomes the only realistic fix, because nobody wrote down what the old untested behavior actually was, and you still do not want to leave the security hole open ^[13]. It recommends a canary segment before a full rollout, then concedes the limit in one line: "A canary isn't always possible with a security hole." ^[12]