Skip to content
Fencer Intel
medium —

GHSA-6c73-2v8x-qpvm json

Argo Server TLS requests could be forged by attacker with network access

published 5y ago modified 8mo ago also GO-2022-0388

cvss
—
not scored
cisa kev
Not listed
not in CISA's catalog
epss
—
no score, EPSS covers CVEs only
public exploits
0
none known

Summary

### Impact

We are not aware of any exploits. This is a pro-active fix.

Impacted:

* You are running Argo Server < v3.0 with `--secure=true` or >= v3.0 with `--secure` unspecified (note - running in secure mode is recommended regardless). * The attacker is within your network. If you expose Argo Server to the Internet then "your network" is "the Internet".

The Argo Server's keys are packaged within the image. They could be extracted and used to decrypt traffic, or forge requests.

### Patches

https://github.com/argoproj/argo-workflows/pull/6540

### Workarounds

* Make sure that your Argo Server service or pod are not directly accessible outside of your cluster. Put TLS load balancer in front of it.

This was identified by engineers at Jetstack.io

Patch / fix

  • go github.com/argoproj/argo-workflows/v3 3.0.9, 3.1.6

Is GHSA-6c73-2v8x-qpvm in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Affected packages

ecosystem package affected fixed in
go github.com/argoproj/argo-workflows/v3
>=3.0.0, <3.0.9
>=3.1.0, <3.1.6
3.0.9
3.1.6
go github.com/argoproj/argo-workflows
all versions
 no fix listed
go github.com/argoproj/argo-workflows/v2
all versions
 no fix listed

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.