CVE-2026-39892

What it actually does

The flaw is a buffer overflow in Python cryptography versions 45.0.0 through 46.0.6. When an API that accepts Python buffer objects, such as Hash.update(), receives a non-contiguous buffer, the library can read or write outside the expected memory bounds. At minimum, this can cause memory corruption and process crashes; depending on how the vulnerable API is reached and how memory is laid out, it may also create undefined behavior in the hosting Python process. The issue is in a widely used cryptographic dependency, so exposure is often indirect through applications, frameworks, agents, and services that bundle or depend on cryptography.

Why it matters to the business

Applications that use affected versions of cryptography may be vulnerable to reliability failures or potentially more serious memory-safety consequences if attacker-controlled input can be passed into cryptographic operations as a non-contiguous buffer. The most likely operational impact is unexpected service crashes or degraded availability in Python-based applications. Because cryptography is a foundational library used across authentication, TLS, signing, encryption, and certificate-handling workflows, affected versions can be present deep in dependency chains. Although the EPSS score is currently low, there is no CISA KEV listing, no ransomware association, and no known public exploit maturity, the high CVSS score and memory-safety nature of the bug make prompt dependency remediation important.

How an attack unfolds

An attacker first identifies an application or service using a vulnerable cryptography release. The vulnerable condition is only reachable if attacker-controlled data or objects can influence a Python buffer object passed into cryptography APIs that accept buffers, such as hashing update functions. The attacker then causes the application to process a specially shaped non-contiguous buffer, for example through an upstream library, plugin, deserialization path, numerical array handling, file-processing workflow, or API path that converts user-controlled content into strided or sliced memory. When the application passes that non-contiguous buffer to the vulnerable cryptography API, cryptography mishandles the buffer layout and may access memory out of bounds. Successful exploitation would likely manifest as a Python worker crash, service restart, segmentation fault, or other memory-corruption symptom. There are currently no known named threat actors, KEV listing, ransomware campaigns, or public exploit maturity associated with this vulnerability, so exploitation assessment should focus on exposure and crash/abnormality evidence rather than known attacker tooling.

How to fix it

Upgrade cryptography to version 46.0.7 or later everywhere it is installed, including direct dependencies, transitive dependencies, vendored packages, container images, serverless packages, build artifacts, virtual environments, and embedded Python runtimes. Rebuild and redeploy applications after upgrading, because Python services often package dependency versions at build time. If immediate upgrade is not possible, reduce exposure by preventing untrusted users from influencing buffer-like objects passed to cryptography APIs, normalizing buffer inputs to contiguous bytes before cryptographic operations, and adding guardrails around workflows that process sliced, strided, or non-contiguous memory objects. Pin dependency constraints to exclude affected versions, for example by requiring cryptography>=46.0.7, and regenerate lockfiles so downstream builds cannot resolve to vulnerable releases.

How to confirm the fix worked

Confirm remediation by inventorying installed package versions and verifying that no runtime, container, virtual environment, or build artifact contains cryptography versions 45.0.0 through 46.0.6. Use package-manager inspection such as pip show cryptography, pip freeze, poetry show cryptography, pipenv graph, conda list cryptography, or software composition analysis tooling. Validate container and deployment artifacts, not only source repositories, because vulnerable wheels may be embedded in images or deployment bundles. Run application smoke tests for cryptographic workflows after upgrading. If custom code passes memoryview, NumPy arrays, bytearray slices, or other buffer-like objects into cryptography APIs, add tests that cover non-contiguous input and verify the application either converts it to contiguous bytes or runs safely on cryptography 46.0.7 or later.

Typical attack path

1. Find a Python application, service, worker, or packaged product that includes cryptography versions 45.0.0 through 46.0.6.
2. Identify a remotely reachable or otherwise attacker-influenced code path that performs hashing, signing, encryption, certificate parsing, or other cryptographic operations using cryptography APIs that accept Python buffers.
3. Supply input that an application or dependency converts into a non-contiguous Python buffer, such as a sliced, strided, or otherwise non-contiguous memoryview-like object.
4. Trigger the vulnerable API call, such as Hash.update(), with that non-contiguous buffer.
5. Cause out-of-bounds memory access, leading to memory corruption, process crash, or other undefined behavior in the Python process.
6. Repeat requests as needed to create denial of service or probe for exploitability in the hosting process.

How to detect it

There are no publicly known exploit-specific indicators, named threat actor tradecraft, KEV activity, or ransomware associations for this vulnerability. Detection should focus on identifying vulnerable deployments and investigating suspicious crash patterns in services that used cryptography 45.0.0 through 46.0.6. Review application logs, Python runtime logs, container orchestration events, systemd journals, crash dumps, core dumps, web/API access logs, EDR telemetry, and process supervisor logs for abrupt Python worker exits, segmentation faults, repeated restarts, or denial-of-service-like request bursts correlated with cryptographic processing endpoints. Look for crashes occurring shortly after requests that upload or process files, arrays, serialized objects, certificates, signatures, tokens, encrypted blobs, or other data that may be passed into hashing or cryptographic APIs. For forensics, preserve core dumps and compare stack traces for frames involving cryptography, OpenSSL bindings, hash update routines, or Python buffer handling. Because reliable IOCs are not available, absence of known indicators should not be treated as evidence of non-exploitation.

What your security team should do

• Treat this as a priority dependency update because it is a high-severity memory-safety issue in a foundational Python cryptography library, even though EPSS is currently low and it is not listed in CISA KEV.
• Search all repositories, lockfiles, SBOMs, virtual environments, container images, and deployed artifacts for cryptography versions 45.0.0 through 46.0.6.
• Upgrade or enforce dependency constraints requiring cryptography 46.0.7 or later, then rebuild and redeploy affected applications.
• Prioritize externally exposed Python services, file-processing systems, API gateways, authentication services, certificate-processing tools, and workloads that process user-supplied structured data or arrays.
• Review code and dependencies for cryptography API calls that accept buffer inputs, especially Hash.update() and similar update-style methods, and normalize untrusted buffer-like input to contiguous bytes where practical.
• Monitor for unexplained Python process crashes, segmentation faults, worker restarts, and denial-of-service patterns in services that previously ran affected versions.
• Add SCA or CI policy checks to prevent reintroduction of vulnerable cryptography versions in future builds.