TL;DR: CVE-2026-19519 is a denial-of-service vulnerability in claircore, the Go library that powers Red Hat's Clair container vulnerability scanner. A crafted RPM header embedded in a container image layer triggers an unchecked type assertion that panics the indexer process. The crash is unrecovered. Any deployment that automatically scans untrusted container images, including Quay Container Registry integrations, is affected.

What happened

Clair scans container images for known vulnerabilities by parsing package manager metadata inside each layer. For RPM-based distributions (Fedora, RHEL, CentOS, Rocky, AlmaLinux), the claircore RPM scanner reads RPM headers to identify installed packages and their versions.

The bug sits in the type assertion logic. Go type assertions of the form value.(ConcreteType) panic at runtime if the value does not match the asserted type. The RPM header parser contains such an assertion without a surrounding recover block or a comma-ok fallback. When a container layer includes RPM header data that does not match the expected structure, the assertion fires, the goroutine panics, and because no recovery handler catches it, the entire Clair indexer process crashes.

This is CWE-617, a reachable assertion. The NVD assigned CVSS 3.1 with a base score of 4.3 (MEDIUM) using the vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L. The attack is network-accessible with low complexity. The attacker needs some level of privilege in the sense that their container image must actually get scanned, which in most deployments happens automatically when an image is pushed to a Quay registry or submitted to a Clair indexer API.

Who is affected

Claircore is the core scanning library behind Clair, Red Hat's open-source container vulnerability scanner. Clair is integrated into Quay Container Registry, Red Hat's enterprise container image registry, and is used independently by organizations running their own Clair deployments for container image scanning.

Any deployment where the Clair indexer automatically scans container images from untrusted or partially trusted sources is affected. This includes registry-integrated scanning pipelines, CI/CD security gates that pass images through Clair, and standalone Clair instances exposed to multiple tenants. In multi-tenant registry environments, one tenant pushing a crafted image could crash the shared indexer and disrupt vulnerability scanning for all other tenants.

The CVSS vector reflects the impact profile: confidentiality and integrity are unaffected. The vulnerability only impacts availability. The scanner process crashes and must be restarted. Repeated pushes of the crafted image would keep the scanner down.

What to do

Red Hat has published Bugzilla entry 2513781 tracking this issue. Check the Red Hat CVE page at access.redhat.com/security/cve/CVE-2026-19519 for fixed versions and errata as they become available.

If you run Clair or claircore directly from source, check for upstream patches on the quay/claircore GitHub repository. The fix requires either replacing the unconditional type assertion with a comma-ok check (val, ok := x.(Type)) or wrapping the parser in a recover handler that logs the malformed header and skips the layer instead of crashing the process.

In the interim, you can mitigate by running the Clair indexer under a process supervisor (systemd, supervisord) that restarts on crash. This does not prevent the crash but reduces downtime. For multi-tenant environments, consider rate-limiting image push or indexing operations to limit repeated crash triggers.

Why it matters

Container vulnerability scanners occupy a privileged position in the supply chain. They process untrusted input (container images from arbitrary sources) and are expected to handle malformed or adversarial data gracefully. A scanner that crashes on crafted input is itself a supply chain attack surface. An attacker who can degrade or disable vulnerability scanning creates a window where other vulnerabilities in the same images go undetected.

This class of bug is not theoretical. Container images are opaque archives. A registry that auto-scans pushes from thousands of users only needs one adversarial image to take scanning offline for everyone. The fix is straightforward in Go: never use a bare type assertion on data parsed from untrusted input. Always use the two-value form and handle the failure path.

References

• Red Hat CVE advisory
• Red Hat Bugzilla 2513781
• hol.org CVE page
• claircore GitHub repository