CVE-2026-35201

What it actually does

The flaw is a memory-safety bug in the Discount Markdown parser and products/bindings that embed it, including rdiscount. When an input buffer larger than INT_MAX is passed into the default Markdown parse path, its length is truncated from a larger integer type into a signed int. The native parser then operates with an incorrect length and can read past the end of the supplied buffer, causing an out-of-bounds read and process crash. The practical impact is denial of service against software that parses attacker-controlled Markdown content. The CVSS vector indicates network reachability, no required privileges or user interaction, high availability impact, and no expected confidentiality or integrity impact. Exploitation is high-complexity because the attacker must deliver an unusually large Markdown document and the application, framework, reverse proxy, runtime, and host must allow the payload to reach the parser intact.

Why it matters to the business

An affected service that renders or imports Markdown can be crashed by a very large crafted document, potentially interrupting publishing workflows, documentation portals, comment systems, ticketing systems, content ingestion pipelines, or APIs that accept Markdown. Because the bug is not currently in CISA KEV, is not reported as ransomware-used, and has low EPSS, broad active exploitation is not indicated; however, any internet-facing Markdown ingestion path with permissive upload/body-size limits may still be vulnerable to targeted denial-of-service attempts. Operational risk is highest where Markdown parsing occurs synchronously in web workers, background job pools, or shared services where repeated crashes can exhaust capacity or trigger restart loops.

How an attack unfolds

An attacker first identifies an application feature that accepts Markdown, such as document upload, comments, issue descriptions, wiki pages, README rendering, or an API endpoint that converts Markdown to HTML. The attacker then submits a Markdown payload whose size exceeds INT_MAX, typically requiring a multi-gigabyte body or file. If upstream controls such as web server limits, API gateway limits, application upload limits, memory limits, and request timeouts do not block the payload, the application passes the buffer into the Discount/rdiscount native parser. During parsing, the length is truncated into a signed int, causing the parser to miscalculate the valid buffer boundary and read beyond the supplied memory region. The out-of-bounds read leads to a segmentation fault or similar crash, taking down the worker process and causing denial of service. Repeating the request can keep affected workers unstable until payload limits are enforced or the library is upgraded.

How to fix it

Upgrade Discount to version 2.2.7.4 or later wherever it is used directly or through language bindings such as rdiscount. If using packaged dependencies, update the package that vendors or links against Discount and confirm it incorporates Discount 2.2.7.4 or later. Rebuild native extensions, containers, and statically linked binaries so the fixed parser is actually deployed. As compensating controls, enforce strict maximum request, upload, and Markdown document sizes well below INT_MAX; reject oversized content before it reaches Markdown parsing; apply web server/API gateway body-size limits; set worker memory and execution-time limits; and isolate Markdown rendering in a constrained worker process where crashes do not affect the main application. If immediate upgrade is not possible, disable untrusted Markdown rendering or route it through a safer, patched parser until the vulnerable component is replaced.

How to confirm the fix worked

Confirm dependency inventory shows Discount 2.2.7.4 or later, or a downstream package version that explicitly includes that fix. For rdiscount or other native bindings, verify both the package version and the linked/vendored Discount library version after rebuild, not only the manifest. Inspect deployed containers and hosts for old libmarkdown/Discount artifacts and rebuild images from clean dependency locks. Validate that application, reverse proxy, API gateway, and upload handling layers reject Markdown inputs far below INT_MAX before parsing. In a non-production test environment, submit oversized Markdown-like payloads within safe operational limits and confirm they are rejected by size controls rather than processed by the parser. Review crash monitoring after upgrade to ensure segmentation faults associated with Discount/rdiscount parsing no longer occur.

Typical attack path

1. Find a Markdown-capable feature exposed over a network, such as upload, preview, render, import, comment, wiki, or API conversion functionality.
2. Confirm the target uses Discount, rdiscount, or a downstream component that embeds the vulnerable Discount parser.
3. Prepare an oversized Markdown input larger than INT_MAX so the native parser length conversion truncates the real buffer size.
4. Send the payload through an endpoint that allows very large request bodies or files and does not reject the input before parsing.
5. Trigger Markdown parsing in the affected process.
6. Cause an out-of-bounds read and crash the parser process, producing a denial-of-service condition.
7. Repeat submissions to crash restarted workers or exhaust available processing capacity.

How to detect it

Look for evidence of attempted or successful denial-of-service through oversized Markdown inputs. Useful sources include web server and API gateway access logs, WAF logs, application request logs, upload service logs, object storage write logs, application crash logs, process supervisor logs, container runtime events, kernel logs, core dump metadata, APM error traces, and dependency/runtime logs for rdiscount or Discount. Focus on requests with extremely large Content-Length values, large file uploads to Markdown-capable endpoints, repeated 5xx responses after large POST/PUT requests, worker restarts, SIGSEGV/segmentation fault events, core dumps, and stack traces referencing Discount, rdiscount, libmarkdown, or Markdown parser functions. Because exploitation primarily causes crashes rather than persistent compromise, expect transient artifacts such as failed requests, restart loops, and crash dumps rather than malware files or command execution traces. Correlate large Markdown submissions with process crashes occurring at the same time and with the same client IP, API token, session, or upload object. If threat hunting across retained logs, search from the publication date onward and prioritize externally reachable Markdown ingestion surfaces.

• Content-Length: 2147483648
• Content-Length: 2147483649
• Content-Length: 4294967296
• SIGSEGV
• Segmentation fault
• core dumped
• libmarkdown
• discount
• rdiscount
• mkd_compile
• mkd_document
• markdown_to_html
• worker crash
• CrashLoopBackOff

What your security team should do

• Prioritize internet-facing services or APIs that accept Markdown uploads, previews, imports, comments, wiki pages, documentation, or issue descriptions.
• Inventory all uses of Discount, rdiscount, and downstream packages that embed the Discount C parser, including vendored native libraries inside containers and language extensions.
• Upgrade or rebuild affected components so Discount 2.2.7.4 or later is deployed everywhere.
• Enforce conservative maximum body, upload, and Markdown document sizes at the edge and in application code to prevent multi-gigabyte inputs from reaching parsers.
• Add monitoring for repeated worker crashes, segmentation faults, core dumps, and unusually large Markdown submissions.
• Rate-limit and authenticate expensive rendering/import endpoints where feasible to reduce denial-of-service exposure.
• Run dependency and container scans to identify stale native parser versions after application package updates.
• If the parser cannot be upgraded quickly, temporarily disable untrusted Markdown parsing or move it to an isolated worker with restart limits and resource controls.