Common Weakness Enumeration

CWE-1284

Allowed

Improper Validation of Specified Quantity in Input

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product receives input that is expected to specify a quantity (such as size or length), but it does not validate or incorrectly validates that the quantity has the required properties.

494 vulnerabilities reference this CWE, most recent first.

GHSA-W8J3-PQ8G-8M7W

Vulnerability from github – Published: 2026-05-18 16:33 – Updated: 2026-06-09 10:32
VLAI
Summary
iskorotkov/avro: CPU Exhaustion in Decoder
Details

CPU Exhaustion in Avro Decoder via Unbounded Block-Count Iteration

Summary

The Avro array and map decoders looped over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 / arm64 targets — so a producer can declare a block of up to math.MaxInt64 (~9.2 × 10¹⁸) elements followed by EOF (or any truncated payload), and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is "indefinite until the worker is killed externally" — a single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated. Remote, unauthenticated denial-of-service.

The fix exits the loop on the first inner-decode error. It does not bound the loop length itself; for full coverage on untrusted inputs, also configure Config.MaxSliceAllocSize and Config.MaxMapAllocSize (the latter introduced in v2.33.0).

Description

Avro arrays and maps are encoded as one or more blocks; each block declares an element count followed by that many encoded elements. The decoder reads the block count as a zigzag-encoded long, then iterates that many times calling an inner decoder.

Three iteration sites trusted the block count without checking the reader's accumulated error state between iterations:

  • codec_skip.go sliceSkipDecoder.Decode — skip helper for arrays.
  • codec_skip.go mapSkipDecoder.Decode — skip helper for maps.
  • reader_generic.go Reader.ReadArrayCB and Reader.ReadMapCB — callback-based decoders used by generic and unmarshaling code paths.

Because the inner Decode(nil, r) call is a no-op when r has already errored (it returns immediately without consuming bytes), the loop would run to completion even after the first iteration's EOF. On amd64 / arm64, Reader.ReadBlockHeader returns the count as int (= int64), so the loop bound is whatever the wire payload specified, up to math.MaxInt64. A modest 200-million-count payload (well under 2³¹) already burns several seconds; a math.MaxInt − 2 payload (the value used in the regression test TestDecoder_ArrayMultiBlockExceedsMaxInt from PR #9) effectively pins the goroutine until external kill.

This overlaps with GHSA-mc57-h6j3-3hmv: the same large-block-count payload that drives the unbounded loop here also drives the cumulative-arithmetic overflow there (cross-platform), and on a 32-bit target additionally triggers the union-index / byte-slice narrowing.

Affected components

File Function PR Fix commit
codec_skip.go sliceSkipDecoder.Decode — b124caa
codec_skip.go mapSkipDecoder.Decode — b124caa
reader_generic.go Reader.ReadArrayCB #4 2ce4242
reader_generic.go Reader.ReadMapCB #4 2ce4242

These are the audited and patched sites. Any other code path that iterates over an attacker-controlled count while calling a Reader-style decoder is structurally susceptible to the same pattern; reviewers of consumer code should grep for for range l / for i := 0; i < int(l); i++ near Reader method calls and confirm an in-loop error check.

Technical details

Vulnerable pattern:

for range l {
    d.decoder.Decode(nil, r)
    // r.Error may have been set by Decode; loop continues regardless.
}

After r.Error != nil, subsequent Decode calls short-circuit and return without consuming bytes or doing useful work, but the loop control variable still runs to l. With l = math.MaxInt64, the loop body executes ~9.2 × 10¹⁸ times — effectively infinite for any realistic timeout.

Fixed pattern (b124caa, 2ce4242):

for range l {
    d.decoder.Decode(nil, r)
    if r.Error != nil {
        break
    }
}

The fix terminates the loop on the first inner error. It does not bound l itself — a well-formed payload that actually contains N encoded null elements still iterates N times. The MaxSliceAllocSize / MaxMapAllocSize caps are the policy-level bound on that case (see Mitigation).

Fixed behavior

The reader's accumulated error is checked after every inner Decode in the four affected loops. Decoder errors now surface in O(1) iterations instead of O(blockCount) when the underlying read fails mid-stream.

Affected versions

  • github.com/hamba/avro/v2 — all versions up to and including v2.31.0 (repository is read-only upstream).
  • github.com/iskorotkov/avro/v2 — all versions prior to v2.33.0.

Fixed versions

github.com/iskorotkov/avro/v2 v2.33.0 and later. There is no upstream fix for github.com/hamba/avro/v2 — module path is archived. Migrate to the fork as described under Mitigation.

Mitigation

Migrate from github.com/hamba/avro/v2 to github.com/iskorotkov/avro/v2 >= v2.33.0. Replace the import path and run go mod tidy:

go get github.com/iskorotkov/avro/v2@latest

