See how wavpack compares to other vendors in security performance
A null pointer dereference bug was found in wavpack-5.4.0 The results from the ASAN log: AddressSanitizer:DEADLYSIGNAL ===================================================================84257==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x561b47a970c6 bp 0x7fff13952fb0 sp 0x7fff1394fca0 T0) ==84257==The signal is caused by a WRITE memory access. ==84257==Hint: address points to the zero page. #0 0x561b47a970c5 in main cli/wvunpack.c:834 #1 0x7efc4f5c0082 in libcstartmain (/lib/x8664-linux-gnu/libc.so.6+0x24082) #2 0x561b47a945ed in start (/usr/local/bin/wvunpack+0xa5ed) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV cli/wvunpack.c:834 in main ==84257==ABORTING
An out of bounds read was found in Wavpack 5.4.0 in processing .WAV files. This issue triggered in function WavpackPackSamples of file src/packutils.c, tainted variable cnt is too large, that makes pointer sptr read beyond heap bound.
WavPack 5.3.0 has an out-of-bounds write in WavpackPackSamples in packutils.c because of an integer overflow in a malloc argument. NOTE: some third-parties claim that there are later "unofficial" releases through 5.3.2, which are also affected.
Last updated 25 August 2025
Last updated 25 August 2025
Last updated 25 August 2025
WavpackSetConfiguration64 in packutils.c in libwavpack.a in WavPack through 5.1.0 has a "Conditional jump or move depends on uninitialised value" condition, which might allow attackers to cause a denial of service (application crash) via a DFF file that lacks valid sample-rate data.
Last updated 25 August 2025
Last updated 25 August 2025
An issue was discovered in WavPack 5.1.0 and earlier for W64 input. Out-of-bounds writes can occur because ParseWave64HeaderConfig in wave64.c does not validate the sizes of unknown chunks before attempting memory allocation, related to a lack of integer-overflow protection within a bytestocopy calculation and subsequent malloc call, leading to insufficient memory allocation.
An issue was discovered in WavPack 5.1.0 and earlier for DSDiff input. Out-of-bounds writes can occur because ParseDsdiffHeaderConfig in dsdiff.c does not validate the sizes of unknown chunks before attempting memory allocation, related to a lack of integer-overflow protection within a bytestocopy calculation and subsequent malloc call, leading to insufficient memory allocation.
An issue was discovered in WavPack 5.1.0 and earlier. The W64 parser component contains a vulnerability that allows writing to memory because ParseWave64HeaderConfig in wave64.c does not reject multiple format chunks.
An issue was discovered in WavPack 5.1.0 and earlier for WAV input. Out-of-bounds writes can occur because ParseRiffHeaderConfig in riff.c does not validate the sizes of unknown chunks before attempting memory allocation, related to a lack of integer-overflow protection within a bytestocopy calculation and subsequent malloc call, leading to insufficient memory allocation.
An issue was discovered in WavPack 5.1.0 and earlier. The WAV parser component contains a vulnerability that allows writing to memory because ParseRiffHeaderConfig in riff.c does not reject multiple format chunks.
Last updated 25 August 2025
A stack-based buffer over-read in the ParseRiffHeaderConfig function of cli/riff.c file of WavPack 5.1.0 allows a remote attacker to cause a denial-of-service attack or possibly have unspecified other impact via a maliciously crafted RF64 file.
Last updated 25 August 2025