A palette PNG reaches a flaw in libpng's palette handling
One of three libpng flaws in the paths that handle palette (indexed-colour) PNGs. The upstream record was not re-fetched when this entry was written; see notes.
- Advisory
- CVE-2026-33636 (also GHSA-wjr5-c57x-95m2)
- Library
- libpng, libpng1.6 on Debian
- Published
- Severity
- 7.6 out of 10, as published
- Affected
- >= 1.6.36, <= 1.6.55
- Fixed in
- 1.6.56
- Reaches you
- by opening a file
What triggers it
Opening a palette-type PNG.
What sillybos does
Refused with a setting
sillybos refuses the triggering file when the policy says so (Policy(png_colour_types={"greyscale", "rgb"})); the default policy lets it through.
The colour type is in the PNG's IHDR. The default allows all five colour types; a policy for scans alone can keep to greyscale and RGB, which keeps palette PNGs from the decoder.
Cited from the policy's own notes (policy.py), written from the advisory at the time; the OSV record was unreachable when this entry was made and its fields should be filled in.
Proved by this test in the sillybos suite, which builds the triggering file from bytes and checks that it is refused:
How to protect yourself
In general. Keep libpng current.
Specifically. If nothing you handle is a palette PNG, say so in the policy: sillybos --png-colour-types greyscale,rgb.
The general advice applies to every row here.
Sources
- https://github.com/advisories/GHSA-wjr5-c57x-95m2
- https://osv.dev/vulnerability/CVE-2026-33636
- The record entry, triaged 2026-11-01, last checked 2026-11-01