Or, for consumers that prefer the original import path, a replace directive in go.mod:

replace github.com/hamba/avro/v2 => github.com/iskorotkov/avro/v2 v2.33.0

replace is honoured only for the main module of a build — transitive consumers must add their own replace, or migrate the import path directly.

The error-propagation fix runs on the existing decode path and requires no configuration.

For defense-in-depth against well-formed but oversized payloads (where the fix above does not help, because no error fires), set explicit allocation caps:

cfg := avro.Config{
    MaxByteSliceSize:  102_400,
    MaxSliceAllocSize: 10_000,
    MaxMapAllocSize:   10_000,
}.Freeze()

decoder := cfg.NewDecoder(schema, reader)

MaxMapAllocSize is new in v2.33.0 and opt-in (default zero, which leaves the previous unbounded behavior). Without setting it, a producer that ships a math.MaxInt64-count block still consumes the corresponding memory and CPU; see GHSA-mx64-mj3q-7prj for the cumulative-allocation enforcement details.

If you cannot upgrade immediately, the structural workarounds are application-level: per-request decode timeouts, isolated decoder workers under CPU quotas, and rejection of payloads whose advertised block count exceeds a known sane bound for your schema.

Proof-of-concept input

A minimal payload that triggers the bug for an array of int:

zigzag-encoded long: math.MaxInt64   (block element count)
EOF                                  (no further bytes)

The decoder reads the block-count header, enters the loop, fails to read the first element (EOF), records the error, and then iterates math.MaxInt64 − 1 further times calling the inner decoder as a no-op. Wall-clock cost on commodity hardware: indefinite — the goroutine pins one CPU core until the process is OOM-killed, deadline-cancelled, or terminated externally. The classic "a few seconds per request" characterisation applies only to small-but-still-pathological block counts in the 10⁸–10⁹ range (e.g. 200_999_000 in TestDecoder_SkipArrayEOF); the architectural ceiling is math.MaxInt64.

A negative block count (-N) is also legal in Avro (signals an N-element block with an explicit byte length); the same iteration pattern applies once the count is negated.

References

