CVE-2026-34610
leancrypto: Integer truncation in X.509 name parser enables certificate identity impersonation
The leancrypto library is a cryptographic library that exclusively contains only PQC-resistant cryptographic algorithms. Prior to version 1.7.1, lc_x509_extract_name_segment() casts size_t vlen to uint8_t when storing the Common Name (CN) length. An attacker who crafts a certificate with CN = victim's CN + 256 bytes padding gets cn_size = (uint8_t)(256 + N) = N, where N is the victim's CN length. The first N bytes of the attacker's CN are the victim's identity. After parsing, the attacker's certificate has an identical CN to the victim's — enabling identity impersonation in PKCS#7 verification, certificate chain matching, and code signing. This issue has been patched in version 1.7.1.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- High
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- None
- Integrity
- High
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
5.9
leancrypto: Integer truncation in X.509 name parser enables certificate identity impersonation
The leancrypto library is a cryptographic library that exclusively contains only PQC-resistant cryptographic algorithms. Prior to version 1.7.1, lc_x509_extract_name_segment() casts size_t vlen to uint8_t when storing the Common Name (CN) length. An attacker who crafts a certificate with CN = victim's CN + 256 bytes padding gets cn_size = (uint8_t)(256 + N) = N, where N is the victim's CN length. The first N bytes of the attacker's CN are the victim's identity. After parsing, the attacker's certificate has an identical CN to the victim's — enabling identity impersonation in PKCS#7 verification, certificate chain matching, and code signing. This issue has been patched in version 1.7.1.
- Record
CVE-2026-34610- CVSS 3.1
- 5.9 Medium
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N - Weakness
- CWE-681
- Updated
- 2026-11-02
EUVDEUVD-2026-18466
5.9
The leancrypto library is a cryptographic library that exclusively contains only PQC-resistant cryptographic algorithms. Prior to version 1.7.1, lc_x509_extract_name_segment() casts size_t vlen to uint8_t when storing the Common Name (CN) length. An attacker who crafts a certificate with CN = victim's CN + 256 bytes padding gets cn_size = (uint8_t)(256 + N) = N, where N is the victim's CN length. The first N bytes of the attacker's CN are the victim's identity. After parsing, the attacker's certificate has an identical CN to the victim's — enabling identity impersonation in PKCS#7 verification, certificate chain matching, and code signing. This issue has been patched in version 1.7.1.
- Record
EUVD-2026-18466- CVSS 3.1
- 5.9 Medium
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N - Updated
- 2026-11-02
NVD
5.9
The leancrypto library is a cryptographic library that exclusively contains only PQC-resistant cryptographic algorithms. Prior to version 1.7.1, lc_x509_extract_name_segment() casts size_t vlen to uint8_t when storing the Common Name (CN) length. An attacker who crafts a certificate with CN = victim's CN + 256 bytes padding gets cn_size = (uint8_t)(256 + N) = N, where N is the victim's CN length. The first N bytes of the attacker's CN are the victim's identity. After parsing, the attacker's certificate has an identical CN to the victim's — enabling identity impersonation in PKCS#7 verification, certificate chain matching, and code signing. This issue has been patched in version 1.7.1.
- Record
CVE-2026-34610- CVSS 3.1
- 5.9 Medium
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N - Weakness
- CWE-681
- Updated
- 2026-11-02
OSV
5.9
leancrypto: Integer truncation in X.509 name parser enables certificate identity impersonation
The leancrypto library is a cryptographic library that exclusively contains only PQC-resistant cryptographic algorithms. Prior to version 1.7.1, lc_x509_extract_name_segment() casts size_t vlen to uint8_t when storing the Common Name (CN) length. An attacker who crafts a certificate with CN = victim's CN + 256 bytes padding gets cn_size = (uint8_t)(256 + N) = N, where N is the victim's CN length. The first N bytes of the attacker's CN are the victim's identity. After parsing, the attacker's certificate has an identical CN to the victim's — enabling identity impersonation in PKCS#7 verification, certificate chain matching, and code signing. This issue has been patched in version 1.7.1.
- Record
CVE-2026-34610- CVSS 3.1
- 5.9 Medium
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N - Weakness
- CWE-681
- Updated
- 2026-11-02
OSVopenSUSE-SU-2026:10563-1 No score
leancrypto-devel-1.7.2-1.1 on GA media
These are all security issues fixed in the leancrypto-devel-1.7.2-1.1 package on the GA media of openSUSE Tumbleweed.
- Record
openSUSE-SU-2026:10563-1- Updated
- 2026-11-02
OSVopenSUSE-SU-2026:20783-1 No score
Security update for leancrypto
This update for leancrypto fixes the following issues
Security issue:
- CVE-2026-34610: The leancrypto library is a cryptographic library that exclusively contains only PQC-resistant cryptographic algorithms. Prior to version 1.7.1, lc_x509_extract_name_segment() casts size_t vlen to uint8_t when stori (bsc#1261382).
Non security issues:
- gnutls Illegal instruction lc_kyber_768_kem_dec_selftest (bsc#1253654).
- gnutls: test pqc-hybrid-kx fails on Nehalem or older CPU (bsc#1254370).
Changes for leancrypto:
- Calculate the FIPS HMAC for the leancrypto and the leancrypto-fips libraries. (bsc#1262399)
- Fix build on kernel 7.0
- Pick fix for ABI issue in AVX2 assembly for Curve448 causing test failures when building with GCC 16.
- Update to 1.7.2:
- Fix RDSEED counter
- Process code by AI code checkers and apply suggested cosmetic fixes
- Heap memory: always munlock all mlock'ed memory
- Fix ChaCha20 on Apple compiled with XCode 26.4
- Fix a potential crasher with Base64 and applied various fixes reported
- Add X.509 certificate signing request (CSR) generator and parser
- ML-DSA: add lc_dilithium_pk_from_sk API to derive the PK from a given SK
- SLH-DSA: add lc_sphincs_pk_from_sk API to derive the PK from a given SK
- ML-KEM: add lc_kyber_pk_from_sk API to derive the PK from a given SK
- AES-CT: fix non-aligned data processing - reported
- Apply suggestions from Claude code
- X.509: Enforce path length restriction
- Update to 1.7.1
- Offer a means to select the AES-C constant time / S-Box implementation via lc_init API
- use the AES-C constant time implementation by default - it is about 3 times slower than the AES-C S-Box implementation, but more secure. As the leancrypto library is about secure by default, the CT implementation is just right. Furthermore, if a caller wants to have the faster AES-C S-Box, he can call lc_init(LC_INIT_AES_SBOX) at the beginning.
- FIPS: mark only seeded DRBG instances as FIPS-approved
- ASN.1: add lc_x509_cert_check_issuer_ca convenience function
- Enable side-channel-resistant AES implementation (and thus enable respective Timecop tests)
- Fix some side channel test failures (all failures are due to test case issues, and no real problems)
- AARCH64: enable GCS support
- Add PKCS#8 support for ML-DSA following RFC9881 including full support for the seed or full keys. The change adds OpenSSL interoperability testing as well. NOTE: The raw on-disk private key format that is generated with lc_x509_generate --create-keypair changed to comply with RFC9881.
- Add PKCS#8 support for SLH-DSA. The change adds OpenSSL interoperability testing as well. NOTE: The raw on-disk private key format that is generated with lc_x509_generate --create-keypair changed to dump the raw key instead of wrapping it into a BIT STRING to comply with OpenSSL's format.
- Provide full PKCS#7 interoperability with OpenSSL: OpenSSL artificially orders the parsing of the authenticated attributes. This implies that the message digest part of the authenticated attributes is parsed as last entry. This ordering is important for the signature generation and verification. Furthermore, for ML-DSA/SLH-DSA, the authenticated attributes are signed with the pure algorithm instead of the pre-hashed operation as suggested by RFC5652 section 9.2.
- ML-KEM/DSA: add safety measures against compilers trying to reason about code they should not reason about. Derived from https://github.com/pq-code-package/ml[dsa|kem]-native/
- ML-DSA: reduce amount of duplicate code compilation suggested
- ML-DSA: fix bug in poly_uniform which, however, is unlikely to be triggered
- ChaCha20: fix crasher when assembler support is not compiled
- Add AES constant time C implementation accessible with the lc_aes_*ct references. Yet, it is about 3 times slower than the default C implementation. Thus is is only provided if somebody truly relies on a constant time implementation.
- Fix bsc#1254370,…
- Record
openSUSE-SU-2026:20783-1- Updated
- 2026-11-02
OSVSUSE-SU-2026:21754-1 No score
Security update for leancrypto
This update for leancrypto fixes the following issues
Security issue:
- CVE-2026-34610: The leancrypto library is a cryptographic library that exclusively contains only PQC-resistant cryptographic algorithms. Prior to version 1.7.1, lc_x509_extract_name_segment() casts size_t vlen to uint8_t when stori (bsc#1261382).
Non security issues:
- gnutls Illegal instruction lc_kyber_768_kem_dec_selftest (bsc#1253654).
- gnutls: test pqc-hybrid-kx fails on Nehalem or older CPU (bsc#1254370).
Changes for leancrypto:
- Calculate the FIPS HMAC for the leancrypto and the leancrypto-fips libraries. (bsc#1262399)
- Fix build on kernel 7.0
- Pick fix for ABI issue in AVX2 assembly for Curve448 causing test failures when building with GCC 16.
- Update to 1.7.2:
- Fix RDSEED counter
- Process code by AI code checkers and apply suggested cosmetic fixes
- Heap memory: always munlock all mlock'ed memory
- Fix ChaCha20 on Apple compiled with XCode 26.4
- Fix a potential crasher with Base64 and applied various fixes reported
- Add X.509 certificate signing request (CSR) generator and parser
- ML-DSA: add lc_dilithium_pk_from_sk API to derive the PK from a given SK
- SLH-DSA: add lc_sphincs_pk_from_sk API to derive the PK from a given SK
- ML-KEM: add lc_kyber_pk_from_sk API to derive the PK from a given SK
- AES-CT: fix non-aligned data processing - reported
- Apply suggestions from Claude code
- X.509: Enforce path length restriction
- Update to 1.7.1
- Offer a means to select the AES-C constant time / S-Box implementation via lc_init API
- use the AES-C constant time implementation by default - it is about 3 times slower than the AES-C S-Box implementation, but more secure. As the leancrypto library is about secure by default, the CT implementation is just right. Furthermore, if a caller wants to have the faster AES-C S-Box, he can call lc_init(LC_INIT_AES_SBOX) at the beginning.
- FIPS: mark only seeded DRBG instances as FIPS-approved
- ASN.1: add lc_x509_cert_check_issuer_ca convenience function
- Enable side-channel-resistant AES implementation (and thus enable respective Timecop tests)
- Fix some side channel test failures (all failures are due to test case issues, and no real problems)
- AARCH64: enable GCS support
- Add PKCS#8 support for ML-DSA following RFC9881 including full support for the seed or full keys. The change adds OpenSSL interoperability testing as well. NOTE: The raw on-disk private key format that is generated with lc_x509_generate --create-keypair changed to comply with RFC9881.
- Add PKCS#8 support for SLH-DSA. The change adds OpenSSL interoperability testing as well. NOTE: The raw on-disk private key format that is generated with lc_x509_generate --create-keypair changed to dump the raw key instead of wrapping it into a BIT STRING to comply with OpenSSL's format.
- Provide full PKCS#7 interoperability with OpenSSL: OpenSSL artificially orders the parsing of the authenticated attributes. This implies that the message digest part of the authenticated attributes is parsed as last entry. This ordering is important for the signature generation and verification. Furthermore, for ML-DSA/SLH-DSA, the authenticated attributes are signed with the pure algorithm instead of the pre-hashed operation as suggested by RFC5652 section 9.2.
- ML-KEM/DSA: add safety measures against compilers trying to reason about code they should not reason about. Derived from https://github.com/pq-code-package/ml[dsa|kem]-native/
- ML-DSA: reduce amount of duplicate code compilation suggested
- ML-DSA: fix bug in poly_uniform which, however, is unlikely to be triggered
- ChaCha20: fix crasher when assembler support is not compiled
- Add AES constant time C implementation accessible with the lc_aes_*ct references. Yet, it is about 3 times slower than the default C implementation. Thus is is only provided if somebody truly relies on a constant time implementation.
- Fix bsc#1254370,…
- Record
SUSE-SU-2026:21754-1- Updated
- 2026-11-02
OSVSUSE-SU-2026:21824-1 No score
Security update for leancrypto
This update for leancrypto fixes the following issues
Security issue:
- CVE-2026-34610: The leancrypto library is a cryptographic library that exclusively contains only PQC-resistant cryptographic algorithms. Prior to version 1.7.1, lc_x509_extract_name_segment() casts size_t vlen to uint8_t when stori (bsc#1261382).
Non security issues:
- gnutls Illegal instruction lc_kyber_768_kem_dec_selftest (bsc#1253654).
- gnutls: test pqc-hybrid-kx fails on Nehalem or older CPU (bsc#1254370).
Changes for leancrypto:
- Calculate the FIPS HMAC for the leancrypto and the leancrypto-fips libraries. (bsc#1262399)
- Fix build on kernel 7.0
- Pick fix for ABI issue in AVX2 assembly for Curve448 causing test failures when building with GCC 16.
- Update to 1.7.2:
- Fix RDSEED counter
- Process code by AI code checkers and apply suggested cosmetic fixes
- Heap memory: always munlock all mlock'ed memory
- Fix ChaCha20 on Apple compiled with XCode 26.4
- Fix a potential crasher with Base64 and applied various fixes reported
- Add X.509 certificate signing request (CSR) generator and parser
- ML-DSA: add lc_dilithium_pk_from_sk API to derive the PK from a given SK
- SLH-DSA: add lc_sphincs_pk_from_sk API to derive the PK from a given SK
- ML-KEM: add lc_kyber_pk_from_sk API to derive the PK from a given SK
- AES-CT: fix non-aligned data processing - reported
- Apply suggestions from Claude code
- X.509: Enforce path length restriction
- Update to 1.7.1
- Offer a means to select the AES-C constant time / S-Box implementation via lc_init API
- use the AES-C constant time implementation by default - it is about 3 times slower than the AES-C S-Box implementation, but more secure. As the leancrypto library is about secure by default, the CT implementation is just right. Furthermore, if a caller wants to have the faster AES-C S-Box, he can call lc_init(LC_INIT_AES_SBOX) at the beginning.
- FIPS: mark only seeded DRBG instances as FIPS-approved
- ASN.1: add lc_x509_cert_check_issuer_ca convenience function
- Enable side-channel-resistant AES implementation (and thus enable respective Timecop tests)
- Fix some side channel test failures (all failures are due to test case issues, and no real problems)
- AARCH64: enable GCS support
- Add PKCS#8 support for ML-DSA following RFC9881 including full support for the seed or full keys. The change adds OpenSSL interoperability testing as well. NOTE: The raw on-disk private key format that is generated with lc_x509_generate --create-keypair changed to comply with RFC9881.
- Add PKCS#8 support for SLH-DSA. The change adds OpenSSL interoperability testing as well. NOTE: The raw on-disk private key format that is generated with lc_x509_generate --create-keypair changed to dump the raw key instead of wrapping it into a BIT STRING to comply with OpenSSL's format.
- Provide full PKCS#7 interoperability with OpenSSL: OpenSSL artificially orders the parsing of the authenticated attributes. This implies that the message digest part of the authenticated attributes is parsed as last entry. This ordering is important for the signature generation and verification. Furthermore, for ML-DSA/SLH-DSA, the authenticated attributes are signed with the pure algorithm instead of the pre-hashed operation as suggested by RFC5652 section 9.2.
- ML-KEM/DSA: add safety measures against compilers trying to reason about code they should not reason about. Derived from https://github.com/pq-code-package/ml[dsa|kem]-native/
- ML-DSA: reduce amount of duplicate code compilation suggested
- ML-DSA: fix bug in poly_uniform which, however, is unlikely to be triggered
- ChaCha20: fix crasher when assembler support is not compiled
- Add AES constant time C implementation accessible with the lc_aes_*ct references. Yet, it is about 3 times slower than the default C implementation. Thus is is only provided if somebody truly relies on a constant time implementation.
- Fix bsc#1254370,…
- Record
SUSE-SU-2026:21824-1- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
leancryptoopenSUSE:Tumbleweed |
before 1.7.2-1.1 | 1.7.2-1.1 |
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | CVE List, EUVD, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-34610 is a medium vulnerability (CVSS 5.9) in Leancrypto, published April 2, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.17%, the 6th percentile. Fixed in leancrypto 1.7.2-1.1.
References
github.com/smuellerDD/leancrypto/security/advisories/GHSA-636g-jxv4-v4gr
github.com/smuellerDD/leancrypto/commit/5cdcbe12bd6c3d6e87e969972a580b44a74c3a6a
github.com/smuellerDD/leancrypto/releases/tag/v1.7.1
github.com/CVEProject/cvelistV5/tree/main/cves/2026/34xxx/CVE-2026-34610.json
nvd.nist.gov/vuln/detail/CVE-2026-34610
suse.com/support/update/announcement/2026/suse-su-202621754-1
Left out here: the rest of 3 source descriptions. The JSON record has them.