CVE intelligence and bounded remediation

CVE-2021-41272 — Besu is an Ethereum client written in Java

High CVSS 7.5

Besu is an Ethereum client written in Java. Starting in version 21.10.0, changes in the implementation of the SHL, SHR, and SAR operations resulted in the introduction of a signed type coercion error in values that represent negative values for 32 bit signed integers. Smart contracts that ask for shifts between approximately 2 billion and 4 billion bits (nonsensical but valid values for the operation) will fail to execute and hence fail to validate. In networks where vulnerable versions are mining with other clients or non-vulnerable versions this will result in a fork and the relevant transactions will not be included in the fork. In networks where vulnerable versions are not mining (such as Rinkeby) no fork will result and the validator nodes will stop accepting blocks. In networks where only vulnerable versions are mining the relevant transaction will not be included in any blocks. When the network adds a non-vulnerable version the network will act as in the first case. Besu 21.10.2 contains a patch for this issue. Besu 21.7.4 is not vulnerable and clients can roll back to that version. There is a workaround available: Once a transaction with the relevant shift operations is in…

Severity
High
CVSS
7.5 (3.1)
Published
2021-12-13
CISA KEV
Not currently listed
Ecosystem
java/maven
Weaknesses
CWE-681

Affected products

  • linuxfoundation / besu / 21.10.0
  • linuxfoundation / besu / 21.10.1

Showing 2 representative product identities from 6 source matches. Confirm exact affected versions with the linked vendor and NVD evidence.

Matched remediation archetype

General vulnerability remediation

This catalog composition supplies bounded fallback guidance. Explicitly reviewed curated workflows load with the complete record below.

Check exposure

  • Confirm the affected component, deployment paths, reachable interfaces, and enabled features from inventories and configuration, without probing production destructively.
  • Compare the advisory's affected conditions with the repository lockfiles, build manifests, artifacts, and runtime inventory.
  • Identify data sensitivity, trust boundaries, and privilege level for every confirmed affected deployment.

Remediate safely

  • Apply a vendor-supported fix or remove the affected component or feature; record the selected change and its source in the repository.
  • Update direct and transitive dependency locks, generated artifacts, deployment manifests, and asset inventories together.
  • Add a regression test for the documented unsafe condition using inert inputs and preserve rollback instructions.

Authoritative sources

Complete CVE record and remediation plan

The detailed catalog view below loads this exact record, its source evidence, and the full seven-phase agentic change plan.