It seems that author basically found a 0day and published it. It's for sure better than selling it on the dark web but maybe it's better first tell it to Apple?

Not exactly. It's not a "new" attack vector, any software which was malicious would have already been able to attack when you first gave it permission (a prerequisite for this sticky permission issue). If you had downloaded an app and discovered it was malicious the remedy would generally be to uninstall the app, not just "revoke the permission for the one folder".

It's not a good look for Apple, and it's not great that the permission revocation basically doesn't actually work, but any malware that could have infected the system due to this issue would have also been able to infect the system while the permission was still (intentionally) enabled.

> If you had downloaded an app and discovered it was malicious the remedy would generally be to uninstall the app

There are many apps that themselves are not malicious but they run untrusted code via plugins and stuff. Like VS Code for example.

So you gave it a permission and then revoked it thinking all is fine. tomorrow an extension was hijacked and it now reads your files. cool?

Apple Security would instantly close it as "don't see the problem here" if you reported it to them. They have a poor reputation around TCC bug reports.

That makes it OK for you to not responsibly disclose a vuln? Cool I guess)

I have nothing to do with any of this.

But since they don't consider these as vulnerabilities in the first place, then yeah, sure.

Not really, just an unintuitive security feature. You still need the user's permission to access that folder, but that permission is then persistent. I consider it a UX bug for sure but not an exploit.

I agree, it's a ui/ux problem. It would seem that using the open file dialog should also request access but I'm guessing that was too intrusive and the user action is seen as implicit authorization. Security is one of those things that should aways be explicit though.