CVE-2018-1000620: ReDoS in marked markdown parser

Markdown looks harmless — it's just text with a few symbols for headings and emphasis. But when a parser turns that text into HTML using regular expressions, a single crafted input can turn "harmless" into "your Node process pegged at 100% CPU." That's exactly what CVE-2018-1000620 describes: a Regular Expression Denial of Service (ReDoS) vulnerability in marked, one of the most widely used Markdown-to-HTML parsers in the JavaScript ecosystem.

marked ships as a dependency in an enormous number of projects — documentation generators, static site builders, README renderers, chat and comment systems, CMS platforms, and countless internal tools that convert user-supplied Markdown into HTML. Because it's frequently pulled in transitively (a tool depends on a tool that depends on marked), many teams run vulnerable copies of it without ever adding it to package.json directly. That transitive-dependency exposure is a big part of why this CVE matters for supply chain security, even years after it was first reported.

What the vulnerability actually is

CVE-2018-1000620 is a ReDoS flaw in marked's Markdown lexer. Like most Markdown parsers of its era, marked relies heavily on regular expressions to detect block- and inline-level constructs — headings, emphasis, links, code spans, and so on. Some of those regular expressions were written in a way that is vulnerable to catastrophic backtracking: certain crafted Markdown strings (long runs of repeated or nested delimiter-like characters) cause the regex engine's matching time to blow up exponentially relative to input length.

The practical effect is a classic ReDoS: an attacker who can get a small, otherwise-innocuous-looking string rendered by marked — a comment, a bio field, a chat message, a pull request description, anything a service passes through the parser — can force the Node.js event loop to spend seconds or minutes on a single regex match. Because Node is single-threaded for JavaScript execution, that one blocked call stalls the entire process, turning a tiny payload into a denial-of-service condition for every user of that service, not just the attacker.

This is the same underlying vulnerability class (CWE-400, Uncontrolled Resource Consumption, sometimes tagged alongside CWE-1333 for inefficient regular expression complexity) that shows up repeatedly across the Markdown and templating ecosystem. It's a good example of why "just parsing text" is still an attack surface.

Affected versions and components

CVE-2018-1000620 applies to versions of the marked npm package prior to the fix that shipped in the 0.3.9 release line. The issue is specific to marked's own lexer/regex implementation, not to a bundling tool or a downstream framework — so any project, plugin, or SaaS feature that calls into an unpatched marked version to render Markdown is exposed, regardless of how that call is triggered.

Because marked is consumed both directly and transitively, the realistic blast radius is larger than "check your package.json." Common exposure paths include:

• Static site generators and documentation tools that render Markdown at build time or, worse, at request time.
• Chat, ticketing, wiki, and comment systems that allow users to submit Markdown-formatted text.
• Editor plugins and browser extensions that preview Markdown live.
• CI/CD tooling and bots that render README or changelog content pulled from third-party repositories.

If any of these sit behind your infrastructure and accept Markdown from an untrusted or semi-trusted source (end users, external contributors, webhook payloads), the vulnerable code path can be reached remotely.

CVSS, EPSS, and KEV context

CVE-2018-1000620 was disclosed in 2018 as part of a cluster of marked advisories covering several ReDoS and related parsing issues found around the same time. Public vulnerability databases classify it as a network-exploitable, low-complexity issue whose impact is availability rather than confidentiality or integrity — consistent with the ReDoS pattern: no data is read or modified, but the service can be knocked unresponsive with a small, unauthenticated request.

We're intentionally not quoting a specific CVSS numeric score here, because scoring for this entry has varied across sources and versions of the CVSS spec, and getting it precisely right matters more than getting it quickly. What's consistent across sources is the qualitative picture: a remotely triggerable, low-effort denial-of-service issue against an availability-impacting resource, rather than a critical remote code execution or data-exposure bug.

