False positive on libglib2.0-0t64 version 2.86.3-4 for CVE-2025-13601

[benglewis]

IDs

CVE-2025-13601

Description

See: https://gitlab.gnome.org/GNOME/glib/-/blob/2.86.3/NEWS?ref_type=tags
The vulnerability fix was back-ported to 2.86.3

Reproduction Steps

Install from Debian APT package:

echo "deb http://deb.debian.org/debian sid main" > /etc/apt/sources.list.d/sid.list \
  && printf "Package: libglib2.0-0t64 libglib2.0-bin libglib2.0-data\nPin: release n=sid\nPin-Priority: 990\n\nPackage: *\nPin: release n=sid\nPin-Priority: 100\n" > /etc/apt/preferences.d/sid-glib \
  && apt-get update \
  && apt-get install -y --no-install-recommends -t sid \
    libglib2.0-0t64 libglib2.0-bin libglib2.0-data

Then scan with Trivy GitHub Action

Target

Container Image

Scanner

Vulnerability

Target OS

Debian 13 Trixie

Debug Output

:/

I couldn't find an easy way to get this out of the Trivy GitHub Action workflow without changing our code, which doesn't seem logical.

Version

v0.56.1
TRIVY_DB_REPOSITORY: ghcr.io/aquasecurity/trivy-db,public.ecr.aws/aquasecurity/trivy-db

Likewise, I couldn't find an easy way to get this out of the Trivy GitHub Action workflow without changing our code, which doesn't seem logical.

Checklist

• Read the documentation regarding wrong detection
• Ran Trivy with -f json that shows data sources and confirmed that the security advisory in data sources was correct

[knqyf263]

This is a known issue that occurs when packages from a different repository (in this case, sid) are installed on a system detected as another release (trixie).

Root Cause

Trivy detects your OS as Debian 13 (trixie) and uses the trixie vulnerability database. According to the Debian Security Tracker:

Release	Version	Status
trixie	2.84.4-3~deb13u1	Vulnerable
sid	2.86.3-4	Fixed

Your installed version 2.86.3-4 is the sid (fixed) version, but Trivy checks it against the trixie database where this version doesn't exist, resulting in a false positive.

Related Issues

• Possible false positive for ubuntu packages, when fixed package sources from newer ubuntu versions are used to build and install debs #403 - False positive when installing packages from a different Ubuntu version
• Distroless cross distribution packages #1525 - Distroless cross distribution packages

Why Automatic Detection is Difficult

We have previously investigated whether Trivy could automatically detect the source repository:

• /var/lib/apt/lists/ contains repository metadata that could identify package sources, but these files are typically deleted in container images to reduce size
• /var/lib/dpkg/status does not contain repository information

Potential Improvements

Although we're not sure that the following approaches are appropriate:

• /var/lib/apt/lists/ contains repository metadata (Packages files) that could identify which repository each package came from. These files are typically deleted in container images to reduce size, but when present, Trivy could parse them to determine the correct vulnerability database to use.
• Version suffixes (e.g., ~deb13u1, +deb12u2) could be used as a heuristic to detect when an installed package version doesn't match the detected OS release, which could help reduce false positives in some cases.

[benglewis]

Both of the suggested improvements would be greatly appreciated!