Skip to content

[SECURITY] consumer-prices-core: zlib1g integer-overflow CVE has no Debian fix — accept-risk vs. rebuild decision #4364

Description

@lspassos1

Context

Snyk flags a critical integer overflow / wraparound in zlib1g (1:1.2.13.dfsg-1) on the consumer-prices-core image. It rides in through the node:20-slim (Debian 12) base image used by consumer-prices-core/Dockerfile.

  • Snyk advisory: SNYK-DEBIAN12-ZLIB-6008963
  • Severity: Snyk / NVD CVSS v3.1 9.8 (Critical)
  • Remediation per Snyk: No remediation path available.

This one is the odd sibling of the GnuTLS findings on the same image. The GnuTLS CVEs are getting patched in #4365 (apt-get upgrade pulls libgnutls30 3.7.9-2+deb12u7). zlib1g can't be cleared the same way — there's no fixed Debian package to upgrade to, so apt-get upgrade leaves the version exactly where it is.

Why there's no fix

This matches the well-known MiniZip integer-overflow class in zlib (publicly tracked as CVE-2023-45853). The overflow lives in zlib's contrib/minizip component, which Debian does not compile into the shared libz that zlib1g ships. Debian's security team therefore tracks it as a no-fix / not-affecting-the-library issue for the packaged binary, which is exactly why Snyk says "no remediation path available."

Please confirm the CVE mapping from the Snyk advisory page before we write any justification text — I'm reading this off the Snyk ID + description rather than the (auth-gated) advisory body.

Reachability in this service

Per our SECURITY.md, only "dependency vulnerabilities with a viable attack vector" are in scope. consumer-prices-core is a Fastify + Playwright scraper; nothing in it feeds attacker-controlled archives into MiniZip, and the vulnerable code path isn't compiled into the libz we link against. So the practical exposure here looks like none — but that's a call worth making explicitly rather than leaving a red "Critical" sitting on the dashboard.

Options

  1. Accept & document — record a formal risk acceptance (no viable vector + no upstream fix). Cheapest, honest, leaves an audit trail.
  2. Suppress in Snyk — add a .snyk policy ignore for SNYK-DEBIAN12-ZLIB-6008963 with a written justification and an expiry, so the dashboard stops flagging it and automatically re-surfaces it if Debian ever ships a fix. Needs a maintainer sign-off since it's silencing a 9.8.
  3. Drop the Debian base entirely — migrate this service to node:22-alpine (every other service and .nvmrc are already on 22) or a Playwright/distroless image. Alpine ships zlib, not Debian's zlib1g, so the finding disappears at the source. Biggest effort, since Playwright/Chromium on musl needs its dependency set reworked — but it also retires the lingering Node 20 → 22 drift on this image.

Recommendation

Given the scoping in SECURITY.md and the lack of a reachable vector, I'd lean (1) + (2) now, with (3) as the clean long-term fix. Happy to send either the .snyk policy PR or the Alpine migration once a direction is picked.

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    claudeGenerated with Claude CodedockerDocker, self-hosting, containerssecuritySecurity-related

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions