Reach a signing service through the deployment path

CI/CD Posture Cloud Security

Deployment credentials are usually treated as a compute permission:
whoever holds them can start a workload. In organisations that also
run signing, approval or transaction-authorisation services, the
deployment path is a route to those services, because a workload
started inside the estate inherits the trust the service places in
callers from that network — a workload identity, a service account, a
mutual-TLS client, or simply an internal address that is reachable and
not otherwise authenticated. The attacker does not need a key. They
need the ability to run code somewhere the signing service will
answer, and then to ask it for the signature the business would have
asked for.

Binance's October 2026 incident shows the shape. Using a container
deployment token taken from an engineer's laptop, the attacker
deployed a container from a second engineer's computer on 29 October
between 17:15 and 19:56 UTC and triggered a script. The container
reached an internal wallet signing service, which initiated transfers
outside the normal withdrawal process and signed 50 transactions that
set up an EIP-7702 delegation to an attacker-controlled contract. Those
signatures were valid. The delegation then persisted on-chain after
Binance suspended withdrawals, because a delegation is account state
rather than a transaction, and the wallet's MPC arrangement meant
there was no single key with which to revoke it quickly; Binance
cleared it with a new authorisation to the zero address at 00:10 UTC
on 30 October. About $6.34 billion left the hot wallets.

The lesson is that protecting the private key is only part of
protecting a signing service. The service also has to decide who may
ask and what it will sign, and those rules are only as strong as the
identity a workload can present from inside the deployment path.

Distinct from T0208, where the attacker obtains or abuses a
code-signing identity so that artifacts carry a trusted signature, and
from T0222, where a page's own client and signer are borrowed inside a
browser session. Distinct from T0166, which is triggering a pipeline
the victim already runs; here the attacker brings their own workload
and asks a downstream service for authorisation.

Where this idea came from

Public incident / advisory

From the same findings. A container deployed with a token taken from an engineer's laptop reached an internal wallet signing service that authorised transfers outside the withdrawal process and signed 50 EIP-7702 delegation transactions, and the delegation outlived the withdrawal freeze. The technique is the trust a signing service places in workloads inside its own estate.

Mitigations

None linked yet.

Detections