{
    "dataType": "CVE_RECORD",
    "dataVersion": "5.2",
    "cveMetadata": {
        "cveId": "CVE-2026-48702",
        "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "state": "PUBLISHED",
        "assignerShortName": "GitHub_M",
        "dateReserved": "2026-05-22T18:47:27.754Z",
        "datePublished": "2026-08-13T13:14:19.324Z",
        "dateUpdated": "2026-08-13T15:16:26.293Z"
    },
    "containers": {
        "cna": {
            "title": "Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic",
            "problemTypes": [
                {
                    "descriptions": [
                        {
                            "cweId": "CWE-770",
                            "lang": "en",
                            "description": "CWE-770: Allocation of Resources Without Limits or Throttling",
                            "type": "CWE"
                        }
                    ]
                }
            ],
            "metrics": [
                {
                    "cvssV3_1": {
                        "attackComplexity": "LOW",
                        "attackVector": "NETWORK",
                        "availabilityImpact": "HIGH",
                        "baseScore": 7.5,
                        "baseSeverity": "HIGH",
                        "confidentialityImpact": "NONE",
                        "integrityImpact": "NONE",
                        "privilegesRequired": "NONE",
                        "scope": "UNCHANGED",
                        "userInteraction": "NONE",
                        "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
                        "version": "3.1"
                    }
                }
            ],
            "references": [
                {
                    "name": "https://github.com/sigstore/rekor/security/advisories/GHSA-47q9-m4ww-924m",
                    "tags": [
                        "x_refsource_CONFIRM"
                    ],
                    "url": "https://github.com/sigstore/rekor/security/advisories/GHSA-47q9-m4ww-924m"
                }
            ],
            "affected": [
                {
                    "vendor": "sigstore",
                    "product": "rekor",
                    "versions": [
                        {
                            "version": ">= 0.3.0, < 1.5.2",
                            "status": "affected"
                        }
                    ]
                }
            ],
            "providerMetadata": {
                "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
                "shortName": "GitHub_M",
                "dateUpdated": "2026-08-13T13:14:19.324Z"
            },
            "descriptions": [
                {
                    "lang": "en",
                    "value": "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."
                }
            ],
            "source": {
                "advisory": "GHSA-47q9-m4ww-924m",
                "discovery": "UNKNOWN"
            }
        },
        "adp": [
            {
                "metrics": [
                    {
                        "other": {
                            "type": "ssvc",
                            "content": {
                                "timestamp": "2026-08-13T15:12:38.632066Z",
                                "id": "CVE-2026-48702",
                                "options": [
                                    {
                                        "Exploitation": "none"
                                    },
                                    {
                                        "Automatable": "yes"
                                    },
                                    {
                                        "Technical Impact": "partial"
                                    }
                                ],
                                "role": "CISA Coordinator",
                                "version": "2.0.3"
                            }
                        }
                    }
                ],
                "title": "CISA ADP Vulnrichment",
                "providerMetadata": {
                    "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
                    "shortName": "CISA-ADP",
                    "dateUpdated": "2026-08-13T15:16:26.293Z"
                }
            }
        ]
    }
}