{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:06:58.727Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/18"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka",
          "packageURL": "pkg:maven/org.apache.kafka/kafka",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "4.1.2",
              "status": "affected",
              "version": "0.11.0.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.2.1",
              "status": "affected",
              "version": "4.2.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.3.1",
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Peyton Kennedy \u003cpkennedy@endor.ai\u003e"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Trung Nguyen \u003ctrungnh@cystack.net\u003e, CyStack"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Bart\u0142omiej Dmitruk \u003cbartek@striga.ai\u003e, Striga"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "\uc784\uc131\ubbfc \u003cat_haemil@naver.com\u003e"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Mike Read (GitHub: Michael-JRead)"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Salman Aljardan \u003csalman1aljardan@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Yuchao Zhang \u003cndaugoing@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Yu Bao \u003cyubao@paypal.com\u003e, PayPal Cyber Security Team"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Vamsi K \u003cxh081ix@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Srinivas Akhil Mallela \u003csrinivasakhil@gmail.com\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cbr\u003e\u003cdiv\u003eWhen a broker decodes a compressed record batch, the per-record decoder reads a declared body\u0026nbsp;\u003cspan\u003esize from the decompressed stream and allocates a buffer of that size before validating it\u0026nbsp;\u003c/span\u003e\u003cspan\u003eagainst the bytes available or any configured limit. The size is attacker-controlled, and the\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebatch CRC does not constrain it, so a small (around 90-byte), CRC-valid compressed produce\u0026nbsp;\u003c/span\u003e\u003cspan\u003erequest can declare a body size of up to about 2 GiB and force the broker to attempt that\u0026nbsp;\u003c/span\u003e\u003cspan\u003eallocation, raising OutOfMemoryError. The record size limit (max.message.bytes), the request\u0026nbsp;\u003c/span\u003e\u003cspan\u003esize limit, and client/broker quotas bound only the compressed wire size, not the declared\u0026nbsp;\u003c/span\u003e\u003cspan\u003edecompressed size.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cdiv\u003eAn authenticated principal with Write on a topic can crash broker request-handler threads\u0026nbsp;\u003cspan\u003e(reached when a batch\u0027s codec differs from the topic\u0027s compression.type and records are\u0026nbsp;\u003c/span\u003e\u003cspan\u003ere-encoded) and any consumer that fetches the record, denying service. On brokers started\u0026nbsp;\u003c/span\u003e\u003cspan\u003ewith -XX:+ExitOnOutOfMemoryError, a common hardening, a single crafted request terminates the\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebroker JVM. More seriously, a\u0026nbsp;crafted record\u0026nbsp;\u0026nbsp;\u003c/span\u003e\u003cspan\u003eis accepted at ingest and written to disk; when the log-cleaner later reads it\u0026nbsp;\u003c/span\u003e\u003cspan\u003eon a compacted topic, the OutOfMemoryError (an Error, not an Exception) terminates the cleaner\u0026nbsp;\u003c/span\u003e\u003cspan\u003ethread, which is not restarted. With the default of a single cleaner thread, log compaction\u0026nbsp;\u003c/span\u003e\u003cspan\u003ethen stops for the entire broker, including the internal __consumer_offsets and\u0026nbsp;\u003c/span\u003e\u003cspan\u003e__transaction_state topics, and the condition persists across restarts until the offending\u0026nbsp;\u003c/span\u003e\u003cspan\u003erecord is removed. The impact is availability only; no data is disclosed or altered.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eMitigation:\u003c/div\u003e\u003cdiv\u003eUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0, and set max.decompressed.message.bytes (at the\u0026nbsp;\u003cspan\u003ebroker and/or topic level) to a bounded value appropriate for your workload. Upgrading alone is\u0026nbsp;\u003c/span\u003e\u003cspan\u003enot sufficient: for backward compatibility this configuration defaults to an effectively\u0026nbsp;\u003c/span\u003e\u003cspan\u003eunlimited value (about 2 GiB), so a broker remains exposed until the limit is set. Choose a\u0026nbsp;\u003c/span\u003e\u003cspan\u003evalue at or slightly above the largest legitimate decompressed record your applications\u0026nbsp;\u003c/span\u003e\u003cspan\u003eproduce, and comfortably below the broker heap divided by the number of request-handler and\u0026nbsp;\u003c/span\u003e\u003cspan\u003ecleaner threads. Until you can upgrade and configure the limit, restrict Write access to\u0026nbsp;\u003c/span\u003e\u003cspan\u003etrusted producers; quotas and max.message.bytes do not mitigate this issue.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eResolution:\u003c/div\u003e\u003cdiv\u003eFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the broker validates a record\u0027s declared decompressed\u0026nbsp;\u003cspan\u003ebody size against max.decompressed.message.bytes before allocating, on the produce-validation,\u0026nbsp;\u003c/span\u003e\u003cspan\u003elog-compaction, and timestamp-lookup paths, and rejects oversized or negative sizes with\u0026nbsp;\u003c/span\u003e\u003cspan\u003eInvalidRecordException. Operators must set this configuration to a bounded value to be protected,\u0026nbsp;\u003c/span\u003e\u003cspan\u003eas its default is effectively unlimited.\u003c/span\u003e\u003c/div\u003e"
            }
          ],
          "value": "When a broker decodes a compressed record batch, the per-record decoder reads a declared body\u00a0size from the decompressed stream and allocates a buffer of that size before validating it\u00a0against the bytes available or any configured limit. The size is attacker-controlled, and the\u00a0batch CRC does not constrain it, so a small (around 90-byte), CRC-valid compressed produce\u00a0request can declare a body size of up to about 2 GiB and force the broker to attempt that\u00a0allocation, raising OutOfMemoryError. The record size limit (max.message.bytes), the request\u00a0size limit, and client/broker quotas bound only the compressed wire size, not the declared\u00a0decompressed size.\n\n\nImpact:\n\nAn authenticated principal with Write on a topic can crash broker request-handler threads\u00a0(reached when a batch\u0027s codec differs from the topic\u0027s compression.type and records are\u00a0re-encoded) and any consumer that fetches the record, denying service. On brokers started\u00a0with -XX:+ExitOnOutOfMemoryError, a common hardening, a single crafted request terminates the\u00a0broker JVM. More seriously, a\u00a0crafted record\u00a0\u00a0is accepted at ingest and written to disk; when the log-cleaner later reads it\u00a0on a compacted topic, the OutOfMemoryError (an Error, not an Exception) terminates the cleaner\u00a0thread, which is not restarted. With the default of a single cleaner thread, log compaction\u00a0then stops for the entire broker, including the internal __consumer_offsets and\u00a0__transaction_state topics, and the condition persists across restarts until the offending\u00a0record is removed. The impact is availability only; no data is disclosed or altered.\n\n\nMitigation:\n\nUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0, and set max.decompressed.message.bytes (at the\u00a0broker and/or topic level) to a bounded value appropriate for your workload. Upgrading alone is\u00a0not sufficient: for backward compatibility this configuration defaults to an effectively\u00a0unlimited value (about 2 GiB), so a broker remains exposed until the limit is set. Choose a\u00a0value at or slightly above the largest legitimate decompressed record your applications\u00a0produce, and comfortably below the broker heap divided by the number of request-handler and\u00a0cleaner threads. Until you can upgrade and configure the limit, restrict Write access to\u00a0trusted producers; quotas and max.message.bytes do not mitigate this issue.\n\n\nResolution:\n\nFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the broker validates a record\u0027s declared decompressed\u00a0body size against max.decompressed.message.bytes before allocating, on the produce-validation,\u00a0log-compaction, and timestamp-lookup paths, and rejects oversized or negative sizes with\u00a0InvalidRecordException. Operators must set this configuration to a bounded value to be protected,\u00a0as its default is effectively unlimited."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-789",
              "description": "CWE-789 Memory allocation with excessive size value",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400 Uncontrolled Resource Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-1284",
              "description": "CWE-1284 Improper validation of specified quantity in input",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:46:54.920Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Kafka: Denial of service via unbounded memory allocation when decoding compressed record batches",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-114349",
    "datePublished": "2026-10-28T16:46:54.920Z",
    "dateReserved": "2026-10-21T08:14:55.090Z",
    "dateUpdated": "2026-10-28T20:06:58.727Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka",
          "packageURL": "pkg:maven/org.apache.kafka/kafka",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "4.1.2",
              "status": "affected",
              "version": "3.2.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.2.1",
              "status": "affected",
              "version": "4.2.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.3.1",
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Arthur Chan \u003carthur.chan@adalogics.com\u003e, Ada Logics and Anthropic Research"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "OpenAI Codex Security - Amy Burnett and Khai Tran"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Mickael Maison \u003cmickael.maison@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Manikumar Reddy \u003cmanikumar.reddy@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Chia-Ping Tsai \u003cchia7712@gmail.com\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003eAn authenticated Kafka principal with no authorization grants (not even ALTER_CONFIGS) can\u0026nbsp;\u003cspan\u003emake a broker read a file or an environment variable from the broker host and return its\u0026nbsp;\u003c/span\u003e\u003cspan\u003econtents. An IncrementalAlterConfigs (or AlterConfigs) request targeting a BROKER resource\u0026nbsp;\u003c/span\u003e\u003cspan\u003ereaches the broker\u0027s configuration validation before any authorization check is applied to\u0026nbsp;\u003c/span\u003e\u003cspan\u003ethat path. Validation resolves configuration variables such as ${file:/path:key} or ${env:VAR}\u0026nbsp;\u003c/span\u003e\u003cspan\u003eusing a ConfigProvider named in the request, and this resolution bypasses the\u0026nbsp;\u003c/span\u003e\u003cspan\u003eorg.apache.kafka.automatic.config.providers allowlist that was added as the mitigation for\u0026nbsp;\u003c/span\u003e\u003cspan\u003eCVE-2024-31141. An arbitrary ConfigProvider (for example FileConfigProvider or\u0026nbsp;\u003c/span\u003e\u003cspan\u003eEnvVarConfigProvider) is therefore instantiated and the referenced file or environment\u0026nbsp;\u003c/span\u003e\u003cspan\u003evariable is read, and a type-validation error returns the resolved content to the caller.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cdiv\u003eOn a cluster with an authorizer enabled, an authenticated principal with no authorization\u0026nbsp;\u003cspan\u003egrants can read the contents of files accessible to the broker process, and the broker\u0027s\u0026nbsp;\u003c/span\u003e\u003cspan\u003eenvironment variables, exposing credentials, keystores, or other secrets, defeating the\u0026nbsp;\u003c/span\u003e\u003cspan\u003eCVE-2024-31141 allowlist. The read is bounded by the broker process\u0027s file permissions. The\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebrokers and the cluster remain available; the issue is disclosure of file and environment-\u0026nbsp;\u003c/span\u003e\u003cspan\u003evariable contents. Clusters with no authorizer configured are not affected in practice,\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebecause every principal already holds ALTER_CONFIGS there.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eMitigation:\u003c/div\u003e\u003cdiv\u003eUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. As defense in depth, run brokers under a\u0026nbsp;\u003cspan\u003eleast-privileged operating-system account so that sensitive files are not readable by the\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebroker process.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eResolution:\u003c/div\u003e\u003cdiv\u003eFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: broker configuration changes are authorized\u0026nbsp;\u003cspan\u003e(ALTER_CONFIGS on the cluster) before the configuration is validated, and configuration-\u0026nbsp;\u003c/span\u003e\u003cspan\u003evariable resolution enforces the config-providers allowlist.\u003c/span\u003e\u003c/div\u003e"
            }
          ],
          "value": "An authenticated Kafka principal with no authorization grants (not even ALTER_CONFIGS) can\u00a0make a broker read a file or an environment variable from the broker host and return its\u00a0contents. An IncrementalAlterConfigs (or AlterConfigs) request targeting a BROKER resource\u00a0reaches the broker\u0027s configuration validation before any authorization check is applied to\u00a0that path. Validation resolves configuration variables such as ${file:/path:key} or ${env:VAR}\u00a0using a ConfigProvider named in the request, and this resolution bypasses the\u00a0org.apache.kafka.automatic.config.providers allowlist that was added as the mitigation for\u00a0CVE-2024-31141. An arbitrary ConfigProvider (for example FileConfigProvider or\u00a0EnvVarConfigProvider) is therefore instantiated and the referenced file or environment\u00a0variable is read, and a type-validation error returns the resolved content to the caller.\n\n\nImpact:\n\nOn a cluster with an authorizer enabled, an authenticated principal with no authorization\u00a0grants can read the contents of files accessible to the broker process, and the broker\u0027s\u00a0environment variables, exposing credentials, keystores, or other secrets, defeating the\u00a0CVE-2024-31141 allowlist. The read is bounded by the broker process\u0027s file permissions. The\u00a0brokers and the cluster remain available; the issue is disclosure of file and environment-\u00a0variable contents. Clusters with no authorizer configured are not affected in practice,\u00a0because every principal already holds ALTER_CONFIGS there.\n\n\nMitigation:\n\nUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. As defense in depth, run brokers under a\u00a0least-privileged operating-system account so that sensitive files are not readable by the\u00a0broker process.\n\n\nResolution:\n\nFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: broker configuration changes are authorized\u00a0(ALTER_CONFIGS on the cluster) before the configuration is validated, and configuration-\u00a0variable resolution enforces the config-providers allowlist."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-862",
              "description": "CWE-862 Missing Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:46:38.006Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Kafka: Unauthorized principal can read arbitrary broker files via IncrementalAlterConfigs",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-112375",
    "datePublished": "2026-10-28T16:46:38.006Z",
    "dateReserved": "2026-10-19T16:21:36.477Z",
    "dateUpdated": "2026-10-28T16:46:38.006Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:07:01.640Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/16"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:connect-runtime",
          "packageURL": "pkg:maven/org.apache.kafka/connect-runtime",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.2.2",
              "status": "affected",
              "version": "2.4.0",
              "versionType": "semver"
            },
            {
              "lessThan": "4.3.2",
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Hyunwoo Kim \u003cimv4bel@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Sudhanshu Chauhan \u003csudhanshu@redhuntlabs.com\u003e, RedHunt Labs"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Bart\u0142omiej Dmitruk \u003cbartek@striga.ai\u003e, Striga"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Andrew MacPherson \u003candrew@andrewmohawk.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Mickael Maison \u003cmickael.maison@gmail.com\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Apache Kafka Connect has the /connector-plugins/{connector-type}/config/validate endpoint on its REST API to validate connector configurations.\u003cbr\u003eApache Kafka Connect also support Configuration Providers which enable to hide the values of sensitive configuration and only resolve them at runtime.\u0026nbsp;\u003cbr\u003e\u003cbr\u003eAn attacker with access to the validate endpoint can use it to resolve and return plaintext values via any of the configuration providers installed on a Connect worker.\u003cbr\u003e\u003cbr\u003eUsers are recommended to upgrade to version 4.2.2, 4.3.2, 4.4.0 or above, which fix this issue."
            }
          ],
          "value": "Apache Kafka Connect has the /connector-plugins/{connector-type}/config/validate endpoint on its REST API to validate connector configurations.\nApache Kafka Connect also support Configuration Providers which enable to hide the values of sensitive configuration and only resolve them at runtime.\u00a0\n\nAn attacker with access to the validate endpoint can use it to resolve and return plaintext values via any of the configuration providers installed on a Connect worker.\n\nUsers are recommended to upgrade to version 4.2.2, 4.3.2, 4.4.0 or above, which fix this issue."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "moderate"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:46:21.415Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Kafka: Kafka Connect configuration provider values exposed via validation REST API endpoint",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-116593",
    "datePublished": "2026-10-28T16:46:21.415Z",
    "dateReserved": "2026-10-26T15:15:31.645Z",
    "dateUpdated": "2026-10-28T20:07:01.640Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:07:00.157Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/15"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:connect-runtime",
          "packageURL": "pkg:maven/org.apache.kafka/connect-runtime",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.2.2",
              "status": "affected",
              "version": "2.4.0",
              "versionType": "semver"
            },
            {
              "lessThan": "4.3.2",
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Bart\u0142omiej Dmitruk \u003cbartek@striga.ai\u003e, Striga"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Mickael Maison \u003cmickael.maison@gmail.com\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003eApache Kafka Connect contains an authentication bypass vulnerability affecting the admin REST API when admin.listeners is configured with a separate listener from the main listeners property.\u003c/div\u003e\u003cdiv\u003eWhen operators isolate the admin REST API by explicitly configuring the \"admin.listeners\" property, REST extensions specified via rest.extension.classes (such as BasicAuthSecurityRestExtension) are not registered or applied to the admin resource configuration.\u003cbr\u003e\u003cbr\u003eWhile the primary REST API listener (configured via listeners) enforces configured authentication and authorization filters, endpoints mounted under the separate admin listener (/admin/loggers) fail to inherit or instantiate these extension filters. As a result, the admin logger endpoint accepts unauthenticated read and write requests even when security extensions are active on the main listener.\u003c/div\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cdiv\u003eAn unauthenticated attacker with network access to the admin listener can:\u003cbr\u003e\u003cbr\u003e  1. Read the complete set of logger names and levels, disclosing loaded class names and which security extensions are in use.\u003cbr\u003e  2. Write logger levels, including with scope=cluster which propagates the change to all workers in the Connect cluster. This can be used to suppress\u003cbr\u003e     logging (setting root to OFF) or generate excessive log output (setting root to TRACE), potentially impacting availability and observability.\u003c/div\u003e\u003cdiv\u003eMitigation:\u003cbr\u003e\u003cbr\u003e  Users who cannot upgrade immediately can remove the admin.listeners configuration (or leave it unset). When unset, admin resources share the regular listener and inherit its security extensions.\u003c/div\u003e\u003cdiv\u003eResolution:\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e\u003cdiv\u003eFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0, we make sure the\u0026nbsp;REST extensions specified via \"rest.extension.classes\" will also apply to\u0026nbsp;\"admin.listeners\".\u003c/div\u003e\u003c/div\u003e"
            }
          ],
          "value": "Apache Kafka Connect contains an authentication bypass vulnerability affecting the admin REST API when admin.listeners is configured with a separate listener from the main listeners property.\n\nWhen operators isolate the admin REST API by explicitly configuring the \"admin.listeners\" property, REST extensions specified via rest.extension.classes (such as BasicAuthSecurityRestExtension) are not registered or applied to the admin resource configuration.\n\nWhile the primary REST API listener (configured via listeners) enforces configured authentication and authorization filters, endpoints mounted under the separate admin listener (/admin/loggers) fail to inherit or instantiate these extension filters. As a result, the admin logger endpoint accepts unauthenticated read and write requests even when security extensions are active on the main listener.\n\nImpact:\n\nAn unauthenticated attacker with network access to the admin listener can:\n\n  1. Read the complete set of logger names and levels, disclosing loaded class names and which security extensions are in use.\n  2. Write logger levels, including with scope=cluster which propagates the change to all workers in the Connect cluster. This can be used to suppress\n     logging (setting root to OFF) or generate excessive log output (setting root to TRACE), potentially impacting availability and observability.\n\nMitigation:\n\n  Users who cannot upgrade immediately can remove the admin.listeners configuration (or leave it unset). When unset, admin resources share the regular listener and inherit its security extensions.\n\nResolution:\n\n\nFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0, we make sure the\u00a0REST extensions specified via \"rest.extension.classes\" will also apply to\u00a0\"admin.listeners\"."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "low"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:45:36.440Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Kafka: Connect Admin REST API Authentication Bypass via Unapplied REST Extensions",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-115644",
    "datePublished": "2026-10-28T16:45:36.440Z",
    "dateReserved": "2026-10-23T03:48:31.242Z",
    "dateUpdated": "2026-10-28T20:07:00.157Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:06:57.172Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/13"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka-streams",
          "packageURL": "pkg:maven/org.apache.kafka/kafka-streams",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "4.1.2",
              "status": "affected",
              "version": "0.10.0.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.2.1",
              "status": "affected",
              "version": "4.2.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.3.1",
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        },
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka-clients",
          "packageURL": "pkg:maven/org.apache.kafka/kafka-clients",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "4.1.2",
              "status": "affected",
              "version": "0.10.0.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.2.1",
              "status": "affected",
              "version": "4.2.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.3.1",
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Peyton Kennedy \u003cpkennedy@endor.ai\u003e"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Bartlomiej Dmitruk \u003cbartek@striga.ai\u003e"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Mike Read (GitHub: Michael-JRead)"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Matthias J. Sax \u003cmatthias@confluent.io\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Lucy Liu \u003clucliu@confluent.io\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003eSeveral Kafka deserialization paths read a size or count field from input data and use it directly\u0026nbsp;\u003cspan\u003eto allocate an array, collection, or byte buffer, with no check against the bytes actually\u0026nbsp;\u003c/span\u003e\u003cspan\u003eavailable. A small crafted input can therefore declare a very large size and force a\u0026nbsp;\u003c/span\u003e\u003cspan\u003emulti-gigabyte allocation. The affected paths are, in Kafka Streams, ProcessorRecordContext\u0026nbsp;\u003c/span\u003e\u003cspan\u003e(header count), ChangedDeserializer (varint value length), CombinedKeySchema (foreign-key length,\u0026nbsp;\u003c/span\u003e\u003cspan\u003ewhich could also produce a negative size), ProcessorMetadata (key length), and AssignmentInfo\u0026nbsp;\u003c/span\u003e\u003cspan\u003egroup-assignment decoding; and, in the clients library, ListDeserializer (used by ListSerde).\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cdiv\u003eAn attacker can trigger the oversized allocation and raise an OutOfMemoryError that crashes the\u0026nbsp;\u003cspan\u003eaffected consumer or Kafka Streams thread; the broker and the rest of the cluster are unaffected.\u0026nbsp;\u003c/span\u003e\u003cspan\u003eThe reachable surface depends on the path: writing a crafted record to a Streams application\u0027s\u0026nbsp;\u003c/span\u003e\u003cspan\u003einternal changelog or repartition topics, or committing crafted offset metadata to its consumer\u0026nbsp;\u003c/span\u003e\u003cspan\u003egroup (Streams internal paths); writing a crafted record to any topic that a consumer reads with\u0026nbsp;\u003c/span\u003e\u003cspan\u003eListSerde (ListDeserializer); or, as a member of a Streams consumer group, returning crafted\u0026nbsp;\u003c/span\u003e\u003cspan\u003eassignment data when elected leader (AssignmentInfo). Because a crafted record remains in its\u0026nbsp;\u003c/span\u003e\u003cspan\u003etopic, the error can recur on restart. The record size limit (max.message.bytes) does not help,\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebecause the allocation is driven by a size field rather than by the input\u0027s length.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eMitigation:\u003c/div\u003e\u003cdiv\u003eUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Where authorization is enabled, restrict write\u0026nbsp;\u003cspan\u003eaccess to each application\u0027s internal topics and consumer group to its own principal, and restrict\u0026nbsp;\u003c/span\u003e\u003cspan\u003ewho can produce to topics that are consumed with ListSerde.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eResolution:\u003c/div\u003e\u003cdiv\u003eFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: these deserialization paths validate the declared size\u0026nbsp;\u003cspan\u003eagainst the remaining input before allocating and reject input that fails the check.\u003c/span\u003e\u003c/div\u003e"
            }
          ],
          "value": "Several Kafka deserialization paths read a size or count field from input data and use it directly\u00a0to allocate an array, collection, or byte buffer, with no check against the bytes actually\u00a0available. A small crafted input can therefore declare a very large size and force a\u00a0multi-gigabyte allocation. The affected paths are, in Kafka Streams, ProcessorRecordContext\u00a0(header count), ChangedDeserializer (varint value length), CombinedKeySchema (foreign-key length,\u00a0which could also produce a negative size), ProcessorMetadata (key length), and AssignmentInfo\u00a0group-assignment decoding; and, in the clients library, ListDeserializer (used by ListSerde).\n\n\nImpact:\n\nAn attacker can trigger the oversized allocation and raise an OutOfMemoryError that crashes the\u00a0affected consumer or Kafka Streams thread; the broker and the rest of the cluster are unaffected.\u00a0The reachable surface depends on the path: writing a crafted record to a Streams application\u0027s\u00a0internal changelog or repartition topics, or committing crafted offset metadata to its consumer\u00a0group (Streams internal paths); writing a crafted record to any topic that a consumer reads with\u00a0ListSerde (ListDeserializer); or, as a member of a Streams consumer group, returning crafted\u00a0assignment data when elected leader (AssignmentInfo). Because a crafted record remains in its\u00a0topic, the error can recur on restart. The record size limit (max.message.bytes) does not help,\u00a0because the allocation is driven by a size field rather than by the input\u0027s length.\n\n\nMitigation:\n\nUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Where authorization is enabled, restrict write\u00a0access to each application\u0027s internal topics and consumer group to its own principal, and restrict\u00a0who can produce to topics that are consumed with ListSerde.\n\n\nResolution:\n\nFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: these deserialization paths validate the declared size\u00a0against the remaining input before allocating and reject input that fails the check."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-789",
              "description": "CWE-789 Memory allocation with excessive size value",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400 Uncontrolled Resource Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-20",
              "description": "CWE-20 Improper input validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:45:25.163Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Kafka: Denial of service in Kafka Streams and client deserializers via unbounded memory allocation",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-111551",
    "datePublished": "2026-10-28T16:45:25.163Z",
    "dateReserved": "2026-10-16T11:01:49.270Z",
    "dateUpdated": "2026-10-28T20:06:57.172Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:06:55.726Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/14"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka-streams",
          "packageURL": "pkg:maven/org.apache.kafka/kafka-streams",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "4.1.2",
              "status": "affected",
              "version": "1.1.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.2.1",
              "status": "affected",
              "version": "4.2.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.3.1",
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Mike Read (GitHub: Michael-JRead)"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Matthias J. Sax \u003cmatthias@confluent.io\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003eKafka Streams derives its stream-time clock from record timestamps. PunctuationSchedule.next()\u0026nbsp;\u003cspan\u003ecomputed the next punctuation time as timestamp + (intervalsMissed + 1) * interval with no\u0026nbsp;\u003c/span\u003e\u003cspan\u003eoverflow check. A record with a timestamp at or near Long.MAX_VALUE advances stream time to that\u0026nbsp;\u003c/span\u003e\u003cspan\u003evalue, so the next stream-time punctuation overflows to a negative time. PunctuationQueue then\u0026nbsp;\u003c/span\u003e\u003cspan\u003ere-queues that time and loops on it indefinitely while holding a lock, stalling the StreamThread.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cdiv\u003eA single record is enough. The affected StreamThread stops processing, and because the record\u0026nbsp;\u003cspan\u003estays in the topic the hang returns on restart; an application whose partitions are all affected\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebecomes unresponsive. Only the Streams application is affected, not the brokers or the cluster.\u0026nbsp;\u003c/span\u003e\u003cspan\u003eTriggering it needs write access to a source topic whose topology uses stream-time punctuation,\u0026nbsp;\u003c/span\u003e\u003cspan\u003eand a broker that stores the record: brokers from Apache Kafka 4.0.0 reject such a timestamp by\u0026nbsp;\u003c/span\u003e\u003cspan\u003edefault (log.message.timestamp.after.max.ms, one hour), so it is reachable only on older brokers\u0026nbsp;\u003c/span\u003e\u003cspan\u003eor where that bound has been relaxed.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eMitigation:\u003c/div\u003e\u003cdiv\u003eUpgrade Kafka Streams to 4.2.2, 4.3.2, or 4.4.0. As defense in depth, keep\u0026nbsp;\u003cspan\u003elog.message.timestamp.after.max.ms bounded on source topics and restrict write access to them.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eResolution:\u003c/div\u003e\u003cdiv\u003eFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the next punctuation time is computed with\u0026nbsp;\u003cspan\u003eoverflow-checked arithmetic (clamped to Long.MAX_VALUE), and a rescheduled punctuation is\u0026nbsp;\u003c/span\u003e\u003cspan\u003ere-queued only when its time moves forward.\u003c/span\u003e\u003c/div\u003e"
            }
          ],
          "value": "Kafka Streams derives its stream-time clock from record timestamps. PunctuationSchedule.next()\u00a0computed the next punctuation time as timestamp + (intervalsMissed + 1) * interval with no\u00a0overflow check. A record with a timestamp at or near Long.MAX_VALUE advances stream time to that\u00a0value, so the next stream-time punctuation overflows to a negative time. PunctuationQueue then\u00a0re-queues that time and loops on it indefinitely while holding a lock, stalling the StreamThread.\n\n\nImpact:\n\nA single record is enough. The affected StreamThread stops processing, and because the record\u00a0stays in the topic the hang returns on restart; an application whose partitions are all affected\u00a0becomes unresponsive. Only the Streams application is affected, not the brokers or the cluster.\u00a0Triggering it needs write access to a source topic whose topology uses stream-time punctuation,\u00a0and a broker that stores the record: brokers from Apache Kafka 4.0.0 reject such a timestamp by\u00a0default (log.message.timestamp.after.max.ms, one hour), so it is reachable only on older brokers\u00a0or where that bound has been relaxed.\n\n\nMitigation:\n\nUpgrade Kafka Streams to 4.2.2, 4.3.2, or 4.4.0. As defense in depth, keep\u00a0log.message.timestamp.after.max.ms bounded on source topics and restrict write access to them.\n\n\nResolution:\n\nFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the next punctuation time is computed with\u00a0overflow-checked arithmetic (clamped to Long.MAX_VALUE), and a rescheduled punctuation is\u00a0re-queued only when its time moves forward."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "low"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-190",
              "description": "CWE-190 Integer overflow or wraparound",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-835",
              "description": "CWE-835 Loop with unreachable exit condition (\u0027infinite loop\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:45:08.114Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Kafka: Kafka Streams StreamThread hang from integer overflow in stream-time punctuation",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-111496",
    "datePublished": "2026-10-28T16:45:08.114Z",
    "dateReserved": "2026-10-16T09:55:02.432Z",
    "dateUpdated": "2026-10-28T20:06:55.726Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:06:54.294Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/12"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka",
          "packageURL": "pkg:maven/org.apache.kafka/kafka",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "4.1.2",
              "status": "affected",
              "version": "2.4.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.2.1",
              "status": "affected",
              "version": "4.2.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.3.1",
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Mufeed VH  \u003cmufeed@winfunc.com\u003e"
        },
        {
          "lang": "en",
          "type": "finder",
          "value": "Vivek R \u003cvivek@winfunc.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Shay Elkin \u003cselkin@confluent.io\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003e\u003cdiv\u003e\u003cspan\u003eApache Kafka\u0027s code-generated readers for flexible protocol versions read a tagged-field count\u0026nbsp;\u003c/span\u003e\u003cspan\u003edeclared by the sender and retain a RawTaggedField object for each unknown field. That count\u0026nbsp;\u003c/span\u003e\u003cspan\u003ewas bounded only by the outer request frame size (socket.request.max.bytes); it was not checked\u0026nbsp;\u003c/span\u003e\u003cspan\u003eagainst the remaining buffer bytes or capped. Because each entry can be encoded in as little as\u0026nbsp;\u003c/span\u003e\u003cspan\u003etwo bytes (unknown tag 0, size 0), a modest request can declare tens of millions of tagged\u0026nbsp;\u003c/span\u003e\u003cspan\u003efields and force one object allocation per declared field. Flexible request headers (header\u0026nbsp;\u003c/span\u003e\u003cspan\u003eversion 2, used by flexible APIs such as ApiVersions v3) are parsed this way, so the\u0026nbsp;\u003c/span\u003e\u003cspan\u003eamplification applies to the request header itself.\u003c/span\u003e\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003eImpact:\u003cbr\u003eThe flexible request header is parsed on the network thread before authorization, request dispatch, and request-time quota accounting. A client can send a request of a few tens of megabytes whose header declares about 20 million tagged fields, forcing roughly that many RawTaggedField allocations and exhausting broker heap or inducing process-wide GC stalls, denying broker service. Because the header is parsed for pre-authentication APIs such as ApiVersions (v3), the allocation can occur before authentication; no Kafka resource ACL or quota is required.\u003cbr\u003e\u003cbr\u003eMitigation:\u003cbr\u003eUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes and restricting network access to broker listeners reduces, but does not remove, exposure.\u003cbr\u003e\u003cbr\u003eResolution:\u003cbr\u003eFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers bounds-check the tagged-field count for flexible-versioned messages, rejecting a negative count, a count exceeding the remaining buffer bytes, or a count exceeding a fixed maximum (10,000), before any per-field allocation.\u003c/div\u003e\u003c/div\u003e"
            }
          ],
          "value": "Apache Kafka\u0027s code-generated readers for flexible protocol versions read a tagged-field count\u00a0declared by the sender and retain a RawTaggedField object for each unknown field. That count\u00a0was bounded only by the outer request frame size (socket.request.max.bytes); it was not checked\u00a0against the remaining buffer bytes or capped. Because each entry can be encoded in as little as\u00a0two bytes (unknown tag 0, size 0), a modest request can declare tens of millions of tagged\u00a0fields and force one object allocation per declared field. Flexible request headers (header\u00a0version 2, used by flexible APIs such as ApiVersions v3) are parsed this way, so the\u00a0amplification applies to the request header itself.\n\n\nImpact:\nThe flexible request header is parsed on the network thread before authorization, request dispatch, and request-time quota accounting. A client can send a request of a few tens of megabytes whose header declares about 20 million tagged fields, forcing roughly that many RawTaggedField allocations and exhausting broker heap or inducing process-wide GC stalls, denying broker service. Because the header is parsed for pre-authentication APIs such as ApiVersions (v3), the allocation can occur before authentication; no Kafka resource ACL or quota is required.\n\nMitigation:\nUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes and restricting network access to broker listeners reduces, but does not remove, exposure.\n\nResolution:\nFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers bounds-check the tagged-field count for flexible-versioned messages, rejecting a negative count, a count exceeding the remaining buffer bytes, or a count exceeding a fixed maximum (10,000), before any per-field allocation."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:44:53.268Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Kafka: Broker OutOfMemoryError via tagged-field allocation amplification in flexible protocol request parsing",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-111115",
    "datePublished": "2026-10-28T16:44:53.268Z",
    "dateReserved": "2026-10-15T16:27:16.838Z",
    "dateUpdated": "2026-10-28T20:06:54.294Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:06:52.812Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/10"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka",
          "packageURL": "pkg:maven/org.apache.kafka/kafka",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "4.1.2",
              "status": "affected",
              "version": "3.3.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.2.1",
              "status": "affected",
              "version": "4.2.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.3.1",
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Mike Read (GitHub: Michael-JRead)"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Izzy Harker \u003ciharker@confluent.io\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Alyssa Huang \u003cahuang@confluent.io\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Truc Nguyen  \u003ctrnguyen@confluent.io\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003eApache Kafka\u0027s code-generated protocol readers pre-size an array\u0027s collection from the element\u0026nbsp;\u003cspan\u003ecount declared by the sender. That count is checked only against the bytes remaining in the\u0026nbsp;\u003c/span\u003e\u003cspan\u003erequest buffer, which assumes about one byte per element; because most elements need several\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebytes, a request can declare far more elements than the buffer holds and still pass. For a\u0026nbsp;\u003c/span\u003e\u003cspan\u003ekeyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count +\u003c/span\u003e\u003cspan\u003e1), so a request of a few tens of megabytes can force a heap allocation several times larger\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebefore any element is read. The pattern is emitted into every generated reader, so it affects\u0026nbsp;\u003c/span\u003e\u003cspan\u003eall Kafka API types with an array field.\u0026nbsp;\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cdiv\u003eRequest parsing happens before any authorization check. On a listener that does not require\u0026nbsp;\u003cspan\u003eauthentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent\u0026nbsp;\u003c/span\u003e\u003cspan\u003erequests that each declare a very large=\u003c/span\u003e\u003c/div\u003e\u003cdiv\u003e\u003cspan\u003earray length and allocate many times their wire size\u0026nbsp;\u003c/span\u003e\u003cspan\u003ein broker heap, crashing the broker with an OutOfMemoryError. The reporter demonstrated three\u0026nbsp;\u003c/span\u003e\u003cspan\u003econcurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification).\u0026nbsp;\u003c/span\u003e\u003cspan\u003eOn listeners that require authentication, the attacker needs valid credentials but no specific ACL,\u0026nbsp;\u003c/span\u003e\u003cspan\u003esince parsing precedes authorization.\u003c/span\u003e\u003cspan\u003e.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eMitigation:\u003c/div\u003e\u003cdiv\u003eUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes\u0026nbsp;\u003cspan\u003eand restricting network access to broker listeners reduces, but does not remove, exposure.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eResolution:\u003c/div\u003e\u003cdiv\u003eFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array\u0026nbsp;\u003cspan\u003epre-allocation at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) and grow it on demand,\u0026nbsp;\u003c/span\u003e\u003cspan\u003eand reject a declared array length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000).\u003c/span\u003e\u003c/div\u003e"
            }
          ],
          "value": "Apache Kafka\u0027s code-generated protocol readers pre-size an array\u0027s collection from the element\u00a0count declared by the sender. That count is checked only against the bytes remaining in the\u00a0request buffer, which assumes about one byte per element; because most elements need several\u00a0bytes, a request can declare far more elements than the buffer holds and still pass. For a\u00a0keyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count +1), so a request of a few tens of megabytes can force a heap allocation several times larger\u00a0before any element is read. The pattern is emitted into every generated reader, so it affects\u00a0all Kafka API types with an array field.\u00a0\n\n\nImpact:\n\nRequest parsing happens before any authorization check. On a listener that does not require\u00a0authentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent\u00a0requests that each declare a very large=\n\narray length and allocate many times their wire size\u00a0in broker heap, crashing the broker with an OutOfMemoryError. The reporter demonstrated three\u00a0concurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification).\u00a0On listeners that require authentication, the attacker needs valid credentials but no specific ACL,\u00a0since parsing precedes authorization..\n\n\nMitigation:\n\nUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes\u00a0and restricting network access to broker listeners reduces, but does not remove, exposure.\n\n\nResolution:\n\nFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array\u00a0pre-allocation at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) and grow it on demand,\u00a0and reject a declared array length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000)."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770 Allocation of resources without limits or throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-789",
              "description": "CWE-789 Memory allocation with excessive size value",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400 Uncontrolled Resource Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:38:08.524Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Kafka: Broker OutOfMemoryError via array allocation amplification in code-generated protocol readers",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-111108",
    "datePublished": "2026-10-28T16:38:08.524Z",
    "dateReserved": "2026-10-15T15:57:59.889Z",
    "dateUpdated": "2026-10-28T20:06:52.812Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:06:51.327Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/11"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka",
          "packageURL": "pkg:maven/org.apache.kafka/kafka",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "4.1.2",
              "status": "affected",
              "version": "3.7.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.2.1",
              "status": "affected",
              "version": "4.2.0",
              "versionType": "semver"
            },
            {
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Dawit Jeong \u003cdev.d4v1d@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Apoorv Mittal \u003capoorvmittal10@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Andrew Schofield \u003caschofield@confluent.io\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003eThe broker-side PushTelemetry API (KIP-714) validates only the compressed size of\u0026nbsp;\u003cspan\u003ea client\u0027s metrics payload against telemetry.max.bytes (default 1 MB) before decompressing\u0026nbsp;\u003c/span\u003e\u003cspan\u003eit. ClientTelemetryUtils.decompress() then decompresses the payload with no limit on the\u0026nbsp;\u003c/span\u003e\u003cspan\u003edecompressed output size, growing a heap buffer until the compressed input is exhausted. A\u0026nbsp;\u003c/span\u003e\u003cspan\u003esmall, highly compressible payload (for example gzip-compressed zeros) can therefore expand\u0026nbsp;\u003c/span\u003e\u003cspan\u003eto hundreds of megabytes of broker heap.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eAn authenticated client can send a PushTelemetry request with a small compressed payload that\u0026nbsp;\u003cspan\u003edecompresses to a very large size, consuming broker heap out of proportion to the request\u0026nbsp;\u003c/span\u003e\u003cspan\u003esize. Repeated or concurrent requests can exhaust the broker heap and cause an\u0026nbsp;\u003c/span\u003e\u003cspan\u003eOutOfMemoryError, degrading or crashing the broker; a client that targets multiple brokers\u0026nbsp;\u003c/span\u003e\u003cspan\u003ecan affect cluster availability. PushTelemetry is available to any authenticated client and is\u0026nbsp;\u003c/span\u003e\u003cspan\u003enot gated by an ACL.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eMitigation:\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eUpgrade to Apache Kafka 4.2.2, 4.3.1, or 4.4.0. On affected versions there is no configuration that fully\u0026nbsp;\u003cspan\u003eprevents the amplification, because telemetry.max.bytes bounds only the compressed size;\u0026nbsp;\u003c/span\u003e\u003cspan\u003elowering telemetry.max.bytes reduces the worst-case decompressed size proportionally and is a\u0026nbsp;\u003c/span\u003e\u003cspan\u003epartial mitigation.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eResolution:\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003e- From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: ClientTelemetryUtils.decompress() enforces a maximum decompressed\u0026nbsp;\u003cspan\u003esize equal to telemetry.max.bytes (default 1 MB). Decompression reads in bounded chunks and\u0026nbsp;\u003c/span\u003e\u003cspan\u003eaborts with a TelemetryTooLargeException once the decompressed total exceeds the limit, so an\u0026nbsp;\u003c/span\u003e\u003cspan\u003eover-large or highly compressible payload is rejected instead of being fully expanded in\u0026nbsp;\u003c/span\u003e\u003cspan\u003eheap. The decompressed size is therefore bounded by default.\u0026nbsp;\u003c/span\u003e\u003c/div\u003e"
            }
          ],
          "value": "The broker-side PushTelemetry API (KIP-714) validates only the compressed size of\u00a0a client\u0027s metrics payload against telemetry.max.bytes (default 1 MB) before decompressing\u00a0it. ClientTelemetryUtils.decompress() then decompresses the payload with no limit on the\u00a0decompressed output size, growing a heap buffer until the compressed input is exhausted. A\u00a0small, highly compressible payload (for example gzip-compressed zeros) can therefore expand\u00a0to hundreds of megabytes of broker heap.\n\n\nImpact:\n\n\nAn authenticated client can send a PushTelemetry request with a small compressed payload that\u00a0decompresses to a very large size, consuming broker heap out of proportion to the request\u00a0size. Repeated or concurrent requests can exhaust the broker heap and cause an\u00a0OutOfMemoryError, degrading or crashing the broker; a client that targets multiple brokers\u00a0can affect cluster availability. PushTelemetry is available to any authenticated client and is\u00a0not gated by an ACL.\n\n\nMitigation:\n\n\nUpgrade to Apache Kafka 4.2.2, 4.3.1, or 4.4.0. On affected versions there is no configuration that fully\u00a0prevents the amplification, because telemetry.max.bytes bounds only the compressed size;\u00a0lowering telemetry.max.bytes reduces the worst-case decompressed size proportionally and is a\u00a0partial mitigation.\n\n\nResolution:\n\n\n- From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: ClientTelemetryUtils.decompress() enforces a maximum decompressed\u00a0size equal to telemetry.max.bytes (default 1 MB). Decompression reads in bounded chunks and\u00a0aborts with a TelemetryTooLargeException once the decompressed total exceeds the limit, so an\u00a0over-large or highly compressible payload is rejected instead of being fully expanded in\u00a0heap. The decompressed size is therefore bounded by default."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "moderate"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-409",
              "description": "CWE-409 Improper handling of highly compressed data (data amplification)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770 Allocation of resources without limits or throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400 Uncontrolled Resource   Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:37:58.482Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Kafka: PushTelemetry (KIP-714) metrics payloads are decompressed without a size limit, allowing a broker out-of-memory denial of service",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-111073",
    "datePublished": "2026-10-28T16:37:58.482Z",
    "dateReserved": "2026-10-15T13:40:49.926Z",
    "dateUpdated": "2026-10-28T20:06:51.327Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka",
          "packageURL": "pkg:maven/org.apache.kafka/kafka",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "4.1.2",
              "status": "affected",
              "version": "4.1.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.2.1",
              "status": "affected",
              "version": "4.2.0",
              "versionType": "semver"
            },
            {
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "San Zhang \u003cfalaxe1642@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Kaixuan Li \u003ckaixuanli0131@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Evan Zhou \u003cezhou@confluent.io\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003eA Kafka broker using SASL/OAUTHBEARER with the default validator\u0026nbsp;\u003cspan\u003e(sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator) selects its implementation from\u0026nbsp;\u003c/span\u003e\u003cspan\u003econfiguration. When sasl.oauthbearer.jwks.endpoint.url is set, the validator verifies the\u0026nbsp;\u003c/span\u003e\u003cspan\u003eJWT signature. When that URL is unset (the default) and no verification key resolver is\u0026nbsp;\u003c/span\u003e\u003cspan\u003esupplied, DefaultJwtValidator silently falls back to ClientJwtValidator, which does not\u0026nbsp;\u003c/span\u003e\u003cspan\u003everify the JWT signature, algorithm, or issuer - and the broker starts with no warning or\u0026nbsp;\u003c/span\u003e\u003cspan\u003eerror. This is the residual of CVE-2026-33557, whose fix restored signature verification\u0026nbsp;\u003c/span\u003e\u003cspan\u003eonly on the path where the JWKS endpoint URL is set.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cdiv\u003eA broker in this state accepts any structurally valid JWT, including \"alg\":\"none\" tokens. An\u0026nbsp;\u003cspan\u003eunauthenticated remote attacker who can reach the listener can forge a token asserting any\u0026nbsp;\u003c/span\u003e\u003cspan\u003eprincipal - including configured superusers - and gain full access to the cluster. Only\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebrokers that enable SASL/OAUTHBEARER validation without a JWKS endpoint URL (and without a\u0026nbsp;\u003c/span\u003e\u003cspan\u003ecustom verification key resolver) are affected; brokers that set the URL verify signatures\u0026nbsp;\u003c/span\u003e\u003cspan\u003eand are not affected. Unlike CVE-2026-110952 (issuer/audience not enforced by default), here\u0026nbsp;\u003c/span\u003e\u003cspan\u003eno signature is verified at all.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eMitigation (all affected versions, no upgrade required):\u003c/div\u003e\u003cdiv\u003e\u003cdiv\u003eSet sasl.oauthbearer.jwks.endpoint.url for every listener/mechanism that uses\u0026nbsp;\u003cspan\u003eOAuthBearerValidatorCallbackHandler, or configure a signature-verifying\u0026nbsp;\u003c/span\u003e\u003cspan\u003esasl.oauthbearer.jwt.validator.class.\u003cbr\u003e\u003c/span\u003e\u003cspan\u003e\u003cbr\u003eResolution:\u003c/span\u003e\u003c/div\u003e\u003cdiv\u003e\u003cspan\u003eFrom Apache Kafka 4.2.2, 4.3.1, and 4.4.0: a broker that would fall back to the\u0026nbsp;\u003c/span\u003e\u003cspan\u003enon-verifying ClientJwtValidator fails to start with a ConfigException instead of running\u0026nbsp;\u003c/span\u003e\u003cspan\u003ewithout signature verification (secure by default).\u0026nbsp;\u003c/span\u003e\u003c/div\u003e\u003c/div\u003e"
            }
          ],
          "value": "A Kafka broker using SASL/OAUTHBEARER with the default validator\u00a0(sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator) selects its implementation from\u00a0configuration. When sasl.oauthbearer.jwks.endpoint.url is set, the validator verifies the\u00a0JWT signature. When that URL is unset (the default) and no verification key resolver is\u00a0supplied, DefaultJwtValidator silently falls back to ClientJwtValidator, which does not\u00a0verify the JWT signature, algorithm, or issuer - and the broker starts with no warning or\u00a0error. This is the residual of CVE-2026-33557, whose fix restored signature verification\u00a0only on the path where the JWKS endpoint URL is set.\n\n\nImpact:\n\nA broker in this state accepts any structurally valid JWT, including \"alg\":\"none\" tokens. An\u00a0unauthenticated remote attacker who can reach the listener can forge a token asserting any\u00a0principal - including configured superusers - and gain full access to the cluster. Only\u00a0brokers that enable SASL/OAUTHBEARER validation without a JWKS endpoint URL (and without a\u00a0custom verification key resolver) are affected; brokers that set the URL verify signatures\u00a0and are not affected. Unlike CVE-2026-110952 (issuer/audience not enforced by default), here\u00a0no signature is verified at all.\n\n\nMitigation (all affected versions, no upgrade required):\n\nSet sasl.oauthbearer.jwks.endpoint.url for every listener/mechanism that uses\u00a0OAuthBearerValidatorCallbackHandler, or configure a signature-verifying\u00a0sasl.oauthbearer.jwt.validator.class.\n\nResolution:\n\nFrom Apache Kafka 4.2.2, 4.3.1, and 4.4.0: a broker that would fall back to the\u00a0non-verifying ClientJwtValidator fails to start with a ConfigException instead of running\u00a0without signature verification (secure by default)."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-345",
              "description": "CWE-345 Insufficient Verification of Data Authenticity and its child",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-347",
              "description": "CWE-347 Improper verification of cryptographic signature",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-1287",
              "description": "CWE-1287 Improper validation of specified type of input",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-636",
              "description": "CWE-636 Failing Open",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:37:45.688Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Kafka: Broker silently skips JWT signature verification for SASL/OAUTHBEARER when the JWKS endpoint URL is not configured",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-110985",
    "datePublished": "2026-10-28T16:37:45.688Z",
    "dateReserved": "2026-10-15T11:31:31.708Z",
    "dateUpdated": "2026-10-28T16:37:45.688Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka",
          "packageURL": "pkg:maven/org.apache.kafka/kafka",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.4.0",
              "status": "affected",
              "version": "3.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Kai Aizen \u003ckai.aizen.dev@gmail.com\u003e, SnailSploit"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Evan Zhou \u003cezhou@confluent.io\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003e\u003c/div\u003e\u003cdiv\u003e\u003cp\u003eA Kafka broker that authenticates clients with SASL/OAUTHBEARER using the bundled JWKS-backed validator always verifies the JWT signature, but two further checks are only performed when explicitly configured:\u003cbr\u003e\u003cbr\u003e- The issuer (iss) claim is verified only when sasl.oauthbearer.expected.issuer is set. When it is unset, a validly-signed token carrying the expected audience is accepted regardless of which issuer minted it.\u003cbr\u003e- An audience (aud) claim is required only when sasl.oauthbearer.expected.audience is set. When it is unset, a validly-signed token that omits the aud claim is accepted. (A token that carries an aud claim is\u003cbr\u003e  still rejected when no expected audience is configured.)\u003cbr\u003e\u003cbr\u003eBoth options default to unset and have been documented as optional (Importance LOW) since KIP-768 (3.1.0).\u003cbr\u003e\u003cbr\u003eImpact:\u003cbr\u003e  The exposure is realizable mainly in deployments whose JWKS endpoint serves signing keys for more than one issuer (a multi-tenant identity provider, an aggregated/shared JWKS, or shared signing keys): a token\u003cbr\u003e  minted for a different issuer, or a token lacking an audience, may be accepted to authenticate \u2014 potentially as a higher-privileged principal. In a single-issuer deployment where the provider controls the iss\u003cbr\u003e  claim and issues audience-scoped tokens, exposure is limited. The signature trust anchor remains enforced in all cases. This is distinct from CVE-2026-33557 (acceptance of unsigned/unvalidated tokens); here the\u003cbr\u003e  signature is validated and only the issuer/audience checks are not enforced by default.\u003cbr\u003e\u003cbr\u003eMitigation (all affected versions, no upgrade required):\u003cbr\u003e  Set both sasl.oauthbearer.expected.issuer (to your provider\u0027s exact iss value) and sasl.oauthbearer.expected.audience (to the audience(s) your brokers expect), per listener. Brokers that set these perform\u003cbr\u003e  exact-match issuer/audience checks and are not affected. Both have been available since 3.1.0.\u003cbr\u003e\u003cbr\u003eResolution:\u003cbr\u003e  - From Apache Kafka 4.4.0: a broker configured with a JWKS endpoint fails to start unless both sasl.oauthbearer.expected.issuer and sasl.oauthbearer.expected.audience are set (secure by default). Deployments that\u003cbr\u003e  intentionally do not restrict the issuer and/or audience may opt out per axis with sasl.oauthbearer.allow.unverified.issuer=true and/or sasl.oauthbearer.allow.unverified.audience=true.\u003c/p\u003e\u003c/div\u003e"
            }
          ],
          "value": "A Kafka broker that authenticates clients with SASL/OAUTHBEARER using the bundled JWKS-backed validator always verifies the JWT signature, but two further checks are only performed when explicitly configured:\n\n- The issuer (iss) claim is verified only when sasl.oauthbearer.expected.issuer is set. When it is unset, a validly-signed token carrying the expected audience is accepted regardless of which issuer minted it.\n- An audience (aud) claim is required only when sasl.oauthbearer.expected.audience is set. When it is unset, a validly-signed token that omits the aud claim is accepted. (A token that carries an aud claim is\n  still rejected when no expected audience is configured.)\n\nBoth options default to unset and have been documented as optional (Importance LOW) since KIP-768 (3.1.0).\n\nImpact:\n  The exposure is realizable mainly in deployments whose JWKS endpoint serves signing keys for more than one issuer (a multi-tenant identity provider, an aggregated/shared JWKS, or shared signing keys): a token\n  minted for a different issuer, or a token lacking an audience, may be accepted to authenticate \u2014 potentially as a higher-privileged principal. In a single-issuer deployment where the provider controls the iss\n  claim and issues audience-scoped tokens, exposure is limited. The signature trust anchor remains enforced in all cases. This is distinct from CVE-2026-33557 (acceptance of unsigned/unvalidated tokens); here the\n  signature is validated and only the issuer/audience checks are not enforced by default.\n\nMitigation (all affected versions, no upgrade required):\n  Set both sasl.oauthbearer.expected.issuer (to your provider\u0027s exact iss value) and sasl.oauthbearer.expected.audience (to the audience(s) your brokers expect), per listener. Brokers that set these perform\n  exact-match issuer/audience checks and are not affected. Both have been available since 3.1.0.\n\nResolution:\n  - From Apache Kafka 4.4.0: a broker configured with a JWKS endpoint fails to start unless both sasl.oauthbearer.expected.issuer and sasl.oauthbearer.expected.audience are set (secure by default). Deployments that\n  intentionally do not restrict the issuer and/or audience may opt out per axis with sasl.oauthbearer.allow.unverified.issuer=true and/or sasl.oauthbearer.allow.unverified.audience=true."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "moderate"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-345",
              "description": "CWE-345 Insufficient Verification of Data Authenticity)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-1188",
              "description": "CWE-1188 Initialization of a resource with an insecure default",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:37:34.723Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Kafka: Broker does not enforce JWT issuer and audience validation for SASL/OAUTHBEARER by default",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-110952",
    "datePublished": "2026-10-28T16:37:34.723Z",
    "dateReserved": "2026-10-15T09:13:40.750Z",
    "dateUpdated": "2026-10-28T16:37:34.723Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:07:03.066Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/7"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka-raft",
          "packageURL": "pkg:maven/org.apache.kafka/kafka-raft",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.2.2",
              "status": "affected",
              "version": "2.8.0",
              "versionType": "semver"
            },
            {
              "lessThan": "4.3.2",
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Mike Read (GitHub: Michael-JRead)"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Kevin Wu \u003ckwu@confluent.io\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Incorrect operator (CWE-480) in the FetchSnapshot RPC handler\u003cbr\u003ein Apache Kafka from 2.8.0 before 4.2.2, and from 4.3.0 before 4.3.2\u003cbr\u003eon all platforms allows an authenticated attacker with\u003cbr\u003eCLUSTER_ACTION privilege to cause a denial of service\u003cbr\u003e(controller process termination) via a crafted\u003cbr\u003eFetchSnapshotRequest with an empty topics array or a topic\u003cbr\u003ewith no partitions.\u003cbr\u003e\u003cbr\u003eUsers are recommended to upgrade to version 4.2.2, 4.3.2, or\u003cbr\u003e4.4.0, which fix this issue. Users on unsupported branches\u003cbr\u003e(4.1.x and earlier) should upgrade to 4.2.2 or later."
            }
          ],
          "value": "Incorrect operator (CWE-480) in the FetchSnapshot RPC handler\nin Apache Kafka from 2.8.0 before 4.2.2, and from 4.3.0 before 4.3.2\non all platforms allows an authenticated attacker with\nCLUSTER_ACTION privilege to cause a denial of service\n(controller process termination) via a crafted\nFetchSnapshotRequest with an empty topics array or a topic\nwith no partitions.\n\nUsers are recommended to upgrade to version 4.2.2, 4.3.2, or\n4.4.0, which fix this issue. Users on unsupported branches\n(4.1.x and earlier) should upgrade to 4.2.2 or later."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "low"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-480",
              "description": "CWE-480 Use of incorrect operator",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:37:19.893Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/kafka/pull/23185"
        },
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Kafka: Incorrect boolean operator in FetchSnapshot RPC handler allows authenticated network clients to crash the KRaft controller via a malformed request.",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-83525",
    "datePublished": "2026-10-28T16:37:19.893Z",
    "dateReserved": "2026-08-31T16:02:13.499Z",
    "dateUpdated": "2026-10-28T20:07:03.066Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-27T00:17:16.330Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/26/20"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://pypi.python.org",
          "defaultStatus": "unaffected",
          "packageName": "apache-airflow-providers-ssh",
          "packageURL": "pkg:pypi/apache-airflow-providers-ssh",
          "product": "Apache Airflow SSH provider",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "7.0.1",
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Enrico Maria Carmona, Serasoft S.r.l."
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Kaxil Naik"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "In apache-airflow-providers-ssh before 7.0.1, SSHRemoteJobOperator quoted the values of its templated `environment` parameter only once, although they are placed inside an already-quoted wrapper script, so shell syntax such as `$(...)` in a value was executed on the remote SSH host. In a Dag that passes trigger-time input such as `params` or `dag_run.conf` into `environment`, a user who can trigger that Dag but cannot author Dags could run arbitrary commands on the remote host as the SSH connection\u0026#x27;s user. Users are advised to upgrade apache-airflow-providers-ssh to 7.0.1 or later."
            }
          ],
          "value": "In apache-airflow-providers-ssh before 7.0.1, SSHRemoteJobOperator quoted the values of its templated `environment` parameter only once, although they are placed inside an already-quoted wrapper script, so shell syntax such as `$(...)` in a value was executed on the remote SSH host. In a Dag that passes trigger-time input such as `params` or `dag_run.conf` into `environment`, a user who can trigger that Dag but cannot author Dags could run arbitrary commands on the remote host as the SSH connection\u0027s user. Users are advised to upgrade apache-airflow-providers-ssh to 7.0.1 or later."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "low"
            },
            "type": "Textual description of severity"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-78",
              "description": "CWE-78: Improper Neutralization of Special Elements used in an OS Command (\u0027OS Command Injection\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-26T23:29:30.363Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/airflow/pull/74810"
        },
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/k159xrq1tbgmkvl24j63g12qh0mczk79"
        },
        {
          "tags": [
            "release-notes"
          ],
          "url": "https://airflow.apache.org/docs/apache-airflow-providers-ssh/7.0.1/changelog.html"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Airflow SSH provider: SSHRemoteJobOperator: `environment` values are executed as shell on the remote host",
      "x_generator": {
        "engine": "airflow-s/generate_cve_json.py"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-111422",
    "datePublished": "2026-10-26T23:29:30.363Z",
    "dateReserved": "2026-10-16T02:30:23.102Z",
    "dateUpdated": "2026-10-27T00:17:16.330Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-26T15:34:11.951Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/23/21"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.vysper:vysper",
          "packageURL": "pkg:maven/org.apache.vysper/vysper",
          "product": "Apache Vysper",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "*",
              "status": "affected",
              "version": "0",
              "versionType": "maven"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Ho1aAs \u003cxxy010605@gmail.com\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003e**UNSUPPORTED WHEN ASSIGNED**\u0026nbsp;\u0026nbsp;Authorization bypass in Apache Vysper, all versions.\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003cdiv\u003eApache Vysper is an XMPP (Jabber) server library. Its XEP-0077 (In-Band Registration) implementation is missing an authentication check, allowing any authenticated user to compromise other accounts.\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003cspan\u003eAs this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative.\u003c/span\u003e"
            }
          ],
          "value": "**UNSUPPORTED WHEN ASSIGNED**\u00a0\u00a0Authorization bypass in Apache Vysper, all versions.\n\n\n\n\nApache Vysper is an XMPP (Jabber) server library. Its XEP-0077 (In-Band Registration) implementation is missing an authentication check, allowing any authenticated user to compromise other accounts.\n\n\n\n\nAs this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-639",
              "description": "CWE-639 Authorization bypass through User-Controlled key",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-26T15:01:40.644Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "url": "https://mina.apache.org/vysper-project/"
        },
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread.html/979n9lzg10vc7tdrrlgy4lh5yrsw8wsj"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "tags": [
        "unsupported-when-assigned"
      ],
      "title": "Apache Vysper: Authorization bypass",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-115748",
    "datePublished": "2026-10-26T15:01:40.644Z",
    "dateReserved": "2026-10-23T12:48:46.471Z",
    "dateUpdated": "2026-10-26T15:34:11.951Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-26T15:01:29.549Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/23/20"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.vysper:vysper",
          "packageURL": "pkg:maven/org.apache.vysper/vysper",
          "product": "Apache Vysper",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "*",
              "status": "affected",
              "version": "0",
              "versionType": "maven"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Gjoko Krstic (Zero Science Lab)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003e**UNSUPPORTED WHEN ASSIGNED**\u0026nbsp;\u0026nbsp;Unbounded allocation in XML parsing in Apache Vysper; all versions, may lead to an out of memory condition.\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e\u003c/div\u003e\u003cdiv\u003eThis issue affects all versions of Apache Vysper.\u0026nbsp;\u003cspan\u003eApache Vysper is an XMPP (Jabber) server library.\u003c/span\u003e\u003c/div\u003e\u003cdiv\u003e\u003cspan\u003e\u003cbr\u003e\u003c/span\u003e\u003c/div\u003e\u003cdiv\u003e\u003cspan\u003eAs this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative.\u003c/span\u003e\u003c/div\u003e"
            }
          ],
          "value": "**UNSUPPORTED WHEN ASSIGNED**\u00a0\u00a0Unbounded allocation in XML parsing in Apache Vysper; all versions, may lead to an out of memory condition.\n\n\n\n\nThis issue affects all versions of Apache Vysper.\u00a0Apache Vysper is an XMPP (Jabber) server library.\n\n\n\n\nAs this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "moderate"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "description": "cwe-770",
              "lang": "en"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-26T15:01:18.445Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "url": "https://mina.apache.org/vysper-project/"
        },
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread.html/d0bx15hjcs69gktk9tt25vgvk121c9vm"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "tags": [
        "unsupported-when-assigned"
      ],
      "title": "Apache Vysper: Unbounded allocation",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-115721",
    "datePublished": "2026-10-26T15:01:18.445Z",
    "dateReserved": "2026-10-23T11:19:39.107Z",
    "dateUpdated": "2026-10-26T15:01:29.549Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-90885",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-26T15:29:02.992870Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-26T15:35:49.414Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.camel:camel-saxon",
          "packageURL": "pkg:maven/org.apache.camel/camel-saxon",
          "product": "Apache Camel",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.18.5",
              "status": "affected",
              "version": "4.0.0",
              "versionType": "maven"
            },
            {
              "lessThan": "4.22.2",
              "status": "affected",
              "version": "4.19.0",
              "versionType": "maven"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Leon Zlobecki"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Andrea Cosentino"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eImproper Restriction of XML External Entity Reference vulnerability in Apache Camel Saxon component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2.\u003c/p\u003e\u003cp\u003eXQueryBuilder in camel-saxon, which evaluates expressions for the xquery language and the xquery component, built its default Saxon Configuration with parse options that set only a whitespace stripping rule, leaving the XML parser at its defaults, under which a DOCTYPE declaration is accepted and external entities are resolved. A message body of type String or byte[], or any body read as an InputStream, is first turned into a javax.xml.transform.Source by Camel\u0027s own XML type converters, which configure the parser against external entities, so those bodies were not affected. A body that was already a Source, however, was handed to Saxon unchanged, and when that Source still had to be parsed, as a stream-based Source does, Saxon parsed it with that Configuration, bypassing the protection applied to the other body types. Such a body arises, for example, after a route converts the message with convertBodyTo(Source.class), or when a component or processor earlier in the route sets the body to a stream-based Source. A DOCTYPE with an external subset, or an external entity, declared in that body was therefore resolved and expanded into the document the expression was evaluated against. An external sender whose XML reaches an XQuery expression or an xquery endpoint in that form could read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since the default Configuration is used whenever the route does not supply one of its own.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier, as well as the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not evaluate XQuery over a message body that is already a javax.xml.transform.Source when that body carries XML from an untrusted sender, or set the configuration option of the xquery endpoint or language to a Saxon Configuration whose parse options refuse a DOCTYPE declaration and disable external entities and external DTD loading, which is what the fixed releases now apply by default.\u003c/p\u003e"
            }
          ],
          "value": "Improper Restriction of XML External Entity Reference vulnerability in Apache Camel Saxon component.\n\n\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2.\n\n\n\nXQueryBuilder in camel-saxon, which evaluates expressions for the xquery language and the xquery component, built its default Saxon Configuration with parse options that set only a whitespace stripping rule, leaving the XML parser at its defaults, under which a DOCTYPE declaration is accepted and external entities are resolved. A message body of type String or byte[], or any body read as an InputStream, is first turned into a javax.xml.transform.Source by Camel\u0027s own XML type converters, which configure the parser against external entities, so those bodies were not affected. A body that was already a Source, however, was handed to Saxon unchanged, and when that Source still had to be parsed, as a stream-based Source does, Saxon parsed it with that Configuration, bypassing the protection applied to the other body types. Such a body arises, for example, after a route converts the message with convertBodyTo(Source.class), or when a component or processor earlier in the route sets the body to a stream-based Source. A DOCTYPE with an external subset, or an external entity, declared in that body was therefore resolved and expanded into the document the expression was evaluated against. An external sender whose XML reaches an XQuery expression or an xquery endpoint in that form could read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since the default Configuration is used whenever the route does not supply one of its own.\n\n\n\nUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier, as well as the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not evaluate XQuery over a message body that is already a javax.xml.transform.Source when that body carries XML from an untrusted sender, or set the configuration option of the xquery endpoint or language to a Saxon Configuration whose parse options refuse a DOCTYPE declaration and disable external entities and external DTD loading, which is what the fixed releases now apply by default."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-611",
              "description": "CWE-611 Improper Restriction of XML External Entity Reference",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-26T14:47:03.155Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "name": "Apache Camel Security Advisory - CVE-2026-90885",
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-90885.html"
        },
        {
          "name": "CAMEL-24691",
          "tags": [
            "issue-tracking"
          ],
          "url": "https://issues.apache.org/jira/browse/CAMEL-24691"
        },
        {
          "name": "Fix on main, released in 4.23.0 (commit 9c23b6868bb92cb19c2b5a7ee624421d760cda8f)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/26344"
        },
        {
          "name": "Backport to camel-4.22.x for 4.22.2 (commit 0d0ed8bbe38fdae6e778c4f719e80c2e2d0e51b2)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/26728"
        },
        {
          "name": "Backport to camel-4.18.x, released in 4.18.5 (commit ed513f3a7117c3343a9e31e22e5627498f2fcdb6)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/26730"
        },
        {
          "name": "CVE-2026-85250, the camel-xpath documentType=InputSource XXE, distinct from this issue",
          "tags": [
            "related"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-85250.html"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. XQueryBuilder now builds its default Saxon Configuration with parse options that refuse a DOCTYPE declaration and disable external general entities, external parameter entities and external DTD loading, aligning a body that is already a javax.xml.transform.Source with the hardened parser configuration that Camel\u0027s XmlConverter applies to String, byte[] and InputStream bodies. A body that reaches XQuery as an already-built Source and carries a DOCTYPE declaration is now rejected with a parse error. A Configuration supplied through the configuration option of the xquery endpoint or language is used as is and is not modified. The 4.14.x releases stream and earlier, as well as the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release.\u003c/p\u003e"
            }
          ],
          "value": "Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. XQueryBuilder now builds its default Saxon Configuration with parse options that refuse a DOCTYPE declaration and disable external general entities, external parameter entities and external DTD loading, aligning a body that is already a javax.xml.transform.Source with the hardened parser configuration that Camel\u0027s XmlConverter applies to String, byte[] and InputStream bodies. A body that reaches XQuery as an already-built Source and carries a DOCTYPE declaration is now rejected with a parse error. A Configuration supplied through the configuration option of the xquery endpoint or language is used as is and is not modified. The 4.14.x releases stream and earlier, as well as the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Camel: Camel-Saxon XML External Entity Processing - XQueryBuilder Parsed a Message Body That Was Already a javax.xml.transform.Source With Saxon\u0027s Default Parser Settings, so an External Entity Declared in That Body Was Resolved",
      "workarounds": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eFor deployments that cannot upgrade immediately, do not evaluate XQuery over a message body that is already a javax.xml.transform.Source when that body carries XML from an untrusted sender. Alternatively, set the configuration option of the xquery endpoint or language to a Saxon Configuration whose parse options refuse a DOCTYPE declaration and disable external entities and external DTD loading, which is what the fixed releases now apply by default.\u003c/p\u003e"
            }
          ],
          "value": "For deployments that cannot upgrade immediately, do not evaluate XQuery over a message body that is already a javax.xml.transform.Source when that body carries XML from an untrusted sender. Alternatively, set the configuration option of the xquery endpoint or language to a Saxon Configuration whose parse options refuse a DOCTYPE declaration and disable external entities and external DTD loading, which is what the fixed releases now apply by default."
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-90885",
    "datePublished": "2026-10-26T14:47:03.155Z",
    "dateReserved": "2026-09-14T08:19:08.798Z",
    "dateUpdated": "2026-10-26T15:35:49.414Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-94386",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-26T15:29:39.655802Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-26T15:35:49.712Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.camel:camel-oauth",
          "packageURL": "pkg:maven/org.apache.camel/camel-oauth",
          "product": "Apache Camel",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.22.2",
              "status": "affected",
              "version": "4.19.0",
              "versionType": "maven"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Andrea Cosentino from Apache Software Foundation"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Andrea Cosentino from Apache Software Foundation"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eUse of Cache Containing Sensitive Information vulnerability in Apache Camel Oauth component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.19.0 before 4.22.2.\u003c/p\u003e\u003cp\u003eOAuthClientCredentialsTokenResolver obtains OAuth 2.0 bearer tokens through the client credentials grant on behalf of the components that authenticate their outbound calls with a named OAuth profile, such as camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat and the IBM watsonx components, and of applications that call the OAuthClientAuthenticationFactory SPI directly. It kept the tokens it obtained in a static cache shared by every resolver instance and every CamelContext in the JVM, and keyed that cache on the token endpoint and the client ID only, although the token request also carries the client secret and the requested scope. Two profiles that share a token endpoint and a client ID but request different scopes, or authenticate with different client secrets, therefore mapped to the same cache entry: the profile that resolved a token first populated the entry, and the other profile was then handed that token, with no token request made under its own configuration, for as long as the token remained valid. Token caching is enabled by default, and pointing several profiles at one identity provider client is an ordinary use of the profile support rather than an opt-in to an insecure setting. The outcome is an outbound request that carries a token issued for another profile\u0027s scope, which can grant broader authority than the calling profile was configured for, or reach a service the token was not issued for; with identity providers that derive a token\u0027s audience from the requested scope, a different scope can mean a token for a different service altogether. A profile configured with a different client secret was likewise served the token obtained with the other secret, without authenticating with its own. The profiles are configured by the deployment, which is trusted, so no untrusted input reaches the cache: the party that gains is the service that receives a token it was not meant to receive, which, if hostile or compromised, can replay that token within its scope. Reaching the issue requires a deployment that defines more than one profile sharing a token endpoint and client ID while differing in scope or client secret.\u003c/p\u003e\u003cdiv\u003eUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. The 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, disable token caching on every OAuth profile that shares a token endpoint and client ID with another profile, by setting camel.oauth.NAME.cache-tokens=false for a named profile or camel.oauth.cache-tokens=false for the default one, so that each resolution requests a token with that profile\u2019s own scope and client secret, at the cost of a token request on every resolution. Alternatively, register a separate client at the identity provider for each profile that needs a different scope or client secret, so that no two such profiles share a client ID.\u003c/div\u003e"
            }
          ],
          "value": "Use of Cache Containing Sensitive Information vulnerability in Apache Camel Oauth component.\n\n\n\nThis issue affects Apache Camel: from 4.19.0 before 4.22.2.\n\n\n\nOAuthClientCredentialsTokenResolver obtains OAuth 2.0 bearer tokens through the client credentials grant on behalf of the components that authenticate their outbound calls with a named OAuth profile, such as camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat and the IBM watsonx components, and of applications that call the OAuthClientAuthenticationFactory SPI directly. It kept the tokens it obtained in a static cache shared by every resolver instance and every CamelContext in the JVM, and keyed that cache on the token endpoint and the client ID only, although the token request also carries the client secret and the requested scope. Two profiles that share a token endpoint and a client ID but request different scopes, or authenticate with different client secrets, therefore mapped to the same cache entry: the profile that resolved a token first populated the entry, and the other profile was then handed that token, with no token request made under its own configuration, for as long as the token remained valid. Token caching is enabled by default, and pointing several profiles at one identity provider client is an ordinary use of the profile support rather than an opt-in to an insecure setting. The outcome is an outbound request that carries a token issued for another profile\u0027s scope, which can grant broader authority than the calling profile was configured for, or reach a service the token was not issued for; with identity providers that derive a token\u0027s audience from the requested scope, a different scope can mean a token for a different service altogether. A profile configured with a different client secret was likewise served the token obtained with the other secret, without authenticating with its own. The profiles are configured by the deployment, which is trusted, so no untrusted input reaches the cache: the party that gains is the service that receives a token it was not meant to receive, which, if hostile or compromised, can replay that token within its scope. Reaching the issue requires a deployment that defines more than one profile sharing a token endpoint and client ID while differing in scope or client secret.\n\nUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. The 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, disable token caching on every OAuth profile that shares a token endpoint and client ID with another profile, by setting camel.oauth.NAME.cache-tokens=false for a named profile or camel.oauth.cache-tokens=false for the default one, so that each resolution requests a token with that profile\u2019s own scope and client secret, at the cost of a token request on every resolution. Alternatively, register a separate client at the identity provider for each profile that needs a different scope or client secret, so that no two such profiles share a client ID."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 4.8,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-524",
              "description": "CWE-524 Use of Cache Containing Sensitive Information",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-26T14:46:11.551Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "name": "Apache Camel Security Advisory - CVE-2026-94386",
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-94386.html"
        },
        {
          "name": "CAMEL-24872",
          "tags": [
            "issue-tracking"
          ],
          "url": "https://issues.apache.org/jira/browse/CAMEL-24872"
        },
        {
          "name": "Fix on main, released in 4.23.0 (commit 5e896b2df24bf80ad4a78be1f8a708f71d91aa16)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/26681"
        },
        {
          "name": "Backport to camel-4.22.x for 4.22.2 (commit b2d9957bcbcf87bd5e59992fec45231876c645ed)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/27779"
        },
        {
          "name": "CVE-2026-85317, the same class of defect in the camel-http OAuth2 client token cache",
          "tags": [
            "related"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-85317.html"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x stream should upgrade to 4.22.2. The 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. The token cache is now keyed on every input of the token request: the token endpoint, the client ID, a SHA-256 fingerprint of the client secret, so that the raw secret is not kept in the cache, and the requested scope, so profiles that differ in credentials or scope obtain separate tokens while equivalent profiles still share one. The 4.18.x line and earlier never carried the client credentials token resolver and are not affected.\u003c/p\u003e"
            }
          ],
          "value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x stream should upgrade to 4.22.2. The 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. The token cache is now keyed on every input of the token request: the token endpoint, the client ID, a SHA-256 fingerprint of the client secret, so that the raw secret is not kept in the cache, and the requested scope, so profiles that differ in credentials or scope obtain separate tokens while equivalent profiles still share one. The 4.18.x line and earlier never carried the client credentials token resolver and are not affected."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Camel: Camel-OAuth Cross-Scope Token Reuse via an Under-Keyed JVM-Global Client Credentials Token Cache",
      "workarounds": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eDisable token caching on every OAuth profile that shares a token endpoint and client ID with another profile, by setting camel.oauth.NAME.cache-tokens=false for a named profile or camel.oauth.cache-tokens=false for the default one, so that each resolution requests a token with that profile\u0027s own scope and client secret, at the cost of a token request on every resolution. Alternatively, register a separate client at the identity provider for each profile that needs a different scope or client secret, so that no two such profiles share a client ID.\u003c/p\u003e"
            }
          ],
          "value": "Disable token caching on every OAuth profile that shares a token endpoint and client ID with another profile, by setting camel.oauth.NAME.cache-tokens=false for a named profile or camel.oauth.cache-tokens=false for the default one, so that each resolution requests a token with that profile\u0027s own scope and client secret, at the cost of a token request on every resolution. Alternatively, register a separate client at the identity provider for each profile that needs a different scope or client secret, so that no two such profiles share a client ID."
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-94386",
    "datePublished": "2026-10-26T14:46:11.551Z",
    "dateReserved": "2026-09-21T13:06:48.343Z",
    "dateUpdated": "2026-10-26T15:35:49.712Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.sis:sis-metadata",
          "packageURL": "pkg:maven/org.apache.sis/sis-metadata",
          "product": "Apache SIS",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "1.6.0",
              "status": "affected",
              "version": "0.7",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "n0mi1k Security"
        },
        {
          "lang": "en",
          "type": "finder",
          "value": "Ho1aAs \u003cxxy010605@gmail.com\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eThis issue affects Apache SIS from version 0.7 through 1.6 inclusive. When a data file contains links to other files, Apache SIS opened these files regardless their paths. It was possible, for example, to specify a path to a local file. However, these files were always expected to be in some specific formats and the reading stops at the first parsing error, which makes this vulnerability unlikely to leak sensitive information. The impacted formats are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eGeographic Markup Language (GML) with `xlink:href` attributes for other files in GML format.\u003c/li\u003e\u003cli\u003eWell Known Text (WKT) with parameter elements for datum shift grids in NADCON, NTv2 or RGF93 formats.\u003c/li\u003e\u003cli\u003eLandsat scene with paths to files for each band in the GeoTIFF format.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eUsers are recommended to upgrade to version 1.7, which fixes the issue by restricting the paths to the same directory as the file containing the references to other files, or to a predetermined directory for datum shift grids.\u003c/p\u003e"
            }
          ],
          "value": "This issue affects Apache SIS from version 0.7 through 1.6 inclusive. When a data file contains links to other files, Apache SIS opened these files regardless their paths. It was possible, for example, to specify a path to a local file. However, these files were always expected to be in some specific formats and the reading stops at the first parsing error, which makes this vulnerability unlikely to leak sensitive information. The impacted formats are:\n\n  *  Geographic Markup Language (GML) with `xlink:href` attributes for other files in GML format.\n  *  Well Known Text (WKT) with parameter elements for datum shift grids in NADCON, NTv2 or RGF93 formats.\n  *  Landsat scene with paths to files for each band in the GeoTIFF format.\n\n\n\n\nUsers are recommended to upgrade to version 1.7, which fixes the issue by restricting the paths to the same directory as the file containing the references to other files, or to a predetermined directory for datum shift grids."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "low"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-22",
              "description": "CWE-22: Improper Limitation of a Pathname to a Restricted Directory",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-26T14:40:39.690Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread.html/j43dd1okv97o0qygbox381l01rsszsln"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache SIS: CWE-22: improper limitation of paths to GML, GeoTIFF, NADCON or NTv2 files",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-110748",
    "datePublished": "2026-10-26T14:40:39.690Z",
    "dateReserved": "2026-10-14T16:54:39.253Z",
    "dateUpdated": "2026-10-26T14:40:39.690Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "NETWORK",
              "availabilityImpact": "LOW",
              "baseScore": 5.4,
              "baseSeverity": "MEDIUM",
              "confidentialityImpact": "LOW",
              "integrityImpact": "NONE",
              "privilegesRequired": "LOW",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-110733",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-26T16:28:56.170596Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-26T16:29:01.382Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.sis.storage:sis-sqlstore",
          "packageURL": "pkg:maven/org.apache.sis.storage/sis-sqlstore",
          "product": "Apache SIS",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "1.6.0",
              "status": "affected",
              "version": "1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Ho1aAs \u003cxxy010605@gmail.com\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eVulnerability in the SQL storage module of Apache SIS. When sorting a stream of features, the clause is copied after \u003ccode\u003eORDER BY\u003c/code\u003e without quoting the identifier character. A crafter sort clause could inject SQL in the query.\u003c/p\u003e\n\n\u003cp\u003eThis issue affects the \u003ccode\u003esql-storage\u003c/code\u003e module of Apache SIS from version 1.0 through 1.6 inclusive. Other modules such as \u003ccode\u003esis-referencing\u003c/code\u003e are not impacted. Users are recommended to upgrade to version 1.7, which fixes the issue.\u003c/p\u003e"
            }
          ],
          "value": "Vulnerability in the SQL storage module of Apache SIS. When sorting a stream of features, the clause is copied after ORDER BY without quoting the identifier character. A crafter sort clause could inject SQL in the query.\n\n\n\n\n\nThis issue affects the sql-storage module of Apache SIS from version 1.0 through 1.6 inclusive. Other modules such as sis-referencing are not impacted. Users are recommended to upgrade to version 1.7, which fixes the issue."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "low"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-89",
              "description": "CWE-89: Improper Neutralization of Special Elements used in an SQL Command",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-26T14:15:55.097Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread.html/j43dd1okv97o0qygbox381l01rsszsln"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache SIS: SQL injection via unvalidated ORDER BY sort expression in the SQL feature store",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-110733",
    "datePublished": "2026-10-26T14:15:55.097Z",
    "dateReserved": "2026-10-14T15:35:24.535Z",
    "dateUpdated": "2026-10-26T16:29:01.382Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-95628",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-26T14:12:52.898968Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-26T14:35:19.442Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.camel:camel-docling",
          "packageURL": "pkg:maven/org.apache.camel/camel-docling",
          "product": "Apache Camel",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.18.5",
              "status": "affected",
              "version": "4.15.0",
              "versionType": "maven"
            },
            {
              "lessThan": "4.22.2",
              "status": "affected",
              "version": "4.19.0",
              "versionType": "maven"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Zhixi \"Jace\" Sun, independent security researcher"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Andrea Cosentino"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eImproper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in Apache Camel Docling component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2.\u003c/p\u003e\u003cp\u003eDoclingProducer builds the command line of the external docling tool and appends to it the custom arguments supplied in the CamelDoclingCustomArguments header, a list of strings whose flags the fix for CVE-2026-40047 restricted to an allowlist. That fix also introduced validatePathSafety to keep path-like argument values inside the intended directory, but the method only looked for relative traversal: it rejected a value containing a traversal sequence such as ../ and a value whose normalized form still held a .. element. It never checked whether a value was an absolute path, and an absolute path without traversal segments contains neither, so it passed unchanged. Every path-like value went through this check, whether it was a separate list element following its flag or was attached to the flag after an equals sign, so an absolute path was accepted in either form, for example as the directory given to the allowlisted --artifacts-path flag, which tells docling where to find its model artifacts. Such a value reached the docling command line as given, so a party able to choose the custom arguments could point the docling process at any directory the Camel process can access, outside the working directory that the check was meant to keep path values in, which is the outcome the CVE-2026-40047 fix set out to prevent. Only the CLI mode, which is the default, passes custom arguments to docling. The header belongs to the Camel header namespace, which consumers applying Camel\u0027s default header filtering, such as the JMS and Kafka consumers, remove from incoming messages, so the issue is reached where a route forwards externally influenced values into the header or where a consumer maps incoming headers without that filtering.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not build the CamelDoclingCustomArguments header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the custom arguments.\u003c/p\u003e"
            }
          ],
          "value": "Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in Apache Camel Docling component.\n\n\n\nThis issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2.\n\n\n\nDoclingProducer builds the command line of the external docling tool and appends to it the custom arguments supplied in the CamelDoclingCustomArguments header, a list of strings whose flags the fix for CVE-2026-40047 restricted to an allowlist. That fix also introduced validatePathSafety to keep path-like argument values inside the intended directory, but the method only looked for relative traversal: it rejected a value containing a traversal sequence such as ../ and a value whose normalized form still held a .. element. It never checked whether a value was an absolute path, and an absolute path without traversal segments contains neither, so it passed unchanged. Every path-like value went through this check, whether it was a separate list element following its flag or was attached to the flag after an equals sign, so an absolute path was accepted in either form, for example as the directory given to the allowlisted --artifacts-path flag, which tells docling where to find its model artifacts. Such a value reached the docling command line as given, so a party able to choose the custom arguments could point the docling process at any directory the Camel process can access, outside the working directory that the check was meant to keep path values in, which is the outcome the CVE-2026-40047 fix set out to prevent. Only the CLI mode, which is the default, passes custom arguments to docling. The header belongs to the Camel header namespace, which consumers applying Camel\u0027s default header filtering, such as the JMS and Kafka consumers, remove from incoming messages, so the issue is reached where a route forwards externally influenced values into the header or where a consumer maps incoming headers without that filtering.\n\n\n\nUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not build the CamelDoclingCustomArguments header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the custom arguments."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "LOW",
            "baseScore": 5.4,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "LOW",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-22",
              "description": "CWE-22 Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-26T08:48:48.344Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "name": "Apache Camel Security Advisory - CVE-2026-95628",
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-95628.html"
        },
        {
          "name": "CAMEL-24893",
          "tags": [
            "issue-tracking"
          ],
          "url": "https://issues.apache.org/jira/browse/CAMEL-24893"
        },
        {
          "name": "Fix on main, released in 4.23.0 (commit fd3bc8e73613f3aec691044ed07869ef79c1bf2f)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/26738"
        },
        {
          "name": "Backport to camel-4.22.x for 4.22.2 (commit e9233c37c6127221157ac0901fb74250c5d24e98)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/26743"
        },
        {
          "name": "Backport to camel-4.18.x, released in 4.18.5 (commit 59d30af17064320073e17cfb516be60d096bb979)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/26744"
        },
        {
          "name": "CVE-2026-40047, the custom CLI argument validation issue whose fix this completes",
          "tags": [
            "related"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-40047.html"
        },
        {
          "name": "CVE-2026-78163, a distinct input-source issue in the same producer",
          "tags": [
            "related"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-78163.html"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x stream should upgrade to 4.22.2 and users on the 4.18.x stream should upgrade to 4.18.5. The validatePathSafety helper now also rejects a path-like custom-argument value that is an absolute path, whether it is given as a separate list element or attached to its flag, so every path-valued flag on the allowlist is covered; a relative value without traversal segments is still accepted. The 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release.\u003c/p\u003e"
            }
          ],
          "value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x stream should upgrade to 4.22.2 and users on the 4.18.x stream should upgrade to 4.18.5. The validatePathSafety helper now also rejects a path-like custom-argument value that is an absolute path, whether it is given as a separate list element or attached to its flag, so every path-valued flag on the allowlist is covered; a relative value without traversal segments is still accepted. The 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Camel: Camel-Docling Custom CLI Argument Path Validation Does Not Reject Absolute Paths (Incomplete Fix of CVE-2026-40047)",
      "workarounds": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eDo not build the CamelDoclingCustomArguments header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the custom arguments.\u003c/p\u003e"
            }
          ],
          "value": "Do not build the CamelDoclingCustomArguments header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the custom arguments."
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-95628",
    "datePublished": "2026-10-26T08:48:48.344Z",
    "dateReserved": "2026-09-22T11:01:34.300Z",
    "dateUpdated": "2026-10-26T14:35:19.442Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.camel:camel-docling",
          "packageURL": "pkg:maven/org.apache.camel/camel-docling",
          "product": "Apache Camel",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.18.5",
              "status": "affected",
              "version": "4.15.0",
              "versionType": "maven"
            },
            {
              "lessThan": "4.22.2",
              "status": "affected",
              "version": "4.19.0",
              "versionType": "maven"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Zhixi \"Jace\" Sun, independent security researcher"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Andrea Cosentino"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eImproper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in Apache Camel Docling component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2.\u003c/p\u003e\u003cp\u003eDoclingProducer runs the external docling tool in CLI mode, the default, and tells it where to write the converted document through the --output flag. When the CamelDoclingOutputFilePath header was set, addOutputDirectoryArguments handed its value to that flag verbatim: the value was not normalized, an absolute path or a path containing .. segments was accepted as given, and no endpoint option could confine it to a directory. The custom-argument validation added by the fix for CVE-2026-40047 refuses the --output and -o flags in the CamelDoclingCustomArguments header and tells callers to choose the output directory with this header instead, so the one value that decides where docling writes reached the command line without any of the checks applied to custom arguments. Docling writes the conversion result, as Markdown, HTML, JSON or text, into that directory, naming the file after the input file, and the producer afterwards removes only its own temporary directory, so the file is left in place. A party able to set the header could therefore have conversion output created in any directory the Camel process can write to. The content of such a file is the conversion of the document carried by the message, so it is shaped by whoever supplies that document without being written byte for byte, and when the document content arrives in the message body the producer stores it under a random temporary name, which the output file then carries. The header belongs to the Camel header namespace, which consumers applying Camel\u0027s default header filtering, such as the JMS and Kafka consumers, remove from incoming messages, so the issue is reached where a route forwards externally influenced values into the header or where a consumer maps incoming headers without that filtering. The docling-serve mode does not use the header.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The fix adds an outputBaseDirectory endpoint option that is unset by default, so after upgrading, set it on every docling endpoint whose CamelDoclingOutputFilePath header can carry a value influenced from outside the deployment; without it the header is normalized but can still name any directory. The 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not build the CamelDoclingOutputFilePath header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the output directory.\u003c/p\u003e"
            }
          ],
          "value": "Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in Apache Camel Docling component.\n\n\n\nThis issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2.\n\n\n\nDoclingProducer runs the external docling tool in CLI mode, the default, and tells it where to write the converted document through the --output flag. When the CamelDoclingOutputFilePath header was set, addOutputDirectoryArguments handed its value to that flag verbatim: the value was not normalized, an absolute path or a path containing .. segments was accepted as given, and no endpoint option could confine it to a directory. The custom-argument validation added by the fix for CVE-2026-40047 refuses the --output and -o flags in the CamelDoclingCustomArguments header and tells callers to choose the output directory with this header instead, so the one value that decides where docling writes reached the command line without any of the checks applied to custom arguments. Docling writes the conversion result, as Markdown, HTML, JSON or text, into that directory, naming the file after the input file, and the producer afterwards removes only its own temporary directory, so the file is left in place. A party able to set the header could therefore have conversion output created in any directory the Camel process can write to. The content of such a file is the conversion of the document carried by the message, so it is shaped by whoever supplies that document without being written byte for byte, and when the document content arrives in the message body the producer stores it under a random temporary name, which the output file then carries. The header belongs to the Camel header namespace, which consumers applying Camel\u0027s default header filtering, such as the JMS and Kafka consumers, remove from incoming messages, so the issue is reached where a route forwards externally influenced values into the header or where a consumer maps incoming headers without that filtering. The docling-serve mode does not use the header.\n\n\n\nUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The fix adds an outputBaseDirectory endpoint option that is unset by default, so after upgrading, set it on every docling endpoint whose CamelDoclingOutputFilePath header can carry a value influenced from outside the deployment; without it the header is normalized but can still name any directory. The 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not build the CamelDoclingOutputFilePath header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the output directory."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "LOW",
            "baseScore": 5.4,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "LOW",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-22",
              "description": "CWE-22 Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-26T08:44:22.849Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "name": "Apache Camel Security Advisory - CVE-2026-95629",
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-95629.html"
        },
        {
          "name": "CAMEL-24894",
          "tags": [
            "issue-tracking"
          ],
          "url": "https://issues.apache.org/jira/browse/CAMEL-24894"
        },
        {
          "name": "Fix on main, released in 4.23.0 (commit 48485d408f190c46ef408ba4ba75e45b4e8ffb04)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/26737"
        },
        {
          "name": "Backport to camel-4.22.x for 4.22.2 (commit 4f8eb14999163523af6b77d08bfd1b9e79ee49c0)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/27365"
        },
        {
          "name": "Backport to camel-4.18.x, released in 4.18.5 (commit 54552df4b9e512cb2025fad22b88429ef0e0169c)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/27362"
        },
        {
          "name": "CVE-2026-40047, whose custom-argument validation directs callers to the header described here",
          "tags": [
            "related"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-40047.html"
        },
        {
          "name": "CVE-2026-78163, whose fix introduced the inputBaseDirectory option that outputBaseDirectory mirrors",
          "tags": [
            "related"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-78163.html"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x stream should upgrade to 4.22.2 and users on the 4.18.x stream should upgrade to 4.18.5. The CamelDoclingOutputFilePath header is now normalized before it reaches docling, and a new outputBaseDirectory endpoint option confines it: when the option is set, a value that resolves outside that directory, including an absolute path, is rejected with an IOException before docling is started. The option is unset by default, so it must be set after upgrading wherever the header can carry a value influenced from outside the deployment; without it the header is normalized but can still name any directory. The 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release.\u003c/p\u003e"
            }
          ],
          "value": "Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x stream should upgrade to 4.22.2 and users on the 4.18.x stream should upgrade to 4.18.5. The CamelDoclingOutputFilePath header is now normalized before it reaches docling, and a new outputBaseDirectory endpoint option confines it: when the option is set, a value that resolves outside that directory, including an absolute path, is rejected with an IOException before docling is started. The option is unset by default, so it must be set after upgrading wherever the header can carry a value influenced from outside the deployment; without it the header is normalized but can still name any directory. The 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Camel: Camel-Docling Unvalidated Output Path Header Enables Writing Conversion Output to an Arbitrary Directory",
      "workarounds": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eDo not build the CamelDoclingOutputFilePath header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the output directory.\u003c/p\u003e"
            }
          ],
          "value": "Do not build the CamelDoclingOutputFilePath header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the output directory."
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-95629",
    "datePublished": "2026-10-26T08:44:22.849Z",
    "dateReserved": "2026-09-22T11:04:06.573Z",
    "dateUpdated": "2026-10-26T08:44:22.849Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.camel:camel-keycloak",
          "packageURL": "pkg:maven/org.apache.camel/camel-keycloak",
          "product": "Apache Camel",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.18.5",
              "status": "affected",
              "version": "4.16.0",
              "versionType": "maven"
            },
            {
              "lessThan": "4.22.2",
              "status": "affected",
              "version": "4.19.0",
              "versionType": "maven"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Andrea Cosentino from Apache Software Foundation"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Andrea Cosentino from Apache Software Foundation"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eInsufficient Session Expiration vulnerability in Apache Camel Keycloak component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.16.0 before 4.18.5, from 4.19.0 before 4.22.2.\u003c/p\u003e\u003cp\u003eWhen token introspection is enabled on the camel-keycloak KeycloakSecurityPolicy (useTokenIntrospection=true), the security processor validates the access token of a request by sending it to Keycloak\u0027s OAuth 2.0 token introspection endpoint, and accepts the token while the response reports it as active. The introspection endpoint reports a token as inactive once its exp (expiration) time has passed, so on this path the active flag is what enforces token expiry. Introspection results are cached by default (introspectionCacheEnabled=true, introspectionCacheTtl=60 seconds), and both cache implementations shipped with the component, ConcurrentMapTokenCache and CaffeineTokenCache, expired an entry a fixed time after it was inserted, without bounding that lifetime by the exp claim that the cached response already carried. KeycloakSecurityProcessor in turn checked only the active flag of the result, on every path that uses introspection, and never compared exp with the current time. A response cached shortly before the token expired was therefore served to later requests carrying the same token for up to the configured time-to-live after the token\u0027s expiry, and those requests were admitted with the roles and permissions the expired token had carried, although RFC 7662, which defines token introspection, states that a response containing exp must not be cached beyond that time. The access token is supplied by the caller with each request, typically as a bearer token in the Authorization header, so a caller holding a token that was valid moments earlier could keep using it after it expired, for as long as the cached entry lived. The window is bounded by introspectionCacheTtl, which is 60 seconds by default and 300 to 600 seconds where the documentation\u0027s recommendation for internal services was followed, and it opens only for a token that the same Camel process introspected and cached while the token was still active. The issue grants nothing beyond what the token already carried: it allows no token forgery and no privilege escalation, and token introspection is not enabled by default, which is why the severity is assessed medium. The local JWT verification path, used when introspection is disabled, is not affected by this issue.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.16.x, 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, set introspectionCacheEnabled=false on the KeycloakSecurityPolicy, so that every request is checked against the introspection endpoint, which reports an expired token as inactive, at the cost of one introspection call per request. Lowering introspectionCacheTtl only narrows the window and does not close it.\u003c/p\u003e"
            }
          ],
          "value": "Insufficient Session Expiration vulnerability in Apache Camel Keycloak component.\n\n\n\nThis issue affects Apache Camel: from 4.16.0 before 4.18.5, from 4.19.0 before 4.22.2.\n\n\n\nWhen token introspection is enabled on the camel-keycloak KeycloakSecurityPolicy (useTokenIntrospection=true), the security processor validates the access token of a request by sending it to Keycloak\u0027s OAuth 2.0 token introspection endpoint, and accepts the token while the response reports it as active. The introspection endpoint reports a token as inactive once its exp (expiration) time has passed, so on this path the active flag is what enforces token expiry. Introspection results are cached by default (introspectionCacheEnabled=true, introspectionCacheTtl=60 seconds), and both cache implementations shipped with the component, ConcurrentMapTokenCache and CaffeineTokenCache, expired an entry a fixed time after it was inserted, without bounding that lifetime by the exp claim that the cached response already carried. KeycloakSecurityProcessor in turn checked only the active flag of the result, on every path that uses introspection, and never compared exp with the current time. A response cached shortly before the token expired was therefore served to later requests carrying the same token for up to the configured time-to-live after the token\u0027s expiry, and those requests were admitted with the roles and permissions the expired token had carried, although RFC 7662, which defines token introspection, states that a response containing exp must not be cached beyond that time. The access token is supplied by the caller with each request, typically as a bearer token in the Authorization header, so a caller holding a token that was valid moments earlier could keep using it after it expired, for as long as the cached entry lived. The window is bounded by introspectionCacheTtl, which is 60 seconds by default and 300 to 600 seconds where the documentation\u0027s recommendation for internal services was followed, and it opens only for a token that the same Camel process introspected and cached while the token was still active. The issue grants nothing beyond what the token already carried: it allows no token forgery and no privilege escalation, and token introspection is not enabled by default, which is why the severity is assessed medium. The local JWT verification path, used when introspection is disabled, is not affected by this issue.\n\n\n\nUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.16.x, 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, set introspectionCacheEnabled=false on the KeycloakSecurityPolicy, so that every request is checked against the introspection endpoint, which reports an expired token as inactive, at the cost of one introspection call per request. Lowering introspectionCacheTtl only narrows the window and does not close it."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 4.8,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-613",
              "description": "CWE-613 Insufficient Session Expiration",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-26T08:42:17.403Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "name": "Apache Camel Security Advisory - CVE-2026-95663",
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-95663.html"
        },
        {
          "name": "CAMEL-24902",
          "tags": [
            "issue-tracking"
          ],
          "url": "https://issues.apache.org/jira/browse/CAMEL-24902"
        },
        {
          "name": "Fix on main, released in 4.23.0 (commit 7bfacb70d3300f97a130eda92b7b86ec5d8b11af)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/26747"
        },
        {
          "name": "Backport to camel-4.22.x for 4.22.2 (commit 66fd7034911aebcaffa80bae4ece265feb2895bb)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/27182"
        },
        {
          "name": "Backport to camel-4.18.x, released in 4.18.5 (commit 6be02c19c0259a983db5910e28deb4b3a00c9d22)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/27183"
        },
        {
          "name": "CVE-2026-46455, expired tokens accepted on the local JWT verification path, distinct from this issue",
          "tags": [
            "related"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-46455.html"
        },
        {
          "name": "CVE-2026-85301, issuer check skipped on the same introspection path, distinct from this issue",
          "tags": [
            "related"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-85301.html"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. Both cache implementations now bound the lifetime of each entry by the shorter of introspectionCacheTtl and the time remaining until the token\u0027s exp, a result whose token has already expired is never served from the cache, and KeycloakSecurityProcessor now rejects a token whose exp lies in the past on every path that uses introspection, so expiry is enforced on the introspection path as it is on the local JWT verification path. The 4.16.x, 4.17.x and 4.19.x to 4.21.x releases streams reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release.\u003c/p\u003e"
            }
          ],
          "value": "Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. Both cache implementations now bound the lifetime of each entry by the shorter of introspectionCacheTtl and the time remaining until the token\u0027s exp, a result whose token has already expired is never served from the cache, and KeycloakSecurityProcessor now rejects a token whose exp lies in the past on every path that uses introspection, so expiry is enforced on the introspection path as it is on the local JWT verification path. The 4.16.x, 4.17.x and 4.19.x to 4.21.x releases streams reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Camel: Camel-Keycloak Security Policy Accepts Expired Access Tokens Because Cached Token Introspection Results Are Not Bounded by the Token Expiry",
      "workarounds": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eFor deployments that cannot upgrade immediately, set introspectionCacheEnabled=false on the KeycloakSecurityPolicy, so that every request is checked against the introspection endpoint, which reports an expired token as inactive, at the cost of one introspection call per request. Lowering introspectionCacheTtl only narrows the window and does not close it.\u003c/p\u003e"
            }
          ],
          "value": "For deployments that cannot upgrade immediately, set introspectionCacheEnabled=false on the KeycloakSecurityPolicy, so that every request is checked against the introspection endpoint, which reports an expired token as inactive, at the cost of one introspection call per request. Lowering introspectionCacheTtl only narrows the window and does not close it."
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-95663",
    "datePublished": "2026-10-26T08:42:17.403Z",
    "dateReserved": "2026-09-22T12:58:07.244Z",
    "dateUpdated": "2026-10-26T08:42:17.403Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.camel:camel-aws2-s3",
          "packageURL": "pkg:maven/org.apache.camel/camel-aws2-s3",
          "product": "Apache Camel",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.18.5",
              "status": "affected",
              "version": "4.8.0",
              "versionType": "maven"
            },
            {
              "lessThan": "4.22.2",
              "status": "affected",
              "version": "4.19.0",
              "versionType": "maven"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Andrea Cosentino from Apache Software Foundation"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Andrea Cosentino from Apache Software Foundation"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eImproper Neutralization of Special Elements used in an Expression Language Statement (\u0027Expression Language Injection\u0027) vulnerability in Apache Camel AWS2-s3 component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.8.0 before 4.18.5, from 4.19.0 before 4.22.2.\u003c/p\u003e\u003cp\u003eFor the object it uploads, reads or deletes, the camel-aws2-s3 producer takes the key from the CamelAwsS3Key message header and falls back to the keyName option configured on the endpoint only when that header is absent. Since 4.8.0, AWS2S3Utils.determineKey() also passed the resulting value to the Simple language whenever it contained ${ or $simple{, so that a route could use a dynamic key, and the evaluation applied to a value taken from the header as well as to the configured option. The header is not route configuration, however: the aws2-s3 consumer sets CamelAwsS3Key on the exchanges it creates to the key of the object it read, that is, the name of the object in the bucket. In a route that does nothing more than consume from one aws2-s3 endpoint and produce to another, the name of each consumed object therefore reached the producer, and a name containing either marker was evaluated as an expression, although the route author never asked for any evaluation, and configuring keyName on the producer did not prevent it, because the header took precedence. A key that a route copied into the header from other message content was evaluated in the same way. Anyone able to choose the name of an object in a bucket that such a route consumes, typically a principal allowed to upload to that bucket, could therefore have Simple expressions of their choosing evaluated in the Camel process. The Simple language can read JVM system properties, environment variables and configuration properties, which commonly carry credentials, and, where camel-bean is on the classpath, invoke methods on beans in the registry. The evaluated result became the key the producer used, so reading a value back additionally required the ability to see object names in the destination bucket, while a method invocation took effect without it; together with the need to name an object in a consumed bucket, this is why the severity is assessed medium. The bucket name went through the same evaluation, but the consumer only ever places the bucket configured on its own endpoint in a bucket header, never a value derived from a remote object, so the bucket name was not reachable in this way. Releases before 4.8.0 used the key from the header as given and are not affected.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.8.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. After upgrading, a key or bucket name supplied through a message header is used literally, so a route that put an unevaluated Simple expression in the CamelAwsS3Key or CamelAwsS3OverrideBucketName header must evaluate it in the route instead, for example with setHeader and simple(), or configure it as the keyName or bucketName option of the endpoint. For deployments that cannot upgrade immediately, do not let a key derived from an object name or from other untrusted message content reach an aws2-s3 producer unchecked: in routes that pass exchanges from an aws2-s3 consumer to an aws2-s3 producer, either remove the CamelAwsS3Key header before the producer with removeHeader(\u201cCamelAwsS3Key\u201d), so that the keyName configured on the endpoint is used, or reject exchanges whose CamelAwsS3Key header contains ${ or $simple{. Configuring keyName alone is not a workaround, because the header takes precedence over it. As defence in depth, allow only trusted principals to write to buckets that Camel routes consume.\u003c/p\u003e"
            }
          ],
          "value": "Improper Neutralization of Special Elements used in an Expression Language Statement (\u0027Expression Language Injection\u0027) vulnerability in Apache Camel AWS2-s3 component.\n\n\n\nThis issue affects Apache Camel: from 4.8.0 before 4.18.5, from 4.19.0 before 4.22.2.\n\n\n\nFor the object it uploads, reads or deletes, the camel-aws2-s3 producer takes the key from the CamelAwsS3Key message header and falls back to the keyName option configured on the endpoint only when that header is absent. Since 4.8.0, AWS2S3Utils.determineKey() also passed the resulting value to the Simple language whenever it contained ${ or $simple{, so that a route could use a dynamic key, and the evaluation applied to a value taken from the header as well as to the configured option. The header is not route configuration, however: the aws2-s3 consumer sets CamelAwsS3Key on the exchanges it creates to the key of the object it read, that is, the name of the object in the bucket. In a route that does nothing more than consume from one aws2-s3 endpoint and produce to another, the name of each consumed object therefore reached the producer, and a name containing either marker was evaluated as an expression, although the route author never asked for any evaluation, and configuring keyName on the producer did not prevent it, because the header took precedence. A key that a route copied into the header from other message content was evaluated in the same way. Anyone able to choose the name of an object in a bucket that such a route consumes, typically a principal allowed to upload to that bucket, could therefore have Simple expressions of their choosing evaluated in the Camel process. The Simple language can read JVM system properties, environment variables and configuration properties, which commonly carry credentials, and, where camel-bean is on the classpath, invoke methods on beans in the registry. The evaluated result became the key the producer used, so reading a value back additionally required the ability to see object names in the destination bucket, while a method invocation took effect without it; together with the need to name an object in a consumed bucket, this is why the severity is assessed medium. The bucket name went through the same evaluation, but the consumer only ever places the bucket configured on its own endpoint in a bucket header, never a value derived from a remote object, so the bucket name was not reachable in this way. Releases before 4.8.0 used the key from the header as given and are not affected.\n\n\n\nUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.8.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. After upgrading, a key or bucket name supplied through a message header is used literally, so a route that put an unevaluated Simple expression in the CamelAwsS3Key or CamelAwsS3OverrideBucketName header must evaluate it in the route instead, for example with setHeader and simple(), or configure it as the keyName or bucketName option of the endpoint. For deployments that cannot upgrade immediately, do not let a key derived from an object name or from other untrusted message content reach an aws2-s3 producer unchecked: in routes that pass exchanges from an aws2-s3 consumer to an aws2-s3 producer, either remove the CamelAwsS3Key header before the producer with removeHeader(\u201cCamelAwsS3Key\u201d), so that the keyName configured on the endpoint is used, or reject exchanges whose CamelAwsS3Key header contains ${ or $simple{. Configuring keyName alone is not a workaround, because the header takes precedence over it. As defence in depth, allow only trusted principals to write to buckets that Camel routes consume."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 5.4,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "LOW",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-917",
              "description": "CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement (\u0027Expression Language Injection\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-26T08:40:32.068Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "name": "Apache Camel Security Advisory - CVE-2026-95664",
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-95664.html"
        },
        {
          "name": "CAMEL-24901",
          "tags": [
            "issue-tracking"
          ],
          "url": "https://issues.apache.org/jira/browse/CAMEL-24901"
        },
        {
          "name": "Fix on main, released in 4.23.0 (commit 1fd7a667913ad068c8571b39c96b0a9c2dd4f3ef)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/26746"
        },
        {
          "name": "Backport to camel-4.22.x for 4.22.2 (commit 19a672aa791480bff6b61c0551c79b2fa079da6e)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/26840"
        },
        {
          "name": "Backport to camel-4.18.x, released in 4.18.5 (commit 124bf3da3cfb5d8e1994471e1301b6421bfe96d2)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/26842"
        },
        {
          "name": "Upgrade-guide documentation for the 4.22.x and 4.18.x lines placed on main (commit aa48bb8a90adfae80a657a9ef427002d6634af31)",
          "tags": [
            "related"
          ],
          "url": "https://github.com/apache/camel/pull/26841"
        },
        {
          "name": "Javadoc of the header and configuration contract in AWS2S3Utils on main (commit 60c2c38b98ebbbaf56c10aff491291afe13df474)",
          "tags": [
            "related"
          ],
          "url": "https://github.com/apache/camel/pull/26889"
        },
        {
          "name": "CAMEL-20971, the dynamic key and bucket name support added in 4.8.0 that introduced the evaluation",
          "tags": [
            "related"
          ],
          "url": "https://issues.apache.org/jira/browse/CAMEL-20971"
        },
        {
          "name": "CVE-2026-78164, HTTP producers resolved property placeholders in message-supplied URI override headers (same family)",
          "tags": [
            "related"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-78164.html"
        },
        {
          "name": "CVE-2026-83531, dynamic-router-control endpoint compiled predicate expressions supplied by control messages (same family)",
          "tags": [
            "related"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-83531.html"
        },
        {
          "name": "CVE-2025-27636, Camel message header injection via improper filtering (distinct from this issue)",
          "tags": [
            "related"
          ],
          "url": "https://camel.apache.org/security/CVE-2025-27636.html"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.8.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. AWS2S3Utils.determineKey() and determineBucketName() now evaluate the Simple language only for the keyName and bucketName options configured on the endpoint, which the route author writes; a key supplied through the CamelAwsS3Key header, or a bucket name supplied through the CamelAwsS3OverrideBucketName header, is used literally. A route that put an unevaluated Simple expression in one of these headers must evaluate it in the route instead, for example with setHeader and simple(), or configure it as the keyName or bucketName option of the endpoint.\u003c/p\u003e"
            }
          ],
          "value": "Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.8.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. AWS2S3Utils.determineKey() and determineBucketName() now evaluate the Simple language only for the keyName and bucketName options configured on the endpoint, which the route author writes; a key supplied through the CamelAwsS3Key header, or a bucket name supplied through the CamelAwsS3OverrideBucketName header, is used literally. A route that put an unevaluated Simple expression in one of these headers must evaluate it in the route instead, for example with setHeader and simple(), or configure it as the keyName or bucketName option of the endpoint."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Camel: Camel-AWS2-S3 Producer Evaluates Untrusted S3 Object Keys From the CamelAwsS3Key Header as Simple Expressions",
      "workarounds": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eFor deployments that cannot upgrade immediately, do not let a key derived from an object name or from other untrusted message content reach an aws2-s3 producer unchecked: in routes that pass exchanges from an aws2-s3 consumer to an aws2-s3 producer, either remove the CamelAwsS3Key header before the producer with removeHeader(\u0026quot;CamelAwsS3Key\u0026quot;), so that the keyName configured on the endpoint is used, or reject exchanges whose CamelAwsS3Key header contains ${ or $simple{. Configuring keyName alone is not a workaround, because the header takes precedence over it. As defence in depth, allow only trusted principals to write to buckets that Camel routes consume.\u003c/p\u003e"
            }
          ],
          "value": "For deployments that cannot upgrade immediately, do not let a key derived from an object name or from other untrusted message content reach an aws2-s3 producer unchecked: in routes that pass exchanges from an aws2-s3 consumer to an aws2-s3 producer, either remove the CamelAwsS3Key header before the producer with removeHeader(\"CamelAwsS3Key\"), so that the keyName configured on the endpoint is used, or reject exchanges whose CamelAwsS3Key header contains ${ or $simple{. Configuring keyName alone is not a workaround, because the header takes precedence over it. As defence in depth, allow only trusted principals to write to buckets that Camel routes consume."
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-95664",
    "datePublished": "2026-10-26T08:40:32.068Z",
    "dateReserved": "2026-09-22T12:59:19.318Z",
    "dateUpdated": "2026-10-26T08:40:32.068Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.camel:camel-coap",
          "packageURL": "pkg:maven/org.apache.camel/camel-coap",
          "product": "Apache Camel",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.18.5",
              "status": "affected",
              "version": "4.0.0",
              "versionType": "maven"
            },
            {
              "lessThan": "4.22.2",
              "status": "affected",
              "version": "4.19.0",
              "versionType": "maven"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Zhixi \"Jace\" Sun, independent security researcher"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Andrea Cosentino"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eGeneration of Error Message Containing Sensitive Information vulnerability in Apache Camel CoAP component.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2.\u003c/p\u003e\u003cp\u003eWhen the CoAP consumer could not build its response once the route had completed, CamelCoapResource caught the resulting exception and sent its message back to the CoAP client as the payload of a 5.00 Internal Server Error response. The typical case is a type conversion failure: the consumer converts the final message body to the byte[] payload, and the CamelCoapMaxAge and CamelCoapETag headers to their types, after the route has returned, and therefore outside the route\u0027s error handler. On the affected releases the message of such a failure names the class of the value being converted, carries the value\u0027s string form, and ends with the class name and message of the underlying cause, so a remote CoAP client could read internal detail about the deployment: class and package names, the string form of the value, such as the path of a file body, and whatever the cause carries, which in practice can include paths, host names and connection detail of a backend. The consumer had no option to suppress this, unlike the HTTP consumers, which offer a muteException option for that purpose. The exception raised by a failing route was not sent: the consumer did not check whether the exchange had failed, and answered a route failure with 2.05 Content and whatever body the message held at that point. Reaching the disclosure therefore requires a route whose completed response a remote client can make unconvertible, which depends on how the route is written.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier, and the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. The upgrade is enough on its own: the new muteException consumer option defaults to true on all three fixed release lines, so the error response carries no payload without any configuration change. For deployments that cannot upgrade immediately, make sure the response can always be built once the route has completed: convert the body to byte[] or String as the last step of each route that consumes from a coap endpoint, for example with convertBodyTo, give the CamelCoapMaxAge and CamelCoapETag headers only values of their own types, and add an onException handler that marks the failure as handled and sets the response body explicitly, so that a conversion failure is raised and replaced inside the route rather than in the consumer.\u003c/p\u003e"
            }
          ],
          "value": "Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel CoAP component.\n\n\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2.\n\n\n\nWhen the CoAP consumer could not build its response once the route had completed, CamelCoapResource caught the resulting exception and sent its message back to the CoAP client as the payload of a 5.00 Internal Server Error response. The typical case is a type conversion failure: the consumer converts the final message body to the byte[] payload, and the CamelCoapMaxAge and CamelCoapETag headers to their types, after the route has returned, and therefore outside the route\u0027s error handler. On the affected releases the message of such a failure names the class of the value being converted, carries the value\u0027s string form, and ends with the class name and message of the underlying cause, so a remote CoAP client could read internal detail about the deployment: class and package names, the string form of the value, such as the path of a file body, and whatever the cause carries, which in practice can include paths, host names and connection detail of a backend. The consumer had no option to suppress this, unlike the HTTP consumers, which offer a muteException option for that purpose. The exception raised by a failing route was not sent: the consumer did not check whether the exchange had failed, and answered a route failure with 2.05 Content and whatever body the message held at that point. Reaching the disclosure therefore requires a route whose completed response a remote client can make unconvertible, which depends on how the route is written.\n\n\n\nUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier, and the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. The upgrade is enough on its own: the new muteException consumer option defaults to true on all three fixed release lines, so the error response carries no payload without any configuration change. For deployments that cannot upgrade immediately, make sure the response can always be built once the route has completed: convert the body to byte[] or String as the last step of each route that consumes from a coap endpoint, for example with convertBodyTo, give the CamelCoapMaxAge and CamelCoapETag headers only values of their own types, and add an onException handler that marks the failure as handled and sets the response body explicitly, so that a conversion failure is raised and replaced inside the route rather than in the consumer."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 5.3,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-209",
              "description": "CWE-209 Generation of Error Message Containing Sensitive Information",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-26T08:36:47.439Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "name": "Apache Camel Security Advisory - CVE-2026-101259",
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-101259.html"
        },
        {
          "name": "CAMEL-25087",
          "tags": [
            "issue-tracking"
          ],
          "url": "https://issues.apache.org/jira/browse/CAMEL-25087"
        },
        {
          "name": "Fix on main, released in 4.23.0 (commit 2245feac8f4f9a85404b01d36114abdac504e7d1)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/26994"
        },
        {
          "name": "Backport to camel-4.22.x for 4.22.2 (commit 868d56044119a8a975f583b63aeb9666cd952a88)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/27046"
        },
        {
          "name": "Backport to camel-4.18.x, released in 4.18.5 (commit aaf5bbf81ede12837c9c65fa9106643fcb58b7c4)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/camel/pull/27048"
        },
        {
          "name": "CVE-2026-84180, the camel-knative member of the same unmuted-consumer-exception family",
          "tags": [
            "related"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-84180.html"
        },
        {
          "name": "CVE-2026-85246, the camel-mina member of the same unmuted-consumer-exception family",
          "tags": [
            "related"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-85246.html"
        },
        {
          "name": "CVE-2026-85257, the camel-cxf member of the same unmuted-consumer-exception family",
          "tags": [
            "related"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-85257.html"
        },
        {
          "name": "CVE-2026-85315, the camel-grpc member of the same unmuted-consumer-exception family",
          "tags": [
            "related"
          ],
          "url": "https://camel.apache.org/security/CVE-2026-85315.html"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eUsers are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The fix adds a muteException consumer option to the coap, coaps, coap+tcp and coaps+tcp endpoints, defaulting to true on all three release lines, so the upgrade is enough on its own and the error response carries no payload without any configuration change. An exception raised while the response is built is answered with an empty 5.00 Internal Server Error and reported through the consumer\u0027s exception handler, and a failed exchange, previously answered with 2.05 Content and the body the message held when the route failed, is now answered with 5.00 Internal Server Error under the same rule. Setting muteException=false sends the exception\u0027s message as the payload of the 5.00 response, for a route failure as well. The 4.14.x releases stream and earlier, and the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release.\u003c/p\u003e"
            }
          ],
          "value": "Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The fix adds a muteException consumer option to the coap, coaps, coap+tcp and coaps+tcp endpoints, defaulting to true on all three release lines, so the upgrade is enough on its own and the error response carries no payload without any configuration change. An exception raised while the response is built is answered with an empty 5.00 Internal Server Error and reported through the consumer\u0027s exception handler, and a failed exchange, previously answered with 2.05 Content and the body the message held when the route failed, is now answered with 5.00 Internal Server Error under the same rule. Setting muteException=false sends the exception\u0027s message as the payload of the 5.00 response, for a route failure as well. The 4.14.x releases stream and earlier, and the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Camel: Camel-CoAP Information Disclosure via Unmuted Consumer Exceptions",
      "workarounds": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eFor deployments that cannot upgrade immediately, make sure the response can always be built once the route has completed: convert the body to byte[] or String as the last step of each route that consumes from a coap endpoint, for example with convertBodyTo, give the CamelCoapMaxAge and CamelCoapETag headers only values of their own types, and add an onException handler that marks the failure as handled and sets the response body explicitly, so that a conversion failure is raised and replaced inside the route rather than in the consumer.\u003c/p\u003e"
            }
          ],
          "value": "For deployments that cannot upgrade immediately, make sure the response can always be built once the route has completed: convert the body to byte[] or String as the last step of each route that consumes from a coap endpoint, for example with convertBodyTo, give the CamelCoapMaxAge and CamelCoapETag headers only values of their own types, and add an onException handler that marks the failure as handled and sets the response body explicitly, so that a conversion failure is raised and replaced inside the route rather than in the consumer."
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-101259",
    "datePublished": "2026-10-26T08:36:47.439Z",
    "dateReserved": "2026-09-28T11:17:22.256Z",
    "dateUpdated": "2026-10-26T08:36:47.439Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-22T20:08:11.797Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/22/10"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.abdera:abdera-parser",
          "packageURL": "pkg:maven/org.apache.abdera/abdera-parser",
          "product": "Apache Abdera",
          "programFiles": [
            "parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java"
          ],
          "programRoutines": [
            {
              "name": "org.apache.abdera.parser.stax.FOMParser.parse"
            }
          ],
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "*",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        },
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.abdera:abdera-jdbc",
          "packageURL": "pkg:maven/org.apache.abdera/abdera-jdbc",
          "product": "Apache Abdera",
          "programFiles": [
            "adapters/jdbc/src/main/java/org/apache/abdera/protocol/server/adapters/ibatis/IBatisCollectionAdapter.java"
          ],
          "programRoutines": [
            {
              "name": "org.apache.abdera.protocol.server.adapters.ibatis.IBatisCollectionAdapter.parseContent"
            }
          ],
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "*",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        },
        {
          "defaultStatus": "unaffected",
          "packageURL": "pkg:git/gitbox.apache.org/repos/asf/abdera",
          "product": "Apache Abdera",
          "programFiles": [
            "parser/src/main/java/org/apache/abdera/parser/stax/FOMParser.java",
            "adapters/jdbc/src/main/java/org/apache/abdera/protocol/server/adapters/ibatis/IBatisCollectionAdapter.java"
          ],
          "programRoutines": [
            {
              "name": "org.apache.abdera.parser.stax.FOMParser.parse"
            },
            {
              "name": "org.apache.abdera.protocol.server.adapters.ibatis.IBatisCollectionAdapter.parseContent"
            }
          ],
          "repo": "https://gitbox.apache.org/repos/asf/abdera.git",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "*",
              "status": "affected",
              "version": "cb5a3646fc8b2a620dba5bdde3a6b7a3753b1be2",
              "versionType": "git"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Fabian Foerg of Addepar, Inc."
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003e\u003cstrong\u003eUNSUPPORTED WHEN ASSIGNED\u003c/strong\u003e Improper restriction of XML external entity references in Apache Abdera allows an attacker to access sensitive data or make server-side requests when an application parses attacker-controlled XML with Abdera.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Abdera: all versions.\u003c/p\u003e\u003cp\u003eApache Abdera is retired and no longer supported, so we do not plan to release a version that fixes this issue. Users are recommended to migrate to a maintained alternative. Applications that cannot migrate should ensure that untrusted XML cannot reach the affected Abdera parser or JDBC adapter parsing paths. Actively maintained downstream products may still be impacted if they include an affected Abdera artifact.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eNOTE:\u003c/strong\u003e This vulnerability only affects products that are no longer supported by the maintainer.\u003c/p\u003e"
            }
          ],
          "value": "UNSUPPORTED WHEN ASSIGNED Improper restriction of XML external entity references in Apache Abdera allows an attacker to access sensitive data or make server-side requests when an application parses attacker-controlled XML with Abdera.\n\n\n\nThis issue affects Apache Abdera: all versions.\n\n\n\nApache Abdera is retired and no longer supported, so we do not plan to release a version that fixes this issue. Users are recommended to migrate to a maintained alternative. Applications that cannot migrate should ensure that untrusted XML cannot reach the affected Abdera parser or JDBC adapter parsing paths. Actively maintained downstream products may still be impacted if they include an affected Abdera artifact.\n\n\n\nNOTE: This vulnerability only affects products that are no longer supported by the maintainer."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 8.7,
            "baseSeverity": "HIGH",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-611",
              "description": "CWE-611 Improper Restriction of XML External Entity Reference",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-22T13:27:11.536Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "product"
          ],
          "url": "https://attic.apache.org/projects/abdera.html"
        },
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread.html/j32tow7bhfnn2p0obsqy1mhg1qs7hq91"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "tags": [
        "unsupported-when-assigned"
      ],
      "timeline": [
        {
          "lang": "en",
          "time": "2017-02-27T00:00:00.000Z",
          "value": "Apache Abdera was retired to the Apache Attic."
        },
        {
          "lang": "en",
          "time": "2026-10-07T16:37:00.000Z",
          "value": "The vulnerability was reported to the Apache Security Team."
        }
      ],
      "title": "Apache Abdera: XML external entity expansion in Atom document parsing",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-113582",
    "datePublished": "2026-10-22T13:27:11.536Z",
    "dateReserved": "2026-10-20T11:25:36.240Z",
    "dateUpdated": "2026-10-22T20:08:11.797Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-22T07:16:57.732Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/10/4"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "NETWORK",
              "availabilityImpact": "LOW",
              "baseScore": 5.3,
              "baseSeverity": "MEDIUM",
              "confidentialityImpact": "NONE",
              "integrityImpact": "NONE",
              "privilegesRequired": "NONE",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-103634",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-26T13:43:10.294464Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-26T13:43:13.987Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://github.com",
          "defaultStatus": "unaffected",
          "packageName": "apache/datasketches-cpp",
          "packageURL": "pkg:github/apache/datasketches-cpp",
          "product": "Apache DataSketches",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "5.2.0",
              "status": "affected",
              "version": "4.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "He Huang"
        },
        {
          "lang": "en",
          "type": "tool",
          "value": "NexusSan"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003eOut-of-bounds read and write in the Count-Min sketch deserialization of Apache DataSketches C++ (repo: datasketches-cpp).\u003cbr\u003e\u003cbr\u003ecount_min_sketch::deserialize() did not include the preamble in its input size check, so a truncated sketch could cause a read of up to 16 bytes past the end of the input. In addition, the table size was computed from the serialized number of buckets and number of hash functions in 32-bit arithmetic. A crafted sketch could make it wrap to zero, so that the sketch deserialized with an empty table, and later updates and estimate queries read and wrote outside the heap allocation. This can corrupt heap memory, causing a crash and potentially enabling further exploitation.\u003cbr\u003e\u003cbr\u003eThis issue affects Apache DataSketches C++: from 4.1.0 before 5.3.0. Only applications that deserialize Count-Min sketches from untrusted sources are affected.\u003cbr\u003e\u003cbr\u003eUsers are recommended to upgrade to version 5.3.0, which fixes this issue.\u003c/div\u003e"
            }
          ],
          "value": "Out-of-bounds read and write in the Count-Min sketch deserialization of Apache DataSketches C++ (repo: datasketches-cpp).\n\ncount_min_sketch::deserialize() did not include the preamble in its input size check, so a truncated sketch could cause a read of up to 16 bytes past the end of the input. In addition, the table size was computed from the serialized number of buckets and number of hash functions in 32-bit arithmetic. A crafted sketch could make it wrap to zero, so that the sketch deserialized with an empty table, and later updates and estimate queries read and wrote outside the heap allocation. This can corrupt heap memory, causing a crash and potentially enabling further exploitation.\n\nThis issue affects Apache DataSketches C++: from 4.1.0 before 5.3.0. Only applications that deserialize Count-Min sketches from untrusted sources are affected.\n\nUsers are recommended to upgrade to version 5.3.0, which fixes this issue."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "moderate"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-787",
              "description": "CWE-787 Out-of-bounds write",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-190",
              "description": "CWE-190 Integer overflow or wraparound",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-22T06:42:20.454Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/rkx9oh06g5cjc6vmmpqloxwfz0gzz01h"
        },
        {
          "tags": [
            "release-notes"
          ],
          "url": "https://github.com/apache/datasketches-cpp/releases/tag/5.3.0"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache DataSketches: datasketches-cpp: Out-of-bounds read and write in Count-Min sketch deserialization allows memory corruption via a crafted sketch",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-103634",
    "datePublished": "2026-10-22T06:42:20.454Z",
    "dateReserved": "2026-09-30T23:36:49.873Z",
    "dateUpdated": "2026-10-26T13:43:13.987Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-112381",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-23T20:43:45.368400Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-23T21:20:44.000Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Apache Traffic Server",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "status": "affected",
              "version": "9.2.15",
              "versionType": "semver"
            },
            {
              "status": "affected",
              "version": "10.1.4",
              "versionType": "semver"
            },
            {
              "status": "affected",
              "version": "10.2.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Masaori Koshiba"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eApache Traffic Server can crash with a null pointer dereference when a client POST request is torn down via half-close while a chunked origin response is being reparsed from a reentrant write-ready callback, a timing-dependent race introduced by the CVE-2021-32564 flow-control backports.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: 9.2.15, 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
            }
          ],
          "value": "Apache Traffic Server can crash with a null pointer dereference when a client POST request is torn down via half-close while a chunked origin response is being reparsed from a reentrant write-ready callback, a timing-dependent race introduced by the CVE-2021-32564 flow-control backports.\n\n\n\nThis issue affects Apache Traffic Server: 9.2.15, 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "moderate"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 5.9,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "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",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-476",
              "description": "CWE-476 NULL Pointer Dereference",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-21T19:20:38.885Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Traffic Server: Nullptr dereference in net_write_io on a POST half-close with chunked response",
      "x_generator": {
        "engine": "scripts/cve_render.py"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-112381",
    "datePublished": "2026-10-21T19:20:38.885Z",
    "dateReserved": "2026-10-19T16:56:57.385Z",
    "dateUpdated": "2026-10-23T21:20:44.000Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-111817",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-23T20:52:19.862625Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-23T21:21:06.850Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Apache Traffic Server",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "status": "affected",
              "version": "8.1.11",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "9.2.15",
              "status": "affected",
              "version": "9.2.5",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "10.1.4",
              "status": "affected",
              "version": "10.0.0",
              "versionType": "semver"
            },
            {
              "status": "affected",
              "version": "10.2.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Omkhar Arasaratnam"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eApache Traffic Server can stall a chunked transfer that it passes through with its trailers removed (proxy.config.http.drop_chunked_trailers) until the connection times out, because it waits for the trailer bytes it has already dropped. Trailer dropping is on by default in 10.x. In 8.1.11 and 9.2.x it is off by default, and those versions are affected only if it is enabled.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: 8.1.11, from 9.2.5 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 10.1.5 or 10.2.1, which fix the issue.\u003c/p\u003e"
            }
          ],
          "value": "Apache Traffic Server can stall a chunked transfer that it passes through with its trailers removed (proxy.config.http.drop_chunked_trailers) until the connection times out, because it waits for the trailer bytes it has already dropped. Trailer dropping is on by default in 10.x. In 8.1.11 and 9.2.x it is off by default, and those versions are affected only if it is enabled.\n\n\n\nThis issue affects Apache Traffic Server: 8.1.11, from 9.2.5 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 10.1.5 or 10.2.1, which fix the issue."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "moderate"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "LOW",
            "baseScore": 5.3,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 6.9,
            "baseSeverity": "MEDIUM",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "LOW",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400 Uncontrolled Resource Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-21T19:20:00.515Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Traffic Server: Dropping chunked trailers stalls a passthrough transfer until timeout",
      "x_generator": {
        "engine": "scripts/cve_render.py"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-111817",
    "datePublished": "2026-10-21T19:20:00.515Z",
    "dateReserved": "2026-10-16T20:29:16.510Z",
    "dateUpdated": "2026-10-23T21:21:06.850Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-111812",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-22T23:05:10.427406Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-23T11:06:21.577Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Apache Traffic Server",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "8.1.11",
              "status": "affected",
              "version": "8.0.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "9.2.15",
              "status": "affected",
              "version": "9.0.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "10.1.4",
              "status": "affected",
              "version": "10.0.0",
              "versionType": "semver"
            },
            {
              "status": "affected",
              "version": "10.2.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Apache Community"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eApache Traffic Server\u0027s origin_server_auth plugin lets a client force signing of attacker-chosen AWS request headers under the proxy\u0027s own credentials.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
            }
          ],
          "value": "Apache Traffic Server\u0027s origin_server_auth plugin lets a client force signing of attacker-chosen AWS request headers under the proxy\u0027s own credentials.\n\n\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "moderate"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 10,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 7,
            "baseSeverity": "HIGH",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-863",
              "description": "CWE-863 Incorrect Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-21T19:18:19.526Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Traffic Server: origin_server_auth signs client-controlled AWS headers under the proxy\u0027s IAM credentials",
      "x_generator": {
        "engine": "scripts/cve_render.py"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-111812",
    "datePublished": "2026-10-21T19:18:19.526Z",
    "dateReserved": "2026-10-16T20:22:21.735Z",
    "dateUpdated": "2026-10-23T11:06:21.577Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-111811",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-22T23:05:09.363203Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-23T11:06:21.737Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Apache Traffic Server",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "8.1.11",
              "status": "affected",
              "version": "8.0.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "9.2.15",
              "status": "affected",
              "version": "9.0.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "10.1.4",
              "status": "affected",
              "version": "10.0.0",
              "versionType": "semver"
            },
            {
              "status": "affected",
              "version": "10.2.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Apache Community"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eApache Traffic Server\u0027s experimental tsmemcache plugin allows unauthenticated network read, write, and deletion of the shared proxy cache.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue.\u003c/p\u003e"
            }
          ],
          "value": "Apache Traffic Server\u0027s experimental tsmemcache plugin allows unauthenticated network read, write, and deletion of the shared proxy cache.\n\n\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.\n\n\n\nUsers are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "moderate"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 9,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 9.4,
            "baseSeverity": "CRITICAL",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "HIGH",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:H",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-306",
              "description": "CWE-306 Missing Authentication for Critical Function",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-21T19:17:32.448Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/r95dq29ywcd1f4x30snxlqmb12z4s4kc"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Traffic Server: tsmemcache plugin exposes the shared proxy cache over the network with no authentication",
      "x_generator": {
        "engine": "scripts/cve_render.py"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-111811",
    "datePublished": "2026-10-21T19:17:32.448Z",
    "dateReserved": "2026-10-16T20:21:46.648Z",
    "dateUpdated": "2026-10-23T11:06:21.737Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}