CVE-2026-10143 - kafka-python SCRAM iteration count DoS

kafka-python before 2.3.2 accepts a broker-controlled SCRAM iteration count and passes it into hashlib.pbkdf2_hmac() without a practical upper bound. A malicious broker or machine-in-the-middle can supply an excessive count during SCRAM authentication and freeze the client event loop long enough to block producer sends, consumer polls, admin requests, and heartbeats.

The blast radius is larger for consumer groups and automation workers because a single frozen authentication path can cause group eviction, reconnect storms, or sustained backlog growth even though the bug is reached only during broker authentication.

When to use it

  • A Python service, notebook, worker, or image resolves kafka-python <2.3.2.
  • The runtime uses SCRAM authentication, especially SCRAM-SHA-256 or SCRAM-SHA-512.
  • Broker identity validation, network boundaries, or authentication timeouts are not clearly documented.
  • You need a bounded dependency-remediation PR or triage note that includes authentication freeze risk and operator cleanup.

Inputs

  • Dependency manifests, lockfiles, Dockerfiles, SBOMs, notebooks, and generated dependency reports.
  • Resolved kafka-python versions and Kafka client configuration for each deployable target.
  • SCRAM, TLS, broker identity, outbound allow-list, timeout, and worker-recycle settings.
  • Available package install, Kafka client test, container build, SBOM refresh, and dependency scan commands.

Affected versions

  • Vulnerable package: kafka-python <2.3.2
  • Fixed package: kafka-python 2.3.2+
  • Affected path: ScramClient.process_server_first_message()
  • Attack precondition: the client uses SCRAM auth against a malicious or impersonated broker

Source-freshness note: GitHub Advisory Database currently publishes this as an unreviewed advisory with no package metadata and unknown affected/patched version fields, even though the description, NVD entry, and upstream fix point to kafka-python prior to 2.3.2. Do not rely on Dependabot alone to find exposure; inventory manifests, lockfiles, images, and notebooks directly.

Indicator-of-exposure

  • The repository depends on kafka-python <2.3.2.
  • Deployments use SCRAM-based Kafka authentication such as SCRAM-SHA-256 or SCRAM-SHA-512.
  • Brokers are shared, third-party, or not strongly authenticated end to end.
  • Authentication freezes can disrupt consumer heartbeats, admin calls, or job throughput in long-lived workers.

Quick checks:

rg -n "kafka-python|SCRAM|SASL|SASL_PLAINTEXT|SASL_SSL|SCRAM-SHA-256|SCRAM-SHA-512|KafkaConsumer|KafkaProducer|KafkaAdminClient" .
python -m pip show kafka-python
python -m pip freeze | rg '^kafka-python=='

Windows:

rg -n "kafka-python|SCRAM|SASL|SASL_PLAINTEXT|SASL_SSL|SCRAM-SHA-256|SCRAM-SHA-512|KafkaConsumer|KafkaProducer|KafkaAdminClient" .
python -m pip show kafka-python
python -m pip freeze | rg '^kafka-python=='

Do not connect to a rogue broker or attempt live SCRAM exploitation to confirm exposure.

Remediation strategy

  • Upgrade every controlled kafka-python dependency, lockfile, image, wheel cache, and SBOM to 2.3.2+.
  • If kafka-python is present, remediate CVE-2026-10142 in the same change set unless there is a documented reason to split the PR; both advisories use the same fixed release.
  • For owned wrappers or forks, bound acceptable SCRAM iteration counts before expensive key derivation and fail closed when broker values are unreasonable.
  • Require TLS with broker identity validation so a machine-in-the-middle cannot impersonate the SCRAM peer.
  • Add connection timeouts, authentication watchdogs, or worker recycling where long-running freezes would otherwise persist silently.
  • If immediate upgrade is blocked, prefer disabling SCRAM-capable paths that talk to untrusted brokers and constrain outbound broker access to approved endpoints only.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-10143 / GHSA-2jcm-hq8r-84wx, where `kafka-python`
before 2.3.2 trusts a broker-controlled SCRAM iteration count and can freeze
the client during authentication. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades or patches the affected
  Kafka Python client, hardens SCRAM broker trust boundaries, adds safe
  regression checks, refreshes generated artifacts, and documents operator
  cleanup, or
- TRIAGE.md if this repository does not control an affected `kafka-python`
  dependency, wrapper, image, deployment, or containment path.

## Rules

