Trezor Safe Firmware CVE-2026-65058

Exploitation requires the victim to initiate an Ethereum contract interaction - not a simple ETH value transfer - whose calldata is large enough to be split across multiple streaming chunks on the device. The attacker must control the calldata streaming pipeline, either by operating or compromising the dApp backend that communicates with the Trezor host software, or by achieving a man-in-the-middle position on the channel between the host and the device. The victim must physically interact with the device by tapping Confirm on the displayed (initial-chunk-only) calldata prompt. Simple ETH transfers with no calldata are not affected. The CVSS PR:N confirms no attacker authentication is required against the victim's device, but the attacker must control the data source. High Attack Complexity (AC:H) reflects the precise streaming-control timing requirement. Non-contract Ethereum transactions and non-Ethereum coins are not affected.

The CVSS 3.1 base score of 5.3 with vector AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N accurately reflects the combination of a High Integrity impact offset by High Attack Complexity and Required User Interaction. Exploitation requires the attacker to have precise control over calldata chunk delivery - achievable via a malicious or compromised dApp backend or MitM on the host-to-device communication - and the victim must actively confirm the transaction on the physical device. No CISA KEV listing is present; CISA's Cybersecurity Group (cisa-cg) is listed as the reporter, which does not equate to confirmed active exploitation. EPSS data was not provided in the source intelligence and cannot be assessed. No public proof-of-concept has been identified. The real-world risk is highest for Trezor Safe users who routinely sign complex Ethereum contract interactions via third-party dApps, particularly those whose calldata exceeds the single-chunk threshold. Users whose workflows are limited to simple ETH transfers or interactions exclusively with locally-verified, self-hosted dApps face materially lower risk. The Information Disclosure tag in the source data appears inconsistent with the CVSS C:N metric; no confidentiality breach is evident from the description or commit diff.

A malicious dApp backend crafts a large Ethereum contract call - for example an ERC-20 approve() for a token amount of 1 - and initially streams only that benign first chunk for the Trezor device to display, prompting the victim to tap Confirm on the physical device. Once the victim confirms, the dApp streams a manipulated calldata tail that silently replaces the approval amount with uint256.max and changes the spender to an attacker-controlled address. The unpatched device, having already received user confirmation for the visible initial chunk, incorporates the full malicious calldata into the digest and signs it without further on-screen prompting, granting the attacker unlimited token spending rights.