Uncaught exceptions/crashes when parsing malformed <![ marked sections in Python-Markdown 3.8 with extra extension

[keshavgoyal1744]

Description

While fuzz-testing the Python-Markdown library (version 3.8) with the extra extension enabled, I found that certain malformed inputs containing <![ sequences cause the parser to throw uncaught exceptions and crash. These inputs appear to break the parser's handling of XML-style marked sections, leading to errors like "expected name token" or "unknown status keyword."

Steps to Reproduce

1. Run the following test script (using Python-Markdown 3.8 with extra extension):

import markdown

print(markdown.__version__)

crash_inputs = [
    "<![",
    "<![>og))/uw_     f{tv+pAr$Ss+[6;^{=<:>g2oV|.pdTMu(Q-E#",
    "<![ g'\"7z5r7cojSO;2LAo0(1Vv5G>,-P",
]

for i, crash_input in enumerate(crash_inputs, 1):
    print(f"\nTesting crash input #{i}:\n{repr(crash_input)}")
    try:
        output = markdown.markdown(crash_input, extensions=["extra"])
        print("No crash, output:")
        print(output)
    except Exception as e:
        print(f"Crash confirmed! Exception:\n{e}")

2. Observe that the first three inputs cause exceptions, crashing the parser.

Expected Behavior

The parser should gracefully handle or sanitize malformed <![ marked sections without raising uncaught exceptions.

Actual Behavior

Uncaught exceptions are raised, such as:

3.8

Testing crash input #1:
'<!['
Crash confirmed! Exception:
expected name token at '<![\n\n'

Testing crash input #2:
'<![>og))/uw_     f{tv+pAr$Ss+[6;^{=<:>g2oV|.pdTMu(Q-E#'
Crash confirmed! Exception:
expected name token at '<![>og))/uw_     f{t'

Testing crash input #3:
'<![ g\'"7z5r7cojSO;2LAo0(1Vv5G>,-P'
Crash confirmed! Exception:
expected name token at '<![ g\'"7z5r7cojSO;2L'

• expected name token at '<![\n\n'
• expected name token at '<![>og))/uw_ f{t'
• expected name token at '<![ g\'"7z5r7cojSO;2L'

Impact

• Potential Denial of Service by crashing apps parsing untrusted Markdown.
• Stability risk in applications relying on Python-Markdown.
• Possible information leakage via stack traces if errors are exposed.

Environment

• Python-Markdown version: 3.8
• Python version: 3.11
• OS: Linux and Windows 11

Additional Notes

I performed fuzz testing and isolated these inputs causing crashes. I'm happy to provide more test cases or logs if needed.

Thank you for your attention to this issue!

[waylan]

I can confirm the behavior. Thanks for the report. However, there is no need for extra to get the reported behavior.

>>> markdown.markdown('<![')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\code\md\markdown\core.py", line 482, in markdown
    return md.convert(text)
           ^^^^^^^^^^^^^^^^
  File "C:\code\md\markdown\core.py", line 354, in convert
    self.lines = prep.run(self.lines)
                 ^^^^^^^^^^^^^^^^^^^^
  File "C:\code\md\markdown\preprocessors.py", line 89, in run
    parser.feed(source)
  File "C:\Users\wlimberg\AppData\Roaming\uv\python\cpython-3.12.9-windows-x86_64-none\Lib\html\parser.py", line 111, in feed
    self.goahead(0)
  File "C:\Users\wlimberg\AppData\Roaming\uv\python\cpython-3.12.9-windows-x86_64-none\Lib\html\parser.py", line 179, in goahead
    k = self.parse_html_declaration(i)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\code\md\markdown\htmlparser.py", line 278, in parse_html_declaration
    return super().parse_html_declaration(i)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\wlimberg\AppData\Roaming\uv\python\cpython-3.12.9-windows-x86_64-none\Lib\html\parser.py", line 264, in parse_html_declaration
    return self.parse_marked_section(i)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\wlimberg\AppData\Roaming\uv\python\cpython-3.12.9-windows-x86_64-none\Lib\_markupbase.py", line 144, in parse_marked_section
    sectName, j = self._scan_name( i+3, i )
                  ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\wlimberg\AppData\Roaming\uv\python\cpython-3.12.9-windows-x86_64-none\Lib\_markupbase.py", line 390, in _scan_name
    raise AssertionError(
AssertionError: expected name token at '<![\n\n'

Looks like we need to catch the AssertionError in parse_html_declaration and handle it somehow.

This is a high priority issue as crashes from Markdown input are unacceptable.

[keshavgoyal1744]

Thank you for confirming the issue and prioritizing it; I appreciate the quick analysis and detailed breakdown!
Given the potential impact (especially for apps processing untrusted Markdown), I wanted to ask if you plan to file a CVE for this vulnerability. If not, would you be open to me submitting one on behalf of the project? I’ll be happy to share all relevant details and credit the project appropriately.
Let me know what works best - happy to help however I can.

[keshavgoyal1744]

Also, I had actually noticed that the crash occurs even without the extra extension after I submitted the report, and didnt wanna make changes to the current report and thought of submitting another one. Appreciate you confirming it as well!

[waylan]

Turns out this is a bug in the standard lib's HTMLParser which was just fixed last month (see cpython#77057). We'll need to provide a workaround until we drop support for all older Python versions.

[keshavgoyal1744]

Thanks for the clarification! That makes sense, I wasn’t aware it had been fixed recently in the standard library. Appreciate you confirming the root cause.
Would it be alright if I still requested a CVE for this issue, considering that many downstream projects using markdown are still on older Python versions and could be affected by the crash? I’d be happy to reference this upstream dependency and note that a workaround is being planned. Let me know if filing a CVE sounds appropriate in this context.
Best regards,
Keshav Goyal

[waylan]

You are welcome to file a CVE if you want.

I have a fix which should be ready to go in #1535. Feel free to verify it works for you. I expect to do a release (3.8.1) today with the fix.

[keshavgoyal1744]

I went through and verified the fix and it seems good to go. Thanks for your help!

[waylan]

Version 3.8.1 has been released with the fix. Thanks again for making the report.