Credits

  • Discovery and fixes (commits b124caa skip helpers and 2ce4242 callback path, PR #4): Daniel Błażewicz (@klajok)
  • Release authorship: Ivan Korotkov (@iskorotkov)

Timeline

  • 2026-04-28 — Skip-decoder fix (b124caa) merged.
  • 2026-04-30 — Callback-decoder fix (PR #4, 2ce4242) merged.
  • 2026-05-06 — v2.33.0 tagged and released.
  • 2026-05-11 — Advisory published.
  • 2026-05-15 — Advisory revised.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/iskorotkov/avro/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.33.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46385"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-400",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T16:33:43Z",
    "nvd_published_at": "2026-05-29T20:16:27Z",
    "severity": "HIGH"
  },
  "details": "# CPU Exhaustion in Avro Decoder via Unbounded Block-Count Iteration\n\n## Summary\n\nThe Avro array and map decoders looped over an attacker-controlled block-count value without checking the underlying reader\u0027s error state inside the loop body. `Reader.ReadBlockHeader` returns the count as a Go `int`, which is 64-bit on `amd64` / `arm64` targets \u2014 so a producer can declare a block of up to `math.MaxInt64` (~9.2 \u00d7 10\u00b9\u2078) elements followed by EOF (or any truncated payload), and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is \"indefinite until the worker is killed externally\" \u2014 a single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated. Remote, unauthenticated denial-of-service.\n\nThe fix exits the loop on the first inner-decode error. It does not bound the loop length itself; for full coverage on untrusted inputs, also configure `Config.MaxSliceAllocSize` and `Config.MaxMapAllocSize` (the latter introduced in `v2.33.0`).\n\n## Description\n\nAvro arrays and maps are encoded as one or more blocks; each block declares an element count followed by that many encoded elements. The decoder reads the block count as a zigzag-encoded `long`, then iterates that many times calling an inner decoder.\n\nThree iteration sites trusted the block count without checking the reader\u0027s accumulated error state between iterations:\n\n- `codec_skip.go` `sliceSkipDecoder.Decode` \u2014 skip helper for arrays.\n- `codec_skip.go` `mapSkipDecoder.Decode` \u2014 skip helper for maps.\n- `reader_generic.go` `Reader.ReadArrayCB` and `Reader.ReadMapCB` \u2014 callback-based decoders used by generic and unmarshaling code paths.\n\nBecause the inner `Decode(nil, r)` call is a no-op when `r` has already errored (it returns immediately without consuming bytes), the loop would run to completion even after the first iteration\u0027s EOF. On `amd64` / `arm64`, `Reader.ReadBlockHeader` returns the count as `int` (= `int64`), so the loop bound is whatever the wire payload specified, up to `math.MaxInt64`. A modest 200-million-count payload (well under 2\u00b3\u00b9) already burns several seconds; a `math.MaxInt \u2212 2` payload (the value used in the regression test `TestDecoder_ArrayMultiBlockExceedsMaxInt` from PR #9) effectively pins the goroutine until external kill.\n\nThis overlaps with [`GHSA-mc57-h6j3-3hmv`](https://github.com/iskorotkov/avro/security/advisories/GHSA-mc57-h6j3-3hmv): the same large-block-count payload that drives the unbounded loop here also drives the cumulative-arithmetic overflow there (cross-platform), and on a 32-bit target additionally triggers the union-index / byte-slice narrowing.\n\n## Affected components\n\n| File | Function | PR | Fix commit |\n|------|----------|----|------------|\n| `codec_skip.go` | `sliceSkipDecoder.Decode` | \u2014 | [`b124caa`](https://github.com/iskorotkov/avro/commit/b124caa58a821f68f100d86f045f9753b88881e8) |\n| `codec_skip.go` | `mapSkipDecoder.Decode` | \u2014 | [`b124caa`](https://github.com/iskorotkov/avro/commit/b124caa58a821f68f100d86f045f9753b88881e8) |\n| `reader_generic.go` | `Reader.ReadArrayCB` | [#4](https://github.com/iskorotkov/avro/pull/4) | [`2ce4242`](https://github.com/iskorotkov/avro/commit/2ce4242e6095d93470ab3b37ed6082b0596f325c) |\n| `reader_generic.go` | `Reader.ReadMapCB` | [#4](https://github.com/iskorotkov/avro/pull/4) | [`2ce4242`](https://github.com/iskorotkov/avro/commit/2ce4242e6095d93470ab3b37ed6082b0596f325c) |\n\nThese are the audited and patched sites. Any other code path that iterates over an attacker-controlled count while calling a `Reader`-style decoder is structurally susceptible to the same pattern; reviewers of consumer code should grep for `for range l` / `for i := 0; i \u003c int(l); i++` near `Reader` method calls and confirm an in-loop error check.\n\n## Technical details\n\n**Vulnerable pattern:**\n\n```go\nfor range l {\n    d.decoder.Decode(nil, r)\n    // r.Error may have been set by Decode; loop continues regardless.\n}\n```\n\nAfter `r.Error != nil`, subsequent `Decode` calls short-circuit and return without consuming bytes or doing useful work, but the loop control variable still runs to `l`. With `l = math.MaxInt64`, the loop body executes ~9.2 \u00d7 10\u00b9\u2078 times \u2014 effectively infinite for any realistic timeout.\n\n**Fixed pattern** ([`b124caa`](https://github.com/iskorotkov/avro/commit/b124caa58a821f68f100d86f045f9753b88881e8), [`2ce4242`](https://github.com/iskorotkov/avro/commit/2ce4242e6095d93470ab3b37ed6082b0596f325c)):\n\n```go\nfor range l {\n    d.decoder.Decode(nil, r)\n    if r.Error != nil {\n        break\n    }\n}\n```\n\nThe fix terminates the loop on the first inner error. It does **not** bound `l` itself \u2014 a well-formed payload that actually contains `N` encoded `null` elements still iterates `N` times. The `MaxSliceAllocSize` / `MaxMapAllocSize` caps are the policy-level bound on that case (see Mitigation).\n\n## Fixed behavior\n\nThe reader\u0027s accumulated error is checked after every inner `Decode` in the four affected loops. Decoder errors now surface in O(1) iterations instead of O(blockCount) when the underlying read fails mid-stream.\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`. Replace the import path and run `go mod tidy`:\n\n```bash\ngo get github.com/iskorotkov/avro/v2@latest\n```\n\nOr, for consumers that prefer the original import path, a `replace` directive in `go.mod`:\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\nThe error-propagation fix runs on the existing decode path and requires no configuration.\n\nFor defense-in-depth against well-formed but oversized payloads (where the fix above does not help, because no error fires), set explicit allocation caps:\n\n```go\ncfg := avro.Config{\n    MaxByteSliceSize:  102_400,\n    MaxSliceAllocSize: 10_000,\n    MaxMapAllocSize:   10_000,\n}.Freeze()\n\ndecoder := cfg.NewDecoder(schema, reader)\n```\n\n`MaxMapAllocSize` is new in `v2.33.0` and opt-in (default zero, which leaves the previous unbounded behavior). Without setting it, a producer that ships a `math.MaxInt64`-count block still consumes the corresponding memory and CPU; see [`GHSA-mx64-mj3q-7prj`](https://github.com/iskorotkov/avro/security/advisories/GHSA-mx64-mj3q-7prj) for the cumulative-allocation enforcement details.\n\nIf you cannot upgrade immediately, the structural workarounds are application-level: per-request decode timeouts, isolated decoder workers under CPU quotas, and rejection of payloads whose advertised block count exceeds a known sane bound for your schema.\n\n## Proof-of-concept input\n\nA minimal payload that triggers the bug for an array of `int`:\n\n```\nzigzag-encoded long: math.MaxInt64   (block element count)\nEOF                                  (no further bytes)\n```\n\nThe decoder reads the block-count header, enters the loop, fails to read the first element (EOF), records the error, and then iterates `math.MaxInt64 \u2212 1` further times calling the inner decoder as a no-op. Wall-clock cost on commodity hardware: indefinite \u2014 the goroutine pins one CPU core until the process is OOM-killed, deadline-cancelled, or terminated externally. The classic *\"a few seconds per request\"* characterisation applies only to small-but-still-pathological block counts in the 10\u2078\u201310\u2079 range (e.g. `200_999_000` in `TestDecoder_SkipArrayEOF`); the architectural ceiling is `math.MaxInt64`.\n\nA negative block count (`-N`) is also legal in Avro (signals an N-element block with an explicit byte length); the same iteration pattern applies once the count is negated.\n\n## References\n\n- Fix PR: [iskorotkov/avro#4](https://github.com/iskorotkov/avro/pull/4) (callback path)\n- Fix commits: [`b124caa`](https://github.com/iskorotkov/avro/commit/b124caa58a821f68f100d86f045f9753b88881e8) (skip helpers), [`2ce4242`](https://github.com/iskorotkov/avro/commit/2ce4242e6095d93470ab3b37ed6082b0596f325c) (callback path)\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-mc57-h6j3-3hmv`](https://github.com/iskorotkov/avro/security/advisories/GHSA-mc57-h6j3-3hmv) (integer overflow \u2014 same large-block-count payload also triggers cumulative-arithmetic overflow there), [`GHSA-mx64-mj3q-7prj`](https://github.com/iskorotkov/avro/security/advisories/GHSA-mx64-mj3q-7prj) (unbounded map allocation \u2014 the policy-level bound on well-formed huge inputs)\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 fixes** (commits `b124caa` skip helpers and `2ce4242` callback path, PR #4): Daniel B\u0142a\u017cewicz ([@klajok](https://github.com/klajok))\n- **Release authorship**: Ivan Korotkov ([@iskorotkov](https://github.com/iskorotkov))\n\n## Timeline\n\n- **2026-04-28** \u2014 Skip-decoder fix (`b124caa`) merged.\n- **2026-04-30** \u2014 Callback-decoder fix (PR #4, `2ce4242`) merged.\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-w8j3-pq8g-8m7w",
  "modified": "2026-06-09T10:32:33Z",
  "published": "2026-05-18T16:33:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/iskorotkov/avro/security/advisories/GHSA-w8j3-pq8g-8m7w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46385"
    },
    {
      "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:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "iskorotkov/avro: CPU Exhaustion in Decoder"
}

