{"vulnerability": "ghsa-q9hr-j4rf-8fjc", "sightings": [{"uuid": "d907ac5f-3074-4bce-907b-2c1e5f5a4c3c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "GHSA-Q9HR-J4RF-8FJC", "type": "seen", "source": "https://t.me/DarkWebInformer_CVEAlerts/7133", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2023-22482\n\ud83d\udd25 CVSS Score: 9.1 (cvssV3_1, Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)\n\ud83d\udd39 Description: Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Versions of Argo CD starting with v1.8.2 and prior to 2.3.13, 2.4.19, 2.5.6, and 2.6.0-rc-3  are vulnerable to an improper authorization bug causing the API to accept certain invalid tokens. OIDC providers include an `aud` (audience) claim in signed tokens. The value of that claim specifies the intended audience(s) of the token (i.e. the service or services which are meant to accept the token). Argo CD _does_ validate that the token was signed by Argo CD's configured OIDC provider. But Argo CD _does not_ validate the audience claim, so it will accept tokens that are not intended for Argo CD. If Argo CD's configured OIDC provider also serves other audiences (for example, a file storage service), then Argo CD will accept a token intended for one of those other audiences. Argo CD will grant the user privileges based on the token's `groups` claim, even though those groups were not intended to be used by Argo CD. This bug also increases the impact of a stolen token. If an attacker steals a valid token for a different audience, they can use it to access Argo CD. A patch for this vulnerability has been released in versions 2.6.0-rc3, 2.5.6, 2.4.19, and 2.3.13. There are no workarounds.\n\ud83d\udccf Published: 2023-01-25T18:25:15.287Z\n\ud83d\udccf Modified: 2025-03-11T13:30:49.509Z\n\ud83d\udd17 References:\n1. https://github.com/argoproj/argo-cd/security/advisories/GHSA-q9hr-j4rf-8fjc", "creation_timestamp": "2025-03-11T13:39:50.000000Z"}]}