FKIE_CVE-2026-33416

Vulnerability from fkie_nvd - Published: 2026-03-26 17:16 - Updated: 2026-04-02 20:28
Severity ?
7.5 (High) - CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Summary
LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. In versions 1.2.1 through 1.6.55, `png_set_tRNS` and `png_set_PLTE` each alias a heap-allocated buffer between `png_struct` and `png_info`, sharing a single allocation across two structs with independent lifetimes. The `trans_alpha` aliasing has been present since at least libpng 1.0, and the `palette` aliasing since at least 1.2.1. Both affect all prior release lines `png_set_tRNS` sets `png_ptr->trans_alpha = info_ptr->trans_alpha` (256-byte buffer) and `png_set_PLTE` sets `info_ptr->palette = png_ptr->palette` (768-byte buffer). In both cases, calling `png_free_data` (with `PNG_FREE_TRNS` or `PNG_FREE_PLTE`) frees the buffer through `info_ptr` while the corresponding `png_ptr` pointer remains dangling. Subsequent row-transform functions dereference and, in some code paths, write to the freed memory. A second call to `png_set_tRNS` or `png_set_PLTE` has the same effect, because both functions call `png_free_data` internally before reallocating the `info_ptr` buffer. Version 1.6.56 fixes the issue.
References
security-advisories@github.comhttps://github.com/pnggroup/libpng/commit/23019269764e35ed8458e517f1897bd3c54820ebPatch
security-advisories@github.comhttps://github.com/pnggroup/libpng/commit/7ea9eea884a2328cc7fdcb3c0c00246a50d90667Patch
security-advisories@github.comhttps://github.com/pnggroup/libpng/commit/a3a21443ed12bfa1ef46fa0d4fb2b74a0fa34a25Patch
security-advisories@github.comhttps://github.com/pnggroup/libpng/commit/c1b0318b393c90679e6fa5bc1d329fd5d5012ec1Patch
security-advisories@github.comhttps://github.com/pnggroup/libpng/pull/824Issue Tracking, Exploit
security-advisories@github.comhttps://github.com/pnggroup/libpng/security/advisories/GHSA-m4pc-p4q3-4c7jPatch, Vendor Advisory
Impacted products
Vendor Product Version
libpng libpng *
To clipboard 

{
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:libpng:libpng:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "C54F2804-F7D5-4BC5-B39A-44300C6A6F98",
              "versionEndExcluding": "1.6.56",
              "versionStartIncluding": "1.2.1",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. In versions 1.2.1 through 1.6.55, `png_set_tRNS` and `png_set_PLTE` each alias a heap-allocated buffer between `png_struct` and `png_info`, sharing a single allocation across two structs with independent lifetimes. The `trans_alpha` aliasing has been present since at least libpng 1.0, and the `palette` aliasing since at least 1.2.1. Both affect all prior release lines `png_set_tRNS` sets `png_ptr-\u003etrans_alpha = info_ptr-\u003etrans_alpha` (256-byte buffer) and `png_set_PLTE` sets `info_ptr-\u003epalette = png_ptr-\u003epalette` (768-byte buffer). In both cases, calling `png_free_data` (with `PNG_FREE_TRNS` or `PNG_FREE_PLTE`) frees the buffer through `info_ptr` while the corresponding `png_ptr` pointer remains dangling. Subsequent row-transform functions dereference and, in some code paths, write to the freed memory. A second call to `png_set_tRNS` or `png_set_PLTE` has the same effect, because both functions call `png_free_data` internally before reallocating the `info_ptr` buffer. Version 1.6.56 fixes the issue."
    },
    {
      "lang": "es",
      "value": "LIBPNG es una biblioteca de referencia para su uso en aplicaciones que leen, crean y manipulan archivos de imagen r\u00e1ster PNG (Portable Network Graphics). En las versiones 1.2.1 a 1.6.55, \u0027png_set_tRNS\u0027 y \u0027png_set_PLTE\u0027 cada una aliasan un b\u00fafer asignado en el heap entre \u0027png_struct\u0027 y \u0027png_info\u0027, compartiendo una \u00fanica asignaci\u00f3n entre dos estructuras con vidas \u00fatiles independientes. El aliasing de \u0027trans_alpha\u0027 ha estado presente desde al menos libpng 1.0, y el aliasing de \u0027palette\u0027 desde al menos 1.2.1. Ambos afectan a todas las l\u00edneas de versiones anteriores: \u0027png_set_tRNS\u0027 establece \u0027png_ptr-\u0026gt;trans_alpha = info_ptr-\u0026gt;trans_alpha\u0027 (b\u00fafer de 256 bytes) y \u0027png_set_PLTE\u0027 establece \u0027info_ptr-\u0026gt;palette = png_ptr-\u0026gt;palette\u0027 (b\u00fafer de 768 bytes). En ambos casos, llamar a \u0027png_free_data\u0027 (con \u0027PNG_FREE_TRNS\u0027 o \u0027PNG_FREE_PLTE\u0027) libera el b\u00fafer a trav\u00e9s de \u0027info_ptr\u0027 mientras que el puntero \u0027png_ptr\u0027 correspondiente permanece colgante. Las funciones de transformaci\u00f3n de fila subsiguientes desreferencian y, en algunas rutas de c\u00f3digo, escriben en la memoria liberada. Una segunda llamada a \u0027png_set_tRNS\u0027 o \u0027png_set_PLTE\u0027 tiene el mismo efecto, porque ambas funciones llaman internamente a \u0027png_free_data\u0027 antes de reasignar el b\u00fafer de \u0027info_ptr\u0027. La versi\u00f3n 1.6.56 corrige el problema."
    }
  ],
  "id": "CVE-2026-33416",
  "lastModified": "2026-04-02T20:28:33.973",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "NETWORK",
          "availabilityImpact": "HIGH",
          "baseScore": 7.5,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "REQUIRED",
          "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.6,
        "impactScore": 5.9,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-03-26T17:16:38.443",
  "references": [
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/pnggroup/libpng/commit/23019269764e35ed8458e517f1897bd3c54820eb"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/pnggroup/libpng/commit/7ea9eea884a2328cc7fdcb3c0c00246a50d90667"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/pnggroup/libpng/commit/a3a21443ed12bfa1ef46fa0d4fb2b74a0fa34a25"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/pnggroup/libpng/commit/c1b0318b393c90679e6fa5bc1d329fd5d5012ec1"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Issue Tracking",
        "Exploit"
      ],
      "url": "https://github.com/pnggroup/libpng/pull/824"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch",
        "Vendor Advisory"
      ],
      "url": "https://github.com/pnggroup/libpng/security/advisories/GHSA-m4pc-p4q3-4c7j"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-416"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Primary"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.