{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0.0"
            },
            {
              "fixed": "36.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "37.0.0"
            },
            {
              "fixed": "42.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "43.0.0"
            },
            {
              "fixed": "43.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "43.0.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34945"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-681"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-09T20:23:02Z",
    "nvd_published_at": "2026-04-09T19:16:24Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nWasmtime\u0027s Winch compiler contains a bug where a 64-bit table, part of the memory64 proposal of WebAssembly, incorrectly translated the `table.size` instruction. This bug could lead to disclosing data on the host\u0027s stack to WebAssembly guests. The host\u0027s stack can possibly contain sensitive data related to other host-originating operations which is not intended to be disclosed to guests.\n\nThis bug specifically arose from a mistake where the return value of `table.size` was statically typed as a 32-bit integer, as opposed to consulting the table\u0027s index type to see how large the returned register could be. When combined with details about Wnich\u0027s ABI, such as multi-value returns, this can be combined to read stack data from the host, within a guest. This information disclosure should not be possible in WebAssembly, violates spec semantics, and is a vulnerability in Wasmtime.\n\n### Patches\n\nWasmtime 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime.\n\n### Workarounds\n\nUsers of Cranelift are not affected by this issue, but users of Winch have no workarounds other than disabling the `Config::wasm_memory64` proposal.",
  "id": "GHSA-m9w2-8782-2946",
  "modified": "2026-04-24T21:03:32Z",
  "published": "2026-04-09T20:23:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-m9w2-8782-2946"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34945"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bytecodealliance/wasmtime"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0086.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Wasmtime has host data leakage with 64-bit tables and Winch"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/iskorotkov/avro/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.33.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46384"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-190",
      "CWE-191",
      "CWE-681"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T16:22:27Z",
    "nvd_published_at": "2026-05-29T20:16:27Z",
    "severity": "HIGH"
  },
  "details": "# Integer Overflow in Avro Decoder\n\n## Summary\n\nSeveral Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized `int` before bounds-checking, or summed them with overflow-prone signed-`int` arithmetic. On 32-bit targets (`GOARCH=386`, `arm`, `mips`, `wasm`, etc.), the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit the OCF negative-`make` panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in `arrayDecoder.Decode` / `mapDecoder.Decode` / `mapDecoderUnmarshaler.Decode` (wraps at `math.MaxInt64` on amd64 / arm64 and bypasses `MaxSliceAllocSize` / `MaxMapAllocSize`), `math.MinInt` negation in block-header handling, and `make([]byte, size)` with a negative size in OCF block reads \u2014 all three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive there.\n\nExploitation requires only an untrusted Avro stream. No primitives reach beyond denial-of-service on current code paths; see the union-index discussion below for a caveat.\n\n\n## Description\n\nSix call sites in the decoder accepted `int64` values from the Avro wire format and converted to `int` before validation. On a 32-bit build any wire value with magnitude `\u2265 2\u00b3\u00b9` truncates and the post-conversion value bears no useful relationship to the original. A value of `(1\u003c\u003c32) + 5` narrows to `5`; `1\u003c\u003c32` narrows to `0`; values just past `MaxInt32` narrow to large negatives.\n\nThis is distinct from the existing `Config.MaxSliceAllocSize`, `Config.MaxByteSliceSize`, and the new `Config.MaxMapAllocSize` limits, because narrowing happens *before* the limit comparison \u2014 the limit sees the truncated value, not the original wire value, so the cap is bypassed.\n\nThree further sub-issues are not 32-bit-specific:\n\n- `arrayDecoder.Decode`, `mapDecoder.Decode`, and `mapDecoderUnmarshaler.Decode` summed attacker-controlled block lengths via `size += int(l)` and then checked `size \u003e limit`. On amd64 / arm64 the running total wraps at `math.MaxInt64`; the post-wrap negative value passes the `\u003e limit` check, and the decoder proceeds. Regression test: `TestDecoder_ArrayMultiBlockExceedsMaxInt` uses `math.MaxInt \u2212 2` for the second block\u0027s count and a `MaxSliceAllocSize` of 13 to demonstrate this on amd64. The Avro block-count field is a signed `long` on the wire, so block counts up to `math.MaxInt64` are admissible \u2014 there is no implicit 2\u00b3\u00b9 ceiling.\n- `ReadBlockHeader()` returns the absolute value of negative block lengths; the negation is unsafe for `math.MinInt`, which on every platform panics on overflow.\n- `ocf/ocf.go readBlock()` passes the decoded block size directly to `make([]byte, size)`. A negative wire value panics on every platform; on 32-bit, values `\u003e MaxInt32` additionally panic via the narrowing path.\n\n## Affected components\n\n| File | Function(s) | Bug class | Platforms |\n|------|-------------|-----------|-----------|\n| `reader.go` | `ReadBlockHeader` \u2014 narrowing | Narrowing | 32-bit |\n| `reader.go` | `ReadBlockHeader` \u2014 `-math.MinInt` | Signed overflow (CWE-191) | all |\n| `reader.go` | `readBytes` (via `Reader.ReadBytes`, `Reader.ReadString`) | Narrowing | 32-bit |\n| `reader_skip.go` | `SkipString`, `SkipBytes` (and OCF skip path) | Narrowing | 32-bit |\n| `codec_array.go` | `arrayDecoder.Decode` | Cumulative-size arithmetic overflow (CWE-190) | all |\n| `codec_map.go` | `mapDecoder.Decode`, `mapDecoderUnmarshaler.Decode` | Cumulative-size arithmetic overflow (CWE-190) | all |\n| `ocf/ocf.go` | `skipToEnd`, `readBlock` \u2014 narrowing | Narrowing | 32-bit |\n| `ocf/ocf.go` | `readBlock` \u2014 negative `make([]byte, \u2026)` | Unchecked-negative (CWE-1284) | all |\n| `reader_generic.go` | union-type index decoding in `Reader.ReadNext` | Narrowing, possible wrong-branch selection | 32-bit |\n\nPR #9 (commit [`bed99b3`](https://github.com/iskorotkov/avro/commit/bed99b315ec097a1a5eb7ae074ef57a91848c583)) covered `ReadBlockHeader`, the cumulative checks in array/map codecs, and the skip helpers. The completeness pass (commit [`e1a570f`](https://github.com/iskorotkov/avro/commit/e1a570f9a8a4fe4b1bc2b4b1fb6d24e4a5f04358)) covered the union index, `readBytes`, and OCF `readBlock`, and added a 32-bit CI job.\n\nNote: the typed-codec union decoder in `codec_union.go` (`getUnionSchema` \u2192 `Reader.ReadInt`) is **not** affected by the union-index narrowing \u2014 `ReadInt` returns `int32`, no narrowing occurs. The narrowing is specific to `Reader.ReadNext` in the generic decode path (reached via `Unmarshal` into `any` / `map[string]any`).\n\n## Technical details\n\n1. **Block-header narrowing and `MinInt` negation.** `ReadBlockHeader()` returned wire-format `int64` values through narrower operations; on 32-bit, large positives truncated. Negating `math.MinInt` to convert a negative block-count signal into a positive size is undefined-on-overflow, and on every platform `-MinInt` panics on overflow when used in subsequent arithmetic. The fix reads into a `*64`-suffixed local, range-checks against `MinInt32`/`MaxInt32` (or `MinInt`/`MaxInt` as appropriate), and narrows after validation.\n\n2. **Cumulative array and map size overflow (all platforms).** `arrayDecoder.Decode`, `mapDecoder.Decode`, and `mapDecoderUnmarshaler.Decode` summed attacker-controlled block lengths using overflow-prone addition; cumulative size could wrap before reaching the configured limit. On amd64 with `MaxSliceAllocSize = 13`, block 1 of 3 elements, block 2 of `math.MaxInt \u2212 2` elements: the pre-fix `size += int(l)` wraps to `math.MinInt`, then `MinInt \u003e 13` is false, so the check passes and the decoder proceeds. The fix uses subtraction-safe comparisons (`l \u003e limit - size` rather than `size + l \u003e limit`), which is overflow-immune.\n\n3. **Skip-length truncation.** `SkipString`, `SkipBytes`, and the OCF skip helper now route through `SkipNBytesInt64()`, which keeps the length as `int64` and range-checks before any narrowing.\n\n4. **Byte-slice length truncation.** A wire-format length such as `(1\u003c\u003c32) + 5` truncated to `5` in `readBytes()`, slipping past `Config.MaxByteSliceSize` on 32-bit. The fix reads the length as `int64`, compares against `MaxByteSliceSize` before narrowing, and returns \"value is too big\" if exceeded.\n\n5. **Union index narrowing (generic decode path only).** `Reader.ReadNext` decoded the union index as `int64` and immediately cast to `int`. On 32-bit, `1\u003c\u003c32` narrowed to `0` and silently selected `types[0]` despite the explicit upper-bound check immediately above. If `types[0]` is the null branch (idiomatic for `[\"null\", T]` nullable unions), the practical result is a null value where the producer encoded a non-null payload \u2014 a DoS-grade logic error. If `types[0]` is a non-trivial schema, downstream bytes are parsed against the wrong schema and produce well-typed but semantically wrong values; treat this as the worst-case interpretation when assessing impact on your own deployment. The typed-codec union decoder (`codec_union.go` `getUnionSchema` \u2192 `Reader.ReadInt`) is not affected.\n\n6. **OCF block-size narrowing and negative `make`.** `readBlock()` passes the decoded `int64` size directly to `make([]byte, size)`. A negative wire value panics on every platform; a value `\u003e MaxInt32` additionally panics via the 32-bit narrowing path. The fix validates the size is in `[0, MaxByteSliceSize]` before narrowing.\n\n## Fixed behavior\n\nBoth commits apply the same pattern across every site:\n\n1. Read the wire value into an `int64`-typed local.\n2. Range-check upper and lower bounds before narrowing.\n3. Compare cumulative limits using subtraction-safe arithmetic.\n4. Route skip operations through `SkipNBytesInt64()`.\n5. Return descriptive errors using the consistent `\"value is too big\"` / `\"value is too small\"` wording.\n6. Cast to `int` only after validation succeeds.\n\nCI: a `test-386` job runs the suite under `GOARCH=386` with `CGO_ENABLED=0` (`-race` is amd64/arm64-only). Three tests with untyped `2147483648` constants whose `t.Skipf` gates fire too late (the file fails to compile before any test runs) were split into sibling `*_64bit_test.go` files gated by `//go:build amd64 || arm64 || ...`.\n\n## Affected versions\n\n- `github.com/hamba/avro/v2` \u2014 all versions up to and including `v2.31.0` (repository is read-only upstream).\n- `github.com/iskorotkov/avro/v2` \u2014 all versions prior to `v2.33.0`.\n\n## Fixed versions\n\n`github.com/iskorotkov/avro/v2` `v2.33.0` and later. There is no upstream fix for `github.com/hamba/avro/v2` \u2014 module path is archived. Migrate to the fork as described under Mitigation.\n\n## Mitigation\n\nMigrate from `github.com/hamba/avro/v2` to `github.com/iskorotkov/avro/v2 \u003e= v2.33.0`. The packages share the same API surface; replace the import path and run `go mod tidy`:\n\n```diff\n- import \"github.com/hamba/avro/v2\"\n+ import \"github.com/iskorotkov/avro/v2\"\n```\n\nFor consumers that prefer the original import path, a `replace` directive in `go.mod` is supported:\n\n```\nreplace github.com/hamba/avro/v2 =\u003e github.com/iskorotkov/avro/v2 v2.33.0\n```\n\n`replace` is honoured only for the **main** module of a build \u2014 transitive consumers must add their own `replace`, or migrate the import path directly.\n\nNo further configuration is required to benefit from the integer-narrowing fixes \u2014 the validation runs on the existing decode path.\n\nIf you cannot upgrade immediately:\n\n- Do not decode untrusted Avro data on any platform \u2014 the cumulative-arithmetic overflow paths (`arrayDecoder.Decode`, `mapDecoder.Decode`, `mapDecoderUnmarshaler.Decode`) are reachable on amd64 / arm64. The truncation paths on 32-bit cannot be mitigated by setting `Config.MaxByteSliceSize` lower, because the truncated post-narrowing value is what the limit sees, not the original wire value.\n- For the cross-platform `math.MinInt` and OCF negative-size panic paths, wrapping `Decode` / OCF read calls in a goroutine with `defer recover()` contains the crash, but is not a substitute for upgrading. The other narrowing paths return errors rather than panicking, so `recover()` does nothing for them.\n- Isolate decoding workers so a crash is bounded.\n\n## Proof-of-concept inputs\n\n- A `bytes` or `string` length of `(1\u003c\u003c32) + N` for small `N`, which narrows to `N` on 32-bit and bypasses `Config.MaxByteSliceSize`.\n- A union index of `1\u003c\u003c32`, which narrows to `0` on 32-bit and selects `types[0]` despite the upper-bound check.\n- An array or map encoded across multiple blocks whose cumulative element count wraps the signed `int` running total before the limit check fires. Demonstrated on amd64 by `TestDecoder_ArrayMultiBlockExceedsMaxInt`: `MaxSliceAllocSize = 13`, block 1 of `3`, block 2 of `math.MaxInt \u2212 2`. Wraps to `math.MinInt`, check passes, decoder proceeds.\n- A block header whose absolute value is `math.MinInt`, triggering the unsafe negation (cross-platform).\n- An OCF block size that is negative on the wire, causing `make([]byte, size)` to panic (cross-platform); or a positive value `\u003e MaxInt32` on 32-bit, same outcome via narrowing.\n\n## References\n\n- Initial hardening PR: [iskorotkov/avro#9](https://github.com/iskorotkov/avro/pull/9)\n- Completeness pass PR: [iskorotkov/avro#10](https://github.com/iskorotkov/avro/pull/10)\n- Fix commits: [`bed99b3`](https://github.com/iskorotkov/avro/commit/bed99b315ec097a1a5eb7ae074ef57a91848c583), [`e1a570f`](https://github.com/iskorotkov/avro/commit/e1a570f9a8a4fe4b1bc2b4b1fb6d24e4a5f04358)\n- Release: [`v2.33.0`](https://github.com/iskorotkov/avro/releases/tag/v2.33.0)\n- Security policy: [`SECURITY.md`](https://github.com/iskorotkov/avro/blob/main/SECURITY.md)\n- Related advisories on this fork: [`GHSA-w8j3-pq8g-8m7w`](https://github.com/iskorotkov/avro/security/advisories/GHSA-w8j3-pq8g-8m7w) (CPU exhaustion \u2014 overlaps via the same large-block-count payload shape), [`GHSA-mx64-mj3q-7prj`](https://github.com/iskorotkov/avro/security/advisories/GHSA-mx64-mj3q-7prj) (unbounded map allocation)\n- Cross-module precedent on `hamba/avro`: [`GO-2023-1930`](https://pkg.go.dev/vuln/GO-2023-1930) / `CVE-2023-37475` / `GHSA-9x44-9pgq-cf45`\n- Upstream (read-only): [`hamba/avro`](https://github.com/hamba/avro)\n\n## Credits\n\n- **Discovery and initial fixes** (PR #9, commit `bed99b3` \u2014 `ReadBlockHeader`, cumulative array/map checks, skip helpers): Daniel B\u0142a\u017cewicz ([@klajok](https://github.com/klajok))\n- **Completeness fixes** (commit `e1a570f` \u2014 union index, `readBytes`, OCF `readBlock`, 32-bit CI coverage): Ivan Korotkov ([@iskorotkov](https://github.com/iskorotkov))\n\n## Timeline\n\n- **2026-05-04** \u2014 Initial integer-overflow hardening (PR #9, `bed99b3`) merged.\n- **2026-05-04** \u2014 Completeness pass (`e1a570f`) merged; 32-bit CI job added.\n- **2026-05-06** \u2014 `v2.33.0` tagged and released.\n- **2026-05-11** \u2014 Advisory published.\n- **2026-05-15** \u2014 Advisory revised.",
  "id": "GHSA-mc57-h6j3-3hmv",
  "modified": "2026-06-09T10:32:44Z",
  "published": "2026-05-18T16:22:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/iskorotkov/avro/security/advisories/GHSA-mc57-h6j3-3hmv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46384"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/iskorotkov/avro"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "iskorotkov/avro: Integer Overflow in Decoder"
}

