An update for libpng is now available for openEuler-24.03-LTS-SP3 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2026-2535 Final 1.0 1.0 2026-05-29 Initial 2026-05-29 2026-05-29 openEuler SA Tool V1.0 2026-05-29 libpng security update An update for libpng is now available for openEuler-24.03-LTS-SP3 The libpng package contains libraries used by other programs for reading and writing PNG format files. The PNG format was designed as a replacement for GIF and, to a lesser extent, TIFF, with many improvements and extensions and lack of patent problems. Security Fix(es): ['Hello, everyone,\n\nThis is an out-of-band notice. Unlike previous libpng announcements,\nthis one doesn\'t coincide with a libpng release, and the disclosure\ncadence differs from the usual coordinated pattern:\n\n- The fix landed on the libpng18 development branch (commit\n faf0692468) approximately one month before this announcement.\n libpng 1.8.0 is in late beta with no tagged release yet, so\n there is no upstream release version with which to align the\n disclosure. Downstream consumers building directly from the\n libpng18 branch have had the fix available since it landed.\n- The vulnerable code originates in the third-party libpng-apng\n patch, which is not under upstream libpng control. The patch\n is applied downstream by Firefox and Thunderbird, as well as\n several Linux distributions (Gentoo and LFS/BLFS among others).\n The libpng-apng maintainer, Daisuke Nishikawa, has since released\n fixed revisions (libpng-1.6.57-apng.patch v2 and\n libpng-1.6.58-apng.patch); downstream consumers should either\n update to those (verifying that both upstream commits are\n included), or backport the upstream commits themselves (see\n "Related fix" below).\n\n=== CVE-2026-40930 ===\n\nChunk smuggling in the push-mode APNG parser via unconsumed\nchunk body\n\nSecurity advisory:', 'Fix on libpng18:', "CVSS 3.1: 5.4 (Medium); CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L\nCWE: CWE-436 (Interpretation Conflict)\nAffected (upstream): libpng 1.8.0 development branch (libpng18)\nAffected (downstream): libpng-1.6.49-apng.patch through\n libpng-1.6.57-apng.patch (original v1) on SourceForge\nNot affected: upstream libpng 1.6.x releases (no APNG support)\nFixed (upstream): libpng18 at commit faf0692468\nFixed (downstream): libpng-1.6.57-apng.patch v2 and\n libpng-1.6.58-apng.patch on SourceForge, released by the\n libpng-apng maintainer\nBuild-time mitigation: building libpng 1.8 with APNG disabled\n (i.e., without PNG_APNG_SUPPORTED), or building libpng 1.6\n without the libpng-apng patch, removes the vulnerable code.\n No runtime workaround exists for push-mode applications.\n\nThree inter-frame chunk discard paths in the push-mode APNG parser\nclear the chunk-header flag without consuming the chunk body and\nCRC, allowing attacker-controlled bytes inside a discarded chunk\nto be reinterpreted as a fresh chunk header on the next call to\npng_process_data.\n\nImpact depends on the application's CRC handling:\n\n- Default configuration: libpng calls png_error on the resulting\n CRC mismatch or APNG sequence-number violation, and the image\n fails to load. Impact is denial of service.\n- Relaxed configuration (png_set_crc_action with PNG_CRC_QUIET_USE\n or PNG_CRC_WARN_USE): smuggled bytes reach the APNG sequence\n counter and the zlib decompressor, and are decoded as frame\n pixel data. No code execution: zlib output writes into a\n pre-allocated row buffer. A crafted fake length exceeding the\n carrier chunk body causes cascading desynchronization beyond\n the carrier.\n\nSequential-mode reading (png_read_info / png_read_row /\npng_read_end) is not affected. Only push-mode (png_process_data)\nis vulnerable, and the Gecko-based browsers (for example) use it.\n\n=== Related fix ===\n\nA sibling defect in the same push-mode fdAT path was reported\nseparately in GitHub issue pnggroup/libpng#854 and fixed on the\nlibpng18 branch in commit 9ec49c2d56. It is distinct from\nCVE-2026-40930 and is not covered by the advisory above.\nDownstream consumers of libpng-apng should apply both commits to\nfully remediate the push-mode fdAT path. Those updating to the\nfixed libpng-apng revisions instead should verify that both commits\nare included; otherwise, 9ec49c2d56 must be backported separately.\n\nRelated fix on libpng18:", 'Credits:\n- Seung Min Shin (CVE-2026-40930 discovery)\n- Ryo Shimada (GitHub issue pnggroup/libpng#854)\n\n---\nCosmin Truta\nlibpng maintainer'](CVE-2026-40930) An update for libpng is now available for openEuler-24.03-LTS-SP3. openEuler Security has rated this update as having a security impact of medium. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. Medium libpng https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2535 https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-40930 https://nvd.nist.gov/vuln/detail/CVE-2026-40930 openEuler-24.03-LTS-SP3 libpng-1.6.40-12.oe2403sp3.aarch64.rpm libpng-debuginfo-1.6.40-12.oe2403sp3.aarch64.rpm libpng-debugsource-1.6.40-12.oe2403sp3.aarch64.rpm libpng-devel-1.6.40-12.oe2403sp3.aarch64.rpm libpng-static-1.6.40-12.oe2403sp3.aarch64.rpm libpng-tools-1.6.40-12.oe2403sp3.aarch64.rpm libpng-1.6.40-12.oe2403sp3.src.rpm libpng-1.6.40-12.oe2403sp3.x86_64.rpm libpng-debuginfo-1.6.40-12.oe2403sp3.x86_64.rpm libpng-debugsource-1.6.40-12.oe2403sp3.x86_64.rpm libpng-devel-1.6.40-12.oe2403sp3.x86_64.rpm libpng-static-1.6.40-12.oe2403sp3.x86_64.rpm libpng-tools-1.6.40-12.oe2403sp3.x86_64.rpm libpng-help-1.6.40-12.oe2403sp3.noarch.rpm ['Hello, everyone,\n\nThis is an out-of-band notice. Unlike previous libpng announcements,\nthis one doesn\'t coincide with a libpng release, and the disclosure\ncadence differs from the usual coordinated pattern:\n\n- The fix landed on the libpng18 development branch (commit\n faf0692468) approximately one month before this announcement.\n libpng 1.8.0 is in late beta with no tagged release yet, so\n there is no upstream release version with which to align the\n disclosure. Downstream consumers building directly from the\n libpng18 branch have had the fix available since it landed.\n- The vulnerable code originates in the third-party libpng-apng\n patch, which is not under upstream libpng control. The patch\n is applied downstream by Firefox and Thunderbird, as well as\n several Linux distributions (Gentoo and LFS/BLFS among others).\n The libpng-apng maintainer, Daisuke Nishikawa, has since released\n fixed revisions (libpng-1.6.57-apng.patch v2 and\n libpng-1.6.58-apng.patch); downstream consumers should either\n update to those (verifying that both upstream commits are\n included), or backport the upstream commits themselves (see\n "Related fix" below).\n\n=== CVE-2026-40930 ===\n\nChunk smuggling in the push-mode APNG parser via unconsumed\nchunk body\n\nSecurity advisory:', 'Fix on libpng18:', "CVSS 3.1: 5.4 (Medium); CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L\nCWE: CWE-436 (Interpretation Conflict)\nAffected (upstream): libpng 1.8.0 development branch (libpng18)\nAffected (downstream): libpng-1.6.49-apng.patch through\n libpng-1.6.57-apng.patch (original v1) on SourceForge\nNot affected: upstream libpng 1.6.x releases (no APNG support)\nFixed (upstream): libpng18 at commit faf0692468\nFixed (downstream): libpng-1.6.57-apng.patch v2 and\n libpng-1.6.58-apng.patch on SourceForge, released by the\n libpng-apng maintainer\nBuild-time mitigation: building libpng 1.8 with APNG disabled\n (i.e., without PNG_APNG_SUPPORTED), or building libpng 1.6\n without the libpng-apng patch, removes the vulnerable code.\n No runtime workaround exists for push-mode applications.\n\nThree inter-frame chunk discard paths in the push-mode APNG parser\nclear the chunk-header flag without consuming the chunk body and\nCRC, allowing attacker-controlled bytes inside a discarded chunk\nto be reinterpreted as a fresh chunk header on the next call to\npng_process_data.\n\nImpact depends on the application's CRC handling:\n\n- Default configuration: libpng calls png_error on the resulting\n CRC mismatch or APNG sequence-number violation, and the image\n fails to load. Impact is denial of service.\n- Relaxed configuration (png_set_crc_action with PNG_CRC_QUIET_USE\n or PNG_CRC_WARN_USE): smuggled bytes reach the APNG sequence\n counter and the zlib decompressor, and are decoded as frame\n pixel data. No code execution: zlib output writes into a\n pre-allocated row buffer. A crafted fake length exceeding the\n carrier chunk body causes cascading desynchronization beyond\n the carrier.\n\nSequential-mode reading (png_read_info / png_read_row /\npng_read_end) is not affected. Only push-mode (png_process_data)\nis vulnerable, and the Gecko-based browsers (for example) use it.\n\n=== Related fix ===\n\nA sibling defect in the same push-mode fdAT path was reported\nseparately in GitHub issue pnggroup/libpng#854 and fixed on the\nlibpng18 branch in commit 9ec49c2d56. It is distinct from\nCVE-2026-40930 and is not covered by the advisory above.\nDownstream consumers of libpng-apng should apply both commits to\nfully remediate the push-mode fdAT path. Those updating to the\nfixed libpng-apng revisions instead should verify that both commits\nare included; otherwise, 9ec49c2d56 must be backported separately.\n\nRelated fix on libpng18:", 'Credits:\n- Seung Min Shin (CVE-2026-40930 discovery)\n- Ryo Shimada (GitHub issue pnggroup/libpng#854)\n\n---\nCosmin Truta\nlibpng maintainer'] 2026-05-29 CVE-2026-40930 openEuler-24.03-LTS-SP3 Medium 5.4 AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L libpng security update 2026-05-29 https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2535