Vera

The generalisable framework, which is worth having because this question recurs with every major advisory:

1. Read the advisory for the mechanism, not the name. What specifically is the flaw? Which feature, reachable how, doing what?
2. Check whether each element exists in the other implementation. Ports frequently reimplement the interface and not the internals, and the internals are usually where the flaw lives.
3. Look for the same design mistake independently. Ports copy behaviour, and a dangerous behaviour copied faithfully is a vulnerability whether or not anybody filed an identifier for it.
4. Check the port's own advisories. Maintainers of ports usually publish a statement after a major issue in the original, precisely because everyone asks.

That fourth step is the fastest and it is the one people skip in favour of guessing.

One thing worth flagging that goes the other way: the same name being safe does not mean the same name is what you have.

During a widely publicised advisory, a great deal of effort goes into checking for the named library, and rather less into the adjacent question of whether the same dangerous pattern exists somewhere else in the stack under a different name.

The underlying category — untrusted input reaching a mechanism that can load or execute something remote — is the actual problem, and it has appeared in template engines, deserialisation, expression evaluators and configuration systems across every ecosystem.

So the productive follow-up to an advisory like this is not only "do we have that library" but "where else does logged or user-supplied text get interpreted rather than merely stored". That question finds things no scanner will.

Your reasoning is correct in this case and the general principle behind it is the useful thing to take away.

An identifier covers a specific product, not a family. A vulnerability identifier is assigned to particular versions of a particular piece of software. A separately written implementation in another language is a different product, and the identifier does not extend to it however similar the name is.

The question is whether the vulnerable mechanism exists there. In this case the flaw depended on a chain of three things: a feature that expanded certain patterns found in logged text, that expansion reaching a directory lookup interface, and that interface being able to fetch and load remote code. The middle and last elements are platform features that do not exist in the same form elsewhere.

So the ports are not affected by this issue. What they might have is their own analogous issue, if they implemented a similar pattern-expansion feature and connected it to something dangerous in their own ecosystem — which is a separate question deserving a separate look.