It's not a case of 'unknown exploits' it's that a proof of concept attack is just to show that there is a problem, and not meant to show the lack of a problem. It's not meant to work in all cases that the vulnerability exists nor as a means to demonstrate that the vulnerability is fixed. It's very easy for small changes (whether a patch, config change, or exploit mitigation) to break a proof of concept in a way that would be possible for an attacker to work around (the effort ranging from 'trivially easy' to 'needing quite a lot of extra development'). This is especially true for binary exploits which can be quite sensitive to things like compiler versions and options (as well as explicit mitigation features), but where there are a range of techniques for adjusting them for a specific target.

The point is you that the criteria for "am I safe from this vulnerability" is "I have applied the patches and/or config changes recommended by the author of the software" and not "I tried to run the PoC against my system and it didn't work". (nor, as was common in this case, "I have applied some config changes that some random people online feel like should help")

> There is more nuance to this as well, it might work, but only in certain circumstances which seems to be where this is going at the moment.

It's memory corruption. That requires some guesswork or understanding of the underlying system (platform + ABI) and heap grooming to actually exploit but that's not a security boundary. Any vulnerable version is just going to get hammered with requests until it either crashes without an exploit or actually gets popped.