I'm not sure it's a new bug, just that if you look up that call you'll find if it's used with any path containing a "/", then it can be raced to check somewhere other that the place the original author intended.
I think it's just that they're tricky when it comes to ownership. People who write code that depends on some type of file or directory ownership for security often don't think about the ways symlinks can be used to bypass their security model.
You can sort of think of a symlink as having 2 owners: the user that owns the symlink itself, and the user who owns the file pointed to by the symlink. One of those owners might be an attacker, so every time you interact with a file, you have to think "this file might be half-owned by an attacker, and half-owned by a victim".
That doesn't always fix it. An attacker can race you to make you write something in a place you didn't intend or expect unless the application is incredibly carefully written.
And by "incredibly" I mean beyond the scope of human endeavour :-).
I'm going to be giving a talk at SambaXP this year (it's virtual, so you only need to register to attend) explaining why IMHO symlinks have utterly broken the POSIX filesystem API, making it impossible for application developers to write secure applications.
Symlinks, the poisonous gift that keeps on giving.