GHSA-WCR3-8JHG-V89R

Vulnerability from github – Published: 2022-12-12 09:30 – Updated: 2022-12-14 18:30
VLAI
Details

Multiple vulnerabilities in the Cisco Discovery Protocol functionality of Cisco ATA 190 Series Analog Telephone Adapter firmware could allow an unauthenticated, adjacent attacker to cause Cisco Discovery Protocol memory corruption on an affected device. These vulnerabilities are due to missing length validation checks when processing Cisco Discovery Protocol messages. An attacker could exploit these vulnerabilities by sending a malicious Cisco Discovery Protocol packet to an affected device. A successful exploit could allow the attacker to cause an out-of-bounds read of the valid Cisco Discovery Protocol packet data, which could allow the attacker to cause corruption in the internal Cisco Discovery Protocol database of the affected device.

Severity
8.8 (High)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-20690"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-130",
      "CWE-20"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-12T09:15:00Z",
    "severity": "HIGH"
  },
  "details": "Multiple vulnerabilities in the Cisco Discovery Protocol functionality of Cisco ATA 190 Series Analog Telephone Adapter firmware could allow an unauthenticated, adjacent attacker to cause Cisco Discovery Protocol memory corruption on an affected device. These vulnerabilities are due to missing length validation checks when processing Cisco Discovery Protocol messages. An attacker could exploit these vulnerabilities by sending a malicious Cisco Discovery Protocol packet to an affected device. A successful exploit could allow the attacker to cause an out-of-bounds read of the valid Cisco Discovery Protocol packet data, which could allow the attacker to cause corruption in the internal Cisco Discovery Protocol database of the affected device.",
  "id": "GHSA-wcr3-8jhg-v89r",
  "modified": "2022-12-14T18:30:28Z",
  "published": "2022-12-12T09:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20690"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ata19x-multivuln-GEZYVvs"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ata19x-multivuln-GEZYVvs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WG24-XC4C-3H5P

