Can .ova file contain an exploit?

Whether or not it contains an exploit, specifically, is irrelevant in the broader question of whether an OVA file can be malicious. The answer to the broader question is yes, absolutely.

The Open Virtualization Format specification gives you an idea of some of the potential vectors, but the obvious one is that it could map your entire OS disk to the VM and then, on VM boot, run code that exfiltrates it via the network or modifies files on disk to elevate privileges or drop malware (it doesn't have to adhere to your OS's security controls around filesystem access at that point). The VM could also map arbitrary USB devices to the VM (including inserted USB sticks) and use them however it likes.

If we want to go into more complex attack mechanisms, the VM could utilise platform vulnerabilities in the CPU, PCH, or memory (e.g. recent vPro/AMT bugs, or rowhammer) to effectively escape the VM environment and run arbitrary code on the host.

You absolutely should not run untrusted OVF VMs.

Any file can contain an exploit.

Whether it works or not, or if it requires a loader, is another story.

For example, if there's a buffer overflow vulnerability in the processing of .ova files, then yes, it could contain an exploitable vulnerability.

It all depends on whether or not you have a vulnerable application which processes the file that contains an exploit.

Yes, any guest OS such as contained in OVA files can carry malicious code; even mere data files of a certain complexity can effectively launch exploits.

Therefore, the flavor of Whonix you may be looking for is the one that runs under the Qubes OS hypervisor, as every aspect of Qubes is designed to prevent privilege escalation attacks from within guest VMs. In fact, the creators assume that guest compromise is likely and that a reasonably secure OS should protect the rest of the system in that case.

Note the long list of Qubes security advantages listed at the Whonix website.

Conversely, VirtualBox is a much less stringent VM environment designed mainly for administrator convenience, as the second bullet at the link explains.

This is not to claim that Qubes is impervious in any situation, but for most scenarios it raises the bar considerably. Since your goal appears to be preventing code of questionable intent from escaping or leaking in any way from a Tor tunnel, then its probably your best option.

The main downside to Qubes, besides loss of GPU access, is how finicky it is about hardware. It needs advanced CPU features such as IOMMU, SLAT, EPT and a BIOS that configures them exactly right. The Qubes HCL exists as a hardware guide.

Converting your OVA file for use as a Qubes HVM:

First, download the OVA to an AppVM then:

tar xvf filename.ova
# ...produces a .vmdk disk image
qemu-img convert -f vmdk filename-disk1.vmdk -O raw filename.img
# ...produces a flat disk image

Next, create an HVM in Qubes (here called 'mynewHVM'), then in dom0:

qvm-run -p myappvm 'cat /home/user/filename.img' >filename.img
# ...transfer img from appVM to dom0
mv filename.img /var/lib/qubes/appvms/mynewHVM/root.img
# ...for Qubes 3.x

From there you can access the HVM's settings panel and change Network to sys-whonix.

Finally, if your disk image contains a Windows OS, see these tips.