Nixpkgs security tracker

Login with GitHub

Suggestions search

With package: rekor-server

Found 3 matching suggestions

View:
Compact
Detailed
Published
Permalink CVE-2026-48702
7.5 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): None (N)
  • Integrity (I): None (N)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): None (N)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): High (H)
updated 12 hours ago by @LeSuisse Activity log
  • Created suggestion
  • @LeSuisse ignored
    3 packages
    • python313Packages.sigstore-rekor-types
    • python314Packages.sigstore-rekor-types
    • rekor-cli
  • @LeSuisse accepted
  • @LeSuisse published on GitHub
Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic

Rekor is a software supply chain transparency log. Starting in version 0.3.0 and prior to version 1.5.2, the `Package.Unmarshal()` function in `pkg/types/alpine/apk.go` decompresses the signature and control gzip members of an APK file into in-memory buffers without bounding the total decompressed size. The existing `max_apk_metadata_size` check (default 1MB) is only applied to individual tar entry header sizes after decompression completes, so it does not prevent a decompression bomb from consuming unbounded heap memory. An attacker can craft a gzip stream that compresses at a ~1000:1 ratio (e.g., 2MB compressed zeros → 2GB decompressed). When submitted as spec.package.content in an Alpine `ProposedEntry`, the server decompresses the full payload into memory during request processing, triggering a fatal Go runtime out-of-memory error or OS OOM-kill that cannot be caught by the server's recover() middleware. This is reachable via two unauthenticated endpoints, `POST /api/v1/log/entries (createLogEntry)` and `POST /api/v1/log/entries/retrieve (searchLogQuery)`. Both invoke `V001Entry.Canonicalize()` → `fetchExternalEntities()` → `apk.Unmarshal(packageData)`, which performs the unbounded decompression. Version 1.5.2 patches the issue. There is no effective workaround. Setting `max_request_body_size` reduces but does not eliminate exposure due to the ~1000:1 compression ratio (a 1MB body limit still allows ~1GB heap allocation). Setting `max_apk_metadata_size` has no effect on this vulnerability since the check is applied after decompression.

Affected products

rekor
  • ==>= 0.3.0, < 1.5.2

Matching in nixpkgs

Ignored packages (3)

pkgs.rekor-cli

CLI client for Sigstore, the Signature Transparency Log

Package maintainers

Needs backport
Published
Permalink CVE-2026-24117
5.3 MEDIUM
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): Low (L)
  • Integrity (I): None (N)
  • Availability (A): None (N)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): Low (L)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): None (N)
updated 6 months, 3 weeks ago by @LeSuisse Activity log
  • Created suggestion
  • @LeSuisse ignored
    3 packages
    • rekor-cli
    • python312Packages.sigstore-rekor-types
    • python313Packages.sigstore-rekor-types
  • @LeSuisse deleted
    2 maintainers
    • @developer-guy
    • @06kellyjac
    maintainer.delete
  • @LeSuisse added
    2 maintainers
    • @fabaff
    • @Bot-wxt1221
    maintainer.add
  • @LeSuisse deleted
    3 maintainers
    • @LeSuisse
    • @Bot-wxt1221
    • @fabaff
    maintainer.delete
  • @LeSuisse added maintainer @LeSuisse maintainer.add
  • @LeSuisse accepted
  • @LeSuisse published on GitHub
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-server

Sigstore server, the Signature Transparency Log

Ignored packages (3)

pkgs.rekor-cli

CLI client for Sigstore, the Signature Transparency Log

Package maintainers

Ignored maintainers (2)
https://github.com/sigstore/rekor/security/advisories/GHSA-4c4x-jm2x-pf9j
Published
Permalink CVE-2026-23831
5.3 MEDIUM
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): None (N)
  • Integrity (I): None (N)
  • Availability (A): Low (L)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): None (N)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): Low (L)
updated 6 months, 3 weeks ago by @LeSuisse Activity log
  • Created suggestion
  • @LeSuisse ignored
    2 packages
    • python313Packages.sigstore-rekor-types
    • python312Packages.sigstore-rekor-types
  • @LeSuisse deleted
    2 maintainers
    • @developer-guy
    • @06kellyjac
    maintainer.delete
  • @LeSuisse added
    2 maintainers
    • @fabaff
    • @Bot-wxt1221
    maintainer.add
  • @LeSuisse deleted
    2 maintainers
    • @fabaff
    • @Bot-wxt1221
    maintainer.delete
  • @LeSuisse ignored package rekor-cli
  • @LeSuisse accepted
  • @LeSuisse published on GitHub
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-server

Sigstore server, the Signature Transparency Log

Ignored packages (3)

pkgs.rekor-cli

CLI client for Sigstore, the Signature Transparency Log

Package maintainers

Ignored maintainers (2)
https://github.com/sigstore/rekor/security/advisories/GHSA-273p-m2cw-6833