← Home

@openzeppelin/contracts

8
Versions
License
No
Install Scripts
Verified
Provenance

Supply chain provenance

Status for the latest visible version.

SLSA provenance attestation npm registry signatures No source commit

Maintainers

ernestognwfrangioamxxericglauarr00luiz-lvjson-oz

Keywords

solidityethereumsmartcontractssecurityzeppelin

Versions (showing 8 of 8)

Version Deps Published
5.6.1 0 / 0
5.6.0 0 / 0
5.5.0 0 / 0
5.4.0 0 / 0
5.3.0 0 / 0
5.2.0 0 / 0
5.1.0 0 / 0
5.0.2 0 / 0

v5.6.1

1 finding
INFO Has SLSA provenance attestation provenance

Published via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.

v5.6.0

2 findings
INFO Has SLSA provenance attestation provenance

Published via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.

INFO Publisher changed: ernestognw → GitHub Actions (on 2026-02-25, now via trusted publisher with provenance) provenance

This version was published by a different npm account (GitHub Actions) than the most recent previously approved version (ernestognw) on 2026-02-25, but it carries Sigstore provenance attestation. This means the package moved to a trusted publisher (CI/CD with OIDC, e.g. GitHub Actions) — a supply-chain integrity improvement, not a compromise, since a stolen npm token cannot forge provenance bound to the source repository. Recorded as INFO for audit trail.

v5.5.0

1 finding
INFO Has SLSA provenance attestation provenance

Published via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.

v5.4.0

1 finding
INFO Has SLSA provenance attestation provenance

Published via CI/CD with Sigstore attestation (predicate: https://slsa.dev/provenance/v1). This is the strongest supply chain integrity signal.

v5.3.0

2 findings
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

INFO GHSA-9rcw-c2f9-2j55: OpenZeppelin Contracts Bytes's lastIndexOf function with position argument performs out-of-bound memory access on empty buffers osv

CVSS 0.0 (INFO) — CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:N ### Impact The `lastIndexOf(bytes,byte,uint256)` function of the `Bytes.sol` library may access uninitialized memory when the following two conditions hold: 1) the provided buffer length is empty (i.e. `buffer.length == 0`) and position is not `2**256 - 1` (i.e. `pos != type(uint256).max`). The `pos` argument could be used to access arbitrary data outside of the buffer bounds. This could lead to the operation running out of gas, or returning an invalid index (outside of the empty buffer). Processing this invalid result for accessing the `buffer` would cause a revert under normal conditions. When triggered, the function reads memory at offset `buffer + 0x20 + pos`. If memory at that location (outside the `buffer`) matches the search pattern, the function would return an out of bound index instead of the expected `type(uint256).max`. This creates unexpected behavior where callers receive a valid-looking index pointing outside buffer bounds. Subsequent memory accesses that don't check bounds and use the returned index must carefully review the potential impact depending on their setup. Code relying on this function returning `type(uint256).max` for empty buffers or using the returned index without bounds checking could exhibit undefined behavior. ### Patches Upgrade to 5.4.0

v5.2.0

2 findings
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.

INFO GHSA-9rcw-c2f9-2j55: OpenZeppelin Contracts Bytes's lastIndexOf function with position argument performs out-of-bound memory access on empty buffers osv

CVSS 0.0 (INFO) — CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:N ### Impact The `lastIndexOf(bytes,byte,uint256)` function of the `Bytes.sol` library may access uninitialized memory when the following two conditions hold: 1) the provided buffer length is empty (i.e. `buffer.length == 0`) and position is not `2**256 - 1` (i.e. `pos != type(uint256).max`). The `pos` argument could be used to access arbitrary data outside of the buffer bounds. This could lead to the operation running out of gas, or returning an invalid index (outside of the empty buffer). Processing this invalid result for accessing the `buffer` would cause a revert under normal conditions. When triggered, the function reads memory at offset `buffer + 0x20 + pos`. If memory at that location (outside the `buffer`) matches the search pattern, the function would return an out of bound index instead of the expected `type(uint256).max`. This creates unexpected behavior where callers receive a valid-looking index pointing outside buffer bounds. Subsequent memory accesses that don't check bounds and use the returned index must carefully review the potential impact depending on their setup. Code relying on this function returning `type(uint256).max` for empty buffers or using the returned index without bounds checking could exhibit undefined behavior. ### Patches Upgrade to 5.4.0

v5.1.0

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Only ~12% of npm packages have provenance, so this is common but not ideal.

v5.0.2

1 finding
LOW No provenance attestation provenance

Package was published without Sigstore provenance. Only ~12% of npm packages have provenance, so this is common but not ideal.