This is impossible. The automation events are generated before the processBlock function gets called, for the plugin to read from. Nothing is generated in parallel with the hope of the plugin being slow enough to not cause problems. That would be extremely poor engineering that would cause problems with all fast plugins.
You have to realize that Steinberg invented VST2 and VST3. Their hosts are basically the “reference” hosts. If your plugin fails in the reference hosts, it may cause other problems in other hosts.
For the sake of argument, let’s say you have an accidental memory-writer in your plugin. Now if you write a random value into the hosts memory, it will have different effects depending on the host. Some hosts may have some resource in that location, so nothing terrible will happen when the memory location gets written to. Other hosts might have a bit of code there, that gets executed for each processBlock, but now that the code has been altered, it crashes.
I had such an issue when I started out writing VST plugins on pre-Windows NT OSes like Windows 98, Windows ME etc. I had a nullptr and without checking, wrote into it. On Windows, nothing bad happened at all. I wrote a value into 0x00000000 and read it back and life went on. On the Mac this led to an immediate segmentation fault. I was stumped by this apparent “only on Mac”-bug and blamed OS9 / OSX for my troubles. Later, when I found out that I was writing in 0x00000000, I became red in the face, fixed the bug and suddenly it worked on Mac. It was totally my mistake and had nothing to do with Windows vs. Mac at all.
This reminds me of your problem. You don’t know the cause, you haven’t investigated it at all, but you’re quick to blame Cubase, the reference host.
I sincerely hope you find the real cause and let us know, so we can all sleep easier knowing that Cubase wasn’t the blame after all.