Skip to content
eastbaycyber

CVE-2026-49485: HAPI FHIR FHIRPathEngine ReDoS Vulnerability

CVE explainers 10 min read
SR
Security Research Desk Expert reviewed
Threat intelligence · Human-verified · Updated 2026-07-18
▲ Escalation ViewOne CVE, briefed at three altitudes — skim the Brief, weigh the Impact, or work the Runbook. The way a SOC actually reads it.
CISOBrief · 30-second brief

TL;DR - High severity ReDoS in HAPI FHIR org.hl7.fhir.core can exhaust CPU through crafted regex input. - Affects versions before 6.9.9 and before 6.9.4.2; upgrade immediately. - No confirmed public PoC or in-the-wild exploitation was verified in the cited sources.

Vulnerability at a Glance

Field Value
CVE ID CVE-2026-49485
CVSS score 7.5 (High)
Attack vector Network reachable in exposed validator and FHIRPath evaluation workflows
Auth required Not stated in the source material; defenders should assume untrusted remote input is enough where affected endpoints are exposed
Patch available Yes
Fixed versions 6.9.9 and 6.9.4.2
Affected versions Versions prior to 6.9.9 and prior to 6.9.4.2
Impact CPU exhaustion and denial of service
Component FHIRPathEngine, matches(), matchesFull(), replaceMatches(), FHIR Validator HTTP endpoint, affected org.hl7.fhir.* modules

CVE-2026-49485 is a Regular Expression Denial of Service (ReDoS) issue in HAPI FHIR’s Java implementation. The vulnerability arises in the logic that evaluates attacker-influenced FHIRPath expressions and regex patterns. The operational risk is not data theft or code execution, but service degradation: a single expensive regex evaluation can consume disproportionate CPU time and tie up application resources.

For healthcare interoperability platforms, that matters because HAPI FHIR is often embedded in validation, transformation, and ingestion paths. If those paths are internet-exposed or reachable by partner traffic, a denial-of-service weakness can disrupt message validation, clinical data exchange, or downstream APIs even when no authentication bypass or privilege escalation is involved.

What Is This Vulnerability?

According to the NVD description, the root cause is unsafe handling of user-controlled regular expressions inside FHIRPathEngine. The vulnerable code path accepts arbitrary FHIRPath expressions without sufficient validation, and the FHIRPath functions matches(), matchesFull(), and replaceMatches() pass attacker-controlled regex input into Java regex processing via Pattern.compile() and String.replaceAll().

That becomes dangerous when the regex engine hits patterns that trigger catastrophic backtracking. In practical terms, certain nested or ambiguous regex constructs can force Java’s regex engine into extremely expensive evaluation paths. Instead of quickly returning true or false, the process burns CPU cycles for a long time, which can stall request processing and reduce service availability for legitimate users.

The NVD also notes that the existing timeout utility was incomplete. That is an important detail for defenders because it means this is not simply “regex is expensive.” The application already had some notion of limiting runtime, but those protections were not sufficient to stop problematic regex execution in all cases. In exposed validator workflows, that incomplete guardrail creates a reliable availability risk.

From an architectural standpoint, this is a classic untrusted-input problem. If users, upstream systems, or external partners can influence FHIRPath expressions or regex arguments reaching these functions, then they may be able to drive the application into worst-case processing behavior. The result is CPU exhaustion rather than memory corruption, but the operational effect can still be severe.

Technical Notes

The vulnerable paths called out in the source material are:

  • matches()
  • matchesFull()
  • replaceMatches()

The risky Java regex operations referenced by NVD are:

Pattern.compile(userControlledRegex);
input.replaceAll(userControlledRegex, replacement);

A representative catastrophic-backtracking style pattern often associated with ReDoS testing looks like this:

^(a+)+$

That example is illustrative of the bug class, not a confirmed exploit string for this CVE. Defenders should focus on the fact pattern confirmed by NVD: attacker-controlled regex reaches Java regex evaluation through incomplete timeout handling.

AnalystImpact · assess the risk

Who Is Affected?

The NVD record states that HAPI FHIR / org.hl7.fhir.core versions prior to 6.9.9 and prior to 6.9.4.2 are affected. The fixes were issued on two maintained release lines, which means defenders need to verify which line their deployment tracks rather than assuming only the latest release matters.

