Nixpkgs security tracker

Login with GitHub
⚠️ You are using a production deployment that is still only suitable for demo purposes. Any work done in this might be wiped later without notice.

Suggestions search

With package: python312Packages.sigstore-rekor-types

Found 3 matching suggestions

View:
Compact
Detailed
Permalink CVE-2026-24137
5.8 MEDIUM
  • CVSS version: 3.1
  • Attack vector (AV): NETWORK
  • Attack complexity (AC): HIGH
  • Privileges required (PR): HIGH
  • User interaction (UI): NONE
  • Scope (S): CHANGED
  • Confidentiality impact (C): NONE
  • Integrity impact (I): HIGH
  • Availability impact (A): NONE
created 2 months, 3 weeks ago
sigstore legacy TUF client allows for arbitrary file writes with target cache path traversal

sigstore framework is a common go library shared across sigstore services and clients. In versions 1.10.3 and below, the legacy TUF client (pkg/tuf/client.go) supports caching target files to disk. It constructs a filesystem path by joining a cache base directory with a target name sourced from signed target metadata; however, it does not validate that the resulting path stays within the cache base directory. A malicious TUF repository can trigger arbitrary file overwriting, limited to the permissions that the calling process has. Note that this should only affect clients that are directly using the TUF client in sigstore/sigstore or are using an older version of Cosign. Public Sigstore deployment users are unaffected, as TUF metadata is validated by a quorum of trusted collaborators. This issue has been fixed in version 1.10.4. As a workaround, users can disable disk caching for the legacy client by setting SIGSTORE_NO_CACHE=true in the environment, migrate to https://github.com/sigstore/sigstore-go/tree/main/pkg/tuf, or upgrade to the latest sigstore/sigstore release.

Affected products

sigstore
  • ==< 1.10.4

Matching in nixpkgs

Package maintainers

Permalink CVE-2026-24117
5.3 MEDIUM
  • CVSS version: 3.1
  • Attack vector (AV): NETWORK
  • Attack complexity (AC): LOW
  • Privileges required (PR): NONE
  • User interaction (UI): NONE
  • Scope (S): UNCHANGED
  • Confidentiality impact (C): LOW
  • Integrity impact (I): NONE
  • Availability impact (A): NONE
created 2 months, 3 weeks ago
Rekor affected by Server-Side Request Forgery (SSRF) via provided public key URL

Rekor is a software supply chain transparency log. In versions 1.4.3 and below, attackers can trigger SSRF to arbitrary internal services because /api/v1/index/retrieve supports retrieving a public key via user-provided URL. Since the SSRF only can trigger GET requests, the request cannot mutate state. The response from the GET request is not returned to the caller so data exfiltration is not possible. A malicious actor could attempt to probe an internal network through Blind SSRF. The issue has been fixed in version 1.5.0. To workaround this issue, disable the search endpoint with --enable_retrieve_api=false.

Affected products

rekor
  • ==< 1.5.0

Matching in nixpkgs

pkgs.rekor-cli

CLI client for Sigstore, the Signature Transparency Log

Package maintainers

Permalink CVE-2026-23831
5.3 MEDIUM
  • CVSS version: 3.1
  • Attack vector (AV): NETWORK
  • Attack complexity (AC): LOW
  • Privileges required (PR): NONE
  • User interaction (UI): NONE
  • Scope (S): UNCHANGED
  • Confidentiality impact (C): NONE
  • Integrity impact (I): NONE
  • Availability impact (A): LOW
created 2 months, 3 weeks ago
Rekor COSE v0.0.1 Canonicalize crashes when passed empty Message

Rekor is a software supply chain transparency log. In versions 1.4.3 and below, the entry implementation can panic on attacker-controlled input when canonicalizing a proposed entry with an empty spec.message, causing nil Pointer Dereference. Function validate() returns nil (success) when message is empty, leaving sign1Msg uninitialized, and Canonicalize() later dereferences v.sign1Msg.Payload. A malformed proposed entry of the cose/v0.0.1 type can cause a panic on a thread within the Rekor process. The thread is recovered so the client receives a 500 error message and service still continues, so the availability impact of this is minimal. This issue has been fixed in version 1.5.0.

Affected products

rekor
  • ==< 1.5.0

Matching in nixpkgs

pkgs.rekor-cli

CLI client for Sigstore, the Signature Transparency Log

Package maintainers