Vulnerability Directory | CVE-2024-44337

Overview

gomarkdown is a widely used Go library for parsing CommonMark-flavored Markdown into an AST and rendering it to HTML, LaTeX, or custom formats. It is the maintained successor to the original blackfriday parser and sits as a transitive dependency in many Go projects, including the Ingress NGINX Controller build graph.

A denial-of-service vulnerability (CVE-2024-44337) has been identified in the paragraph parser of gomarkdown. A logic error in the paragraph function in parser/block.go lets specially crafted input drive the parser into an unbounded loop, hanging the calling goroutine and consuming a full CPU core until the application is restarted or terminated.

Per OWASP: a Denial of Service attack is an attempt to make a service or system unavailable to its users, typically by exhausting compute, memory, network, or filesystem resources.

This issue affects all gomarkdown/markdown releases prior to commit a2a9c4f76ef5, including the version that ships in upstream ingress-nginx v1.15.1. HeroDevs has resolved it in NES for Ingress NGINX 1.15.2.

‍

Why this matters for Ingress NGINX deployments

This CVE is the oldest of the five resolved in NES for Ingress NGINX 1.15.2. It was disclosed in 2024 and remained shipped in upstream Ingress NGINX builds at the time of the project's retirement. It illustrates the EOL pattern documented in The Hidden Complexity of Library Dependencies in End-of-Life Frameworks: a transitive dependency CVE with a patch upstream, an open finding in the scanner against the deployed binary, and no maintained release that picks up the fix.

Smaller transitive dependencies like gomarkdown/markdown sit deep in the dependency tree where most teams never look until a scanner flags them. NES for Ingress NGINX 1.15.2 rebases the build to consume the patched module, closing the finding without a configuration change.

‍

Details

Module Info

Product: gomarkdown/markdown Go library; transitive dependency of Ingress NGINX Controller
Affected components: paragraph function in parser/block.go
Affected versions: all releases prior to v0.0.0-20240729232818-a2a9c4f76ef5; Ingress NGINX builds linking those versions
Upstream GitHub repository: <https://github.com/gomarkdown/markdown>
Published artifacts (NES):

Container image: registry.nes.herodevs.com/neverendingsupport/ingress-nginx-controller:v1.15.1-nes-1.15.2
Helm chart: HeroDevs/ingress-nginx --version 0.0.2 (see helm-charts documentation)
Release notes: docs.herodevs.com/ingress-nginx/release-notes

Distribution channels: registry.nes.herodevs.com, HeroDevs Helm chart repository
Fixed in:

github.com/gomarkdown/markdown commit a2a9c4f76ef5 (upstream)
NES for Ingress NGINX 1.15.2 (April 20, 2026), which bumps the gomarkdown module to the patched pseudo-version

Vulnerability Info

This Medium-severity vulnerability is found in the paragraph parsing path of gomarkdown.

The paragraph function in parser/block.go is responsible for accumulating consecutive non-empty lines into a single paragraph block. It steps forward through the input one line at a time, deciding at each step whether the current line continues the paragraph, terminates it, or transitions into a different block type.

A logical defect in the loop's termination conditions allows a specific class of crafted input to leave the parser's cursor in a state where forward progress is never made: the loop neither advances past the offending bytes nor breaks out, so the function spins indefinitely. Because the parser is invoked synchronously on whichever goroutine handed it the input, the affected goroutine is permanently busy and CPU use rises to one core per concurrent call. Memory stays roughly flat, which makes the symptom a runaway core rather than an out-of-memory crash, and which delays detection in environments that primarily alert on RSS.

Threat model for Ingress NGINX clusters: any Go binary in the cluster that calls gomarkdown/markdown on attacker-influenced input is exposed. The Ingress NGINX controller's primary request path is not Markdown rendering, but the module is reachable from auxiliary tooling, operators, and other Go workloads that share a build pipeline with the controller. Where reachable, exploitation is unauthenticated in the typical case (user comments, README rendering, webhook payloads, chat messages, support tickets), and a single request is enough to pin one CPU core.

When successfully exploited, this vulnerability can lead to:

Sustained CPU exhaustion on hosts that render untrusted Markdown
Application unavailability through request timeouts, queue backpressure, and goroutine accumulation
Outsized cost in autoscaled environments where each stuck request triggers scale-out

‍

Proof Of Concept

A public proof of concept is available at <https://github.com/Brinmon/CVE-2024-44337>.

‍

Mitigation

OSS Users

Users of gomarkdown/markdown and upstream Ingress NGINX should apply one of the following mitigations:

Upgrade gomarkdown to commit a2a9c4f76ef5 or any release that includes it (go get github.com/gomarkdown/markdown@latest dated July 29, 2024 or later).
Until upgrade is possible, render Markdown under a strict request timeout via context.WithTimeout, cap request body size, and add per-client rate limits to bound the impact of a stuck call.
Run Markdown rendering in a separate goroutine pool with a bounded queue so that a stuck call cannot starve unrelated request paths.
For Ingress NGINX specifically, no upstream release will rebase against the patched module because the project retired in March 2026. Sign up for post-EOL security support; HeroDevs customers get immediate access to a patched Ingress NGINX build.

NES Customers

HeroDevs Never Ending Support for Ingress NGINX has resolved CVE-2024-44337 in NES for Ingress NGINX 1.15.2 by upgrading the bundled gomarkdown/markdown module past commit a2a9c4f76ef5. The release ships as a drop-in replacement for upstream ingress-nginx v1.15.1:

‍

Pull the patched container image: registry.nes.herodevs.com/neverendingsupport/ingress-nginx-controller:v1.15.1-nes-1.15.2
Or upgrade via the public Helm chart: HeroDevs/ingress-nginx --version 0.0.2 (helm-charts documentation)
VEX statements ship with the release so scanners that consume OpenVEX or CycloneDX VEX surface the patched status instead of leaving CVE-2024-44337 as an open finding.

‍

Compliance impact

This CVE has been disclosed since 2024. It is the kind of finding that has accumulated in scanner reports for over a year of upstream Ingress NGINX runtime. Several frameworks make the gap acute:

The EU Cyber Resilience Act's Article 14 reporting obligations begin September 11, 2026; "the upstream project no longer ships fixes" is not a valid answer.
DORA's ICT third-party risk requirements have been in force since January 2025.
PCI DSS 4.0 expects continuous evidence that components receive security patches.
FedRAMP authorizations carry continuous monitoring obligations.

The NES release ships a documented patch trail plus VEX statements that scanners consume programmatically.

‍

Taking Action

If your service renders user-supplied Markdown with gomarkdown/markdown, upgrade past commit a2a9c4f76ef5 and verify that the renderer is invoked under a request timeout and a body-size cap. For Ingress NGINX deployments specifically, the upstream project will not ship a release that picks up the patched module because it retired in March 2026 and is in dependency-CVE drift. NES for Ingress NGINX 1.15.2 is the patched build for clusters that cannot complete a Gateway API migration before regulatory deadlines. Pull the 1.15.2 image and Helm chart per docs.herodevs.com/ingress-nginx/release-notes.

‍