Vulnerability in rekor (UBUNTU-CVE-2026-48702)

Summary

Vulnerability in rekor (UBUNTU-CVE-2026-48702). Risk of unauthorized operations or information disclosure. Exploitable via POST /api/v1/log/entries.

Original description

The description as published by the source.

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 t…

Source: OSV.dev (Open Source Vulnerabilities) OSV

Auto-generated summary

Assembled by SecPulse from the source data (CVSS, CWE, affected versions) using templates — no AI involved. Check the original description and references below for exact details.

A vulnerability tracked as UBUNTU-CVE-2026-48702 has been found in rekor.
Attackers can target a specific entry point like POST /api/v1/log/entries over the network to misuse the product.
Risk of unauthorized operations or information disclosure.
What to do: apply the vendor's official patched release.
If unsure, ask your IT team or search "rekor UBUNTU-CVE-2026-48702" on the vendor's site.

UBUNTU-CVE-2026-48702 (rekor)
Attack vector: remote (network-reachable) / unauthenticated / no user interaction
Attack surface: POST /api/v1/log/entries / POST /api/v1/log/entries/retrieve / max_apk_metadata_size / ProposedEntry
Plan: 1) Audit SBOM/dependencies, 2) Stage→prod upgrade, 3) Add WAF/proxy monitoring on affected endpoints, 4) Hunt IOCs in logs.
Refs: see the GHSA / vendor advisory / patched release linked on this page.

❓ What is the problem

A vulnerability (unclassified) exists in rekor. Attackers reach the vulnerable code path via POST /api/v1/log/entries without authentication.

📍 Affected scope

Check the vendor advisory for the affected versions of rekor. Attack surface: POST /api/v1/log/entries / POST /api/v1/log/entries/retrieve / max_apk_metadata_size / ProposedEntry.

🔥 Severity

Severity: ?. Risk of unauthorized operations or information disclosure.

🔧 How to fix

Update to the patched release per vendor advisory.

🛡️ Workaround

Until the patch is applied: disable the affected feature, apply WAF rules, or restrict access via network ACLs.

🔍 Detection

Search webserver/proxy logs for unusual POST /api/v1/log/entries requests with malformed payloads or SQL meta-characters. Run grep -r 'rekor' . against your dependency files (package-lock.json, requirements.txt, go.sum) to find affected services.

Response actions

Concrete steps and command examples for SOC/SRE teams to execute in order

1
Identify exposure identify
```
grep -r 'rekor' . | grep -v node_modules
```
リポジトリと本番環境の依存ファイル (package-lock.json / requirements.txt / go.sum / Gemfile.lock 等) で rekor を grep し、稼働しているサービス・バージョンを把握する。
2
Hunt for indicators of compromise detect
```
grep 'POST /api/v1/log/entries' /var/log/nginx/access.log | grep -E '(unusual_payload|sqli_pattern)'
```
アクセスログで POST /api/v1/log/entries への異常なリクエスト (不正な認証ヘッダ・SQLメタ文字)を過去 30〜90日分捜索。WAF/SIEM があれば該当パスのアラート発火履歴を確認。
3
Post-deployment verification verify
```
Replay attack against POST /api/v1/log/entries on staging to confirm patch closes the vector
```
パッチ適用後、ステージングで PoC または同等の悪用パターンを再現して脆弱性が閉じたことを確認。本番では Step 2 と同じログクエリでアラート再発が無いか継続監視。

Affected packages

Ubuntu:Pro:26.04:LTS rekor

[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}]

References

report ubuntu.com
report cve.org
report github.com