We don't have a CVE number. Whether devices/networks are affected also highly depends on the specific configuration of the device/network. This means that some might interpret some of the identified weaknesses as software flaws, but other weaknesses can also be seen as configuration issues. That's actually what makes some of our findings hard to 'fix': it's easy to say that someone else is responsible for properly ensuring client isolation :) Hence also hard to really assign CVE(s).

One of the main takeaway issues, in my view, is that it's just hard to correctly deploy client isolation in more complex networks. I think it can be done using modern hardware, but it's very tedious. We didn't test with VLAN separation, but using that can definitely help. Enterprise devices also require a high amount of expertise, meaning we might have missed some specialised settings.. So I'd recommend testing your Wi-Fi network, and then see which settings or routing configurations to change: https://github.com/vanhoefm/airsnitch

I think you could apply specific CVEs to specific devices + setting combination, as:

CVE 1 : router brand X software version Y.Z configured with client isolation does not provide sufficient isolation that it cannot be broken with air snitch.

CVE 2 : router brand A software version B.C configured with client isolation does not provide sufficient isolation that it cannot be broken with air snitch.

etc.

CVE are handed out like candy in Java land for artifacts that have code that only opens up a vulnerability when another package is available and the first artifact is misconfigured. So I think you would be fully in your right to claim a CVE and list all affected versions of devices/firmwares there.