Well, then you would have to know:

a) The specific x86 chip manufacturer and architecture (i.e., Intel, AMD, VIA, IDT, Cyrix, Transmeta, Zhaoxin, MCST (Elbrus), ? -- see https://en.wikipedia.org/wiki/List_of_x86_manufacturers -- there's a huge difference in potential security issues between say, the earliest Intel 386, and the latest Intel or AMD (or compatible) 64-bit x86 multi-cored multi-threaded CPU...

b) What security issues are potentially present in that CPU;

c) What the Virtual Machine / Emulator and/or Virtualized Environment does or doesn't do.

(For example, if you use Bochs (https://bochs.sourceforge.io/) for the guest environment on an x86 host -- then there's absolutely nothing that the guest OS can do to mitigate host OS security issues -- that's because all instructions inside of the guest are emulated -- security must be handled at the level of the OS/Hardware that is running Bochs, that is, at the level of the host.)

Now, things get slightly more weird with Virtual Machines/Emulators/Virtual Environments that permit some/all of the x86 instructions to run directly on the host hardware.

Here we have to distinguish between user-mode and "protected mode" (OS and/or Hypervisor, Ring < 3, instructions)...

You see, a Virtual Machines/Emulator/Virtual Environments -- may permit patterns of the following sort:

1) Some/All of the user-mode x86 instructions in the guest environment to run directly in the host environment without translation/modification...

2) Some/All of the user-mode x86 instructions AND some/all of the "protected mode" (OS and/or Hypervisor, Ring < 3, instructions) to run directly in the host environment without translation/modification...

Now, I am not an expert on any of this.

I am not an expert on all of the Virtual Machines/Emulator/Virtual Environments out there, nor am I an expert on all x86 instructions, protected mode or user mode...

But what I can tell you is simply this:

What x86 instructions a Virtual Machine/Emulator/Virtual Environment permits to be run directly, that is, which x86 instructions, existing in the guest OS, ran directly on the host CPU (without modification or deletion or "hooking"/"intercepting" or what-have-you), could have a large impact on security...

Which is a double-edged sword!

The more power that is given to the guest OS to access the lower layers (the host or physical hardware) -- the more guest OS's can potentially mitigate security issues...

But on the other hand:

The more power that is given to a guest OS to access the lower layers (the host or physical hardware) -- the more that guest OS can potentially CAUSE security issues!

It's a double-edged sword!

Ultimately: The more you can know about the layers of your specific stack, the better the position you'll be in to control security, and security-related issues...

Anyway, great question!

I'm not the expert... take everything that I'm saying with the proverbial "grain of salt"... It's a good idea to do all of the research necessary to know your own specific stack...

Also, one thing that I do know -- that if you're running an x86 emulator on a non-x86 CPU, the option (from the Virtual Machine/Emulator/Virtual Environment's point-of-view) of simply passing on instructions to the lower-level CPU for direct execution -- no longer exists -- in other words, running on a non-x86 CPU (i.e. ARM, RISC-V, etc.) -- the Virtual Machine/Emulator/Virtual Environment now MUST translate or interpret x86 instructions in the guest -- it can no longer ask the underlying host to run them directly, without modification...

I know that was not your question -- but I think it's an important additional observation...