Vulnerability from github – Published: 2026-01-16 21:30 – Updated: 2026-01-16 21:30
VLAI
Details

iDailyDiary 4.30 contains a denial of service vulnerability that allows attackers to crash the application by overflowing the preferences tab name field. Attackers can paste a 2,000,000 character buffer into the default diary tab name to trigger an application crash.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
4.6 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-47824"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-16T19:16:07Z",
    "severity": "MODERATE"
  },
  "details": "iDailyDiary 4.30 contains a denial of service vulnerability that allows attackers to crash the application by overflowing the preferences tab name field. Attackers can paste a 2,000,000 character buffer into the default diary tab name to trigger an application crash.",
  "id": "GHSA-wg24-xc4c-3h5p",
  "modified": "2026-01-16T21:30:36Z",
  "published": "2026-01-16T21:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47824"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/49898"
    },
    {
      "type": "WEB",
      "url": "https://www.splinterware.com/index.html"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/idailydiary-denial-of-service-poc"
    }
  ],
  "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:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-WHHR-7F2W-QQJ2

Vulnerability from github – Published: 2023-09-21 17:10 – Updated: 2026-03-11 20:35
VLAI
Summary
phonenumber panics on parsing crafted RFC3966 inputs
Details

Impact

The phonenumber parsing code may panic due to a panic-guarded out-of-bounds access on the phonenumber string.

In a typical deployment of rust-phonenumber, this may get triggered by feeding a maliciously crafted phonenumber over the network, specifically the string .;phone-context=.

Patches

Patches will be published as version 0.3.3+8.13.9 and backported as 0.2.5+8.11.3.

Workarounds

n.a.

References

n.a.

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
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "phonenumber"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "phonenumber"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.0"
            },
            {
              "fixed": "0.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-42444"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-248",
      "CWE-392"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-21T17:10:57Z",
    "nvd_published_at": "2023-09-19T15:15:56Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nThe phonenumber parsing code may panic due to a panic-guarded out-of-bounds access on the phonenumber string.\n\nIn a typical deployment of `rust-phonenumber`, this may get triggered by feeding a maliciously crafted phonenumber over the network, specifically the string `.;phone-context=`.\n\n### Patches\nPatches will be published as version `0.3.3+8.13.9` and backported as `0.2.5+8.11.3`.\n\n### Workarounds\nn.a.\n\n### References\nn.a.",
  "id": "GHSA-whhr-7f2w-qqj2",
  "modified": "2026-03-11T20:35:22Z",
  "published": "2023-09-21T17:10:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/whisperfish/rust-phonenumber/security/advisories/GHSA-whhr-7f2w-qqj2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42444"
    },
    {
      "type": "WEB",
      "url": "https://github.com/whisperfish/rust-phonenumber/commit/2dd44be94539c051b4dee55d1d9d349bd7bedde6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/whisperfish/rust-phonenumber/commit/bea8e732b9cada617ede5cf51663dba183747f71"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/whisperfish/rust-phonenumber"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2023-0082.html"
    }
  ],
  "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": "phonenumber panics on parsing crafted RFC3966 inputs"
}

GHSA-WJ4P-JHRC-WR8Q

Vulnerability from github – Published: 2026-03-11 18:30 – Updated: 2026-03-11 18:30
VLAI
Details

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 16.11 before 18.7.6, 18.8 before 18.8.6, and 18.9 before 18.9.2 that could have allowed an unauthenticated user to cause a denial of service condition due to improper input validation when processing specially crafted JSON payloads in the protected branches API.

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
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-14513"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-11T16:16:19Z",
    "severity": "HIGH"
  },
  "details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 16.11 before 18.7.6, 18.8 before 18.8.6, and 18.9 before 18.9.2 that could have allowed an unauthenticated user to cause a denial of service condition due to improper input validation when processing specially crafted JSON payloads in the protected branches API.",
  "id": "GHSA-wj4p-jhrc-wr8q",
  "modified": "2026-03-11T18:30:32Z",
  "published": "2026-03-11T18:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14513"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/3452477"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/releases/2026/03/11/patch-release-gitlab-18-9-2-released"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/work_items/583718"
    }
  ],
  "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"
    }
  ]
}

GHSA-WJH9-35XC-WCV8

Vulnerability from github – Published: 2026-05-01 00:31 – Updated: 2026-05-01 00:31
VLAI
Details

IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.3 for Linux, UNIX and Windows (includes Db2 Connect Server) could allow an authenticated user to cause a denial of service due to improper neutralization of special elements in data query logic when certain configurations exist.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-14688"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-30T22:16:24Z",
    "severity": "MODERATE"
  },
  "details": "IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.3 for Linux, UNIX and Windows (includes Db2 Connect Server) could allow an authenticated user to cause a denial of service due to improper neutralization of special elements in data query logic when certain configurations exist.",
  "id": "GHSA-wjh9-35xc-wcv8",
  "modified": "2026-05-01T00:31:26Z",
  "published": "2026-05-01T00:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14688"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7269424"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WP8R-G76W-PH6Q

