CVE-2023-46737
Possible endless data attack from attacker-controlled registry in cosign
Cosign is a sigstore signing tool for OCI containers. Cosign is susceptible to a denial of service by an attacker controlled registry. An attacker who controls a remote registry can return a high number of attestations and/or signatures to Cosign and cause Cosign to enter a long loop resulting in an endless data attack. The root cause is that Cosign loops through all attestations fetched from the remote registry in pkg/cosign.FetchAttestations. The attacker needs to compromise the registry or make a request to a registry they control. When doing so, the attacker must return a high number of attestations in the response to Cosign. The result will be that the attacker can cause Cosign to go into a long or infinite loop that will prevent other users from verifying their data. In Kyvernos case, an attacker whose privileges are limited to making requests to the cluster can make a request with an image reference to their own registry, trigger the infinite loop and deny other users from completing their admission requests. Alternatively, the attacker can obtain control of the registry used by an organization and return a high number of attestations instead the expected number of attestations. The issue can be mitigated rather simply by setting a limit to the limit of attestations that Cosign will loop through. The limit does not need to be high to be within the vast majority of use cases and still prevent the endless data attack. This issue has been patched in version 2.2.1 and users are advised to upgrade.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- High
- Privileges needed
- None
- User interaction
- Required
What an attacker can affect
- Confidentiality
- None
- Integrity
- None
- Availability
- Low
Exploit likelihood
What each source reports
CVE List Score used
Possible endless data attack from attacker-controlled registry in cosign
Cosign is a sigstore signing tool for OCI containers. Cosign is susceptible to a denial of service by an attacker controlled registry. An attacker who controls a remote registry can return a high number of attestations and/or signatures to Cosign and cause Cosign to enter a long loop resulting in an endless data attack. The root cause is that Cosign loops through all attestations fetched from the remote registry in pkg/cosign.FetchAttestations. The attacker needs to compromise the registry or make a request to a registry they control. When doing so, the attacker must return a high number of attestations in the response to Cosign. The result will be that the attacker can cause Cosign to go into a long or infinite loop that will prevent other users from verifying their data. In Kyvernos case, an attacker whose privileges are limited to making requests to the cluster can make a request with an image reference to their own registry, trigger the infinite loop and deny other users from completing their admission requests. Alternatively, the attacker can obtain control of the registry used by an organization and return a high number of attestations instead the expected number of attestations. The issue can be mitigated rather simply by setting a limit to the limit of attestations that Cosign will loop through. The limit does not need to be high to be within the vast majority of use cases and still prevent the endless data attack. This issue has been patched in version 2.2.1 and users are advised to upgrade.
- Record
CVE-2023-46737- CVSS 3.1
- 3.1 Low
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L - Weakness
- CWE-400
- Updated
- 2026-11-02
EUVDEUVD-2023-3044
Cosign is a sigstore signing tool for OCI containers. Cosign is susceptible to a denial of service by an attacker controlled registry. An attacker who controls a remote registry can return a high number of attestations and/or signatures to Cosign and cause Cosign to enter a long loop resulting in an endless data attack. The root cause is that Cosign loops through all attestations fetched from the remote registry in pkg/cosign.FetchAttestations. The attacker needs to compromise the registry or make a request to a registry they control. When doing so, the attacker must return a high number of attestations in the response to Cosign. The result will be that the attacker can cause Cosign to go into a long or infinite loop that will prevent other users from verifying their data. In Kyvernos case, an attacker whose privileges are limited to making requests to the cluster can make a request with an image reference to their own registry, trigger the infinite loop and deny other users from completing their admission requests. Alternatively, the attacker can obtain control of the registry used by an organization and return a high number of attestations instead the expected number of attestations. The issue can be mitigated rather simply by setting a limit to the limit of attestations that Cosign will loop through. The limit does not need to be high to be within the vast majority of use cases and still prevent the endless data attack. This issue has been patched in version 2.2.1 and users are advised to upgrade.
- Record
EUVD-2023-3044- CVSS 3.1
- 3.1 Low
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L - Updated
- 2026-11-03
GitHub AdvisoriesGHSA-vfp6-jrw2-99g9
Cosign vulnerable to possible endless data attack from attacker-controlled registry
Summary
Cosign is susceptible to a denial of service by an attacker controlled registry. An attacker who controls a remote registry can return a high number of attestations and/or signatures to Cosign and cause Cosign to enter a long loop resulting in an endless data attack. The root cause is that Cosign loops through all attestations fetched from the remote registry in pkg/cosign.FetchAttestations.
The attacker needs to compromise the registry or make a request to a registry they control. When doing so, the attacker must return a high number of attestations in the response to Cosign. The result will be that the attacker can cause Cosign to go into a long or infinite loop that will prevent other users from verifying their data. In Kyvernos case, an attacker whose privileges are limited to making requests to the cluster can make a request with an image reference to their own registry, trigger the infinite loop and deny other users from completing their admission requests. Alternatively, the attacker can obtain control of the registry used by an organization and return a high number of attestations instead the expected number of attestations.
The vulnerable loop in Cosign starts on line 154 below: https://github.com/sigstore/cosign/blob/004443228442850fb28f248fd59765afad99b6df/pkg/cosign/fetch.go#L135-L196
The l slice is controllable by an attacker who controls the remote registry.
Many cloud-native projects consider the remote registry to be untrusted, including Crossplane, Notary and Kyverno. We consider the same to be the case for Cosign, since users are not in control of whether the registry returns the expected data.
TUF's security model labels this type of vulnerability an "Endless data attack", but an attacker could use this as a type of rollback attack, in case the user attempts to deploy a patched version of a vulnerable image; The attacker could prevent this upgrade by causing Cosign to get stuck in an infinite loop and never complete.
Mitigation
The issue can be mitigated rather simply by setting a limit to the limit of attestations that Cosign will loop through. The limit does not need to be high to be within the vast majority of use cases and still prevent the endless data attack.
- Record
GHSA-vfp6-jrw2-99g9- CVSS 3.1
- 3.1 Low
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L - Weakness
- CWE-400, CWE-835
- Updated
- 2026-11-02
NVD
Cosign is a sigstore signing tool for OCI containers. Cosign is susceptible to a denial of service by an attacker controlled registry. An attacker who controls a remote registry can return a high number of attestations and/or signatures to Cosign and cause Cosign to enter a long loop resulting in an endless data attack. The root cause is that Cosign loops through all attestations fetched from the remote registry in pkg/cosign.FetchAttestations. The attacker needs to compromise the registry or make a request to a registry they control. When doing so, the attacker must return a high number of attestations in the response to Cosign. The result will be that the attacker can cause Cosign to go into a long or infinite loop that will prevent other users from verifying their data. In Kyvernos case, an attacker whose privileges are limited to making requests to the cluster can make a request with an image reference to their own registry, trigger the infinite loop and deny other users from completing their admission requests. Alternatively, the attacker can obtain control of the registry used by an organization and return a high number of attestations instead the expected number of attestations. The issue can be mitigated rather simply by setting a limit to the limit of attestations that Cosign will loop through. The limit does not need to be high to be within the vast majority of use cases and still prevent the endless data attack. This issue has been patched in version 2.2.1 and users are advised to upgrade.
- Record
CVE-2023-46737- CVSS 3.1
- 3.1 Low
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L - CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L - Weakness
- CWE-400, CWE-835
- Updated
- 2026-11-02
OSVALPINE-CVE-2023-46737
Cosign is a sigstore signing tool for OCI containers. Cosign is susceptible to a denial of service by an attacker controlled registry. An attacker who controls a remote registry can return a high number of attestations and/or signatures to Cosign and cause Cosign to enter a long loop resulting in an endless data attack. The root cause is that Cosign loops through all attestations fetched from the remote registry in pkg/cosign.FetchAttestations. The attacker needs to compromise the registry or make a request to a registry they control. When doing so, the attacker must return a high number of attestations in the response to Cosign. The result will be that the attacker can cause Cosign to go into a long or infinite loop that will prevent other users from verifying their data. In Kyvernos case, an attacker whose privileges are limited to making requests to the cluster can make a request with an image reference to their own registry, trigger the infinite loop and deny other users from completing their admission requests. Alternatively, the attacker can obtain control of the registry used by an organization and return a high number of attestations instead the expected number of attestations. The issue can be mitigated rather simply by setting a limit to the limit of attestations that Cosign will loop through. The limit does not need to be high to be within the vast majority of use cases and still prevent the endless data attack. This issue has been patched in version 2.2.1 and users are advised to upgrade.
- Record
ALPINE-CVE-2023-46737- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L - Updated
- 2026-11-03
OSV
Possible endless data attack from attacker-controlled registry in cosign
Cosign is a sigstore signing tool for OCI containers. Cosign is susceptible to a denial of service by an attacker controlled registry. An attacker who controls a remote registry can return a high number of attestations and/or signatures to Cosign and cause Cosign to enter a long loop resulting in an endless data attack. The root cause is that Cosign loops through all attestations fetched from the remote registry in pkg/cosign.FetchAttestations. The attacker needs to compromise the registry or make a request to a registry they control. When doing so, the attacker must return a high number of attestations in the response to Cosign. The result will be that the attacker can cause Cosign to go into a long or infinite loop that will prevent other users from verifying their data. In Kyvernos case, an attacker whose privileges are limited to making requests to the cluster can make a request with an image reference to their own registry, trigger the infinite loop and deny other users from completing their admission requests. Alternatively, the attacker can obtain control of the registry used by an organization and return a high number of attestations instead the expected number of attestations. The issue can be mitigated rather simply by setting a limit to the limit of attestations that Cosign will loop through. The limit does not need to be high to be within the vast majority of use cases and still prevent the endless data attack. This issue has been patched in version 2.2.1 and users are advised to upgrade.
- Record
CVE-2023-46737- CVSS 3.1
- 3.1 Low
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L - Weakness
- CWE-400
- Updated
- 2026-11-02
Show 5 moreShow less
OSVGHSA-vfp6-jrw2-99g9
Cosign vulnerable to possible endless data attack from attacker-controlled registry
Summary
Cosign is susceptible to a denial of service by an attacker controlled registry. An attacker who controls a remote registry can return a high number of attestations and/or signatures to Cosign and cause Cosign to enter a long loop resulting in an endless data attack. The root cause is that Cosign loops through all attestations fetched from the remote registry in pkg/cosign.FetchAttestations.
The attacker needs to compromise the registry or make a request to a registry they control. When doing so, the attacker must return a high number of attestations in the response to Cosign. The result will be that the attacker can cause Cosign to go into a long or infinite loop that will prevent other users from verifying their data. In Kyvernos case, an attacker whose privileges are limited to making requests to the cluster can make a request with an image reference to their own registry, trigger the infinite loop and deny other users from completing their admission requests. Alternatively, the attacker can obtain control of the registry used by an organization and return a high number of attestations instead the expected number of attestations.
The vulnerable loop in Cosign starts on line 154 below: https://github.com/sigstore/cosign/blob/004443228442850fb28f248fd59765afad99b6df/pkg/cosign/fetch.go#L135-L196
The l slice is controllable by an attacker who controls the remote registry.
Many cloud-native projects consider the remote registry to be untrusted, including Crossplane, Notary and Kyverno. We consider the same to be the case for Cosign, since users are not in control of whether the registry returns the expected data.
TUF's security model labels this type of vulnerability an "Endless data attack", but an attacker could use this as a type of rollback attack, in case the user attempts to deploy a patched version of a vulnerable image; The attacker could prevent this upgrade by causing Cosign to get stuck in an infinite loop and never complete.
Mitigation
The issue can be mitigated rather simply by setting a limit to the limit of attestations that Cosign will loop through. The limit does not need to be high to be within the vast majority of use cases and still prevent the endless data attack.
- Record
GHSA-vfp6-jrw2-99g9- CVSS 3.1
- 3.1 Low
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L - Weakness
- CWE-400, CWE-835
- Updated
- 2026-11-02
OSVBIT-cosign-2023-46737 No score
Possible endless data attack from attacker-controlled registry in cosign
Cosign is a sigstore signing tool for OCI containers. Cosign is susceptible to a denial of service by an attacker controlled registry. An attacker who controls a remote registry can return a high number of attestations and/or signatures to Cosign and cause Cosign to enter a long loop resulting in an endless data attack. The root cause is that Cosign loops through all attestations fetched from the remote registry in pkg/cosign.FetchAttestations. The attacker needs to compromise the registry or make a request to a registry they control. When doing so, the attacker must return a high number of attestations in the response to Cosign. The result will be that the attacker can cause Cosign to go into a long or infinite loop that will prevent other users from verifying their data. In Kyvernos case, an attacker whose privileges are limited to making requests to the cluster can make a request with an image reference to their own registry, trigger the infinite loop and deny other users from completing their admission requests. Alternatively, the attacker can obtain control of the registry used by an organization and return a high number of attestations instead the expected number of attestations. The issue can be mitigated rather simply by setting a limit to the limit of attestations that Cosign will loop through. The limit does not need to be high to be within the vast majority of use cases and still prevent the endless data attack. This issue has been patched in version 2.2.1 and users are advised to upgrade.
- Record
BIT-cosign-2023-46737- Updated
- 2026-11-02
OSVGO-2023-2181 No score
Denial of service attack from remote registry in github.com/sigstore/cosign
An attacker who controls a remote registry can return a high number of attestations and/or signatures to cosign. This can cause cosign to enter a long loop resulting in a denial of service, i.e., endless data attack.
- Record
GO-2023-2181- Updated
- 2026-11-02
OSVopenSUSE-SU-2024:13402-1 No score
cosign-2.2.1-1.1 on GA media
These are all security issues fixed in the cosign-2.2.1-1.1 package on the GA media of openSUSE Tumbleweed.
- Record
openSUSE-SU-2024:13402-1- Updated
- 2026-11-02
OSVSUSE-SU-2023:4870-1 No score
Security update for cosign
This update for cosign fixes the following issues:
Updated to 2.2.1 (jsc#SLE-23879)
- Enhancements:
- CVE-2023-46737: Possible endless data attack from attacker-controlled registry (bsc#1216933)
- feat: Support basic auth and bearer auth login to registry (#3310)
- add support for ignoring certificates with pkcs11 (#3334)
- Support ReplaceOp in Signatures (#3315)
- feat: added ability to get image digest back via triangulate (#3255)
- feat: add
--onlyflag incosign copyto copy sign, att & sbom (#3247) - feat: add support attaching a Rekor bundle to a container (#3246)
- feat: add support outputting rekor response on signing (#3248)
- feat: improve dockerfile verify subcommand (#3264)
- Add guard flag for experimental OCI 1.1 verify. (#3272)
- Deprecate SBOM attachments (#3256)
- feat: dedent line in cosign copy doc (#3244)
- feat: add platform flag to cosign copy command (#3234)
- Add SLSA 1.0 attestation support to cosign. Closes #2860 (#3219)
- attest: pass OCI remote opts to att resolver. (#3225)
- Bug Fixes:
- Merge pull request from GHSA-vfp6-jrw2-99g9
- fix: allow cosign download sbom when image is absent (#3245)
- ci: add a OCI registry test for referrers support (#3253)
- Fix ReplaceSignatures (#3292)
- Stop using deprecated in_toto.ProvenanceStatement (#3243)
- Fixes #3236, disable SCT checking for a cosign verification when using .. (#3237)
- fix: update error in
SignedEntityto be more descriptive (#3233) - Fail timestamp verification if no root is provided (#3224)
- Documentation:
- Add some docs about verifying in an air-gapped environment (#3321)
- Update CONTRIBUTING.md (#3268)
- docs: improves the Contribution guidelines (#3257)
- Remove security policy (#3230)
- Others:
- Set go to min 1.21 and update dependencies (#3327)
- Update contact for code of conduct (#3266)
- Update .ko.yaml (#3240)
Updated to 2.2.0 (jsc#SLE-23879)
- Enhancements
- switch to uploading DSSE types to rekor instead of intoto (#3113)
- add 'cosign sign' command-line parameters for mTLS (#3052)
- improve error messages around bundle != payload hash (#3146)
- make VerifyImageAttestation function public (#3156)
- Switch to cryptoutils function for SANS (#3185)
- Handle HTTP_1_1_REQUIRED errors in github provider (#3172)
- Bug Fixes
- Fix nondeterminsitic timestamps (#3121)
- Documentation
- doc: Add example of sign-blob with key in env var (#3152)
- add deprecation notice for cosign-releases GCS bucket (#3148)
- update doc links (#3186)
Updated to 2.1.1 (jsc#SLE-23879)
- Bug Fixes
- wait for the workers become available again to continue the execution (#3084)
- fix help text when in a container (#3082)
Updated to 2.1.0 (jsc#SLE-23879)
- Breaking Change: The predicate is now a required flag in the attest commands, set via the --type flag.
- Enhancements
- Verify sigs and attestations in parallel (#3066)
- Deep inspect attestations when filtering download (#3031)
- refactor bundle validation code, add support for DSSE rekor type (#3016)
- Allow overriding remote options (#3049)
- feat: adds no cert found on sig exit code (#3038)
- Make predicate a required flag in attest commands (#3033)
- Added support for attaching Time stamp authority Response in attach command (#3001)
- Add sign --sign-container-identity CLI (#2984)
- Feature: Allow cosign to sign digests before they are uploaded. (#2959)
- accepts attachment-tag-prefix for cosign copy (#3014)
- Feature: adds '--allow-insecure-registry' for cosign load (#3000)
- download attestation: support --platform flag (#2980)
- Cleanup: Add Digest to the SignedEntity interface. (#2960)
- verify command: support keyless verification using only a provided certificate chain with non-fulcio roots (#2845)
- verify: use workers to limit the paralellism when verifying images with --max-workers flag (#3069)
- Bug Fixes
- Fix pkg/cosign/errors (#3050)
- Fix: update doc to…
- Record
SUSE-SU-2023:4870-1- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
github.com/sigstore/cosign/v2Go |
before 2.2.1 | 2.2.1 |
github.com/sigstore/cosignGo |
through 1.13.1 | 1.13.2 |
cosignAlpine:v3.19 |
before 2.2.1-r0 | 2.2.1-r0 |
cosignAlpine:v3.20 |
before 2.2.1-r0 | 2.2.1-r0 |
cosignAlpine:v3.21 |
before 2.2.1-r0 | 2.2.1-r0 |
cosignAlpine:v3.22 |
before 2.2.1-r0 | 2.2.1-r0 |
cosignAlpine:v3.23 |
before 2.2.1-r0 | 2.2.1-r0 |
cosignAlpine:v3.24 |
before 2.2.1-r0 | 2.2.1-r0 |
cosignBitnami |
before 2.2.1 | 2.2.1 |
github.com/sigstore/cosignGo |
before 1.13.2 | 1.13.2 |
Show 6 moreShow less
| Package | Affected | Fixed |
|---|---|---|
github.com/sigstore/cosignGo |
All versions | None known |
cosignSUSE:Linux Enterprise Module for Basesystem 15 SP4 |
before 2.2.1-150400.3.14.1 | 2.2.1-150400.3.14.1 |
cosignSUSE:Linux Enterprise Module for Basesystem 15 SP5 |
before 2.2.1-150400.3.14.1 | 2.2.1-150400.3.14.1 |
cosignopenSUSE:Leap 15.4 |
before 2.2.1-150400.3.14.1 | 2.2.1-150400.3.14.1 |
cosignopenSUSE:Leap 15.5 |
before 2.2.1-150400.3.14.1 | 2.2.1-150400.3.14.1 |
cosignopenSUSE:Tumbleweed |
before 2.2.1-1.1 | 2.2.1-1.1 |
History
| Recorded | Changed | Sources |
|---|---|---|
| affected, aliases, references | OSV | |
| aliases, published | EUVD | |
| first indexed | CVE List, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2023-46737 is a low vulnerability (CVSS 3.1) in Sigstore Cosign, published November 7, 2023. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.64%, the 50th percentile. Fixed in github.com/sigstore/cosign/v2 2.2.1.
References
github.com/sigstore/cosign/security/advisories/GHSA-vfp6-jrw2-99g9
nvd.nist.gov/vuln/detail/CVE-2023-46737
Show 7 moreShow less
security.alpinelinux.org/vuln/CVE-2023-46737
suse.com/support/update/announcement/2023/suse-su-20234870-1
bugzilla.suse.com/1216933
Left out here: the rest of 1 source description. The JSON record has them.