Ledger SDK Sends Destination and Device Metadata by Default

By Nathan Brooks

Ledger SDK sends transaction destination addresses and details about the signing device by default, according to the SDK’s described reporting behavior. The default flow pairs metadata about a transaction’s destination with information about the device involved in signing, placing both categories in the same reporting path.

Ambire said it “kept the affected versions out of production.” That statement addresses Ambire’s own deployments; the underlying issue concerns the SDK code’s default metadata reporting behavior, independent of whether a particular application used the affected versions.

Default reporting and standard operation

The SDK description identifies two data categories in its reporting code: destination addresses associated with signing and details about the device used for that signing. The SDK includes both categories by default, rather than making them available only after an optional reporting request.

The reporting-code description states: “The reporting code sends metadata about signing, including the transaction’s destination address and information about the device involved.” In practical terms, the behavior belongs to the SDK’s standard operation as described, not to an exceptional path that a particular integration has to activate.

That distinction affects how integrators should read the issue. A privacy or security review cannot assume that destination and device information remain outside the flow unless it has checked the default settings for the SDK version in use.

What does this change for wallet integrators?

Teams embedding the SDK now have to account for both destination-address metadata and signing-device metadata when documenting what the integration collects by default. The practical review should cover:

• Destination addresses associated with a transaction.
• Device details tied to the signing environment.
• The inclusion of both categories in a default reporting flow.

The account identifies a single reporting flow but does not disclose the transport, reporting endpoint, retention period or precise set of device attributes. Those gaps prevent a definitive inventory of the data involved, so teams need to examine the versions they actually ship.

Teams should also separate a code-level default from one company’s deployment decision. Ambire’s exclusion of the affected versions from production limits the relevance of its own exposure, but it does not change the SDK’s default behavior. A review of another application has to begin with the versions that application ships.

Integrators must evaluate whether destination addresses and device details require separate controls, different retention periods or an opt-in setting. Without those answers, a product team cannot describe the SDK’s data handling merely by describing the transaction a user intends to sign.

Scope of the disclosure

The disclosure does not quantify affected installations, name affected versions, identify a reporting endpoint or specify a chain or token standard. It also does not describe unauthorized access, fund losses, an exploit or a regulatory action. Those limits matter because a default data flow does not, by itself, establish compromise.

The issue concerns information handling within a signing workflow, not a reported failure of the signing mechanism. Nothing in the account establishes compromised keys, manipulated approvals or a change to transaction execution. Any assessment of those outcomes would require facts beyond the SDK description and Ambire’s deployment statement.

Ambire’s statement is a mitigation for that application, not a remedy described for the SDK itself. No maintainer response, release timetable or configuration instruction appears in the account. A wider response would depend on whether other integrations used the affected versions and on how they handled the resulting metadata.

With no remediation date specified, any future SDK upgrade becomes the practical checkpoint for integrators to verify whether destination and device metadata still leave the SDK by default.