Versions prior to 4.14.0 had a backward compatibility for older ZScript versions that became problematic later on. In particular, type checking was not fully enforced when accessing one type as another.
This technically was patched but the patch was version-gated. Unfortunately more people were starting to discover ways that this could be exploited, and it eventually led to a vulnerability proof of concept being developed.
This created a conflict between two guiding goals of the source port: Maintaining backward compatibility, and keeping GZDoom in a state that would make most people feel like it is generally safe to use (i.e. vulnerabilities like this patched out).
In general, most people do not want to get their computers infected with malware just by downloading and installing a mod for a game, and there is often the expectation that mods cannot do that (or, you at least generally assume that it's too difficult to exploit for it to be worthwhile). GZDoom's community is vast, and while we have not directly seen malware being distributed in the form of GZDoom mods, there have been increasing concerns over this being a potential attack vector, and it likely would set a bad precedent to wait until one appeared, so it was decided that it had to be patched out.
So - some mods broke with the 4.14.0 update, unfortunately, and that was something we could not avoid. The goal of keeping GZDoom safe won out over maintaining backwards compatibility. While this doesn't prevent potential issues if a mod includes its own executable files, running them is ultimately your choice. If you double-click that .exe, you already understand that the GZDoom developers have no control over what happens next.
It goes without saying - update your GZDoom!
. I'm just asking if the bug in question allows arbitrary code execution on the host machine.