Some information about that problem also.

The BCP 47 tag parser has quadratic time complexity due to inherent
aspects of its design. Since the parser is, by design, exposed to
untrusted user input, this can be leveraged to force a program to
consume significant time parsing Accept-Language headers.

fix was https://go-review.googlesource.com/c/text/+/442235/2/language/parse.go

So I am trying to understand how Echo is affected by it though these dependencies

so far if you have something like in your code you are affected:

• language.ParseAcceptLanguage(r.Header.Get("Accept-Language")) -- as it uses directly that problematic function
• language.MatchStrings - function is using internally language.ParseAcceptLanguage function

golang.org/x/net does not seem to have direct dependency to following methods ParseAcceptLanguage or MatchStrings. there are no usages of package golang.org/x/text/language in x/net

golang.org/x/crypto does not use golang.org/x/text directly and is indirectly tied by golang.org/x/net dependency to x/text

@madmuffin1 what do you think? Echo is not directly/indirectly affected because there are no code that links to that problematic function?

my take on this: echo is not directly affected, but should not have a vulnerable dependency as implementing projects might refer to the affected method.

our company forbids any library with vulnerable dependencies, so all our echo projects will have to explicitly bump x/text, rather than updating this dependency.

as golang.org/x/* packages only support last 2 versions and Echo 4 there are times when bumping x/* package is problematic as it could contains symbols that older Go versions do not understand. For example currently bumping x/net to latest would mean dumping Go 1.16 support.