Vulnerability-Lookup

Vulnerability from cleanstart

Published

2026-02-03 16:02

Modified

2026-02-03 11:13

Summary

Cancelling a query (e

Details

Multiple security vulnerabilities affect the kyverno-fips package. Cancelling a query (e. See references for individual vulnerability details.

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "CleanStart",
        "name": "kyverno-fips"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.14.4-r2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "credits": [],
  "database_specific": {},
  "details": "Multiple security vulnerabilities affect the kyverno-fips package. Cancelling a query (e. See references for individual vulnerability details.",
  "id": "CLEANSTART-2026-QN16013",
  "modified": "2026-02-03T11:13:56Z",
  "published": "2026-02-03T16:02:29.512503Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://github.com/cleanstart-dev/cleanstart-security-advisories/tree/main/advisories/2026/CLEANSTART-2026-QN16013.json"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/CVE-2025-47907"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/GHSA-2X5J-VHC8-9CWM"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/GHSA-6M8W-JC87-6CR7"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/GHSA-VVGC-356P-C3XW"
    },
    {
      "type": "WEB",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47907"
    }
  ],
  "related": [],
  "schema_version": "1.7.3",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Cancelling a query (e",
  "upstream": [
    "CVE-2025-47907",
    "GHSA-2X5J-VHC8-9CWM",
    "GHSA-6M8W-JC87-6CR7",
    "GHSA-VVGC-356P-C3XW"
  ]
}

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-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-VVGC-356P-C3XW

Vulnerability from github – Published: 2025-04-16 19:22 – Updated: 2025-05-17 18:49

Summary

golang.org/x/net vulnerable to Cross-site Scripting

Details

The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g. , , etc contexts).

Severity ?

5.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "golang.org/x/net"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.38.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-22872"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-16T19:22:51Z",
    "nvd_published_at": "2025-04-16T18:16:04Z",
    "severity": "MODERATE"
  },
  "details": "The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g. \u003cmath\u003e, \u003csvg\u003e, etc contexts).",
  "id": "GHSA-vvgc-356p-c3xw",
  "modified": "2025-05-17T18:49:25Z",
  "published": "2025-04-16T19:22:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22872"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/cl/662715"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/issue/73070"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/golang-announce/c/ezSKR9vqbqA"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3595"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250516-0007"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "golang.org/x/net vulnerable to Cross-site Scripting"
}

CVE-2025-47907 (GCVE-0-2025-47907)

Vulnerability from cvelistv5 – Published: 2025-08-07 15:25 – Updated: 2025-11-04 21:10

Title

Incorrect results returned from Rows.Scan in database/sql

Summary

Cancelling a query (e.g. by cancelling the context passed to one of the query methods) during a call to the Scan method of the returned Rows can result in unexpected results if other queries are being made in parallel. This can result in a race condition that may overwrite the expected results with those of another query, causing the call to Scan to return either unexpected results from the other query or an error.

Severity ?

7 (High)


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

CWE

CWE-362 - Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Assigner

References

URL

	Vendor	Product	Version
	Go standard library	database/sql	Affected: 0 , < 1.23.12 (semver) Affected: 1.24.0 , < 1.24.6 (semver)

Sightings

Author	Source	Type	Date

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.

Action not permitted

Vulnerability from cleanstart

GHSA-2X5J-VHC8-9CWM

Impact

Patches

GHSA-6M8W-JC87-6CR7

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

GHSA-VVGC-356P-C3XW

CVE-2025-47907 (GCVE-0-2025-47907)

Tags

Sightings

Nomenclature