Per the specification of vfork, the only valid actions after it are _exit or one of the exec-family functions. In practice you can often get away with most things that are async-signal-safe as long as you're not also using thread cancellation, but the more an action has potential to alter the memory state of the process (which is shared with the suspended parent) the more likely things are going to blow up.
I've had reports of monit crashing in Alpine Linux containers using musl libc, and the strace shows it happening right after vfork. Command_execute is doing a lot of things, all of them formally unsafe, in the child before exec, but the most suspicious is getpwuid, which can allocate memory, manipulate open file state, etc.
Use of vfork should be dropped unless you can ensure that it's done safely. Ideally posix_spawn would be used in its place but it looks like you need some functionality not offered by posix_spawn.