CVE-2022-21681: Second ReDoS flaw in marked

CVE-2022-21681 is a Regular Expression Denial of Service (ReDoS) vulnerability in marked, one of the most widely used Markdown-to-HTML parsing libraries in the JavaScript and Node.js ecosystem. The flaw lives in marked's inline tokenizer — the component responsible for parsing inline Markdown constructs like emphasis, links, and autolinks inside a block of text. A specially crafted Markdown string can drive the tokenizer's regular expression engine into catastrophic backtracking, causing CPU usage to spike and the parsing thread to hang. Because marked is frequently invoked server-side — to render user-submitted comments, README files, chat messages, or documentation — an attacker who can supply arbitrary Markdown input to an application built on a vulnerable version can potentially freeze a request-handling process with a single crafted payload.

CVE-2022-21681 is notable because it is the second of two related ReDoS advisories disclosed against marked's tokenizers around the same time, the other being CVE-2022-21680. Both stem from the same underlying class of bug — regular expressions in marked's lexer/tokenizer stages whose worst-case time complexity is exponential (or high-degree polynomial) relative to crafted input rather than linear relative to input length. This post focuses on CVE-2022-21681 and the inline tokenizer specifically, and explains what teams running marked need to know.

Affected Versions and Components

• Component: marked npm package (Markdown parser/compiler for JavaScript)
• Vulnerable code path: the inline lexer/tokenizer logic in lib/marked.js (inline.js in source form), which processes inline-level Markdown syntax such as emphasis markers, autolinks, and reference-style constructs after the block-level lexer has split input into blocks
• Affected versions: releases of marked prior to 4.0.10
• Fixed version: marked 4.0.10, which tightened the inline tokenizer's regular expressions to eliminate the pathological backtracking behavior
• Advisory reference: the GitHub Security Advisory associated with this CVE documents the issue as "Uncontrolled Resource Consumption in marked," consistent with a classic ReDoS classification (CWE-1333 / CWE-400)

Any application, CLI tool, static site generator, CMS plugin, or backend service that depends on marked below 4.0.10 — directly or transitively through another package — should be treated as exposed if it renders Markdown originating from an untrusted source (user comments, uploaded files, API payloads, webhook bodies, etc.). Because marked is a common transitive dependency pulled in by documentation tooling, note-taking apps, chat platforms, and static site generators, the practical blast radius of this CVE extends well beyond projects that declare marked as a direct dependency.

Severity: CVSS, EPSS, and KEV Context

The GitHub Security Advisory for this issue rates it as High severity, consistent with a CVSS v3.1 base score in the 7.x range for a network-exploitable, low-complexity denial-of-service condition that requires no authentication and no user interaction beyond the application processing attacker-supplied Markdown. The impact is confined to availability (CPU exhaustion / hung event loop) — there is no claim of confidentiality or integrity impact, which is typical for ReDoS findings.

From an exploitability-likelihood standpoint, EPSS scoring for this CVE sits well below the range typically associated with actively-exploited, internet-facing vulnerabilities. That tracks with the nature of the bug: it requires an application to pass attacker-controlled text into marked's rendering pipeline, rather than exposing a directly reachable network service. CVE-2022-21681 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, and there is no public evidence of widespread in-the-wild exploitation. That said, low EPSS and absence from KEV should not be read as "safe to ignore" — ReDoS bugs in popular parsing libraries are trivially weaponizable once a vulnerable code path is identified, and Node.js's single-threaded event loop model means a single hung parse can degrade an entire service instance, not just one request.

Timeline

• marked, as a long-maintained open-source Markdown parser, accumulated multiple regex-based tokenizers over its history for block- and inline-level parsing.
• In January 2022, the maintainers and security researchers identified two related ReDoS conditions in these tokenizers — one in block-level lexing (CVE-2022-21680) and one in the inline tokenizer (CVE-2022-21681) — arising from regular expressions with backtracking-prone constructs.
• The fix for both issues shipped together in marked 4.0.10, which reworked the affected regular expressions to bound backtracking behavior.
• Advisories were published to the GitHub Advisory Database and mirrored to the National Vulnerability Database as CVE-2022-21680 and CVE-2022-21681, allowing dependency scanners and SCA tools to flag affected installations.

Because the two CVEs were fixed in the same release, most remediation guidance treats them together: any consumer patching for one should patch to the same version that resolves both.

Remediation Steps

1. Identify exposure. Run npm ls marked (or the equivalent for yarn/pnpm) across your services, including transitive dependencies, to find every installed version. Don't forget documentation generators, CMS plugins, chat/comment systems, and internal tools that may embed marked indirectly.
2. Upgrade to marked 4.0.10 or later. This is the direct fix for CVE-2022-21681 (and CVE-2022-21680). Where marked is a transitive dependency, you may need to update the parent package or use your package manager's override/resolution mechanism (overrides in npm, resolutions in yarn) to force the patched version until upstream catches up.
3. Re-test Markdown rendering paths after upgrading — tokenizer changes can occasionally alter edge-case rendering output, so regression-test any custom Markdown extensions or renderer overrides your application relies on.
4. Add defense in depth for untrusted input. Even after patching, consider bounding the size of Markdown input accepted from untrusted sources and applying execution timeouts around rendering calls, so that any future or unknown ReDoS-class issue in a parsing dependency can't hang a worker indefinitely.
5. Pin and monitor. Lock the marked version in your lockfile and add it to continuous dependency scanning so any reintroduction of a vulnerable version (via a downgrade, a stale transitive dependency, or a new package that bundles an old marked) is caught automatically rather than discovered in production.

How Safeguard Helps

CVE-2022-21681 is a good example of why point-in-time dependency audits aren't enough: marked is exactly the kind of package that gets pulled in transitively — by a documentation tool, a chat widget, a CMS plugin — long after the original engineering decision to use it was made, and long after anyone remembers it's there. Safeguard is built to catch that gap.

Safeguard continuously inventories every dependency across your software supply chain, direct and transitive, and maps known vulnerabilities like CVE-2022-21681 directly to the services and build artifacts that actually ship them — not just to a manifest file. That means when a new ReDoS or resource-exhaustion CVE surfaces in a parsing library, Safeguard can tell you immediately which running services, containers, and deployed versions are affected, rather than leaving your team to grep package-lock files by hand.

Beyond detection, Safeguard layers in real-world exploitability context — CVSS severity alongside EPSS likelihood and KEV status — so teams can prioritize the marked upgrade appropriately against everything else competing for engineering time, instead of treating every CVE as equally urgent. For vulnerabilities like this one, where the practical risk depends heavily on whether your application actually renders untrusted Markdown, Safeguard's supply chain visibility helps you make that call with evidence instead of guesswork, and its continuous monitoring ensures that once you patch to marked 4.0.10 or later, any regression back to a vulnerable version is flagged before it reaches production.