Probably, but better safe than sorry. This video goes to some extreme debugging of the issue, but comes out unclear if the issue is a clear danger or not.
I don't think the severity is exaggerated, anyone using 7zip should definitely update to fix this. But the scope was exaggerated at least by implication they possibly any use of the Zstd algorithm are at risk while the vast majority of Zstd uses are not vulnerable.
I don't actually think exaggeration was the intent. In context the article reads like someone wrote a 5 line article that had all the actual information then someone else came along and decided they needed to "add context" and did a quick Google search of "uses of Zstd compression".
Sure, now that you're aware, do update. It doesn't cost anything either.
But yes, it was greatly exaggerated. Not only can it happen only if you use 7-zip (which definitely not all people do, especially on Linux), but only if you use it to decompress zstd-compressed files, which would be even more of a niche case, as there are other tools more standard on Linux for doing just that. Let me know the last time you used 7-zip to uncompress zstd.
On Windows, 7-zip (with its associated GUI) is more often used as a general-purpose tools for all major compression formats, so on Windows that could be riskier. But even so, when again was the last time anyone here, on Windows, used 7-zip to decompress a zstd file?
So, making hours-long videos on the topic and worrying articles with false information (whether intended or not) on it, yes that's more clickbaity than useful. Just MHO.
Back to the technical aspect of it, I've posted a link to what appeared to be the culprit and the fix - essentially an integer wrap-around due to using too narrow an integer type - but looking closely at the corresponding function, I still don't get what the problem is. If anyone has and can explain in more details. The CVE doesn't detail it either AFAIK. As a small side-note, I didn't particularly care for all the custom-defined integer types there are in 7-zip's source code. Not even using stdint's from C99 for software in 2024 is pretty questionable to me. Sure it may have historical reasons (it was first released in 1999), but they had like 25 years to refactor that. Oh well. And it turns out that the issue was fixed by using "unsigned" as a type (not even "unsigned int"), which is technically equivalent to "unsigned int" but looks very much like C from the 70's to me. A detail, but doesn't really bode well and if that were me, I would suggest some refactoring of the code base.