Hello!
We are a team using this great package. We also scan our code using snyk(a service helping us find vulnerabilities). It flagged your package for using a outdated version of sharp, which introduces a “Heap-based Buffer Overflow” problem.
We would like to update the dependency.
Here is a reference of the message we got through snyk:
Affected versions of this package are vulnerable to Heap-based Buffer Overflow when the ReadHuffmanCodes() function is used. An attacker can craft a special WebP lossless file that triggers the ReadHuffmanCodes() function to allocate the HuffmanCode buffer with a size that comes from an array of precomputed sizes: kTableSize. The color_cache_bits value defines which size to use. The kTableSize array only takes into account sizes for 8-bit first-level table lookups but not second-level table lookups. libwebp allows codes that are up to 15-bit (MAX_ALLOWED_CODE_LENGTH). When BuildHuffmanTable() attempts to fill the second-level tables it may write data out-of-bounds. The OOB write to the undersized array happens in ReplicateValue.
Notes:
This is only exploitable if the color_cache_bits value defines which size to use.
This vulnerability was also published on libwebp CVE-2023-5129
Hello! We are a team using this great package. We also scan our code using snyk(a service helping us find vulnerabilities). It flagged your package for using a outdated version of sharp, which introduces a “Heap-based Buffer Overflow” problem.
We would like to update the dependency.
Here is a reference of the message we got through snyk:
Introduced through: cypress-movie@3.0.20 Fixed in: sharp@0.32.6 Exploit maturity: Mature
Detailed paths Introduced through: frontend@0.1.0 › cypress-movie@3.0.20 › sharp@0.29.3
Security information
Affected versions of this package are vulnerable to Heap-based Buffer Overflow when the ReadHuffmanCodes() function is used. An attacker can craft a special WebP lossless file that triggers the ReadHuffmanCodes() function to allocate the HuffmanCode buffer with a size that comes from an array of precomputed sizes: kTableSize. The color_cache_bits value defines which size to use. The kTableSize array only takes into account sizes for 8-bit first-level table lookups but not second-level table lookups. libwebp allows codes that are up to 15-bit (MAX_ALLOWED_CODE_LENGTH). When BuildHuffmanTable() attempts to fill the second-level tables it may write data out-of-bounds. The OOB write to the undersized array happens in ReplicateValue.
Notes:
This is only exploitable if the color_cache_bits value defines which size to use.
This vulnerability was also published on libwebp CVE-2023-5129