29 września 2026 projekt libpng opublikował GHSA-qvg3-h654-xq3j — use-after-free zlib input w png_read_end po niepełnej dekompresji chunków zTXt, iTXt lub iCCP (severity Moderate). To dobry temat, bo package match odpowiada tylko na pytanie „czy libpng jest obecny”, a realna exploitability zależy od stanu parsera.
png_read_end po incomplete decompression chunków zTXt/iTXt/iCCP. To nie dowód RCE — nie dopisuj RCE automatycznie (crash / skutki zależne od alokatora).png_read_end + wskazane chunki + wejście w incomplete decompression + istotne uprawnienia procesu.Attack path
False positives i false negatives
SCA może zgłosić każdą aplikację linkującą libpng — ale aplikacja generująca wyłącznie własne obrazy, albo nigdy nieprzechodząca przez podatny parser state, ma istotnie niższe realne ryzyko. Z drugiej strony statycznie linkowana libpng może nie być widoczna jako system package: potrzebne bywają SBOM z build pipeline, symbol/fingerprint analysis lub provenance obrazu. To ta sama lekcja co przy Netty (SCA vs runtime).
Remediation verification
Po wdrożeniu poprawki: potwierdź wersję/commit w finalnym binarium, uruchom corpus z malformed zTXt/iTXt/iCCP, użyj ASan/UBSan, potwierdź brak UAF przy png_read_end i sprawdź wszystkie aplikacje statycznie linkujące bibliotekę. Upstream nie potwierdza exploitation in the wild.
Powiązane na blogu
- Netty: SCA vs runtime — obecność pakietu ≠ affectedness
- FreeRDP: runtime-role VEX — code path decyduje
Źródło
- libpng — Security advisories (GHSA-qvg3-h654-xq3j) — github.com
Nota redakcyjna: stan informacji 29 września 2026. GHSA-qvg3-h654-xq3j (libpng, Moderate, use-after-free w png_read_end po niepełnej dekompresji). Artykuł nie utożsamia UAF z RCE i nie potwierdza active exploitation.