This isn’t a vulnerability nor is it corrupt, these are intentional actions on behalf of the project maintainer. Not that I agree per se, to be absolutely clear, however saying these are corrupt or somehow vulnerabilities isn’t the truth. This is the software working as intended
They are absolutely corrupt -- intentionally corrupt, but the intention was to break the software in retaliation. Drilling holes in your boat to sink it means yes, it is sinking "as intended", but it's still an act of sabotage. I suppose you can specifically argue against the word corrupt as implying a corruption of the author's intention, but I think it also applies to "does not behave as anticipated". (now, the int…
I feel this language is used intentionally to smear the maintainer and paper over a real conversation over open source, responsibilities of maintainers and consumers, and the ecosystem as a whole. Instead it’s all about the “vulnerability” caused by the maintainers choices to commit “malicious” code.
Did the maintainer drastically change the software? You bet they did. Does that mean it’s malicious, a vulnerability, and/or corrupt? No. This isn’t an illicit cryptominer or process injection etc. the host machines are not being exploited in a malicious way.
You can disagree with the actions and what they are doing etc, but labels matter, and I think this is an intentional labeling of this to skirt around having real conversations around OSS, maintainability, the role of consumers etc