Improper Input ValidationWeakness · CWE-20

CVE-2026-45615

HIGH · 8.2 CVSS v3.1 Published 2026-05-29
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
91/100
Remediation priority · Urgent
Remotely reachable No privileges Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
mouse07410/asn1c is an ASN.1 compiler. In 1.4 and earlier, a memory safety vulnerability was identified in the OER decoding skeleton files generated by asn1c (specifically INTEGER_oer.c). When parsing a maliciously crafted, zero-length OER payload for a variable-length, non-negative INTEGER type, the decoder fails to validate the required bytes before extracting the Most Significant Bit (MSB). This forces a precise 1-byte Heap Out-of-Bounds (OOB) Read. Because asn1c generated code is primarily deployed to parse untrusted network inputs (such as V2X network protocols, 5G telecom headers, or X.509 certificates), when the decoder processes untrusted network-originated input, a remote attacker can exploit this to cause a Denial of Service (DoS) or trigger incorrect integer interpretation in downstream applications (e.g., protocol state poisoning or logic bypass).

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

A heap out-of-bounds read vulnerability exists in asn1c-generated OER decoder code for INTEGER types. When parsing a zero-length OER payload for variable-length non-negative INTEGER, the decoder fails to validate that sufficient bytes exist before extracting the Most Significant Bit, causing a precise 1-byte OOB read that can lead to DoS or incorrect integer interpretation.

MitigationUsers of asn1c should update to a patched version of the compiler once available and regenerate their decoding code. Until then, input validation at the network boundary or fuzzing of OER INTEGER parsing is recommended as a defensive measure.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
Low
Availability
High

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify asn1c-generated code usage
    Search for INTEGER_oer.c files in your codebase or dependencies, or check if your application links against asn1c-generated OER decoder libraries
    Affected if Codebase contains OER decoders generated by asn1c for INTEGER types
  2. Verify OER decoding is enabled
    Check application configuration or code for OER (Open Extended Encoding Rules) decoding usage, particularly in V2X, 5G, or X.509 certificate handling modules
    Affected if OER decoding is active for INTEGER values in any of these protocol handlers
  3. Locate INTEGER type definitions
    Inspect ASN.1 schema files or generated C header files for INTEGER type definitions that use variable-length encoding (non-negative INTEGERs with dynamic length)
    Affected if Application processes variable-length non-negative INTEGER types via OER
  4. Test for zero-length INTEGER handling
    Review decoder code in INTEGER_oer.c or test with crafted zero-length OER payloads to observe if bounds checking exists before byte extraction
    Affected if No validation is performed to ensure sufficient bytes exist before MSB extraction; zero-length INTEGER payloads are processed without rejection
  5. Check heap behavior under malformed input
    Run application with memory debugging tools (ASan/MSan) while feeding zero-length OER INTEGER payloads to detect heap out-of-bounds read access
    Affected if Memory sanitizer reports out-of-bounds read 1 byte beyond buffer allocation

Your environment is affected if you use asn1c-generated OER decoders that handle variable-length non-negative INTEGER types without validating payload length before byte extraction.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Users of asn1c should update to a patched version of the compiler once available and regenerate their decoding code. Until then, input validation at the network boundary or fuzzing of OER INTEGER parsing is recommended as a defensive measure.

Recommended fix Moderate confidence

asn1c version > 1.4

  1. 1. Identify all deployments of applications using asn1c-generated decoder code for OER-encoded INTEGER types
  2. 2. Obtain the latest version of asn1c (version greater than 1.4) from the official repository
  3. 3. Re-compile all ASN.1 schemas using the updated asn1c compiler to regenerate the decoder skeleton files
  4. 4. Replace the vulnerable INTEGER_oer.c (and related OER decoding skeleton files) in your codebase with the newly generated versions
  5. 5. Rebuild and redeploy all affected applications
  6. 6. Test the redeployed applications with zero-length OER INTEGER payloads to verify the vulnerability is remediated
  7. 7. Monitor for any downstream integer interpretation issues in protocol processing
Caveat The regenerated decoder code should be functionally equivalent; however, any code that depends on the previous incorrect integer interpretation behavior may need review

Generated from the published advisory — verify against the referenced sources before acting.

Have this fixed Scoped from the published advisory
  • Consultation6.0 h
  • Implementation12.0 h
  • Testing8.0 h
  • Review / QA4.0 h
30.0 hours of engineering $5,280
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $8,448.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-45615 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-45615 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data