Euh... "heap-based buffer over-read" qui permettrait de réaliser de l'ACE, donc RCE si le fichier incriminé fait partie d'une playlist distante, et reçoit un CVSSv3 de 9.8 ? Avec un seul bug d'over-read, je peux comprendre infoleak (de quelques octets, à moins qu'il y ait moyen de répéter l'opération qui leake et d'exfiltrer facilement les données), je peux admettre DoS (même si ce n'est pas toujours le cas hors de builds spéciaux type AddressSanitizer)... mais manipulation de fichiers, et a fortiori ACE/RCE, WTF ? Ou alors, c'est autre chose qu'ESET a trouvé. Aux chiottes les fabricants de pro-virus bourrés de vulnérabilités, au fait.

A https://trac.videolan.org/vlc/ticket/22474 , linké depuis https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13615 et qui confirme que c'est un over-read, les devs de VLC ne semblent pas très contents... et à leur place, je penserais la même chose, si encore une fois, c'est bien le testcase reporté qui pose problème.

Tiens, il faudra que je regarde si VLC a fini par arrêter de packager libmodplug (en la remplaçant par libopenmpt, qui offre un rendu nettement plus fidèle et surtout qui est du code beaucoup plus sûr), comme le fait Debian, ou si au moins, VLC upstream tel qu'il est utilisé sous Windows et MacOS X package un build de libmodplug Git HEAD. Sans ça, de mémoire, il n'y a pas que des OOB reads, dans libmodplug...