Vulnerability from github – Published: 2026-05-27 12:31 – Updated: 2026-05-27 12:31
VLAI
Details

Improper Validation of Specified Quantity in Input vulnerability in Ads by WPQuads Ads by WPQuads quick-adsense-reloaded allows Manipulating Hidden Fields.This issue affects Ads by WPQuads: from n/a through <= 3.0.2.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-42744"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-27T11:16:20Z",
    "severity": "MODERATE"
  },
  "details": "Improper Validation of Specified Quantity in Input vulnerability in Ads by WPQuads Ads by WPQuads quick-adsense-reloaded allows Manipulating Hidden Fields.This issue affects Ads by WPQuads: from n/a through \u003c= 3.0.2.",
  "id": "GHSA-wp8r-g76w-ph6q",
  "modified": "2026-05-27T12:31:23Z",
  "published": "2026-05-27T12:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42744"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/quick-adsense-reloaded/vulnerability/wordpress-ads-by-wpquads-plugin-3-0-2-bypass-vulnerability-vulnerability?_s_id=cve"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WQWX-RQF8-56VM

Vulnerability from github – Published: 2023-05-16 00:30 – Updated: 2024-04-04 04:10
VLAI
Details

In keyinstall, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07576935; Issue ID: ALPS07576935.

Severity
4.4 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-20710"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-20"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-15T22:15:11Z",
    "severity": "MODERATE"
  },
  "details": "In keyinstall, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07576935; Issue ID: ALPS07576935.",
  "id": "GHSA-wqwx-rqf8-56vm",
  "modified": "2024-04-04T04:10:45Z",
  "published": "2023-05-16T00:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20710"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/May-2023"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WR6J-Q48C-HX4C

Vulnerability from github – Published: 2023-10-13 00:30 – Updated: 2024-04-04 08:36
VLAI
Details

An Improper Validation of Specified Quantity in Input vulnerability in the Layer-2 control protocols daemon (l2cpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated adjacent attacker who sends specific LLDP packets to cause a Denial of Service(DoS).

This issue occurs when specific LLDP packets are received and telemetry polling is being done on the device. The impact of the l2cpd crash is reinitialization of STP protocols (RSTP, MSTP or VSTP), and MVRP and ERP. Also, if any services depend on LLDP state (like PoE or VoIP device recognition), then these will also be affected.

This issue affects:

Juniper Networks Junos OS

  • All versions prior to 20.4R3-S8;
  • 21.1 version 21.1R1 and later versions;
  • 21.2 versions prior to 21.2R3-S5;
  • 21.3 versions prior to 21.3R3-S4;
  • 21.4 versions prior to 21.4R3-S3;
  • 22.1 versions prior to 22.1R3-S2;
  • 22.2 versions prior to 22.2R3;
  • 22.3 versions prior to 22.3R2-S2;
  • 22.4 versions prior to 22.4R2;

Juniper Networks Junos OS Evolved

  • All versions prior to 20.4R3-S8-EVO;
  • 21.1 version 21.1R1-EVO and later versions;
  • 21.2 versions prior to 21.2R3-S5-EVO;
  • 21.3 versions prior to 21.3R3-S4-EVO;
  • 21.4 versions prior to 21.4R3-S3-EVO;
  • 22.1 versions prior to 22.1R3-S2-EVO;
  • 22.2 versions prior to 22.2R3-EVO;
  • 22.3 versions prior to 22.3R2-S2-EVO;
  • 22.4 versions prior to 22.4R1-S1-EVO;
Severity
6.5 (Medium)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-36839"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-12T23:15:10Z",
    "severity": "MODERATE"
  },
  "details": "\nAn Improper Validation of Specified Quantity in Input vulnerability in the Layer-2 control protocols daemon (l2cpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated adjacent attacker who sends specific LLDP packets to cause a Denial of Service(DoS).\n\nThis issue occurs when specific LLDP packets are received and telemetry polling is being done on the device. The impact of the l2cpd crash is reinitialization of STP protocols (RSTP, MSTP or VSTP), and MVRP and ERP. Also, if any services depend on LLDP state (like PoE or VoIP device recognition), then these will also be affected.\n\nThis issue affects:\n\nJuniper Networks Junos OS\n\n\n\n  *  All versions prior to 20.4R3-S8;\n  *  21.1 version 21.1R1 and later versions;\n  *  21.2 versions prior to 21.2R3-S5;\n  *  21.3 versions prior to 21.3R3-S4;\n  *  21.4 versions prior to 21.4R3-S3;\n  *  22.1 versions prior to 22.1R3-S2;\n  *  22.2 versions prior to 22.2R3;\n  *  22.3 versions prior to 22.3R2-S2;\n  *  22.4 versions prior to 22.4R2;\n\n\n\n\nJuniper Networks Junos OS Evolved\n\n\n\n  *  All versions prior to 20.4R3-S8-EVO;\n  *  21.1 version 21.1R1-EVO and later versions;\n  *  21.2 versions prior to 21.2R3-S5-EVO;\n  *  21.3 versions prior to 21.3R3-S4-EVO;\n  *  21.4 versions prior to 21.4R3-S3-EVO;\n  *  22.1 versions prior to 22.1R3-S2-EVO;\n  *  22.2 versions prior to 22.2R3-EVO;\n  *  22.3 versions prior to 22.3R2-S2-EVO;\n  *  22.4 versions prior to 22.4R1-S1-EVO;\n\n\n\n\n\n\n",
  "id": "GHSA-wr6j-q48c-hx4c",
  "modified": "2024-04-04T08:36:27Z",
  "published": "2023-10-13T00:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36839"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA73171"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X49M-3CW7-GQ5Q