CVE-2018-1000620 is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, and there's no indication of widespread active exploitation in the wild. Its EPSS (Exploit Prediction Scoring System) probability, consistent with older, single-service ReDoS issues that require reaching a specific parsing code path, tends to sit low relative to remote-code-execution or authentication-bypass CVEs. That doesn't mean it's safe to ignore — ReDoS bugs are cheap to trigger once a vulnerable path is identified, and "low exploitation likelihood" in aggregate scoring doesn't protect any individual service that happens to expose the flaw directly to untrusted input.

Timeline

• Pre-2018: The vulnerable regular expressions ship as part of marked's Markdown lexer across multiple release lines.
• 2018: Security researchers auditing popular npm packages identify a batch of issues in marked, including this ReDoS behavior, and file them with MITRE/NVD. CVE-2018-1000620 is one of several CVE IDs assigned to marked around this time covering related ReDoS and parsing weaknesses.
• marked 0.3.9: The maintainers ship a fix that hardens the affected regular expressions against catastrophic backtracking, closing the reported ReDoS path.
• Post-fix: Downstream projects that pin or vendor older marked versions remain exposed until they bump their dependency; because marked is often several layers deep in a dependency tree, remediation lagged in projects that didn't run regular dependency audits.

If your organization has any long-lived Node.js services, internal tools, or vendored front-end bundles that haven't touched their marked dependency in years, this is a reasonable moment to check.

Remediation steps

1. Identify every copy of marked in use, direct and transitive. Run npm ls marked (or the Yarn/pnpm equivalent) across all services, and don't stop at top-level dependencies — marked is commonly pulled in by documentation, linting, and build tooling that most teams never think to audit.
2. Upgrade to a patched, actively maintained release. Move past 0.3.9 to a current, supported marked version rather than the minimum patched release — later versions have continued to harden parsing behavior and fix additional issues beyond this specific CVE.
3. Regenerate and pin your lockfile after upgrading, and verify with npm audit or an equivalent SCA scanner that no vulnerable marked version remains anywhere in the resolved tree, including nested dependencies of dependencies.
4. Add resource limits around any Markdown rendering of untrusted input, independent of the library fix. Enforce input size caps, set execution timeouts on rendering calls, and consider running untrusted-content rendering in a worker process or sandbox so a slow regex match can't stall your main event loop even if a future, not-yet-discovered ReDoS surfaces.
5. Treat Markdown/templating libraries as first-class attack surface in dependency reviews. ReDoS bugs recur across this category (marked, markdown-it, and others have each had their own advisories); a one-time upgrade doesn't substitute for ongoing monitoring.
6. Re-run this check on every service that renders user- or third-party-supplied content, not just your primary application — internal admin panels, support tools, and bots are common blind spots.

How Safeguard Helps

CVE-2018-1000620 is a textbook case for why dependency visibility has to be continuous, not a one-time audit. It's old, it's not headline news, and it's exactly the kind of finding that gets buried three layers deep in a node_modules tree — which is precisely where it tends to survive the longest.

Safeguard's software supply chain security platform is built to catch issues like this before they ship and flag them if they're already running in production:

• Full dependency graph visibility, including transitive dependencies, so a vulnerable marked version pulled in by a documentation tool or an internal utility shows up in your inventory even if it never appears in your top-level manifest.
• Continuous SCA scanning against up-to-date vulnerability intelligence, so known issues like CVE-2018-1000620 are flagged automatically as they're introduced — whether through a new dependency, a lockfile change, or a vendored bundle — rather than discovered during an incident.
• Policy-based build gating that can block a pipeline from shipping a package with a known ReDoS or DoS-class vulnerability, giving teams a hard stop before vulnerable code reaches production.
• SBOM generation and drift detection, so security and platform teams always have an accurate, queryable record of exactly which version of marked (or any other library) is running where, without waiting for the next manual audit.
• Prioritization grounded in real exploitability signals — CVSS, EPSS, and KEV status together — so teams can distinguish between vulnerabilities that need same-day remediation and ones like this that can be scheduled sensibly, instead of treating every CVE as an equal-priority fire drill.

Old CVEs don't stop mattering just because they stop making headlines. If marked, or any other Markdown-rendering dependency, is still quietly parsing untrusted input somewhere in your stack, Safeguard is built to find it before an attacker does.