{
  "affected": [],
  "aliases": [
    "CVE-2014-125012"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-681"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-18T07:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in FFmpeg 2.0. It has been classified as problematic. Affected is an unknown function of the file libavcodec/dxtroy.c. The manipulation leads to integer coercion error. It is possible to launch the attack remotely. It is recommended to apply a patch to fix this issue.",
  "id": "GHSA-mwq6-9rww-wmjh",
  "modified": "2022-06-28T00:00:45Z",
  "published": "2022-06-19T00:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-125012"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.12390"
    },
    {
      "type": "WEB",
      "url": "http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a392bf657015c9a79a5a13adfbfb15086c1943b9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-27189"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-681"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-05T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "On F5 BIG-IP 16.1.x versions prior to 16.1.2.2, 15.1.x versions prior to 15.1.5.1, 14.1.x versions prior to 14.1.4.6, 13.1.x versions prior to 13.1.5, and all versions of 12.1.x and 11.6.x, when an Internet Content Adaptation Protocol (ICAP) profile is configured on a virtual server, undisclosed traffic can cause an increase in Traffic Management Microkernel (TMM) memory resource utilization. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated",
  "id": "GHSA-p9m7-cfxq-c6rf",
  "modified": "2022-05-14T00:01:23Z",
  "published": "2022-05-06T00:00:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27189"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K16187341"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "soroban-env-host"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "26.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-681"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-07T02:39:44Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\n\nSoroban host ensures that `MuxedAddress` objects can\u0027t be used as storage keys in order to proactively prevent the contract logic bugs. However, due to a bug in Soroban host implementation, a failure in `Val`-\u003e`ScVal` conversion during the storage key computation will have the flag indicating that storage conversion is happening stuck in the `true` state until the next storage access. While the flag is stuck in `true` state, any `MuxedAddress` object conversions to `ScVal` will fail, i.e. a failure will occur if a `MuxedAddress` is emitted in the event or is serialized to XDR via a host function.\n\n### Impact\n\nThe bug may cause unexpected contract failures in the rare edge case scenarios. In the worst case scenario the whole transaction will fail and the changes will be rolled back. Because the contract call is simply rolled back, there is no risk of the state corruption.\n\nAn example scenario that would be affected by the bug is as follows:\n\n- Contract A calls contract B via `try_call`\n- Contract B calls a storage function (e.g. `put_contract_data`) with a non-convertible `Val` as a key (e.g. a `MuxedAddress` object, or a deeply nested vector)\n- Contract B fails\n- Contract A handles the failure gracefully and proceeds without accessing any storage methods\n- Contract A tries to emit an event with a `MuxedAddress` argument. That should be allowed, but instead of succeeding, contract A fails.\n\n### Patches\n\nThe bug will be fixed in protocol 26.\n\n### Workarounds\n\nWe believe that the bug is highly unlikely to occur in practice, as it involves three rare events happening simultaneously: `Val` conversion failure (these should normally not occur for the audited protocols), graceful handling of a cross-contract call failure (most protocols need cross-contract calls to succeed, or fail with a contract error), and `MuxedAddress` write (most of the contracts don\u0027t support `MuxedAddress` at all).\n\nIn the case if the bug does occur, the mitigation depends on the reason of the value conversion failure:\n\n- If the conversion failure has been caused by a malicious contract, then either no action is necessary (because the whole interaction is malicious and has been correctly rolled back), or the contract invocation should be replaced by a non-malicious contract\n- If the conversion failure has been caused by a bad user input for a non-malicious contract (e.g. a bad user input passed to a legitimate protocol), then the user input has to be fixed\n\nIn both scenarios the mitigation is to basically retry the transaction with proper arguments.",
  "id": "GHSA-pm4j-7r4q-ccg8",
  "modified": "2026-03-07T02:39:44Z",
  "published": "2026-03-07T02:39:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-env/security/advisories/GHSA-pm4j-7r4q-ccg8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/stellar/rs-soroban-env"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Soroban: Muxed address\u003c-\u003eScVal conversions may break after a conversion failure"
}

{
  "affected": [],
  "aliases": [
    "CVE-2017-7308"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-119",
      "CWE-681",
      "CWE-787"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-03-29T20:59:00Z",
    "severity": "HIGH"
  },
  "details": "The packet_set_ring function in net/packet/af_packet.c in the Linux kernel through 4.10.6 does not properly validate certain block-size data, which allows local users to cause a denial of service (integer signedness error and out-of-bounds write), or gain privileges (if the CAP_NET_RAW capability is held), via crafted system calls.",
  "id": "GHSA-ppq3-433v-jp43",
  "modified": "2025-04-20T03:34:58Z",
  "published": "2022-05-14T03:17:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7308"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:1297"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:1298"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:1308"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:1854"
    },
    {
      "type": "WEB",
      "url": "https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html"
    },
    {
      "type": "WEB",
      "url": "https://patchwork.ozlabs.org/patch/744811"
    },
    {
      "type": "WEB",
      "url": "https://patchwork.ozlabs.org/patch/744812"
    },
    {
      "type": "WEB",
      "url": "https://patchwork.ozlabs.org/patch/744813"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2017-07-01"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/41994"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/44654"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/97234"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vyper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.8"
            },
            {
              "fixed": "0.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-32481"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-681"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-25T19:53:43Z",
    "nvd_published_at": "2024-04-25T17:15:50Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nWhen looping over a `range` of the form `range(start, start + N)`, if `start` is negative, the execution will always revert.\n \n### Details\n\nThis issue is caused by an incorrect assertion inserted by the code generation of the range (`stmt.parse_For_range()`):\n\nhttps://github.com/vyperlang/vyper/blob/9136169468f317a53b4e7448389aa315f90b95ba/vyper/codegen/stmt.py#L286-L287\n\nThis assertion was introduced in https://github.com/vyperlang/vyper/commit/3de1415ee77a9244eb04bdb695e249d3ec9ed868 to fix https://github.com/advisories/GHSA-6r8q-pfpv-7cgj. The issue arises when `start` is signed, instead of using `sle`, `le` is used and `start` is interpreted as an unsigned integer for the comparison. If it is a negative number, its 255th bit is set to `1` and is hence interpreted as a very large unsigned integer making the assertion always fail. \n### PoC\n\n```Vyper\n@external\ndef foo():\n    x:int256 = min_value(int256)\n    # revert when it should not since we have the following assertion that fails:\n    # [assert, [le, min_value(int256), max_value(int256) + 1 - 10]],\n    for i in range(x, x + 10):\n        pass\n```\n\n### Patches\n\npatched in v0.4.0, specifically, https://github.com/vyperlang/vyper/pull/3679 disallows this form of `range()`.\n\n### Impact\n\nAny contract having a `range(start, start + N)` where `start` is a signed integer with the possibility for `start` to be negative is affected. If a call goes through the loop while supplying a negative `start` the execution will revert.",
  "id": "GHSA-ppx5-q359-pvwj",
  "modified": "2024-04-25T19:53:43Z",
  "published": "2024-04-25T19:53:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/security/advisories/GHSA-ppx5-q359-pvwj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32481"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/commit/3de1415ee77a9244eb04bdb695e249d3ec9ed868"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/commit/5319cfbe14951e007ccdb323257e5ada869b35d5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vyperlang/vyper"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/blob/9136169468f317a53b4e7448389aa315f90b95ba/vyper/codegen/stmt.py#L286-L287"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vyper\u0027s range(start, start + N) reverts for negative numbers"
}

{
  "affected": [],
  "aliases": [
    "CVE-2017-17446"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-681"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-12-06T19:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The Mem_File_Reader::read_avail function in Data_Reader.cpp in the Game_Music_Emu library (aka game-music-emu) 0.6.1 does not ensure a non-negative size, which allows remote attackers to cause a denial of service (application crash) via a crafted file.",
  "id": "GHSA-pwfg-g35m-wrcw",
  "modified": "2022-05-13T01:44:24Z",
  "published": "2022-05-13T01:44:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-17446"
    },
    {
      "type": "WEB",
      "url": "https://bitbucket.org/mpyne/game-music-emu/issues/14/addresssanitizer-negative-size-param-size"
    },
    {
      "type": "WEB",
      "url": "https://bugs.debian.org/883691"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-40138"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-681"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-11T02:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An integer conversion error in Hermes bytecode generation, prior to commit 6aa825e480d48127b480b08d13adf70033237097, could have been used to perform Out-Of-Bounds operations and subsequently execute arbitrary code. Note that this is only exploitable in cases where Hermes is used to execute untrusted JavaScript. Hence, most React Native applications are not affected.",
  "id": "GHSA-qg8w-6wvf-6vp6",
  "modified": "2022-10-12T12:00:29Z",
  "published": "2022-10-11T12:00:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40138"
    },
    {
      "type": "WEB",
      "url": "https://github.com/facebook/hermes/commit/6aa825e480d48127b480b08d13adf70033237097"
    },
    {
      "type": "WEB",
      "url": "https://www.facebook.com/security/advisories/CVE-2022-40138"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2018-5711"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-681"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-01-16T09:29:00Z",
    "severity": "MODERATE"
  },
  "details": "gd_gif_in.c in the GD Graphics Library (aka libgd), as used in PHP before 5.6.33, 7.0.x before 7.0.27, 7.1.x before 7.1.13, and 7.2.x before 7.2.1, has an integer signedness error that leads to an infinite loop via a crafted GIF file, as demonstrated by a call to the imagecreatefromgif or imagecreatefromstring PHP function. This is related to GetCode_ and gdImageCreateFromGifCtx.",
  "id": "GHSA-qwqg-rff2-45cw",
  "modified": "2022-05-13T01:52:54Z",
  "published": "2022-05-13T01:52:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5711"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:1296"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2519"
    },
    {
      "type": "WEB",
      "url": "https://bugs.php.net/bug.php?id=75571"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/01/msg00022.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/01/msg00028.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3CZ2QADQTKRHTGB2AHD7J4QQNDLBEMM6"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201903-18"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3755-1"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2020.html"
    },
    {
      "type": "WEB",
      "url": "http://php.net/ChangeLog-5.php"
    },
    {
      "type": "WEB",
      "url": "http://php.net/ChangeLog-7.php"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}