Vulnerable dependency in jwt-go v3.2.0 (CVE-2020-26160)

[moonman81]

Hi Team,

I've been asked to approve the use of helm v3.7.0 within my organisation, however the source shows as depending upon a vulnerable version of jwt-go (v3.2.0) which has a vulnerability marked as high (CVSS score = 7.7) which is aged by more than 1 year.

As a 'high' vulnerability finding, this will for many teams (where a vulnerability management process is in place) cause an invocation of a 'risk exception process', which could be avoided where the dependency issue is resolved upstream and hence this ask.

This CVE was raised over a year ago as per dgrijalva/jwt-go#482 but alas, the maintainer (presumably "because life...") couldn't fix the issue nor maintain the code in a timely manner, and hence this caused for an official publicly maintained version to be made available here https://github.com/golang-jwt/jwt

It is notable that the fix for this vuln was initially in the v4.0.0-preview1 version which also introduced breaking API changes (which I presume beyond reasons of 'non-release' version code would understandably ward off any appetite to move forward with it).

Since then - the good folk maintaining https://github.com/golang-jwt/jwt have released a fix to the v3.2 branch and now have a v3.2.1 version available here - https://github.com/golang-jwt/jwt/releases/tag/v3.2.1

Please can you consider moving to the community-supported version of jwt-go v3.2.1 because it now has a version which doesn't break the API and should any further vulnerabilities be noted, then I would expect them to happen here and not in the unmaintained and publicly declared deprecated repo of the original author.

Thanks in advance (you'll save us having to undergo another 'risk review' in 3 months time!...)

Warwick

[yxxhero]

@moonman81 PRs is welcome.

[mattfarina]

I looked into this a little. We are picking up the problem package as a transitive dependency from multiple locations.

• Kuberentes 1.22.3 uses the vulnerable package. This has been fixed on master but not from the release-1.22 branch and there is no open work to address it there. Kubernetes may need a cherry pick PR to the release branch so future 1.22 patch releases can pick it up.
• containerd is importing an older version of Kubernetes that is importing the vulnerable package. containerd has updated but not created a stable release with a fix.

[mattfarina]

@moonman81 please note, all released and supported versions of Kubernetes have the same problematic dependency that Helm does.

[IzhakJakov]

 $ ggdh 'github.com/dgrijalva/jwt-go@v3.2.0+incompatible'
 
                     helm.sh/helm/v3@v3.8.0
                               ⬇
                    oras.land/oras-go@v1.1.0
                               ⬇
              github.com/Microsoft/hcsshim@v0.9.1
                               ⬇
            github.com/containerd/containerd@v1.5.7
                               ⬇
             github.com/containerd/imgcrypt@v1.1.1
                               ⬇
          github.com/containerd/containerd@v1.5.0-rc.0
                               ⬇
                    k8s.io/apiserver@v0.20.4
                               ⬇
  go.etcd.io/etcd@v0.5.0-alpha.5.0.20200910180754-dd1b699fc489
                               ⬇
        github.com/dgrijalva/jwt-go@v3.2.0+incompatible

[yankay]

ETCD is fixed by https://github.com/etcd-io/etcd/pull/13571/files.
And Etcd will release 3.6 to fix the CVE-2020-26160.

[github-actions]

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

[github-actions]

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.