### Impact
All versions of Argo CD starting with v1.8.2 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 blast radius of a stolen token. If an attacker steals a valid token for a different audience, they can use it to access Argo CD.
### Patches
A patch for this vulnerability has been released in the following Argo CD versions:
* v2.6.0-rc5
* v2.5.8
* v2.4.20
* v2.3.14
The patch introduces a new `allowedAudiences` to the OIDC config block. By default, the client ID is the only allowed audience. Users who _want_ Argo CD to accept tokens intended for a different audience may use `allowedAudiences` to specify those audiences.
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-cm
data:
oidc.config: |
name: Example
allowedAudiences:
- audience-1
- audience-2
- argocd-client-id # If `allowedAudiences` is non-empty, Argo CD's client ID must be explicitly added if you want to allow it.
``
Even though [the OIDC spec requires the audience claim](https://openid.net/specs/openid-connect-core-1_0.html#IDToken), some tokens may not include it. To avoid a breaking change in a patch release, versions < 2.6.0 of Argo CD will skip the audience claim check for tokens that have no audience. In versions >= 2.6.0, Argo CD will reject all tokens which do not have an audience claim. Users can opt into the old behavior by setting an option:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-cm
data:
oidc.config: |
name: Example
skipAudienceCheckWhenTokenHasNoAudience: true
```
### Workarounds
There is no workaround besides upgrading.
### Credits
The Argo CD team would like to express their gratitude to Vladimir Pouzanov (@farcaller) from Indeed, who discovered the issue, reported it confidentially according to our [guidelines](https://github.com/argoproj/argo-cd/blob/master/SECURITY.md#reporting-a-vulnerability), and actively worked with the project to provide a remedy. Many thanks to Vladimir!
### References
* [How to configure OIDC in Argo CD](https://argo-cd.readthedocs.io/en/latest/operator-manual/user-management/#existing-oidc-provider)
* [OIDC spec section discussing the audience claim](https://openid.net/specs/openid-connect-core-1_0.html#IDToken)
* [JWT spec section discussing the audience claim](https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3)
### For more information
* Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)
* Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd
{"id": "GHSA-Q9HR-J4RF-8FJC", "vendorId": null, "type": "github", "bulletinFamily": "software", "title": "JWT audience claim is not verified", "description": "### Impact\n\nAll versions of Argo CD starting with v1.8.2 are vulnerable to an improper authorization bug causing the API to accept certain invalid tokens.\n\nOIDC 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.\n\nIf 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.\n\nThis bug also increases the blast radius of a stolen token. If an attacker steals a valid token for a different audience, they can use it to access Argo CD.\n\n### Patches\n\nA patch for this vulnerability has been released in the following Argo CD versions:\n\n* v2.6.0-rc5\n* v2.5.8\n* v2.4.20\n* v2.3.14\n\nThe patch introduces a new `allowedAudiences` to the OIDC config block. By default, the client ID is the only allowed audience. Users who _want_ Argo CD to accept tokens intended for a different audience may use `allowedAudiences` to specify those audiences.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: argocd-cm\ndata:\n oidc.config: |\n name: Example\n allowedAudiences:\n - audience-1\n - audience-2\n - argocd-client-id # If `allowedAudiences` is non-empty, Argo CD's client ID must be explicitly added if you want to allow it.\n``\n\nEven though [the OIDC spec requires the audience claim](https://openid.net/specs/openid-connect-core-1_0.html#IDToken), some tokens may not include it. To avoid a breaking change in a patch release, versions < 2.6.0 of Argo CD will skip the audience claim check for tokens that have no audience. In versions >= 2.6.0, Argo CD will reject all tokens which do not have an audience claim. Users can opt into the old behavior by setting an option:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: argocd-cm\ndata:\n oidc.config: |\n name: Example\n skipAudienceCheckWhenTokenHasNoAudience: true\n```\n\n### Workarounds\n\nThere is no workaround besides upgrading.\n\n### Credits \n\nThe Argo CD team would like to express their gratitude to Vladimir Pouzanov (@farcaller) from Indeed, who discovered the issue, reported it confidentially according to our [guidelines](https://github.com/argoproj/argo-cd/blob/master/SECURITY.md#reporting-a-vulnerability), and actively worked with the project to provide a remedy. Many thanks to Vladimir!\n\n### References\n\n* [How to configure OIDC in Argo CD](https://argo-cd.readthedocs.io/en/latest/operator-manual/user-management/#existing-oidc-provider)\n* [OIDC spec section discussing the audience claim](https://openid.net/specs/openid-connect-core-1_0.html#IDToken)\n* [JWT spec section discussing the audience claim](https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3)\n\n### For more information\n\n* Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)\n* Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd\n", "published": "2023-01-25T22:02:52", "modified": "2023-02-07T21:21:41", "epss": [{"cve": "CVE-2023-22482", "epss": 0.0005, "percentile": 0.16862, "modified": "2023-05-31"}], "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}, "cvss2": {"cvssV2": {"version": "2.0", "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "accessVector": "NETWORK", "accessComplexity": "LOW", "authentication": "SINGLE", "confidentialityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "baseScore": 6.5}, "severity": "MEDIUM", "exploitabilityScore": 8.0, "impactScore": 6.4, "acInsufInfo": false, "obtainAllPrivilege": false, "obtainUserPrivilege": false, "obtainOtherPrivilege": false, "userInteractionRequired": false}, "cvss3": {"cvssV3": {"version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "attackVector": "NETWORK", "attackComplexity": "LOW", "privilegesRequired": "LOW", "userInteraction": "NONE", "scope": "UNCHANGED", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "availabilityImpact": "HIGH", "baseScore": 8.8, "baseSeverity": "HIGH"}, "exploitabilityScore": 2.8, "impactScore": 5.9}, "href": "https://github.com/advisories/GHSA-q9hr-j4rf-8fjc", "reporter": "GitHub Advisory Database", "references": ["https://github.com/argoproj/argo-cd/security/advisories/GHSA-q9hr-j4rf-8fjc", "https://nvd.nist.gov/vuln/detail/CVE-2023-22482", "https://github.com/advisories/GHSA-q9hr-j4rf-8fjc"], "cvelist": ["CVE-2023-22482"], "immutableFields": [], "lastseen": "2023-05-31T20:12:25", "viewCount": 27, "enchantments": {"dependencies": {"references": [{"type": "cve", "idList": ["CVE-2023-22482"]}, {"type": "hackerone", "idList": ["H1:1889161"]}, {"type": "osv", "idList": ["OSV:GHSA-Q9HR-J4RF-8FJC"]}, {"type": "redhat", "idList": ["RHSA-2023:0466", "RHSA-2023:0467", "RHSA-2023:0468"]}, {"type": "redhatcve", "idList": ["RH:CVE-2023-22482"]}, {"type": "veracode", "idList": ["VERACODE:39098"]}, {"type": "wallarmlab", "idList": ["WALLARMLAB:3D04C7EFDBCBCF085C43FFA938FB3C47", "WALLARMLAB:9CFFE14B0134DDC7E5CE56ADFE082425", "WALLARMLAB:C01B6866155737862F397EA6AF0FC99E"]}]}, "score": {"value": 8.7, "vector": "NONE"}, "affected_software": {"major_version": [{"name": "github.com/argoproj/argo-cd", "version": 2}, {"name": "github.com/argoproj/argo-cd", "version": 2}, {"name": "github.com/argoproj/argo-cd", "version": 2}, {"name": "github.com/argoproj/argo-cd", "version": 2}, {"name": "github.com/argoproj/argo-cd", "version": 2}, {"name": "github.com/argoproj/argo-cd", "version": 2}, {"name": "github.com/argoproj/argo-cd", "version": 1}, {"name": "github.com/argoproj/argo-cd", "version": 2}]}, "epss": [{"cve": "CVE-2023-22482", "epss": 0.00069, "percentile": 0.28175, "modified": "2023-05-02"}], "vulnersScore": 8.7}, "_state": {"dependencies": 1685574591, "score": 1685564048, "affected_software_major_version": 0, "epss": 0}, "_internal": {"score_hash": "f3ad77cafc0e3abae86d5812c4fee216"}, "affectedSoftware": [{"version": "2.6.0-rc5", "operator": "lt", "ecosystem": "GO", "name": "github.com/argoproj/argo-cd"}, {"version": "2.5.8", "operator": "lt", "ecosystem": "GO", "name": "github.com/argoproj/argo-cd"}, {"version": "2.4.20", "operator": "lt", "ecosystem": "GO", "name": "github.com/argoproj/argo-cd"}, {"version": "1.8.2", "operator": "ge", "ecosystem": "GO", "name": "github.com/argoproj/argo-cd"}, {"version": "2.3.14", "operator": "lt", "ecosystem": "GO", "name": "github.com/argoproj/argo-cd"}]}
{"osv": [{"lastseen": "2023-02-07T21:51:47", "description": "### Impact\n\nAll versions of Argo CD starting with v1.8.2 are vulnerable to an improper authorization bug causing the API to accept certain invalid tokens.\n\nOIDC 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.\n\nIf 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.\n\nThis bug also increases the blast radius of a stolen token. If an attacker steals a valid token for a different audience, they can use it to access Argo CD.\n\n### Patches\n\nA patch for this vulnerability has been released in the following Argo CD versions:\n\n* v2.6.0-rc5\n* v2.5.8\n* v2.4.20\n* v2.3.14\n\nThe patch introduces a new `allowedAudiences` to the OIDC config block. By default, the client ID is the only allowed audience. Users who _want_ Argo CD to accept tokens intended for a different audience may use `allowedAudiences` to specify those audiences.\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: argocd-cm\ndata:\n oidc.config: |\n name: Example\n allowedAudiences:\n - audience-1\n - audience-2\n - argocd-client-id # If `allowedAudiences` is non-empty, Argo CD's client ID must be explicitly added if you want to allow it.\n``\n\nEven though [the OIDC spec requires the audience claim](https://openid.net/specs/openid-connect-core-1_0.html#IDToken), some tokens may not include it. To avoid a breaking change in a patch release, versions < 2.6.0 of Argo CD will skip the audience claim check for tokens that have no audience. In versions >= 2.6.0, Argo CD will reject all tokens which do not have an audience claim. Users can opt into the old behavior by setting an option:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: argocd-cm\ndata:\n oidc.config: |\n name: Example\n skipAudienceCheckWhenTokenHasNoAudience: true\n```\n\n### Workarounds\n\nThere is no workaround besides upgrading.\n\n### Credits \n\nThe Argo CD team would like to express their gratitude to Vladimir Pouzanov (@farcaller) from Indeed, who discovered the issue, reported it confidentially according to our [guidelines](https://github.com/argoproj/argo-cd/blob/master/SECURITY.md#reporting-a-vulnerability), and actively worked with the project to provide a remedy. Many thanks to Vladimir!\n\n### References\n\n* [How to configure OIDC in Argo CD](https://argo-cd.readthedocs.io/en/latest/operator-manual/user-management/#existing-oidc-provider)\n* [OIDC spec section discussing the audience claim](https://openid.net/specs/openid-connect-core-1_0.html#IDToken)\n* [JWT spec section discussing the audience claim](https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3)\n\n### For more information\n\n* Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)\n* Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2023-01-25T22:02:52", "type": "osv", "title": "JWT audience claim is not verified", "bulletinFamily": "software", "cvss2": {}, "cvelist": ["CVE-2023-22482"], "modified": "2023-02-07T21:21:41", "id": "OSV:GHSA-Q9HR-J4RF-8FJC", "href": "https://osv.dev/vulnerability/GHSA-q9hr-j4rf-8fjc", "cvss": {"score": 0.0, "vector": "NONE"}}], "cve": [{"lastseen": "2023-05-31T17:41:11", "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.", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2023-01-26T21:18:00", "type": "cve", "title": "CVE-2023-22482", "cwe": ["CWE-863"], "bulletinFamily": "NVD", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2023-22482"], "modified": "2023-02-23T19:24:00", "cpe": ["cpe:/a:linuxfoundation:argo-cd:2.6.0"], "id": "CVE-2023-22482", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-22482", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}, "cpe23": ["cpe:2.3:a:linuxfoundation:argo-cd:2.6.0:rc4:*:*:*:*:*:*", "cpe:2.3:a:linuxfoundation:argo-cd:2.6.0:rc2:*:*:*:*:*:*", "cpe:2.3:a:linuxfoundation:argo-cd:2.6.0:rc3:*:*:*:*:*:*", "cpe:2.3:a:linuxfoundation:argo-cd:2.6.0:rc1:*:*:*:*:*:*"]}], "redhatcve": [{"lastseen": "2023-05-31T20:14:14", "description": "A flaw was found in ArgoCD. GitOps is vulnerable to an improper authorization bug where the API may accept invalid tokens. ID providers include an audience claim in signed tokens, which may be used to restrict which services can accept the token. ArgoCD doesn't properly validate the audience claim in such scenarios; if the ID provider used with ArgoCD is also being used with other audiences, it will accept tokens that may not be intended to access the ArgoCD cluster.\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2023-01-25T19:05:58", "type": "redhatcve", "title": "CVE-2023-22482", "bulletinFamily": "info", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2023-22482"], "modified": "2023-05-27T09:09:02", "id": "RH:CVE-2023-22482", "href": "https://access.redhat.com/security/cve/cve-2023-22482", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}}], "veracode": [{"lastseen": "2023-05-31T19:44:30", "description": "github.com/argoproj/argo-cd is vulnerable to Improper Authorization. The library does not validate the audience claim from signed-in tokens granting a malicious user's privileges based on the token's group claim, even though these groups were not intended, causing the API to accept certain invalid tokens.\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2023-02-03T07:29:48", "type": "veracode", "title": "Improper Authorization", "bulletinFamily": "software", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2023-22482"], "modified": "2023-02-23T21:44:53", "id": "VERACODE:39098", "href": "https://sca.analysiscenter.veracode.com/vulnerability-database/security/1/1/sid-39098/summary", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}}], "hackerone": [{"lastseen": "2023-06-01T21:32:55", "bounty": 8000.0, "description": "All versions of Argo CD starting with v1.8.2 are vulnerable to an improper authorization bug causing the API to accept certain invalid tokens.\n\nOIDC 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.\n\n## Impact\n\nIf 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.\n\nThis bug also increases the blast radius of a stolen token. If an attacker steals a valid token for a different audience, they can use it to access Argo CD.", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2023-02-28T18:06:26", "type": "hackerone", "title": "Internet Bug Bounty: JWT audience claim is not verified", "bulletinFamily": "bugbounty", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2023-22482"], "modified": "2023-04-16T18:43:01", "id": "H1:1889161", "href": "https://hackerone.com/reports/1889161", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}}], "wallarmlab": [{"lastseen": "2023-05-24T18:20:39", "description": "Argo CD is a popular [Continuous Deployment](<https://www.wallarm.com/what/what-is-ci-cd-concept-how-can-it-work>) tool that enables [DevOps](<https://www.wallarm.com/what/what-is-devops>) teams to manage their applications across multiple environments. However, in the past two weeks, three critical vulnerabilities have been detected in the tool, exposing sensitive information and compromising the security of the system. In this article, we will discuss the three vulnerabilities and their impact on the system, as well as the patches and workarounds available. Let's dive into it!\n\nThe first vulnerability ([CVE-2023-22736](<https://github.com/argoproj/argo-cd/security/advisories/GHSA-6p4m-hw2h-6gmw>)) is a high severity issue that allows for an **authorization bypass**. This vulnerability occurs when the application controller does not enforce the reconciled application namespaces list when sharding is enabled. As a result, a malicious Argo CD user can deploy applications outside of the configured allowed namespaces. This vulnerability affects all Argo CD versions starting with 2.5.0-rc1 and is limited to users who have enabled the "apps-in-any-namespace" feature. Patches have been released in Argo CD versions 2.5.8 and 2.6.0-rc5 to fix this issue.\n\nThe second vulnerability ([CVE-2023-22482](<https://github.com/argoproj/argo-cd/security/advisories/GHSA-q9hr-j4rf-8fjc>)) is a critical issue that is caused by **improper** **authorization**. This vulnerability occurs when Argo CD does not validate the audience claim in signed tokens, resulting in the API accepting invalid tokens. If the OIDC provider also serves other audiences, Argo CD will accept tokens intended for those audiences and grant the user privileges based on the token's groups claim. This issue affects all versions of Argo CD starting with v1.8.2. Patches have been released in Argo CD versions 2.6.0-rc5, 2.5.8, 2.4.20, and 2.3.14. The patch introduces a new "allowedAudiences" feature to the OIDC config block, allowing users to specify the audiences they want to allow.\n\nThe third vulnerability ([CVE-2023-25163](<https://github.com/argoproj/argo-cd/security/advisories/GHSA-mv6w-j4xc-qpfw>)) is a moderate severity issue that results in the **leakage of repository access credentials** in error messages. This vulnerability affects all versions of Argo CD starting with v2.6.0-rc1 and occurs when output sanitization is not properly done, leading to the leakage of sensitive information in error messages. This issue can be resolved by upgrading to a newer version of Argo CD.\n\nIn conclusion, these recent vulnerabilities highlight the importance of[ API security ](<https://www.wallarm.com/what/api-security-tutorial>)and the need for companies to focus on securing their APIs. While these issues are a cause for concern for Argo CD users, it is worth noting that [Wallarm](<https://www.wallarm.com/request-demo>) customers are protected against these vulnerabilities. With the octopus being the Argo CD logo, it's important to have a strong defense against any potential "octo-attacks."\n\nThe post [Octopus Strike! Three Argo CD API Exploits In Two Weeks](<https://lab.wallarm.com/octopus-strike-three-argo-cd-api-exploits-in-two-weeks/>) appeared first on [Wallarm](<https://lab.wallarm.com>).", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2023-02-11T16:07:05", "type": "wallarmlab", "title": "Octopus Strike! Three Argo CD API Exploits In Two Weeks", "bulletinFamily": "blog", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2023-22482", "CVE-2023-22736", "CVE-2023-25163"], "modified": "2023-02-11T16:07:05", "id": "WALLARMLAB:C01B6866155737862F397EA6AF0FC99E", "href": "https://lab.wallarm.com/octopus-strike-three-argo-cd-api-exploits-in-two-weeks/", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}}, {"lastseen": "2023-02-02T15:05:34", "description": "Leaks of API keys and other secrets. The industry has been abuzz with news about attacks \u2013 and the ongoing ripple effect \u2013 involving leaked API keys, credentials and other secrets. This adds another dimension to your API attack surface, which in turn complicates your defenses and adds to your workload. So, this month the focus of The APIary is on leaked API keys and other secrets \u2013 read on for this month's bit o' honey.\n\n\n\n2023 certainly started with a bang. News, which dribbled out (perhaps deliberately?) in the waning minutes of 2022 and into early 2023, regarding several development infrastructure breaches involving APIs gave us a lot to think about. For instance:\n\n * **CircleCI** posted an [advisory](<https://circleci.com/blog/january-4-2023-security-alert/>) in early January regarding a presumed breach of their systems, potentially putting 1000s of organizations at risk.\n * **Slack** [notified](<https://slack.com/intl/en-gb/blog/news/slack-security-update>) the development community on New Year\u2019s Eve that some Slack employee tokens were stolen and misused to gain access to their GitHub repository.\n * **LastPass **finally [admitted](<https://blog.lastpass.com/2022/12/notice-of-recent-security-incident/>) on Dec 22nd that an earlier breach back in August, in which credentials and keys were obtained, allowed an adversary nearly unfettered access to a cloud-based backup system, putting end users\u2019 password vaults at risk.\n * **Travis CI **continues to have issues, with the latest coming from researchers who [reported last summer](<https://arstechnica.com/information-technology/2022/06/credentials-for-thousands-of-open-source-projects-free-for-the-taking-again/>) that they had found over 73,000 tokens, secrets, and various credentials.\n\nThese incidents, all involving leaked API keys and other secrets at some point, are another example of the growing API attack surface that many may not be aware of. And while it's absolutely necessary to mitigate this issue as early as possible (i.e., during the development process), it's also true that it's impossible to prevent the issue entirely.\n\nWhy? Because of increasing development velocity, tech stack complexity and of course SW supply chain risks. That's why we've just dropped an "early release" version of our new [**API Leak Management**](<https://lab.wallarm.com/introducing-proactive-api-leak-management/>) capability. It provides actionable threat intelligence regarding leaked API keys and other secrets from your domain, covering your entire API portfolio. Read on to learn more!\n\nSpeaking of API-related breaches, by now you've undoubtedly heard about another T-Mobile breach, this one impacting 37M customers. If not, read [the coverage](<https://www.infosecurity-magazine.com/news/api-attacker-steals-data-37/>) by the always excellent Phil Muncaster in Infosecurity Magazine, or head over to [our blog post](<https://lab.wallarm.com/learn-from-the-t-mobile-api-breach-to-improve-your-api-security-program-in-2023/>). It's just another proof point that API security needs to be at the forefront of everyone's minds, and 2023 security plans!\n\n \u2013 Ivan, CEO & Co-Founder, Wallarm\n\nPS \u2013 Stay up-to-the-minute on all the latest news about [#apisecurity](<https://www.linkedin.com/feed/hashtag/?keywords=apisecurity&highlightedUpdateUrns=urn%3Ali%3Aactivity%3A6999039478417825792>) exploits and updates by following our new [**API ThreatStats LinkedIn page**](<https://www.linkedin.com/company/threatstats/>).\n\n\n\nLast month we asked whether you use any of the existing cybersecurity frameworks (such as CIS CSC, MITRE ATT&CK, NIST CSF, etc.) for managing your API Security? It looks like most of you are well down this path, although almost one-third say it\u2019s not on your radar:\n\n\n\nAnd we\u2019d love to have you weigh in on our next **LinkedIn poll** we're conducting: **_[How confident are you that _none_ your API keys and other secrets have leaked into the wild?](<https://www.linkedin.com/feed/update/urn:li:activity:7026628486760910848>)_** Please let us know where you stand on this \u2013 [connect with Ivan](<https://www.linkedin.com/in/d0znpp/>) or [follow us at Wallarm](<https://www.linkedin.com/company/wallarm/>) to register your vote.\n\n\n\n[**Devs urged to rotate secrets after CircleCI suffers security breach**](<https://portswigger.net/daily-swig/devs-urged-to-rotate-secrets-after-circleci-suffers-security-breach>)\n\n(**_The Daily Swig_**) Developers are being urged to rotate secrets and API tokens following the discovery of a breach at popular [DevOps](<https://portswigger.net/daily-swig/devsecops>) platform CircleCI.\n\n[**3Commas API Leak Highlights Yet Another Way to Lose Your Money**](<https://www.securities.io/3commas-api-leak-highlights-yet-another-way-to-lose-your-money/>)\n\n(**_Securities.io_**) In today\u2019s digital age, it\u2019s more important than ever to guard against the potential risks of API leaks, as it can lead to the loss of personal information and financial data.\n\n[**Toyota, Mercedes, BMW API flaws exposed owners\u2019 personal info**](<https://www.bleepingcomputer.com/news/security/toyota-mercedes-bmw-api-flaws-exposed-owners-personal-info/>)\n\n(**_BleepingComputer_**) Almost 20 car manufacturers and services contained API security vulnerabilities that could have allowed hackers to unlock, start, and track cars, and/or expose customers' personal information.\n\n[**Employee Tokens Stolen Through Slack GitHub Account**](<https://informationsecuritybuzz.com/employee-tokens-stolen-through-slack-github-account/>)\n\n(**_Information Security Buzz_**) Indications are that intruders used stolen employee tokens to download private code from the company\u2019s GitHub repository.\n\n[**Twitter data breach shows APIs are a goldmine for PII and social engineering**](<https://venturebeat.com/security/twitter-social-engineering/>)\n\n(**_VentureBeat_**) Insecure APIs provide cybercriminals with direct access to user\u2019s personally identifiable information ([PII](<https://venturebeat.com/data-infrastructure/the-new-meaning-of-pii-can-you-ever-be-anonymous/>)), usernames and passwords when a client connects to a third-party service\u2019s API.\n\n[**API Security Is the New Black**](<https://www.darkreading.com/dr-tech/api-security-is-the-new-black>)\n\n(_**DarkReading**_) API attacks are back in the news. It turns out the likely ingress point for the[ Optus breach](<https://www.darkreading.com/attacks-breaches/fbi-helping-australian-authorities-investigate-massive-optus-data-breach-reports>) was a lowly REST API. And someone has leaked all of the data stolen from the [Twitter breach](<https://venturebeat.com/security/twitter-breach-api-attack/>) \u2014 which also involved an API.\n\n[**To Solve the API Security Crisis, Think Beyond OWASP**](<https://securityboulevard.com/2023/01/to-solve-the-api-security-crisis-think-beyond-owasp/>)\n\n(**_Security Boulevard_**) APIs have now become the top attack vector for enterprises to worry about, [according to an October 2022 Gartner report](<https://www.infosecurity-magazine.com/next-gen-infosec/api-attacks-threat-vector-2022/>). Not coincidentally, the frequency of API attacks has increased by an astounding 681%.\n\n[**5 GraphQL Trends to Watch in 2023**](<https://devops.com/5-graphql-trends-to-watch-in-2023/>)\n\n(**_DevOps.com_**) GraphQL introduces new [security concerns](<https://devops.com/graphql-vulnerability-analysis-the-top-threats/>). And as attacks on APIs continue to increase and grow in sophistication, an increased [security focus](<https://devops.com/graphqls-greatest-strength-is-also-its-greatest-weakness/>) will undoubtedly be required to avoid vulnerabilities. \n\n[**Orgs Must Prepare for SEC Cybersecurity Requirements Aimed at Boards**](<https://securityboulevard.com/2023/01/orgs-must-prepare-for-sec-cybersecurity-requirements-aimed-at-boards/>)\n\n(**_Security Boulevard_**) By the end of 2023, the SEC is expected to finalize its proposal requiring companies to attest to their boards\u2019 cybersecurity acumen\u2014as well as disclose their cybersecurity oversight efforts and information on attacks.\n\n[**Why you should never trust PoC exploits on GitHub**](<https://danaepp.com/why-you-should-never-trust-poc-exploits-on-github>)\n\n(**_Dana Epp\u2019s Blog_**) Realize that Ronald Reagan\u2019s thinking that we can \u201ctrust, but verify\u201d is backward. Trust nothing. Verify everything.\n\n\n\n[**KubePi Hardcoded Jwtsigkeys**](<https://github.com/KubeOperator/KubePi/security/advisories/GHSA-vjhf-8vqx-vqpq>) (CVSS score: 9.8)\n\nIn certain versions of KubePi, hard-coded Jwtsigkeys could allow an attacker to take over the admin account of any online project using a forged JWT. ([CVE-2023-22463](<https://nvd.nist.gov/vuln/detail/CVE-2023-22463>))\n\n[**Izanami Authentication Bypass**](<https://github.com/MAIF/izanami/security/advisories/GHSA-9r7j-m337-792c>) (CVSS score: 9.8)\n\nIn some versions of Izanami, attackers could bypass authentication settings using a hard-coded JWT to compromise other Izanami instances. ([CVE-2023-22495](<https://nvd.nist.gov/vuln/detail/CVE-2023-22495>))\n\n[**Argo CD JWT Audience Claim is Not Verified**](<https://github.com/argoproj/argo-cd/security/advisories/GHSA-q9hr-j4rf-8fjc>) (CVSS score: 9.0)\n\nIn some versions of Argo CD, certain invalid tokens are accepted due to improper authorization, which could allow attackers to obtain unintended privileges. ([CVE-2023-22482](<https://nvd.nist.gov/vuln/detail/CVE-2023-22482>))\n\n[**Rancher Wrangler API Missing Encryption**](<https://github.com/advisories/GHSA-cq4p-vp5q-4522>) (CVSS score: 9.9)\n\nIn some versions of Rancher Wrangler, certain secrets (including sensitive fields, secret tokens, encryption keys, and SSH keys) are being stored in plaintext, impacting access and confidentiality. ([CVE-2022-43757](<https://vuldb.com/?id.219300>))\n\n[**GitHub Enterprise Server Incorrect Authorization Vulnerability**](<https://docs.github.com/en/enterprise-server@3.7/admin/release-notes#3.7.1>) (CVSS score: 9.8)\n\nIn some versions of GitHub Enterprise Server, scoped user-to-server tokens from GitHub Apps could bypass authorization checks in GraphQL API requests when accessing non-repository resources. ([CVE-2022-23739](<https://nvd.nist.gov/vuln/detail/CVE-2022-23739>))\n\n[**KubeOperator Unauthorized Access to System API**](<https://github.com/KubeOperator/KubeOperator/security/advisories/GHSA-jxgp-jgh3-8jc8>) (CVSS score: 9.8)\n\nIn some versions of KubeOperator, attackers could bypass preset permission settings to access some API interfaces, allowing them to take over the cluster under certain circumstances. ([CVE-2023-22480](<https://nvd.nist.gov/vuln/detail/CVE-2023-22480>))\n\n[**SAP NetWeaver AS for Java Improper Access Control**](<https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html>) (CVSS score: 9.8)\n\nIn certain versions of SAP NetWeaver AS for Java, improper access controls could allow attackers to obtain full read / write access and perform unauthorized operations impacting users and data. ([CVE-2023-0017](<https://nvd.nist.gov/vuln/detail/CVE-2023-0017>))\n\nWe recommend that you assess your portfolio for exposure to these vulnerabilities, apply updates where possible, and monitor for further incidents.\n\n\n\nICYMI, Wallarm recently announced the early release of our new [**API Leak Management**](<https://www.wallarm.com/api-leak-management-early-release>) solution to help protect against unintended or malicious use of leaked API keys and other secrets.\n\nWith this capability, we automatically and proactively discover leaked API keys and other secrets, create controls to block API calls/requests using leaked credentials, and track those leaked credentials across the organization's entire API portfolio to protect against follow-on attacks. For more information, please see:\n\n[](<https://lab.wallarm.com/introducing-proactive-api-leak-management/>) \n[Blog post](<https://lab.wallarm.com/introducing-proactive-api-leak-management/>)| [](<https://hubspot.wallarm.com/hubfs/Wallarm%20API%20Leak%20Management%20Datasheet.pdf>) \n[Datasheet](<https://hubspot.wallarm.com/hubfs/Wallarm%20API%20Leak%20Management%20Datasheet.pdf>)| [](<https://www.youtube.com/watch?v=MR_lQzzYzYA>) \n[Demo Video](<https://www.youtube.com/watch?v=MR_lQzzYzYA>)| [](<https://www.wallarm.com/webinars/api-leaks-management-intro-webinar>) \n[Webinar](<https://www.wallarm.com/webinars/api-leaks-management-intro-webinar>) \n---|---|---|--- \n \nIn addition, we are offering a complimentary assessment to discover any leaked API secrets from your domain, including API keys, credentials, private specifications, etc. Knowledge is power \u2013 because you can\u2019t protect what you don\u2019t know about.\n\n[](<https://www.wallarm.com/api-leak-management-early-release>)\n\n**Did You Know?** You can subscribe to our [**update announcements**](<https://changelog.wallarm.com/>) to keep up-to-date with the latest product news.\n\n\n\n[Wallarm adds Cybersecurity Leaders to its Board of Advisors](<https://lab.wallarm.com/new-leaders-to-board-of-advisors/>)\n\nWallarm, introduced the newest cybersecurity luminaries to join the company\u2019s already impressive Board of Advisors, who bring broad and in-depth cybersecurity and business expertise, and are eager to share their hard-won knowledge and insights with fellow cybersecurity executives.\n\n\n\n**Upcoming**:\n\n**_Webinar_** [_2023-Feb-16_] \u2014 [API ThreatStats Report: 2022 Year-in-Review & Q4 Results](<https://www.wallarm.com/webinars/api-threatstats-2022-and-q4>)\n\nJoin us for a live, interactive product demo of Wallarm on January 5, where you can learn more about the key components of the platform and recent feature enhancements.\n\n[](<https://www.wallarm.com/webinars/api-threatstats-2022-and-q4>)\n\n**Past**:\n\n**_Webinar_** [_on-demand_] \u2014 [Wallarm Platform Democast: What\u2019s New](<https://us02web.zoom.us/webinar/register/WN_-eTBd58JRL2q-tXlS5psRg?utm_campaign=Monthly%20newsletter&utm_source=hs_email&utm_medium=email&utm_content=2&_hsenc=p2ANqtz-94_Dbp93QsGkMkoDmGVFBZQNFYXfWHOPh1YHzE45ZVpi9gAx5o5oNqMS4brUdRDnxGEH_x8m1TBKtROEXgXYP0iNJS9g>)\n\nWatch this interactive product demo of Wallarm we hosted on January 5, where you can learn more about the key components of the platform and recent feature enhancements.\n\n**_Webinar_** [_on-demand_] \u2014 [Solving Your API Key Leaks Challenge: Wallarm Launches API Leak Solution](<https://www.wallarm.com/webinars/api-leaks-management-intro-webinar>)\n\nCome see this short webinar where we introduced our early release of the Wallarm API Leak Management solution, an enhanced API security technology designed to help organizations discover and remediate attacks exploiting leaked API keys and secrets.\n\n**_Webinar_** [_on-demand_] \u2014 [How CISOs Can Build an API Security Program](<https://www.wallarm.com/webinars/how-cisos-can-build-an-api-security-program>)\n\nRajendra Umadas, Senior Platform Security Manager at ActBlue, and Stepan Ilyin, Wallarm co-founder, have a fireside chat about the necessary components of a robust API security program to better protect your organization\u2019s APIs and web applications. \n\n## **Where APIs Meet Apis**\n\nAnd now for something completely different. Since the t heme of The APIary newsletter is based on hardworking & industrious bees, we thought we\u2019d share this bee-meme with you. Nothing better than a [good Dad joke](<https://hubspot.wallarm.com/e3t/Ctc/ZR+113/ctlhg04/VVp3xd2qC_t_V15x0C1HKtvmW3NdgT54WwswXN4jRWcQ3q3n_V1-WJV7CgRfsW1Twk2b2r_CpXW1Bf7Nc64gTDSW7z7Tg369bZyvW4d-3cr3Hzw_sW5CHC1_3m76r5W2PwM7s6qlPC8W4jr8-w4sbCVLVsZWfS8VQzY1VFKRPy24C0P6W1TWpzB1DD1_DW5T65Z06Mb1lQW6k19p44sGXWSW2w9Fnf3pRtN2W5931fp5YqZPXW2qScMT6n2NPTW55qMtw5YpQhsW5zRtqH5-548WW5XT67C621hP7W1cQGsQ7j419PW8yrVwv1snZJWW3HTVrw357CDRW2mpsgY2L1K8XW5J08QG92pZmlW89kzDx7VdvTSW3BkKDM49zckZW8XBcB44_cNh-32cN1>). Enjoy! \n\n\n\nThe post [Don\u2019t Let API Leaks Sink Your Ship | API Security Newsletter](<https://lab.wallarm.com/january-2023-newsletter/>) appeared first on [Wallarm](<https://lab.wallarm.com>).", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2023-02-02T14:24:48", "type": "wallarmlab", "title": "Don\u2019t Let API Leaks Sink Your Ship | API Security Newsletter", "bulletinFamily": "blog", "cvss2": {}, "cvelist": ["CVE-2022-23739", "CVE-2022-43757", "CVE-2023-0017", "CVE-2023-22463", "CVE-2023-22480", "CVE-2023-22482", "CVE-2023-22495"], "modified": "2023-02-02T14:24:48", "id": "WALLARMLAB:3D04C7EFDBCBCF085C43FFA938FB3C47", "href": "https://lab.wallarm.com/january-2023-newsletter/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2023-05-31T18:21:12", "description": "March has arrived and is roaring like a very confused lion, at least in the northern hemisphere. And much like in the wild, brood production is increasing. We've already seen some fruits of that labor, such as the Q4-2022 and 2022 Year-End ThreatStats\u2122 Report, and some very tasty product upgrades. Read on for this month's bit o' honey.\n\n\n\nGreetings everyone!\n\nWe've been keeping an eye on the API threat landscape, and some notable API vulnerabilities that you should be aware of. But don't worry, we're here to help with our latest threat research and product updates.\n\nOur recent API vulnerability, exploit and attack data analysis has yielded both [Q4-focused results](<https://lab.wallarm.com/q4-2022-api-threatstats-report/>) and a [2022 year-end review](<https://lab.wallarm.com/2022-year-end-api-threatstats-report/>), with predictions for 2023 including continued rise in API vulnerabilities, growth in API attacks, and worsening time-to-exploit window.\n\nAs you'll also learn from the report, OWASP API Security Top-10 does not perfectly cover real API exploits; therefore, we\u2019re hoping the new one will be much better. To learn more about the recently released first draft and what to expect of OWASP API Top-10 2023, join us on March 16th for what promises to be [a lively webinar](<https://www.wallarm.com/webinars/new-2023-owasp-api-security>).\n\nOn the product front, we're continuing to release improvements to ensure users are getting the best end-to-end security for their APIs. We've recently dropped enhancements in API Discovery (which is really all about security posture), and SSRF protection. Find the details below.\n\nAs a spoiler, this month you will also find my API security predictions for 2023 in an upcoming Forbes article. I'm expecting that API token leaks will be part of kill-chains which will result in different types of attacks in 2023. I also expect to see an increase in API abuse attacks due to authentication and authorization issues, as well as a rise in data decoding attacks targeting APIs. My thoughts are based on vulnerability, exploit & attack data analyzed in our [2022 Year-End ThreatStats\u2122 Report](<https://www.wallarm.com/resources/2022-year-end-api-threatstats-full-report>), and the many data breaches which happened last year.\n\n\u2013 Ivan, CEO & Co-Founder, Wallarm\n\nPS \u2013 Stay up-to-the-minute on all the latest news about [#apisecurity](<https://www.linkedin.com/feed/hashtag/?keywords=apisecurity&highlightedUpdateUrns=urn%3Ali%3Aactivity%3A6999039478417825792>) exploits and updates by following our new [**API ThreatStats LinkedIn page**](<https://www.linkedin.com/company/threatstats/>).\n\n\n\n**Wallarm news**\n\nThe 2022 API vulnerability, exploit and attack data have been crunched and the latest **API ThreatStats\u2122 Report** season is complete. The team provided both Q4-focused results and, perhaps more importantly, a 2022 year-end review. Lots to explore, including:\n\n * Q4-2022 [blog post](<https://lab.wallarm.com/q4-2022-api-threatstats-report/>) and [infographic](<https://hubspot.wallarm.com/hubfs/Q4%20API%20ThreatStats\\(TM\\)%20infographic.pdf>)\n * YE-2022 [blog post](<https://lab.wallarm.com/2022-year-end-api-threatstats-report/>), [report](<https://www.wallarm.com/resources/2022-year-end-api-threatstats-full-report>) and [on-demand webinar](<https://www.wallarm.com/webinars/api-threatstats-2022-and-q4>)\n\nToo much to recap here, but be sure to read check out our predictions for 2023, including:\n\n * Continued rise in API vulnerabilities, in numbers and severity.\n * Unceasing growth in API attacks, which will lead to even more breaches.\n * Worsening time-to-exploit window, which will put even more pressure on security and DevOps teams.\n\n\n\nRead the 2022 year-end collection to know what to prepare for, and look at the Q4-2022 collection to learn how we got here. Dig In!\n\n\n\nThe hive has served up some sweet ambrosia for Wallarm users in the past month.\n\n\n\n**API Discovery Dashboard Upgrades**\n\nWith this update, you can now more easily monitor sensitive data (to maintain compliance), track API changes (to monitor drift), identify risky endpoints (to reduce your API attack surface), and more. Read more in [this changelog entry](<https://changelog.wallarm.com/introducing-the-wallarm-api-discovery-dashboard-12HrJ6>).\n\n**SSRF Attack Mitigation**\n\nServer-Side Request Forgery (SSRF) attacks can allow malicious actors to read server configurations, connect to internal services, perform unintended post requests, or circumvent input validation. With this update, which requires Node v 4.4.3, you can now more easily protect against this attack vector. Read more in [this changelog entry](<https://changelog.wallarm.com/ssrf-mitigation-for-mission-critical-apis-with-wallarm-last-update-NTPws>).\n\n**Did You Know?** You can subscribe to our [**update announcements**](<https://changelog.wallarm.com/>) to keep up-to-date with the latest product news.\n\n\n\n**Upcoming:**\n\n**_Webinar_** [_Mar 16, 2023_] \u2014 [A CISOs Guide To The New 2023 OWASP API Security Update](<https://www.wallarm.com/webinars/new-2023-owasp-api-security>)\n\nJoin our upcoming webinar as we explore the new Top-10 API risks Release Candidate (RC) for 2023, and the implications of these updates to your API security posture.\n\n[](<https://www.wallarm.com/webinars/new-2023-owasp-api-security>)\n\n**Past:**\n\n**_Webinar_** [_on-demand_] \u2014 [API ThreatStats\u2122 Report: 2022 Year-in-Review & Q4 Results](<https://www.wallarm.com/webinars/api-threatstats-2022-and-q4>)\n\nThe Wallarm Research team looked through all published API vulnerabilities and exploits for 2022 and aggregated these into our year-end report. Watch our recording of our recap of the highlights and trends we saw in 2022, and hear our predictions for what\u2019s to come in 2023.\n\n\n\n[**VMware NSX Manager Vulnerabilities Being Actively Exploited in the Wild**](<https://lab.wallarm.com/vmware-nsx-manager-vulnerabilities-being-actively-exploited-in-the-wild/>)\n\nRead this write-up from the Wallarm Detect team regarding exploit attempts in the wild of [CVE-2022-31678](<https://nvd.nist.gov/vuln/detail/CVE-2022-31678>) (CVSS score: 9.1) and [CVE-2021-39144](<https://nvd.nist.gov/vuln/detail/CVE-2021-39144>) (CVSS score: 8.5) impacting [VMware NSX Manager](<https://www.vmware.com/products/nsx.html>). If successfully exploited, the impact of these vulnerabilities could be catastrophic, allowing attackers to execute arbitrary code, steal data, and/or take control of the network infrastructure.\n\n[**Octopus Strike! Three Argo CD API Exploits In Two Weeks**](<https://lab.wallarm.com/octopus-strike-three-argo-cd-api-exploits-in-two-weeks/>)\n\nRead this write-up from the Wallarm Detect team regarding three (3) vulnerabilities impacting [Argo CD](<https://github.com/argoproj/argo-cd>), a popular open-source CD tool used by many DevOps teams to manage their apps. These include:\n\n * [CVE-2023-22736](<https://nvd.nist.gov/vuln/detail/CVE-2023-22736>) \u2013 an authorization bypass vulnerability (CVSS score: 8.5)\n * [CVE-2023-22482](<https://nvd.nist.gov/vuln/detail/CVE-2023-22482>) \u2013 an improper authorization vulnerability (CVSS score: 8.8)\n * [CVE-2023-25163](<https://nvd.nist.gov/vuln/detail/CVE-2023-25163>) \u2013 results in leakage of repository access credentials in error messages (CVSS score: 6.5)\n\n[**Yet More ImageMagick Vulnerabilities**](<https://lab.wallarm.com/yet-more-imagemagick-vulnerabilities/>)\n\nRead this write-up from the Wallarm Detect team regarding [CVE-2022-44267](<https://nvd.nist.gov/vuln/detail/CVE-2022-44267>) (CVSS score: 6.5) and [CVE-2022-44268](<https://nvd.nist.gov/vuln/detail/CVE-2022-44268>) (CVSS score: 6.5) which allow attackers to arbitrarily read files in [ImageMagick](<https://imagemagick.org/index.php>), a popular open-source image editing suite, and to cause denial-of-service (DoS) disruptions.\n\n[**React-admin XSS Attack on RichTextField**](<https://github.com/marmelab/react-admin/security/advisories/GHSA-5jcr-82fh-339v>) (CVSS score: 5.4)\n\nAll React applications built with react-admin and using the <RichTextField> are affected. If the data isn't sanitized server-side, this opens a possible Cross-Site-Scripting (XSS) attack. An exploit POC has been published. ([CVE-2023-25572](<https://nvd.nist.gov/vuln/detail/CVE-2023-25572>))\n\n[**Directus SSRF Attack on File Import**](<https://github.com/directus/directus/security/advisories/GHSA-j3rg-3rgm-537h>) (CVSS score: 5.0)\n\nSome versions of Directus are vulnerable to Server-Side Request Forgery (SSRF) when importing a file from a remote web server (POST to `/files/import`). An exploit POC has been published. ([CVE-2023-26492](<https://nvd.nist.gov/vuln/detail/CVE-2023-26492>))\n\n[**ZoneMinder SQL Injection Attack via Malicious JWT**](<https://github.com/ZoneMinder/zoneminder/security/advisories/GHSA-6c72-q9mw-mwx9>) (CVSS score: 8.1)\n\nSome versions of Zoneminder are susceptible to SQL Injection via malicious JSON web token (JWT). A patch has been released. ([CVE-2023-26032](<https://nvd.nist.gov/vuln/detail/CVE-2023-26032>))\n\n[**Apache Kafka Connect Unrestricted Deserialization of Untrusted Data**](<https://kafka.apache.org/cve-list>) (CVSS score: 8.8)\n\nSome versions of Apache Kafka Connect might be subject to possible Remote Code Execution (RCE) or Denial of Service (DoS) attacks via SASL JAAS configs which allow JNDI requests to be performed. An upgrade is available. ([CVE-2023-25194](<https://nvd.nist.gov/vuln/detail/CVE-2023-25194>))\n\n[**TinaCMS Sensitive Information Leak via Script File**](<https://github.com/tinacms/tinacms/security/advisories/GHSA-pc2q-jcxq-rjrr>) (CVSS score: 7.5)\n\nSome versions of TinaCMS which store sensitive credentials such as environment variables (e.g., Algolia API keys) are impacted. Users are advised to rotate exposed keys. An upgrade is available. ([CVE-2023-25164](<https://nvd.nist.gov/vuln/detail/CVE-2023-25164>))\n\n[**Gitpod Cross-Site WebSocket Hijacking Vulnerability**](<https://app.safebase.io/portal/71ccd717-aa2d-4a1e-942e-c768d37e9e0c/preview?product=default&orgId=71ccd717-aa2d-4a1e-942e-c768d37e9e0c&tcuUid=1d505bda-9a38-4ca5-8724-052e6337f34d>) (CVSS score: 8.2)\n\nSome versions of Gitpod are vulnerable to a takeover of shared workspaces due to a a Cross-Site WebSocket Hijacking (CSWSH) vulnerability. An upgrade is available. ([CVE-2023-0957](<https://nvd.nist.gov/vuln/detail/CVE-2023-0957>))\n\nWe recommend that you assess your portfolio for exposure to these vulnerabilities, apply updates where possible, and monitor for further incidents. For more on notable API vulns, make sure to subscribe to our new [**API ThreatStats LinkedIn page**](<https://www.linkedin.com/company/threatstats/>). \n\n\n\n[**Sumo Logic Keeps API Credentials on Endpoints**](<https://seclists.org/fulldisclosure/2023/Feb/11>)\n\n(SecLists) _Get access to the entire API using accessid and accesskey, found in log file_.\n\n[**High-severity Vulnerability in F5 BIG-IP Let Attackers Execute Arbitrary Code**](<https://gbhackers.com/high-severity-flaw-in-f5-big-ip/>)\n\n(GBHackers) _A high-severity format string vulnerability in F5 BIG-IP that could result in a denial-of-service (DoS) issue and possibly execute arbitrary code_.\n\n[**E-Commerce Shops: 12% Are Publicly Exposing Private Backup**](<https://www.databreachtoday.com/e-commerce-shops-12-are-publicly-exposing-private-backups-a-21152>)\n\n(Data Breach Today) _A study of 2,037 e-commerce shops found that 250 of them had backups that contained private information and that were stored in publicly accessible folders with no access restrictions_.\n\n[**Bypassing Akamai\u2019s WAF Using an Injected Content-Encoding Header**](<https://www.praetorian.com/blog/using-crlf-injection-to-bypass-akamai-web-app-firewall/>)\n\n(Praetorian blog) _An interesting method to bypass the cross-site scripting (XSS) filtering functionality within the Akamai Web Application Firewall (WAF) solution_.\n\n[**Analyzing Your Existing API Testing Through a Security Lens**](<https://danaepp.com/analyzing-your-existing-api-testing-through-a-security-lens>)\n\n(Dana Epp\u2019s blog) _APIs are a prime target for exploitation and need to be protected, so developers must also introduce security testing into their existing QA strategy to protect applications from malicious attacks and vulnerabilities_.\n\n[**How Application Mapping Can Boost Application Security**](<https://gbhackers.com/how-application-mapping-can-boost-application-security/>)\n\n(GBHackers) _Application mapping helps identify potential vulnerabilities and areas of risk, and supports security testing, incident response, and overall application security planning_.\n\n[**ChatGPT for Offensive Security: Five Attacks**](<https://cisoperspective.com/index.php/2023/02/21/chatgpt-for-offensive-security-five-attacks/>)\n\n(The CISO Perspective) _Attackers are finding ways are using ChatGPT for nefarious purposes on underground hacking forums_.\n\n[**An API Security Testing Checklist\u2026 with a twist**](<https://danaepp.com/an-api-security-testing-checklist-with-a-twist>)\n\n(Dana Epp\u2019s blog) _This red team checklist enumerates how to approach the API target, how to attack it, and how to leave little to no trace_.\n\n[**Most web API flaws are missed by standard security tests**](<https://portswigger.net/daily-swig/most-web-api-flaws-are-missed-by-standard-security-tests-corey-j-ball-on-securing-a-neglected-attack-vector>)\n\n(The Daily Swig) _APIs can become less of a liability by including security-focused team members during design, encouraging secure coding, conducting regular security tests, and monitoring programming calls for attacks and misuse_.\n\n[**When It Comes To Zero Trust, Nobody Puts Appsec In A Corner**](<https://www.forrester.com/blogs/when-it-comes-to-zero-trust-nobody-puts-appsec-in-a-corner/>)\n\n(Forrester blog) _Forrester\u2019s Security Survey, 2022, shows that 83% of global large enterprises are reporting that senior leadership has committed their organizations to the adoption of Zero Trust_.\n\n[**Top Takeaways From CloudNativeSecurityCon 2023**](<https://www.darkreading.com/omdia/top-takeaways-from-cloudnativesecuritycon-2023>)\n\n(Dark Reading) _One notable trend is "shift right," which is gaining equal importance in understanding what is going on in the runtime environment_.\n\n[**How to address growing API security vulnerabilities in 2023**](<https://www.itsecurityguru.org/2023/02/24/how-to-address-growing-api-security-vulnerabilities-in-2023/?utm_source=rss&utm_medium=rss&utm_campaign=how-to-address-growing-api-security-vulnerabilities-in-2023>)\n\n(IT Security Guru) _In many ways, considered the \u201cnew battleground for cybersecurity\u201d in 2023, APIs can make \u2013 or break \u2013 a business in the coming year_.\n\n\n\nLast month we asked about leaked API keys and other secrets. It looks like only a few are truly confident, while about 50% are somewhat or completely blind to this issue: \n\n\n\n\nAnd we\u2019d love to have you weigh in on our next **LinkedIn poll** we're conducting: **[How mature is your API vulnerability assessment / management process](<https://www.linkedin.com/feed/update/urn:li:activity:7039587864833089536>)**? Please let us know where you stand on this \u2013 [connect with Ivan](<https://www.linkedin.com/in/d0znpp/>) or [follow us at Wallarm](<https://www.linkedin.com/company/wallarm/>) to register your vote.\n\n## **Where APIs Meet Apis**\n\nAnd now for something completely different. Since the theme of The APIary newsletter is based on hardworking & industrious bees, we like to finish with an uplifting image. Since it\u2019s March, the flowers are beginning to bloom and our namesakes are preparing for flight, as you can see. Enjoy!\n\n\n\nSource: Cyan-Biologist Tumblr | [First Bee GIF of the Year](<https://cyan-biologist.tumblr.com/post/159264087364/first-bee-gif-of-the-year>)\n\nThe post [Predictions for 2023 from Latest API Threat Research | API Security Newsletter](<https://lab.wallarm.com/predictions-for-2023-from-latest-api-threat-research-api-security-newsletter/>) appeared first on [Wallarm](<https://lab.wallarm.com>).", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.6, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 6.0}, "published": "2023-03-09T13:10:48", "type": "wallarmlab", "title": "Predictions for 2023 from Latest API Threat Research | API Security Newsletter", "bulletinFamily": "blog", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.8, "vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-39144", "CVE-2022-31678", "CVE-2022-44267", "CVE-2022-44268", "CVE-2023-0957", "CVE-2023-22482", "CVE-2023-22736", "CVE-2023-25163", "CVE-2023-25164", "CVE-2023-25194", "CVE-2023-25572", "CVE-2023-26032", "CVE-2023-26492"], "modified": "2023-03-09T13:10:48", "id": "WALLARMLAB:9CFFE14B0134DDC7E5CE56ADFE082425", "href": "https://lab.wallarm.com/predictions-for-2023-from-latest-api-threat-research-api-security-newsletter/", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}], "redhat": [{"lastseen": "2023-05-30T18:20:41", "description": "Red Hat Openshift GitOps is a declarative way to implement continuous deployment for cloud native applications.\n\nSecurity Fix(es):\n\n* ArgoCD: JWT audience claim is not verified (CVE-2023-22482)\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 9.1, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.2}, "published": "2023-01-25T20:21:54", "type": "redhat", "title": "(RHSA-2023:0466) Important: Red Hat OpenShift GitOps security update", "bulletinFamily": "unix", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-46848", "CVE-2022-35737", "CVE-2022-40303", "CVE-2022-40304", "CVE-2022-42010", "CVE-2022-42011", "CVE-2022-42012", "CVE-2022-43680", "CVE-2023-22482"], "modified": "2023-01-25T20:22:14", "id": "RHSA-2023:0466", "href": "https://access.redhat.com/errata/RHSA-2023:0466", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}}, {"lastseen": "2023-05-30T18:20:41", "description": "Red Hat Openshift GitOps is a declarative way to implement continuous deployment for cloud native applications.\n\nSecurity Fix(es):\n\n* ArgoCD: JWT audience claim is not verified (CVE-2023-22482)\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 9.1, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.2}, "published": "2023-01-25T20:47:16", "type": "redhat", "title": "(RHSA-2023:0468) Important: Red Hat OpenShift GitOps security update", "bulletinFamily": "unix", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-46848", "CVE-2022-35737", "CVE-2022-3821", "CVE-2022-40303", "CVE-2022-40304", "CVE-2022-42010", "CVE-2022-42011", "CVE-2022-42012", "CVE-2022-43680", "CVE-2023-22482"], "modified": "2023-01-25T20:47:27", "id": "RHSA-2023:0468", "href": "https://access.redhat.com/errata/RHSA-2023:0468", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}}, {"lastseen": "2023-05-30T18:20:41", "description": "Red Hat Openshift GitOps is a declarative way to implement continuous deployment for cloud native applications.\n\nSecurity Fix(es):\n\n* ArgoCD: JWT audience claim is not verified (CVE-2023-22482)\n\n* ArgoCD: authorization bypass (CVE-2023-22736)\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 9.1, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.2}, "published": "2023-01-25T20:30:21", "type": "redhat", "title": "(RHSA-2023:0467) Important: Red Hat OpenShift GitOps security update", "bulletinFamily": "unix", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.5, "vectorString": "AV:N/AC:L/Au:S/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-46848", "CVE-2022-35737", "CVE-2022-3821", "CVE-2022-40303", "CVE-2022-40304", "CVE-2022-42010", "CVE-2022-42011", "CVE-2022-42012", "CVE-2022-43680", "CVE-2023-22482", "CVE-2023-22736"], "modified": "2023-01-25T20:30:32", "id": "RHSA-2023:0467", "href": "https://access.redhat.com/errata/RHSA-2023:0467", "cvss": {"score": 6.5, "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P"}}]}