Please report it privately, through the Report a vulnerability form on this repository's Security tab, rather than in a public issue. The report opens a draft advisory that only the maintainer and you can see, and the fix can be worked out there before anything is public.

The latest tag. Versions are cut automatically once CI passes on main (see Releases), so a fix ships as the next patch version; the module is v0.x and has no maintenance branches.

The kernels are assembly, and that is where a vulnerability in this module would be:

• a read outside the input, or a write outside the hash state, by any backend at any length — including the ones selected only on hardware CI does not have, which are verified by simulation;
• a crash, hang or data race on input the documentation allows — a custom secret shorter than xxh3.MinSecretSize panics by design;
• a Digest that UnmarshalBinary accepts from crafted bytes and that then does any of the above.

A hash that differs from the reference C implementation is a correctness bug rather than a vulnerability: an ordinary issue is the place for it.

XXH3, XXH64 and rapidhash are not cryptographic hashes, and this module claims no resistance to deliberately constructed collisions, with or without a seed or a custom secret. A collision someone has engineered is not a vulnerability here, including one used to degrade a hash table built on these functions. Where an adversary chooses the input and a collision would cost you something, use a cryptographic construction instead.