Devilutionx
Monthly
Heap-based buffer overflow in DevilutionX 1.4.0 through 1.5.5 corrupts memory when the engine loads a crafted MPQ archive whose block table count exceeds its hash table count, overflowing a memcpy inside the bundled libmpq libmpq__archive_dup routine during startup; the confirmed outcome is a crash of the game (availability impact, no confidentiality impact and no demonstrated code execution). Exploitation is local: an attacker must first place the malicious archive in the game data the engine reads at startup, and the victim must then launch the game, so passive user interaction is required and no privileges are needed on the victim side. The issue is rated medium (CVSS 4.0 6.9, independently assessed CVSS 3.1 AV:L/AC:L/PR:N/UI:R with A:H only), EPSS is 0.13% (3rd percentile), it is not in CISA KEV, and no confirmed public exploit code has been identified at time of analysis - the only public material is a technical write-up. Priority guidance places it at this_month rather than emergency.
An out-of-bounds read in the libmpq library bundled with DevilutionX 1.4.0 through 1.5.5 lets a crafted .mpq archive crash the game: the file-number lookup routine libmpq__file_number_from_hash uses an unchecked block_table_index from the archive's hash table to index the block table array, reading past the heap buffer (mpq_map) and terminating the process. The attack is not remote - the attacker must first get a malicious archive into the game's data path (for example distributed as a mod) and the victim must then launch DevilutionX and load it, so a legitimate install using only official Blizzard data is not affected. Per the assessed impact the consequence is availability only (crash), with no confidentiality or integrity effect; there is no CISA KEV listing, EPSS is low at 0.12% (2nd percentile), and no working public exploit code is confirmed, although a public technical write-up of the flaw exists.
Heap-based buffer overflow in DevilutionX 1.4.0 through 1.5.5 corrupts memory when the engine loads a crafted MPQ archive whose block table count exceeds its hash table count, overflowing a memcpy inside the bundled libmpq libmpq__archive_dup routine during startup; the confirmed outcome is a crash of the game (availability impact, no confidentiality impact and no demonstrated code execution). Exploitation is local: an attacker must first place the malicious archive in the game data the engine reads at startup, and the victim must then launch the game, so passive user interaction is required and no privileges are needed on the victim side. The issue is rated medium (CVSS 4.0 6.9, independently assessed CVSS 3.1 AV:L/AC:L/PR:N/UI:R with A:H only), EPSS is 0.13% (3rd percentile), it is not in CISA KEV, and no confirmed public exploit code has been identified at time of analysis - the only public material is a technical write-up. Priority guidance places it at this_month rather than emergency.
An out-of-bounds read in the libmpq library bundled with DevilutionX 1.4.0 through 1.5.5 lets a crafted .mpq archive crash the game: the file-number lookup routine libmpq__file_number_from_hash uses an unchecked block_table_index from the archive's hash table to index the block table array, reading past the heap buffer (mpq_map) and terminating the process. The attack is not remote - the attacker must first get a malicious archive into the game's data path (for example distributed as a mod) and the victim must then launch DevilutionX and load it, so a legitimate install using only official Blizzard data is not affected. Per the assessed impact the consequence is availability only (crash), with no confidentiality or integrity effect; there is no CISA KEV listing, EPSS is low at 0.12% (2nd percentile), and no working public exploit code is confirmed, although a public technical write-up of the flaw exists.