- Scope only CVE-2026-10143 / GHSA-2jcm-hq8r-84wx and directly related SCRAM
  authentication, broker identity, and fail-fast client behavior.
- Treat Kafka credentials, SCRAM secrets, TLS keys, topic names, message
  payloads, and customer data as sensitive.
- Do not connect to rogue brokers, harvest traffic, or ship an exploit-like
  SCRAM test harness.
- Do not disable broker certificate validation or SASL protections just to make
  tests pass.
- Do not auto-merge.

## Steps

1. Inventory every controlled `kafka-python` dependency in source,
   requirements, lockfiles, vendored code, Dockerfiles, CI images, notebooks,
   scripts, and SBOMs.
2. Determine the resolved version for every deployable target. A target is
   vulnerable if it resolves to `<2.3.2`.
3. Determine which runtimes use SCRAM and how broker identity is validated:
   TLS, certificate pinning, mTLS, SASL config, network assumptions, and broker
   allow-lists.
4. Identify where authentication freezes would cause user-visible impact:
   consumer heartbeats, admin automation, queue workers, scheduled jobs, or API
   request paths.
5. If this repository does not control an affected dependency or runtime, stop
   with `TRIAGE.md` listing checked files, observed version if known, runtime
   owner, and required fixed version `2.3.2+`.
6. Upgrade all controlled `kafka-python` references to `2.3.2+`. Refresh
   lockfiles, constraints, image layers, SBOMs, and generated reports.
7. For owned forks or wrappers, reject pathological SCRAM iteration counts
   before calling expensive key-derivation logic and ensure failures close and
   recycle the connection safely.
8. Harden runtime containment:
   - require TLS with broker identity verification;
   - restrict outbound broker access to approved endpoints;
   - avoid using SCRAM against shared or untrusted brokers without strong
     transport authentication;
   - add authentication timeouts or worker recycling where needed.
9. Add safe regression checks:
   - dependency resolution rejects `kafka-python <2.3.2`;
   - SCRAM unit tests cover unreasonable iteration counts without a live broker;
   - failures surface as controlled exceptions or reconnects instead of frozen
     workers;
   - logs and metrics expose no secrets.
10. Add a PR body section named `CVE-2026-10143 operator actions` that states:
    - `kafka-python` versions before and after;
    - which clients used SCRAM;
    - whether any brokers were reachable without strong identity validation;
    - whether worker restart, credential review, or network tightening is
      required;
    - whether CVE-2026-10142 was remediated in the same PR or tracked
      separately;
    - which validation commands passed.
11. Run available validation: dependency install, lockfile integrity, unit
    tests, Kafka client tests, container build, SBOM refresh, and security
    scans.
12. Use PR title:
    `fix(sec): remediate CVE-2026-10143 in kafka-python`.

## Stop conditions

- No affected `kafka-python` package, fork, wrapper, image, or deployment is
  controlled by this repository.
- The only affected runtime is owned by another team or vendor.
- A fixed version cannot be consumed and the repository cannot safely carry a
  reviewed SCRAM-boundary patch or containment.
- Verification would require connecting to rogue brokers, exposing credentials,
  or using live customer traffic.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Verification - what the reviewer looks for

  • No controlled dependency source still resolves kafka-python <2.3.2.
  • SCRAM authentication rejects unreasonable broker-supplied iteration counts.
  • Authentication failures do not freeze consumers, producers, or admin clients.
  • Broker identity validation is documented where the repository owns it.
  • Validation covers the vulnerable code path without rogue-broker testing.

Output contract

  • Reviewer-ready PR upgrading controlled kafka-python references to 2.3.2+ and refreshing lockfiles, images, SBOMs, and generated reports.
  • Safe regression coverage for dependency policy and SCRAM iteration rejection where this repository owns wrappers or forks.
  • Operator notes for SCRAM clients, broker identity validation, worker restarts, credential review, and whether CVE-2026-10142 was fixed in the same change.
  • TRIAGE.md when the repository does not control the vulnerable dependency, runtime, broker boundary, or safe verification path.

Watch for

  • Updating the package while keeping old versions in worker images, notebooks, or internal tools.
  • Treating SCRAM alone as secure while TLS broker identity is weak or absent.
  • Timeouts that detect the freeze but leave the process unable to recover.
  • Fixing this CVE while leaving the adjacent parser-frame bug (CVE-2026-10142) unresolved in the same package.

References