Patching CVE-2026-66066 Leaves the Intruder Logged In
The disclosed value is a signing key, so every session cookie your application trusts can be minted by whoever read it, and the order you rotate in decides whether they lose access.
What the disclosed key buys
Rails derives cookie signing and encryption from secret_key_base. An attacker who reads it does not need the vulnerability again. They can mint session cookies the application accepts as authentic, privileged accounts included, and unwrap whatever the app kept in its encrypted credential store. Risky Business's framing is the one to brief upward: the attacker gets what a shell would have given them without creating a process, a child shell or a beacon that endpoint tooling is tuned to catch.
Patched and exposed are separate facts. Triage queues record the first. A host that took the early-August fix but had its keys read in mid-August looks, from the attacker's side, identical to one still running vulnerable code. The access arrives as ordinary authenticated traffic through the application's own front door. No payload lands on disk for a later scan to find.
Sequence the rotation
One secret regenerates all the others, so order decides whether the work holds.
- Inventory every Rails application using Active Storage, including internal apps that quietly terminate public traffic behind a load balancer, and confirm the early-August fix on each one.
- Rotate secret_key_base and the signed and encrypted cookie keys first, then invalidate sessions fleet-wide. Rotating downstream credentials while cookie forgery still works hands an intruder the replacements from an authenticated session.
- Rotate database credentials, cloud IAM keys and third-party API tokens held by anything internet-facing since 1 August. Cloud IAM keys are the ones most likely to have unknown consumers. Teams that skip the broken-jobs check find out at 3am.
- Hunt authentication logs for sessions and tokens issued before rotation and still in use, and for the same credential appearing from an unfamiliar network.
Step 3 depends on a complete list of what holds a credential. Few organisations have one.
The pattern across these items
McKesson shows the same shape. The company confirmed an intrusion sourced from a third-party application, with the extortion crew claiming hundreds of millions of customer and patient records. That breach happened inside a vendor integration's token scope. Bring-your-own-key agent tooling leaves long-lived Anthropic, OpenAI and Google API keys sitting in local secret stores, the artifact class commodity infostealers already enumerate. Every MCP endpoint an agent calls is an authenticated path into a production system whose credential use is typically unlogged.
The sources pull against each other, which is instructive. Risky Business treats rotation as the control that closes a secrets-disclosure bug, and operationally that holds. The agent and AI-tooling reporting shows the rotation inventory is incomplete by construction: credentials have migrated into config stores, delegated grants and desktop secret vaults that no register covers. The Rails work is the urgent task and a rehearsal at once. The list built to answer which secrets did this app hold is the list needed the next time a disclosure hands someone a key.
Rotation and session invalidation close a secrets-disclosure bug. A version number records the patch date.
What to do
Inventory every Rails application using Active Storage, confirm the early-August patch, then rotate secret_key_base and the signed and encrypted cookie keys and invalidate all sessions.
Rotate database credentials, cloud IAM keys and third-party API tokens held by any app exposed since 1 August, then hunt authentication logs for pre-rotation sessions still in use.
Assign a named owner for application-secret rotation this quarter and publish a maximum time-to-rotate per secret class.