Which 4.y.z to 4.y'.z' updates increase vulnerability?

Per the previously mentioned comment, upgrading from a previous 4.y to any of the following releases introduces the possibility of running into this problem:

4.19.8
4.18.22
4.17.38
4.16.46

The bug will also be present in releases after those listed above until the workaround patch ships.

Worth noting that it is not possible to deploy a problematic configuration on one of these broken versions in the first place, so it isn't possible to, say, deploy on 4.19.8 and upgrade to 4.19.9 and introduce this problem.

Which types of clusters?

Baremetal clusters that use NMState to create br-ex instead of configure-ovs. That means it is also specific to clusters running OVNKubernetes as the CNI.

What is the impact? Is it serious enough to warrant removing update recommendations?

The bug will not immediately affect any upgraded clusters, but it will break scaleout or re-deployment of any nodes.

How involved is remediation?

There are a couple of options:

1. Add a machine-config to the cluster that replicates the workaround we merged in MCO, this should also be safe to do before upgrading to an affected version if necessary.
2. SSH to each node being deployed and manually run the NMState service.

Is this a regression?

Yes. This problem was not present before the releases listed above.