CVE-2026-45784

What it actually does

The flaw is a heap memory corruption bug in `CipherCtxRef::cipher_update_inplace` when it is used with AES key-wrap-with-padding ciphers: `EVP_aes_128_wrap_pad`, `EVP_aes_192_wrap_pad`, or `EVP_aes_256_wrap_pad`. For inputs whose length is not a multiple of 8, the output buffer is sized too small and OpenSSL can write up to 7 bytes beyond the caller-provided buffer or vector. If an attacker can influence the plaintext length passed into this operation, they may be able to trigger attacker-influenced heap corruption. The most likely technical outcomes are process crash, denial of service, corrupted cryptographic operation state, or undefined behavior; reliable code execution would depend on allocator behavior, surrounding memory layout, and application-specific usage.

Why it matters to the business

Applications that perform AES key wrapping with padding on attacker-influenced data may be vulnerable to crashes or instability in security-sensitive workflows such as token handling, key management, encrypted payload processing, or protocol handling. Although this issue is not currently listed in CISA KEV, has no known public exploit maturity, and has a low EPSS score, it affects cryptographic code paths where failures can disrupt authentication, encryption services, or key-management operations. Organizations should prioritize patching systems that expose AES key-wrap-with-padding operations to untrusted or semi-trusted input.

How an attack unfolds

An attacker first identifies an application or service that uses the affected in-place cipher update routine with AES key-wrap-with-padding. The attacker then submits data that causes the application to wrap or process plaintext whose length is not a multiple of 8. Because the vulnerable routine sizes the caller buffer incorrectly, OpenSSL writes a small number of bytes past the end of the allocated buffer. This can corrupt adjacent heap metadata or neighboring application objects. In many deployments, the practical result is a crash or service restart; in more favorable memory layouts, the corruption could potentially be shaped into more serious memory-safety impact. Exploitation requires the vulnerable cipher mode to be used and the attacker to influence the processed plaintext length, so generic OpenSSL use or unrelated AES modes are not sufficient.

How to fix it

Upgrade the affected library or package that provides `CipherCtxRef::cipher_update_inplace` to a fixed release when available from the vendor or package maintainer. Because no exact fixed versions were provided in the input, use vendor advisories, package lockfiles, and software composition analysis results to identify the corrected version for the specific package in use. As a mitigation until patching is complete, avoid using `cipher_update_inplace` with `EVP_aes_128_wrap_pad`, `EVP_aes_192_wrap_pad`, or `EVP_aes_256_wrap_pad` on attacker-influenced data; use a non-in-place API that allocates a correctly sized output buffer, or enforce safe buffer sizing based on the maximum possible padded output length. Where feasible, reject or normalize untrusted inputs that would reach AES key-wrap-with-padding with non-multiple-of-8 lengths, but do not treat input filtering as a complete fix.

How to confirm the fix worked

Confirm whether the affected package is present by reviewing dependency manifests, lockfiles, SBOMs, and built artifacts for the cryptographic binding or library that exposes `CipherCtxRef::cipher_update_inplace`. Confirm exposure by searching source code for `cipher_update_inplace` and AES key-wrap-with-padding cipher selections such as `EVP_aes_128_wrap_pad`, `EVP_aes_192_wrap_pad`, and `EVP_aes_256_wrap_pad`. After upgrading, verify that dependency resolution selects the fixed version and that no older vulnerable copy remains in statically linked binaries, containers, vendored source trees, or transitive dependencies. Add regression tests that call the relevant AES key-wrap-with-padding paths with non-multiple-of-8 input lengths under AddressSanitizer, Valgrind, Miri where applicable, or equivalent memory-checking tooling to confirm that no heap out-of-bounds write occurs.

Typical attack path

1. Find an exposed application feature, API, protocol handler, or key-management workflow that uses AES key-wrap-with-padding.
2. Provide or influence plaintext/input data whose length is not a multiple of 8.
3. Trigger processing through `CipherCtxRef::cipher_update_inplace` with `EVP_aes_128_wrap_pad`, `EVP_aes_192_wrap_pad`, or `EVP_aes_256_wrap_pad`.
4. Cause OpenSSL to write up to 7 bytes past the end of the allocated buffer.
5. Observe application crash, memory allocator failure, corrupted cryptographic processing, or other undefined behavior.
6. Repeat with varied input lengths and heap state to determine whether the corruption is controllable beyond denial of service.

How to detect it

There are no known CVE-specific exploitation indicators, network signatures, or public exploit artifacts for this issue. Retrospective detection should focus on applications that use AES key-wrap-with-padding and review crash logs, application logs, core dumps, sanitizer reports, and memory allocator diagnostics from the period since the issue was introduced or publicly disclosed. Look for crashes occurring immediately after key-wrapping, encrypted payload processing, token/key import-export, or cryptographic envelope handling, especially when requests contain variable-length attacker-controlled data. Useful forensic sources include application logs, service supervisor restart logs, container termination reasons, kernel OOM/crash messages, core dumps, AddressSanitizer or Valgrind findings, and EDR telemetry showing repeated process crashes in services that link the affected library. Because heap corruption symptoms may appear away from the original write, absence of explicit AES-related log messages does not rule out exploitation.

What your security team should do

• Inventory applications and libraries that use AES key-wrap-with-padding, especially key-management, token, authentication, encryption, and message-protection components.
• Prioritize remediation for externally reachable services or APIs where untrusted users can influence plaintext length passed into AES key-wrap-with-padding operations.
• Upgrade the affected package to a vendor-fixed version and rebuild/redeploy statically linked binaries and containers.
• Search code for `cipher_update_inplace` combined with `EVP_aes_128_wrap_pad`, `EVP_aes_192_wrap_pad`, or `EVP_aes_256_wrap_pad` to identify vulnerable call sites.
• Temporarily replace in-place processing with safely sized out-of-place encryption/wrapping routines where immediate upgrade is not possible.
• Enable crash monitoring and memory-safety telemetry for services using the affected cryptographic code paths.
• Treat repeated crashes around key-wrapping, encrypted payload handling, or allocator corruption as suspicious until patched, even though there is no known exploitation at this time.