@openzeppelin/contracts-upgradeable
Supply chain provenance
Status for the latest visible version.
Without SLSA provenance there is no cryptographic link between this tarball and the public source, so a manually published version cannot be tied back to a reviewed commit.
Maintainers
Keywords
Accepted risks
Findings the reviewer chose to accept rather than block on.
| Source | Rule | Reason | Accepted by | When |
|---|---|---|---|---|
| provenance | publisher-changed | AI (provenance): Legitimate transition from human publisher (amxx) to GitHub Actions CI/CD for OpenZeppelin, a major org. | ai | |
| provenance | missing-githead | AI (provenance): Side effect of switching to GitHub Actions publishing; no security concern for this well-known package. | ai | |
| publish-pattern | dormant-publish | AI (publish-pattern): OpenZeppelin publishes regularly; dormancy metric likely reflects scoped package gap, not actual inactivity. | ai | |
| provenance | no-provenance | AI (provenance): Informational only; OpenZeppelin is a trusted publisher with verified GitHub org. | ai |
Versions (showing 9 of 9)
| 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 | |
| 4.9.6 | 0 / 0 |
v5.6.1
2 findings[Accepted risk] Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
[Accepted risk] This version has no gitHead field linking it to a source commit, but previous versions did. This suggests the publish environment changed. Published by: GitHub Actions.
v5.6.0
3 findings[Accepted risk] Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
[Accepted risk] This version has no gitHead field linking it to a source commit, but previous versions did. This suggests the publish environment changed. Published by: GitHub Actions.
[Accepted risk] This version was published by a different npm account than previous versions on 2026-02-25. This could indicate a legitimate maintainer transition or an account compromise.
v5.5.0
2 findings[Accepted risk] Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
This version was published by a different npm account (amxx) than the most recent previously approved version (arr00) on 2025-10-31, but amxx is listed as a maintainer on prior approved versions (matched on name). This looks like a manual publish by a known maintainer rather than a publisher change. Recorded as INFO for audit trail.
v5.4.0
2 findings[Accepted risk] Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
This version was published by a different npm account (arr00) than the most recent previously approved version (amxx) on 2025-07-17, but arr00 is listed as a maintainer on prior approved versions (matched on name). This looks like a manual publish by a known maintainer rather than a publisher change. Recorded as INFO for audit trail.
v5.3.0
2 findings[Accepted risk] Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
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
3 findings[Accepted risk] Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
This version was published by a different npm account (ernestognw) than the most recent previously approved version (amxx) on 2025-01-09, but ernestognw is listed as a maintainer on prior approved versions (matched on name). This looks like a manual publish by a known maintainer rather than a publisher change. Recorded as INFO for audit trail.
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[Accepted risk] Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
v5.0.2
1 finding[Accepted risk] Package was published without Sigstore provenance. Only ~12% of npm packages have provenance, so this is common but not ideal.
v4.9.6
1 finding[Accepted risk] Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.