CVE-2026-102941 in markdown
Summary
by MITRE • 10/16/2026
The package github.com/gomarkdown/markdown is a Go library for parsing Markdown text and rendering as HTML. Prior to 0.0.0-20260724235538-61af6e1e6971, parser.IsSafeURL in parser/parser.go slices url[:nPath] before the len(url) >= nPath guard. A short destination causes a slice-bounds panic when the loop reaches a relative-path prefix for which len(url) < nPath and cap(url) < nPath. The one-byte destination / is an explicit non-panic counterexample because it matches the first valid path and returns before a longer prefix is sliced. Demonstrated panic cases include empty, ., and .. destinations under those conditions. The panic is reachable when markdown.ToHTML renders untrusted Markdown with html.Safelink enabled, including an empty link destination, and is also reachable by callers that pass a short attacker-controlled URL directly to the exported parser.IsSafeURL function. An uncaught panic can terminate the calling process and cause denial of service. This issue is fixed in 0.0.0-20260724235538-61af6e1e6971.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified within the github.com/gomarkdown/markdown package represents a critical input validation failure that leads to application instability through unhandled runtime panics in Go environments. This library, widely used for parsing Markdown text and rendering it as HTML, contains a logic error in its URL safety checking mechanism specifically located in the parser.IsSafeURL function within the parser/parser.go file. The core technical flaw stems from an incorrect order of operations during string slicing operations. Specifically, the code attempts to slice a URL string using indices derived from path length calculations before verifying that the total length of the input URL is sufficient to support such a slice operation. This lack of defensive programming allows for out-of-bounds memory access when processing specific edge cases involving short or malformed URLs.
The operational impact of this flaw manifests as a denial of service condition due to an uncaught panic. When the markdown.ToHTML function processes Markdown content containing links with empty, relative dot notation such as . or .. destinations, and the html.Safelink option is enabled, the parser attempts to validate these paths against safety criteria. Because the validation logic slices url[:nPath] without first ensuring that len(url) >= nPath, a panic occurs if the URL length is less than the required path index and the capacity constraints are violated. While simple single-character destinations like / may bypass this specific code path due to early returns on valid prefixes, more complex relative paths trigger the boundary violation. This vulnerability can be exploited by attackers providing untrusted Markdown input containing maliciously crafted link structures, causing the hosting application or service to crash abruptly and terminate its process.
From a classification perspective, this issue aligns with CWE-20 Improper Input Validation, as the software fails to adequately verify that inputs meet specified requirements before processing them. Furthermore, it relates to CWE-134 Use of Externally-Controlled Format String or CWE-787 Out-of-bounds Write depending on the specific memory state at runtime, though primarily it is a logic error leading to resource exhaustion via crash. In terms of adversary tactics, this vulnerability supports Denial of Service (T1499) techniques where an attacker disrupts service availability by causing application crashes rather than exploiting data confidentiality or integrity directly. The attack vector typically involves supplying crafted Markdown content through web forms, API endpoints, or document uploads that are subsequently rendered using the vulnerable library version.
Mitigation strategies require immediate upgrading to the patched version 0.0.0-20260724235538-61af6e1e6971 which corrects the logical sequence of validation checks. Developers should ensure that all dependencies are updated via standard Go module management tools such as go get or go mod tidy to resolve this security risk. Additionally, implementing defense-in-depth measures is recommended; applications consuming Markdown content from untrusted sources should employ additional input sanitization layers and consider using panic recovery mechanisms in critical services to prevent total system failure even if a vulnerability exists. Regular dependency auditing using automated tools can help identify such logic errors early in the software development lifecycle before they reach production environments.