CVE-2026-33636: 
NixOS vulnerability analysis and mitigation

CVE-2026-33636 is an out-of-bounds read and write vulnerability in libpng's ARM/AArch64 Neon-optimized palette expansion path. Affecting libpng versions 1.6.36 through 1.6.55, the flaw exists in arm/palette_neon_intrinsics.c and is triggered when expanding 8-bit paletted PNG rows to RGB or RGBA on ARM/AArch64 systems with Neon enabled. The vulnerability was published on March 26, 2026, with a fix released in libpng 1.6.56. It carries a CVSS v3.1 base score of 7.6 (High) (GitHub Advisory, Microsoft MSRC).

The root cause (CWE-125: Out-of-bounds Read; CWE-787: Out-of-bounds Write) lies in the Neon loop within png_do_expand_palette_rgba8_neon and png_do_expand_palette_rgb8_neon, which advance in fixed-size chunks (4 pixels for RGBA, 8 pixels for RGB) using for (i = 0; i < row_width; i += pixels_per_chunk) without verifying that a full chunk of input pixels remains. Because the implementation works backward from the end of the row, the final iteration dereferences sp - 3 (RGBA) or sp - 7 (RGB) before the start of the row buffer (OOB read), and the corresponding Neon store instructions (vst1q_u32 / vst3_u8) write expanded pixel data to the same underflowed positions (OOB write). A secondary issue is that both functions pre-adjust *ddp before the loop (by 15 bytes for RGBA, 23 bytes for RGB) and fail to undo this adjustment before handing off to the scalar fallback, compounding the OOB write. The vulnerability is reachable via normal decoding of attacker-controlled PNG input (color type 3, palette-based) with specific row widths: RGBA path requires width ≥ 5 where width % 4 != 0; RGB path requires width > 8 where width % 8 != 0 (GitHub Advisory, Fix Commit).

Successful exploitation can result in information disclosure (the OOB read can leak heap contents through decoded pixel output, since the attacker-controlled palette can map byte values to distinguishable colors), heap corruption (the OOB write deposits attacker-influenced palette data at deterministic negative offsets from the row buffer), and reliable process crashes (denial of service). Arbitrary code execution has not been demonstrated but cannot be ruled out given the heap corruption primitive. The impact is limited to ARM/AArch64 systems with Neon enabled; x86/x64, PowerPC VSX, and LoongArch LSX builds are unaffected (GitHub Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The vulnerability requires user interaction — a victim must open or process a malicious PNG file — and targets only ARM/AArch64 builds with Neon enabled, limiting the attack surface. The EPSS score is approximately 0.032% (very low probability of exploitation in the near term). The CVE is not listed in the CISA Known Exploited Vulnerabilities catalog. Microsoft has acknowledged the vulnerability in its products (azl3_libpng_1.6.55-1 and cbl2_libpng_1.6.55-1) (Microsoft MSRC).

1. Craft a malicious PNG file: Create a palette-based PNG (color type 3) with an 8-bit palette. For the RGBA path, include a tRNS chunk and set the image width to a value ≥ 5 where width % 4 != 0 (e.g., width = 5, 9, 13). For the RGB path, omit the tRNS chunk and set width > 8 where width % 8 != 0 (e.g., width = 9, 17).
2. Construct the palette for information leakage: Populate the palette so that each index maps to a distinguishable color, enabling the attacker to read heap contents through the decoded pixel output produced by the OOB read.
3. Deliver the PNG to the target: Distribute the crafted PNG via any channel that causes the target ARM/AArch64 application (compiled with Neon enabled) to decode it — e.g., embedding it in a web page, email attachment, document, or image upload endpoint.
4. Trigger the OOB access: When the application calls png_read_image() or equivalent, libpng invokes the Neon palette expansion path. The final loop iteration reads from sp - 3 (RGBA) or sp - 7 (RGB) before the row buffer start, and writes expanded data to the underflowed destination pointer.
5. Achieve the objective: Depending on heap layout, the attacker may observe leaked heap bytes in the decoded image output (information disclosure), cause heap corruption for potential further exploitation, or reliably crash the process (DoS) (GitHub Advisory).

• File System: Presence of crafted PNG files with color type 3 (palette-based), unusual row widths (e.g., width % 4 ≠ 0 or width % 8 ≠ 0), and a tRNS chunk; unexpected PNG files in upload directories or temporary folders on ARM-based servers.
• Process: Application crashes (segmentation faults, SIGBUS, or SIGABRT) in processes that decode PNG images on ARM/AArch64 systems, particularly in functions related to png_do_expand_palette or palette_neon_intrinsics.
• Logs: Crash reports or core dumps referencing arm/palette_neon_intrinsics.c, png_do_expand_palette_rgba8_neon, or png_do_expand_palette_rgb8_neon; application error logs showing repeated failures when processing specific PNG files.
• Network: Unusual inbound delivery of PNG files to image-processing services on ARM infrastructure, particularly files with atypical dimensions or palette configurations.

Upgrade libpng to version 1.6.56 or later, which contains the fix (commit aba9f18) that restricts the Neon loop to full chunks only, removes the erroneous post-loop adjustment, and correctly undoes the *ddp pre-adjustment before the scalar fallback (Fix Commit, GitHub Advisory). Microsoft has released updates for affected products (azl3_libpng_1.6.55-1 and cbl2_libpng_1.6.55-1) (Microsoft MSRC). Downstream distributions including Red Hat, Debian, Ubuntu, Fedora, openSUSE, Slackware, Amazon Linux, and Rocky Linux have also issued security advisories and updated packages. As a temporary workaround, build libpng with -DPNG_ARM_NEON_OPT=0 in CFLAGS to disable ARM Neon optimizations entirely, though this will reduce performance. Additionally, restrict processing of PNG files from untrusted sources until patching is complete.

The vulnerability was reported by researcher Amemoyoi and disclosed via the libpng GitHub Security Advisory on March 25–26, 2026 (GitHub Advisory). Security news outlets including GBHackers, CyberSecurityNews, and SecurityOnline covered the vulnerability, noting its potential for RCE on ARM/Neon systems alongside the companion CVE-2026-33416. Social media discussion appeared on Mastodon and Bluesky shortly after disclosure. The vulnerability received broad attention from Linux distribution maintainers, with rapid patch releases across Debian, Ubuntu, Red Hat, Fedora, openSUSE, Slackware, and others, reflecting the wide deployment of libpng across the ecosystem.