SAP retracted the workaround. The ticket was already closed.

A vendor advisory carries two kinds of information. The first is the description of the vulnerability — what code is wrong, what the impact is, what version contains the fix. The second is the operator instruction — what action to take, in what order, with what fallback. The first kind gets read once. The second kind gets actioned, ticketed, and closed.

SAP’s April 24 advisory described the vulnerability accurately and listed three mitigation options for operators who could not patch immediately. Options 1 and 2 covered restricting access to the Visual Composer servlet path and tightening authentication on the development server. Option 3 was the only path that removed the vulnerable component entirely — undeploy devserver_metadataupload_ear per KBA 3593336.

On May 12, SAP updated KBA 3593336 to mark Options 1 and 2 with a “Do Not Use” label. Both could be bypassed; only Option 3 (undeploy) and the actual patches provided real protection. This is the right call as a vendor decision. It is also the moment the advisory’s distribution mechanism broke down for the operators it most needed to reach.

Two weeks earlier, a Basis admin reading the original advisory had two plausible paths: take downtime to apply the patch through the change advisory board, or apply Option 1 or 2 as a short-term shield while the patching cycle worked through regression testing. The second path is the one most shops took. The change ticket closed on or around April 29. The mitigation was documented in the CMDB. The CVE moved off the active risk register.

There is no channel in SAP’s customer communication that re-opens that ticket. The KBA was updated; the operator did not see the update. The “Do Not Use” label is rendered on the SAP support portal, behind a login that the admin who applied the workaround in April has no reason to re-enter in May. Email notification on KBA changes is opt-in and defaults off for the same support account that downloaded the original advisory. The compromise-assessment tool Onapsis and Mandiant released — the right tool for finding the webshells that were already in place — sits in a GitHub repository that operators have to find on their own.

The advisory describes the patches accurately. The retraction describes the workarounds accurately. The gap is the absence of a mechanism that carries the retraction to the audience that already actioned the first version. Operators who waited and applied Note 3594142 are now in a better state than operators who acted in good faith on the original guidance. That inversion is a product of distribution, not of malice or incompetence — but it is the kind of thing the advisory’s own structure will not surface to a reader who only encounters the May 12 revision when they go looking.

The operator-facing version of this story: if your team applied a workaround for CVE-2025-31324 between April 24 and May 12 and the ticket is closed, open a new ticket. Verify which option you applied. If it was Option 1 or 2, the system is in scope for re-assessment. Run the Onapsis/Mandiant compromise tool against the suspected window before you assume the workaround held. Apply Note 3604119 alongside Note 3594142 — the second is not optional, CVE-2025-42999 is a real follow-on, not a re-disclosure.

The structural lesson is the harder one: an advisory revision that matters operationally needs a push channel, not a pull channel. SAP has the customer mapping. The retraction of a bad workaround is exactly the case where the vendor knows who applied what — and where the absence of an outbound notification turns a vendor correction into an operator surprise that, in this case, was running adjacent to five threat groups already inside the perimeter.