What do you mean and? The implications are implicit; any vulnerability will be unpatched, so bad actor (tm) has to know only ONE vulnerability after XP support was ceased. If he has means of talking to the machine through TCP/IP or UDP he will have 100% guaranteed access.
You wouldn't believe how much traffic is hammering IP ranges with known vulnerabilities. Forward port 22 to your Linux box or similar, check the logs for number of "connection attempts", it's going to be glorious log. A-HOLES of this planet are doing this just to get control of devices connected to the internet, if for no other reason than use them in DDoS-for-hire service. If there is a quick buck to be made.. they'll be all over it. Human parasites.
You normally wouldn't forward open ports on your VM straight through your host and also through your LAN (or at least, I wouldn't), so that's not really a huge attack vector.
The main threat would be connecting to a malicious server that attacks some hypothetical hole in the TCP/TLS stack when you connect, but such servers aren't really omnipresent, and you can apply the usual measures of 'making regular backups' and 'not keeping extraordinarily sensitive data on a VM' to mitigate any impacts.
(Looking at actual historical holes, I find things like CVE-2005-0048, which requirs a malformed IP packet a modern router wouldn't pass through, and CVE-2007-0069 and CVE-2019-0708, which require a malicious incoming connection to a particular port. There's also stuff like https://www.forcepoint.com/sites/default/files/resources/fil..., but that's not really specific to XP services, and requires many stars to align unless you're running a vulnerable HTTP service.)
I wrote a small test bench for my own uses as wanted to compare with different codecs and see how "raw compression" would work, how would QOI+ZSTD combination work and so on.
The True Cost in this specific case is (0..7 bits to fill a byte) + 2 bytes for the RST marker for each interval. 320x240 image and RST interval for each 240/8 block means 30 RST's so something close to 75 bytes "wasted", or, other way to look at it is ~3 bits per row.
The reason is that for the JPEG the Huffman tree is fixed and is transmitted with the image data so restarting is cheap; it does not start from scratch and build a new tree each time; each decoded symbol is also independent so you can stop and restart at any time you want. I don't have any ANS experience at all so won't say anything about that.. but it would be nice if some sort of way would be possible to isolate the ranges.
You wouldn't believe how much traffic is hammering IP ranges with known vulnerabilities. Forward port 22 to your Linux box or similar, check the logs for number of "connection attempts", it's going to be glorious log. A-HOLES of this planet are doing this just to get control of devices connected to the internet, if for no other reason than use them in DDoS-for-hire service. If there is a quick buck to be made.. they'll be all over it. Human parasites.