TFA actually says that clearly:
> Remember that this example is a video a friend sent to me, and not the original video sent by MBS to Bezos. But the same principle applies. Simply look in that file in the backup, extract the URL and mediakey, insert into this program, and you'll get that file decrypted.
What they've demonstrated is a method that should work on Bezos' phone.
Edit: OK, I see that they get the encrypted file from the WhatsApp server:
> mediaurl = https://mmg-fna.whatsapp.net/d/f/[string].enc
So might the Saudi file in question have been deleted from WhatsApp?
Could the Saudis have done that?
I don't think anyone was claiming it wasn't video - it plays in the app, so clearly the majority of the data is indeed regular MPEG. And it's difficult to prove that an exploit _isn't_ present, especially if the payload could be hidden in the video stream (since you could control the video frames, you can likely hide a significant amount of data before you need to resort to actual steganography).
But, given the claim (that a remote exploit was used to gain C&C over the phone), there must be _something_ odd in there: metadata that doesn't make sense, frames of video not used, etc. - because there's an overflow (which probably means some byte index or something in the metadata is bad) and an exploit (there's a payload in there making use of the overflow). At the very least, some regular software like ffmpeg will complain during decoding that stuff doesn't make sense.
Like you say, the CVE is interesting, and I don't think there's a public description of the flaw. The article doesn't actually analyse the video: which is a bit odd since they are able to decrypt it. If the flaw is a buffer overflow in the MPEG stream parsing, it appears it would be reasonably easy to demonstrate that the MP4 file in question had been specially crafted, even if you couldn't directly demonstrate the exploit....