<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-16T12:32:20.143136+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-100352</id>
    <title>fkie_cve-2026-100352</title>
    <updated>2026-10-16T12:32:20.144424+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>kin-openapi is a Go project for handling OpenAPI files. Prior to 0.148.0, the OpenAPI 3.1 validation path passes YAML NaN and infinity numeric values to santhosh-tekuri/jsonschema v6.0.2 without applying kin-openapi's existing finite-number guards. A remote unauthenticated client can send an application/yaml or application/x-yaml request body containing .nan, .inf, or -.inf to an operation with a numeric constraint, causing the dependency to create and dereference a nil big.Rat during ValidateRequest. Standard net/http servers recover the panic per connection, while other hosts or application goroutines may terminate the process. This issue is fixed in version 0.148.0.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-100352"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-rj39-cv6w-8wv7</id>
    <title>GHSA-rj39-cv6w-8wv7 — kin-openapi: YAML NaN/Inf Values Bypass Built-in Guards and Panic via OAS 3.1 Validation Path</title>
    <updated>2026-10-16T12:32:20.144506+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/getkin/kin-openapi</p>
<p>## Summary</p>
<p>kin-openapi guards against `NaN` and `Inf` values in its built-in schema visitor (`visitJSON`) by returning `ErrSchemaInputNaN` / `ErrSchemaInputInf` when a `float64` input violates those constraints. For OAS 3.1 specs, however, `Schema.VisitJSON` routes through `useJSONSchema2020`, which hands the value directly to `santhosh-tekuri/jsonschema/v6` v6.0.2 without applying the same guard.</p>
<p>Inside `jsonschema/v6` v6.0.2, `numValidate` builds a `*big.Rat` from the input via `big.Rat.SetString(fmt.Sprintf("%v", v))`. For `NaN`/`Inf` this parse fails silently and returns `nil`. `numValidate` then dereferences the nil `*big.Rat` (in `math/big.(*Rat).Cmp`), producing a Go runtime panic.</p>
<p>An attacker delivers this by sending an HTTP request with `Content-Type: application/yaml` (or `application/x-yaml`) and a YAML body containing `.nan`, `.inf`, or `-.inf`. The `YamlBodyDecoder` decodes those tokens into `math.NaN()` / `math.Inf(±1)` (standard YAML 1.2 behavior), and they propagate to the unguarded `useJSONSchema2020` path whenever the schema declares a numeric constraint (`minimum`, `maximum`, `exclusiveMinimum`, `exclusiveMaximum`, or `multipleOf`).</p>
<p>## Details
### Root Cause</p>
<p>The built-in visitor `visitJSON` at `openapi3/schema.go:1968` guards NaN/Inf explicitly:</p>
<p>```go
case float64:
    if math.IsNaN(value) {
        return ErrSchemaInputNaN
    }
    if math.IsInf(value, 0) {
        return ErrSchemaInputInf
    }
```</p>
<p>For OAS 3.1 specs, `VisitJSON` dispatches to `us…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-rj39-cv6w-8wv7"/>
  </entry>
</feed>
