CVE-2026-33936: python-ecdsa’s DER Length Validation Bug That Turned Malformed Input into Crashy Key Parsing

Whenever a library accepts externally supplied key material or structured binary input, correctness is not just a quality issue. It is a security property.

If malformed input is accepted when it should be rejected, downstream code starts making assumptions on top of invalid state. That is where bugs stop being “just parsing mistakes” and start becoming vulnerabilities.

Why This Surface Was Worth Looking At

DER parsing is one of those areas where small validation mistakes can have outsized effects.

The bug class is straightforward:

• length field says one thing
• actual buffer contains something shorter
• parser trusts the claim too far
• later code operates on state that should never have existed

That is exactly the kind of boundary failure worth checking in security review.

I was not looking for weird cryptographic behavior here. I was looking for trust failures in structured-input handling.

That was the right place to look.

Root Cause

The root issue was improper validation of DER length fields when parsing malformed or truncated input.

Specifically, ecdsa.der.remove_octet_string() accepted input where the declared DER length exceeded the number of bytes actually available in the buffer.

So instead of rejecting malformed DER like this:

• declared length: 4096
• actual remaining bytes: 3

the helper accepted it and returned truncated content as if it were valid.

That is already a bug.

But the stronger impact showed up downstream.

Because malformed input was accepted instead of rejected at the boundary, SigningKey.from_der() could later reach an internal exception path and raise:

That matters because this is not the kind of failure a caller expects from malformed input. The correct behavior is a clean parse rejection such as UnexpectedDER or ValueError.

So the vulnerability was not “IndexError exists” in isolation.

The real vulnerability was this:

• malformed DER length fields were not validated correctly
• truncated input crossed the parse boundary
• downstream code hit an internal exception path as a consequence

That is one bug chain, not two unrelated issues.

Why This Is a Security Issue, Not Just Bad Parsing Hygiene

A parser rejecting malformed input is not a cosmetic improvement. It is part of the security model.

The important distinction here is not whether the input was invalid. Of course it was invalid.

The important distinction is how the library behaved in the face of invalid input.

There is a real difference between:

• rejecting malformed DER cleanly at the boundary, and
• accepting malformed DER, continuing deeper, and crashing with an internal exception

The first is robust behavior.

The second creates application-level risk if software parses untrusted DER and assumes library failures stay within expected exception types.

That is why this was properly classified as a vulnerability rather than merely a parser-quality bug.

Proof of Concept

I used two PoCs because they demonstrated two different parts of the same bug chain.

PoC 1: truncated DER accepted

The first PoC showed that remove_octet_string() accepted truncated DER whose declared length exceeded the available buffer.

That established the core validation failure:

• the buffer was shorter than the encoded length
• the helper should have rejected it
• it did not

PoC 2: deterministic internal exception path

The second PoC showed the more important downstream effect: malformed DER supplied to SigningKey.from_der() deterministically triggered an internal IndexError before the fix.

That established the security-relevant impact:

• malformed input crossed the boundary
• parsing continued too far
• library code raised an internal exception instead of a clean parse error

That is a much stronger result than “parser accepted weird bytes.”

It shows boundary failure plus real operational consequence.

Why the PoCs Were Chosen This Way

The first PoC proves root cause.

The second PoC proves impact.

That split matters.

A lot of reports stop at:

“this parser accepts malformed data.”

That is useful, but not always enough to show why the bug matters.

In this case, the stronger report was:

• malformed DER is wrongly accepted
• that acceptance is not self-contained
• it can propagate into a crashy internal exception path in key parsing

That makes the security story much clearer.

Fix Analysis

The fix was minimal and correct.

The patch added the same missing safety rule already used in remove_sequence():

the declared length must fit within the available buffer

That check was applied to:

• remove_constructed()
• remove_implicit()
• remove_octet_string()

Once those bounds checks were added, malformed/truncated DER was rejected immediately with:

And the PoC that previously triggered IndexError no longer reached the internal exception path. It failed cleanly during parsing, which is exactly what should have happened from the start.

This is the kind of fix you want to see in a parser vulnerability:

• narrow
• explicit
• directly tied to the trust boundary
• easy to reason about
• reinforced with regression coverage

No redesign. No ambiguity. Just correct validation where it was missing.

Regression Tests

I also added focused regression tests to make sure this exact class of malformed DER stays rejected.

The new tests cover truncated-length rejection for:

• remove_octet_string
• remove_constructed
• remove_implicit

That was important because the bug was not about one weird runtime path. It was about a validation rule that needed to hold consistently across related DER helpers.

After the fix and tests were added, the full suite passed locally:

That matters in real disclosure work.

A fix is much stronger when it comes with tests that lock the boundary down.

Severity and Classification

This issue was reasonably classified as Moderate.

The key impact here is availability / robustness, not confidentiality or integrity.

The advisory classification was:

• CWE-20: Improper Input Validation
• CVSS:

That makes sense.

The claim is not that malformed DER lets an attacker execute code. The claim is that malformed DER could trigger unexpected internal exceptions in software that parses untrusted DER material using this library.

That is a real and defensible DoS-style parsing bug.

Disclosure

This issue was reported privately through GitHub Security Advisories.

The report included:

• the validation bug
• a deterministic downstream IndexError reproducer
• a minimal patch
• regression tests
• local verification results

The maintainer validated the issue, requested that the fix land with unit tests, and the coordinated fix proceeded through the GHSA temporary private fork workflow.

During CVE handling, GitHub initially refused assignment because the advisory text looked like it might describe more than one vulnerability. The clarification was simple:

this was a single vulnerability with a single root cause — improper DER length validation — and the SigningKey.from_der() IndexError was a downstream consequence of that same malformed-input acceptance, not a separate independently fixable issue.

That clarification was enough, and the issue was assigned:

CVE-2026-33936

What This Bug Actually Teaches

The lesson here is not “DER is tricky.”

Everybody already knows DER is tricky.

The real lesson is this:

malformed structured input must be rejected at the exact point where the parser knows it is invalid.

If you miss that boundary, later code ends up operating on assumptions that are no longer trustworthy.

That is how low-level parsing mistakes become security issues.

This bug also reinforces something important about writeups and triage:

• root cause matters
• impact path matters
• and connecting the two cleanly matters even more

“Malformed input accepted” was the start of the story.

“Malformed input accepted, then propagated into an internal exception path during key parsing” was the complete story.

That distinction helped make the case clearly and correctly.

Key Points

• DER parsers are security boundaries
• malformed length fields must be validated against the actual buffer
• acceptance of truncated structured input is already a bug
• it becomes a stronger vulnerability when downstream parsing reaches internal exception paths
• clean parse rejection is part of secure behavior
• minimal validation fixes plus regression tests are exactly what you want in parser bug remediation

Final Words

This vulnerability was not about exotic crypto.

It was about a parser trusting malformed input longer than it should have.

A truncated DER length field crossed the boundary, survived validation when it should have been rejected, and eventually caused crashy behavior in key parsing.

That is why this became CVE-2026-33936.

Fixed by enforcing proper DER length bounds checks in the affected helper parsers.