The Wallet Address Your Page Rendered Was Not the One You Sent
Two items need out-of-band work: one is a patch you can schedule in an afternoon, and the other leaves evidence only in edge logs you may no longer hold.
Why nothing in the estate recorded it
The malicious logic executed in the visitor's browser. The origin server returned exactly the HTML it was built to return, and the poisoned code arrived afterward, inside an asset the page was configured to fetch from the vendor. Nothing on the origin changed, so no access log, WAF decision, or file-integrity check on the web root shows a deviation. One class of telemetry can place a malicious script version in front of a real user: the CDN or edge log recording which asset was served. Those are typically the shortest-retained logs in the estate.
The wallet theft is not the operational problem. A vendor's detection date marks the end of an incident, never the beginning. If the poisoned build was live for longer than edge retention, the honest answer to "were our customers affected" is unknown. Unknown is the answer that goes to counsel, to the payments partner, and to any regulator who asks.
The applicable controls are integrity controls, not detections
There is no alert to tune here. What holds is Content Security Policy in enforce mode with a strict script-src allowlist, Subresource Integrity on every static third-party asset, and origin isolation for adtech tags that require dynamic loading and therefore break SRI. A sandboxed iframe or a separate origin, so the tag cannot read or mutate the main document.
One control matters more than all of those and almost nobody runs it. A synthetic check that loads the page the way a customer does and asserts that the rendered wallet address, IBAN, or payment destination matches the value the backend intended. Substitution attacks throw no exception and fail no transaction. They run until someone complains about money.
An address-substitution attack produces no failed transaction. The first evidence is a customer who paid someone else.
The CVSS 10.0 in the same batch, and why it sits outside the SLA
Adobe Campaign Classic is the patch that should move out of band. A perfect score with no user interaction implies a network-reachable, unauthenticated code execution path. Campaign Classic holds customer contact and behavioral data and owns a trusted outbound mail channel, so one compromise yields both a PII store and a way to send mail customers will open. Marketing operations owns the platform in most companies, which is exactly why it is absent from the patch calendar. Take the inventory from marketing directly rather than the CMDB, and pull the CVE and affected build range from Adobe's advisory. The reporting names neither.
Where the sources converge
Techpresso reported AI vendors discovering their own agent escapes months later through retrospective log review. Set that beside this incident and one property repeats across otherwise unrelated stories: the vendor finds the failure, the vendor dates it, and your evidence window is shorter than their dwell time. CSO Update frames that class as a shared-responsibility problem. The Hacker News frames it as third-party script risk. Neither addresses the variable actually under defender control, which is retention. Extending edge and CDN log retention is unglamorous work. It decides whether the next vendor disclosure produces an investigation or a shrug.
What to do
Enumerate every third-party script loading on customer-facing pages by end of week, confirm whether an Adform tag is present, and document the exact date range your CDN and edge logs still cover.
Patch Adobe Campaign Classic out of band after pulling the CVE and affected build range from Adobe's advisory, then hunt for webshells in the web root and new outbound connections from the application service account.
Ship a synthetic canary this sprint on every page that renders a wallet address, IBAN, or payment destination, asserting the rendered value matches the backend value and alerting on mismatch.