Vulnerability from github – Published: 2023-06-23 21:44 – Updated: 2023-06-26 16:31
VLAI
Summary
jcvi vulnerable to Configuration Injection due to unsanitized user input
Details

Summary

A configuration injection happens when user input is considered by the application in an unsanitized format and can reach the configuration file. A malicious user may craft a special payload that may lead to a command injection.

PoC

The vulnerable code snippet is /jcvi/apps/base.py#LL2227C1-L2228C41. Under some circumstances a user input is retrieved and stored within the fullpath variable which reaches the configuration file ~/.jcvirc.

        fullpath = input(msg).strip()
        config.set(PATH, name, fullpath)

I ripped a part of the codebase into a runnable PoC as follows. All the PoC does is call the getpath() function under some circumstances.

from configparser import (
    ConfigParser,
    RawConfigParser,
    NoOptionError,
    NoSectionError,
    ParsingError,
)

import errno
import os
import sys
import os.path as op
import shutil
import signal
import sys
import logging


def is_exe(fpath):
    return op.isfile(fpath) and os.access(fpath, os.X_OK)


def which(program):
    """
    Emulates the unix which command.

    >>> which("cat")
    "/bin/cat"
    >>> which("nosuchprogram")
    """
    fpath, fname = op.split(program)
    if fpath:
        if is_exe(program):
            return program
    else:
        for path in os.environ["PATH"].split(os.pathsep):
            exe_file = op.join(path, program)
            if is_exe(exe_file):
                return exe_file

    return None


def getpath(cmd, name=None, url=None, cfg="~/.jcvirc", warn="exit"):
    """
    Get install locations of common binaries
    First, check ~/.jcvirc file to get the full path
    If not present, ask on the console and store
    """
    p = which(cmd)  # if in PATH, just returns it
    if p:
        return p

    PATH = "Path"
    config = RawConfigParser()
    cfg = op.expanduser(cfg)
    changed = False
    if op.exists(cfg):
        config.read(cfg)

    assert name is not None, "Need a program name"

    try:
        fullpath = config.get(PATH, name)
    except NoSectionError:
        config.add_section(PATH)
        changed = True

    try:
        fullpath = config.get(PATH, name)
    except NoOptionError:
        msg = "=== Configure path for {0} ===\n".format(name, cfg)
        if url:
            msg += "URL: {0}\n".format(url)
        msg += "[Directory that contains `{0}`]: ".format(cmd)
        fullpath = input(msg).strip()
        config.set(PATH, name, fullpath)
        changed = True

    path = op.join(op.expanduser(fullpath), cmd)
    if warn == "exit":
        try:
            assert is_exe(path), "***ERROR: Cannot execute binary `{0}`. ".format(path)
        except AssertionError as e:
            sys.exit("{0!s}Please verify and rerun.".format(e))

    if changed:
        configfile = open(cfg, "w")
        config.write(configfile)
        logging.debug("Configuration written to `{0}`.".format(cfg))

    return path


# Call to getpath
path = getpath("not-part-of-path", name="CLUSTALW2", warn="warn")
print(path)

To run the PoC, you need to remove the config file ~/.jcvirc to emulate the first run, 

# Run the PoC with the payload
echo -e "e\rvvvvvvvv = zzzzzzzz\n" | python3 poc.py

image

You can notice the random key/value characters vvvvvvvv = zzzzzzzz were successfully injected.

Impact

