CVE-2026-34610
Is CVE-2026-34610 real, exploitable, or a false positive? Here's the community verdict.
signals
public sources
Moderate signals. Triage by your actual exposure and reachability.
baseline read
auto · not a community verdict
Low signal — verdict needed
Few public signals point to active risk. Whether a scanner hit here is a true or false positive depends on your version and config — community verdicts decide.
Based on CVSS · FIRST EPSS
Confirm or dispute →CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
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.
References
Published
Embed this verdict
[](https://www.truepositive.app/cve/CVE-2026-34610)<a href="https://www.truepositive.app/cve/CVE-2026-34610"><img src="https://www.truepositive.app/cve/CVE-2026-34610/badge.svg" alt="TruePositive verdict for CVE-2026-34610"></a>Live badge that updates automatically as the community verdict changes.
Community ground truth
Be the first practitioner to weigh in
So far this is only TruePositive's editorial baseline from public sources. Add your real-world verdict below — it becomes the signal the next person triaging this relies on.
🥇 The first 50 practitioners to contribute earn a Founding Contributor badge.
In your experience, is this finding real and exploitable?
awaiting field verdictsNo account needed. Anonymous verdicts post as an unverified signal. Log in to make yours verified and earn reputation.
Field notes & remediation
Verdicts are the quick signal. Notes are the evidence and fixes behind them.
No notes yet. Be the first to share what you saw, or a fix that worked.
Add a field note or remediationoptional
Related CVEs
Same weakness: CWE-681.
- CVE-2026-4602HIGH 7.5Real · low riskEPSS 0%
Versions of the package jsrsasign before 11.1.1 are vulnerable to Incorrect Conversion between Numeric Types due to handling negative exponents in ext/jsbn2.js. An attacker can force the computation of incorrect modular inverses and break signature verification by calling modPow with a negative exponent.
- CVE-2026-24192HIGH 7.8Real · low riskEPSS 0%
NVIDIA Display Driver for Linux contains a vulnerability where an attacker could cause an incorrect conversion between numeric types, leading to a heap buffer overflow. A successful exploit of this vulnerability might lead to denial of service, escalation of privileges, information disclosure, data tampering, and code execution.
- CVE-2026-9143LOW 3.7EPSS 0%
There is an incorrect conversion between numeric types vulnerability in NI grpc-device due to missing range checks in CodeGen. This may silently discard high bits if a size value exceeded the target type's range. This affects NI grpc-device 2.17.0 and prior versions.
- CVE-2026-53133HIGH 7.8Real · low riskEPSS 0%
In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.