The vulnerable component scope includes the FHIRPathEngine, the FHIR Validator HTTP endpoint, and affected org.hl7.fhir.* modules. That means the impact is broader than a single standalone validator binary. If your environment embeds these libraries in custom Java services, integration middleware, validation gateways, or internal healthcare data processing tools, you may still be exposed even if you do not market the service as a “FHIR validator.”

The wording “prior to 6.9.9 and 6.9.4.2” reflects two distinct fixed branches:

  • Current line fixed in 6.9.9
  • Maintenance/backport line fixed in 6.9.4.2

If you are on an older branch earlier than those versions, assume you are vulnerable unless your vendor or build pipeline can prove the two upstream fix commits were backported. If you consume shaded JARs, bundled application distributions, or transitive dependencies, verify the actual embedded org.hl7.fhir.core version rather than the top-level product version alone.

Technical Notes

To inventory the affected package in a Maven-based project:

mvn dependency:tree | grep -i "org.hl7.fhir.core"

To inspect a packaged Java application for the library version:

find /opt /srv /app -type f \( -name "*.jar" -o -name "*.war" \) | xargs -I{} sh -c 'jar tf "{}" 2>/dev/null | grep -qi "org/hl7/fhir" && echo "{}"'

If you use Gradle:

./gradlew dependencies | grep -i "org.hl7.fhir.core"

CVSS Score Breakdown

The reported CVSS base score is 7.5, which places CVE-2026-49485 in the High severity band. The source material available here does not provide the exact CVSS vector string, so defenders should avoid overstating the individual metric values. Still, the score is consistent with a remotely reachable denial-of-service issue that has material availability impact without confirmed confidentiality or integrity loss.

In practice, a 7.5 for this type of flaw usually reflects a relatively low attacker cost when the vulnerable endpoint is exposed and the service accepts untrusted input. The business impact depends heavily on how central the affected FHIR validation path is to your environment. A public-facing validation API or heavily used interoperability gateway will experience higher operational risk than an internal-only development utility.

The key point for risk owners is that this is an availability-centric vulnerability. If your SLAs, healthcare workflows, or partner integrations depend on continuous validator responsiveness, then a CPU exhaustion issue can become a production incident quickly. Even without evidence of broad exploitation, the attack pattern is simple enough that waiting for active exploitation reports is not a sound patching strategy.

Where specific CVSS components are unknown, defenders should assume a conservative posture: treat network-reachable, unauthenticated or low-friction input paths as exposed until architecture review proves otherwise.

Exploitation Status

Based on the source material provided, no confirmed public proof of concept was verified. The NVD references include upstream commits and a pull request, but no exploit repository or demonstration code was identified in the supplied research note. That does not mean exploitation is difficult; it only means this article should not claim a PoC exists unless a primary source confirms it.

There is also no confirmed in-the-wild exploitation in the supplied sources. The research note specifically states that CVE-2026-49485 is not listed in the CISA Known Exploited Vulnerabilities catalog at the time of review. That is an important signal, but not a guarantee of safety. KEV is a lagging and selective list, not a complete exploitation index.

Operationally, defenders should treat this as a vulnerability with straightforward abuse potential in exposed environments. ReDoS bugs often do not need sophisticated exploit chains. If an attacker can submit crafted regex-bearing content to the vulnerable evaluation path, the impact can be immediate. In the absence of confirmed exploitation data, the right assumption is not “safe to defer,” but “patch based on exposure.”

ResponderRunbook · act now

How to Detect It

Detection is mainly about correlating CPU saturation, slow request handling, and requests that contain suspicious regex-heavy FHIRPath input. Because this vulnerability affects regex evaluation rather than a distinct network protocol exploit, detection quality depends on how much request content and application telemetry you log.

Start with application and reverse-proxy logs around your FHIR Validator HTTP endpoint and any internal service path that accepts FHIRPath expressions. Look for repeated long-running requests, sudden spikes in 5xx responses, upstream timeouts, worker thread starvation, and CPU spikes on nodes running org.hl7.fhir.core. If your logs include request bodies or parameters, hunt for regex metacharacter density, nested quantifiers, and repeated use of matches, matchesFull, or replaceMatches.