The impact of a configuration injection may vary. Under some conditions, it may lead to command injection if there is for instance shell code execution from the configuration file values.

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "jcvi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.3.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-35932"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-77"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-06-23T21:44:35Z",
    "nvd_published_at": "2023-06-23T22:15:08Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA configuration injection happens when user input is considered by the application in an unsanitized format and can reach the configuration file. A malicious user may craft a special payload that may lead to a command injection.\n\n### PoC\n\nThe vulnerable code snippet is [/jcvi/apps/base.py#LL2227C1-L2228C41](https://github.com/tanghaibao/jcvi/blob/cede6c65c8e7603cb266bc3395ac8f915ea9eac7/jcvi/apps/base.py#LL2227C1-L2228C41). Under some circumstances a user input is retrieved and stored within the `fullpath` variable which reaches the configuration file `~/.jcvirc`.\n\n```python\n        fullpath = input(msg).strip()\n        config.set(PATH, name, fullpath)\n```\n\nI ripped a part of the codebase into a runnable PoC as follows. All the PoC does is call the `getpath()` function under some circumstances.\n\n```python\nfrom configparser import (\n    ConfigParser,\n    RawConfigParser,\n    NoOptionError,\n    NoSectionError,\n    ParsingError,\n)\n\nimport errno\nimport os\nimport sys\nimport os.path as op\nimport shutil\nimport signal\nimport sys\nimport logging\n\n\ndef is_exe(fpath):\n    return op.isfile(fpath) and os.access(fpath, os.X_OK)\n\n\ndef which(program):\n    \"\"\"\n    Emulates the unix which command.\n\n    \u003e\u003e\u003e which(\"cat\")\n    \"/bin/cat\"\n    \u003e\u003e\u003e which(\"nosuchprogram\")\n    \"\"\"\n    fpath, fname = op.split(program)\n    if fpath:\n        if is_exe(program):\n            return program\n    else:\n        for path in os.environ[\"PATH\"].split(os.pathsep):\n            exe_file = op.join(path, program)\n            if is_exe(exe_file):\n                return exe_file\n\n    return None\n\n\ndef getpath(cmd, name=None, url=None, cfg=\"~/.jcvirc\", warn=\"exit\"):\n    \"\"\"\n    Get install locations of common binaries\n    First, check ~/.jcvirc file to get the full path\n    If not present, ask on the console and store\n    \"\"\"\n    p = which(cmd)  # if in PATH, just returns it\n    if p:\n        return p\n\n    PATH = \"Path\"\n    config = RawConfigParser()\n    cfg = op.expanduser(cfg)\n    changed = False\n    if op.exists(cfg):\n        config.read(cfg)\n\n    assert name is not None, \"Need a program name\"\n\n    try:\n        fullpath = config.get(PATH, name)\n    except NoSectionError:\n        config.add_section(PATH)\n        changed = True\n\n    try:\n        fullpath = config.get(PATH, name)\n    except NoOptionError:\n        msg = \"=== Configure path for {0} ===\\n\".format(name, cfg)\n        if url:\n            msg += \"URL: {0}\\n\".format(url)\n        msg += \"[Directory that contains `{0}`]: \".format(cmd)\n        fullpath = input(msg).strip()\n        config.set(PATH, name, fullpath)\n        changed = True\n\n    path = op.join(op.expanduser(fullpath), cmd)\n    if warn == \"exit\":\n        try:\n            assert is_exe(path), \"***ERROR: Cannot execute binary `{0}`. \".format(path)\n        except AssertionError as e:\n            sys.exit(\"{0!s}Please verify and rerun.\".format(e))\n\n    if changed:\n        configfile = open(cfg, \"w\")\n        config.write(configfile)\n        logging.debug(\"Configuration written to `{0}`.\".format(cfg))\n\n    return path\n\n\n# Call to getpath\npath = getpath(\"not-part-of-path\", name=\"CLUSTALW2\", warn=\"warn\")\nprint(path)\n\n```\n\nTo run the PoC, you need to remove the config file `~/.jcvirc` to emulate the first run, \n\n```bash\n# Run the PoC with the payload\necho -e \"e\\rvvvvvvvv = zzzzzzzz\\n\" | python3 poc.py\n```\n\n![image](https://user-images.githubusercontent.com/13036531/247852364-f8a384a3-fc62-41ca-b467-877d197ac6ff.png)\n\nYou can notice the random key/value characters `vvvvvvvv = zzzzzzzz` were successfully injected.\n\n### Impact\n\nThe impact of a configuration injection may vary. Under some conditions, it may lead to command injection if there is for instance shell code execution from the configuration file values.\n",
  "id": "GHSA-x49m-3cw7-gq5q",
  "modified": "2023-06-26T16:31:23Z",
  "published": "2023-06-23T21:44:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tanghaibao/jcvi/security/advisories/GHSA-x49m-3cw7-gq5q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35932"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tanghaibao/jcvi"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tanghaibao/jcvi/blob/cede6c65c8e7603cb266bc3395ac8f915ea9eac7/jcvi/apps/base.py#LL2227C1-L2228C41"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "jcvi vulnerable to Configuration Injection due to unsanitized user input "
}
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list