Also review infrastructure indicators. ReDoS incidents often show up first as high sustained CPU usage with relatively low request volume, especially compared with volumetric DDoS events. A small number of crafted requests causing disproportionate load is a useful distinguishing pattern.

Technical Notes

Example application or proxy log indicators to investigate:

/Validator
/validate
matches(
matchesFull(
replaceMatches(

Simple grep across logs:

grep -R -E 'matches\(|matchesFull\(|replaceMatches\(|/Validator|/validate' /var/log

A rough Splunk search for suspicious validator activity with errors or latency:

index=app_logs ("matches(" OR "matchesFull(" OR "replaceMatches(" OR "/validate" OR "/Validator")
| stats count avg(response_time_ms) max(response_time_ms) values(status) by src_ip, uri
| where max(response_time_ms) > 5000 OR count > 20

A rough Loki/LogQL pattern:

{app="fhir-validator"} |= "matches(" or |= "matchesFull(" or |= "replaceMatches(" or |= "/validate"

Host-side correlation for CPU spikes on Java processes:

pidstat -u -p ALL 5
top -H -p $(pgrep -f 'java')

If detailed request logging is unavailable, monitor for a combination of: - sustained Java CPU spikes, - increased request latency, - thread pool exhaustion, - and repeated access to validator-related endpoints.

Mitigation and Patching

The primary fix is to upgrade to 6.9.9 on the current release line or 6.9.4.2 on the maintenance line. Those are the versions explicitly identified by NVD as containing the fix. If you are on any version prior to 6.9.9 or prior to 6.9.4.2, plan remediation now. Do not rely on generic timeout settings alone, because the vulnerability description explicitly mentions incomplete timeout protection in the vulnerable implementation.

If immediate upgrade is not possible, apply exposure-reduction controls. Restrict access to validator endpoints, block or sanitize untrusted FHIRPath expressions where feasible, rate-limit requests that trigger validation logic, and place CPU and request time limits around the affected service. These are compensating controls, not substitutes for the fixed code.

For internet-exposed healthcare interoperability services, the best short-term mitigation is often to combine WAF or API gateway rate limiting with endpoint access restrictions and body-size or expression complexity constraints. That can reduce the blast radius while change control for the Java dependency update proceeds.

Technical Notes

Maven dependency update example:

<dependency>
  <groupId>ca.uhn.hapi.fhir</groupId>
  <artifactId>org.hl7.fhir.core</artifactId>
  <version>6.9.9</version>
</dependency>

Or, if you are pinned to the maintenance line:

<dependency>
  <groupId>ca.uhn.hapi.fhir</groupId>
  <artifactId>org.hl7.fhir.core</artifactId>
  <version>6.9.4.2</version>
</dependency>

Maven build command after updating pom.xml:

mvn clean verify

Gradle example:

implementation "ca.uhn.hapi.fhir:org.hl7.fhir.core:6.9.9"

Temporary NGINX rate limiting in front of validator endpoints:

limit_req_zone $binary_remote_addr zone=fhirlimit:10m rate=5r/s;

location /validate {
    limit_req zone=fhirlimit burst=10 nodelay;
    proxy_pass http://fhir_backend;
}

If you cannot safely log request bodies, consider blocking direct public access to validator endpoints until patched:

location /validate {
    allow 10.0.0.0/8;
    deny all;
    proxy_pass http://fhir_backend;
}

After patching, verify the running version and redeployed artifact inventory rather than assuming the build pipeline updated all nodes.

References

The primary reference for this CVE is the NVD record, which provides the authoritative description used here, including the affected version ranges, the vulnerable functions, and the fixed versions. It is the best source for an accurate summary when vendor security advisories are limited or when multiple package ecosystems wrap the same upstream codebase.

The second key reference set is the upstream remediation trail in the hapifhir/org.hl7.fhir.core repository, including the two fix commits and release tags for 6.9.9 and 6.9.4.2. These sources matter for defenders validating that the patch was actually incorporated into their build or downstream product.

For additional insights on similar vulnerabilities, you may want to check out our articles on CVE-2017-20251 and CVE-2026-42208.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

Last verified: 2026-07-18

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.