CVE-2026-48705

CRITICALPre-NVD 9.39.3
EchelonGraph scoreHIGH confidence

“—” beside the score: it is equal to the CVSS score beside it.

Score 9.3 from GitHub Security Advisory (severity: CRITICAL) published 2026-10-27. The CNA's CVSS baseline 9.3; sources differ by 0.0.

Triggered by: GitHub Security Advisory CVSS
Sources: the CNA's CVSS, GitHub Security Advisory

Also known asGHSA-6hp3-vr39-rqw8 (GitHub Security Advisories)

9.3EG
EchelonGraph verdictPlan a fixRemediate within your standard update timelines (the SSVC decision on this page).
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: —CVSS: 9.3Exploit: None knownExposed services: Not assessed

A fixed version is listed under Patch Availability — apply it.

MONAILabel Server Crash and Silent Inference Corruption via Crafted DICOM (pydicom DS/IS Validation Bypass)

Summary

An unauthenticated remote attacker can crash a running MONAILabel server or silently corrupt its medical AI inference results by uploading a single crafted DICOM file (~132 KB) via the REST API. The vulnerability stems from pydicom's lack of validation for Decimal String (DS) and Integer String (IS) DICOM Value Representations, which allows NaN and infinity values to pass through MONAI's PydicomReader and propagate through the entire spatial transform and ML inference pipeline.

No authentication is required for the default MONAILabel REST API. The attacker needs only network access to the server (default port 8000).

Severity: CVSS 3.1: 8.7 HIGH CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:L CWE: CWE-20 (Improper Input Validation) → CWE-682 (Incorrect Calculation)

Details

Root Cause — Layer 1: pydicom accepts invalid VR values

pydicom's DSfloat.__new__() calls Python's float(val), which silently accepts "NaN", "inf", and "-inf". The DICOM standard (PS3.5 Table 6.2-1) defines DS as digits 0-9, +, -, ., e only. NaN and inf are not valid DS values. The is_valid_ds() check only runs in RAISE validation mode, which is NOT the default. The default mode is WARN, which still returns the invalid value.

>>> from pydicom.valuerep import DSfloat
>>> DSfloat("NaN")
nan    # Accepted silently — should be rejected
>>> DSfloat("inf")
inf    # Accepted silently — should be rejected

This affects ALL pydicom versions from 0.9.7 through 3.0.2 (current).

A related bypass exists in pydicom's IS type: IS("1e4") returns 10000 via an int(float(val)) fallback, accepting scientific notation that is not valid per the DICOM standard.

Root Cause — Layer 2: MONAI Core trusts pydicom output without validation

MONAI's PydicomReader._get_affine() builds a 4x4 affine transformation matrix from PixelSpacing, ImagePositionPatient, and ImageOrientationPatient with ZERO isfinite() or isnan() checks. NaN in PixelSpacing produces NaN in the affine diagonal, propagating through every spatial transform: PydicomReader._get_affine() → LoadImaged → Spacingd → Model → Writer

Root Cause — Layer 3: MONAILabel REST API accepts anything

MONAILabel's PUT /datastore/ endpoint accepts DICOM uploads with no authentication (default deployment), no validation of spatial metadata, and no bounds checking on any DICOM tag values. The malicious DICOM is stored permanently and made available for inference.

PoC

Environment Setup:

# Start MONAILabel (Docker)
docker pull projectmonai/monailabel:latest
docker run -d --name monailabel-poc -p 8000:8000 --memory=8g \
    projectmonai/monailabel:latest monailabel start_server \
    --app /opt/monai/sample-apps/radiology \
    --studies /opt/monai/datasets/Task09_Spleen/imagesTr \
    --conf models segmentation

Verify server is running

curl http://localhost:8000/info/

Step 1 — Establish baseline (legitimate data works):

curl -X POST "http://localhost:8000/infer/segmentation?image=spleen_40" \
     -o baseline.nii.gz -w "HTTP %{http_code} - %{size_download} bytes"

Result: HTTP 200, ~223,628 bytes valid segmentation mask

Step 2 — Run the attack (NaN DICOM upload + inference):

pip install pydicom numpy requests
python poc_monailabel_ds_bypass.py --server http://localhost:8000

The PoC script:

  • Confirms pydicom accepts NaN/inf in DS fields
  • 2. Creates three malicious DICOM files (~132 KB each) with NaN/inf in PixelSpacing and ImagePositionPatient
  • 3. Uploads each via PUT /datastore/ (no auth required) — HTTP 200 accepted
  • 4. Triggers inference via POST /infer/segmentation — HTTP 500, server crash
Demonstrated Results:

| Payload | Upload | Inference | Result | |---|---|---|---| | Baseline (spleen_40) | N/A | HTTP 200 | Valid 223 KB segmentation | | NaN PixelSpacing | HTTP 200 | HTTP 500 | RuntimeError crash (18.0s wasted compute) | | NaN PixelSpacing + IPP | HTTP 200 | HTTP 500 | RuntimeError crash (16.7s wasted compute) | | Inf PixelSpacing | HTTP 200 | HTTP 500 | RuntimeError crash (16.4s wasted compute) |

Server crash traceback:

monailabel/tasks/infer/basic_infer.py → self.writer(data)
monailabel/transform/writer.py → write_itk(...)
itk/ITKCommonBasePython.py → itkProcessObject_Update()
RuntimeError: itkGDCMImageIO.cxx:1226:
  ITK ERROR: GDCMImageIO: A Floating point buffer was passed
  but the stored pixel type was not specified.

Each request burns ~16 seconds of server compute (full ML inference pipeline) before crashing. The NaN DICOM persists in the datastore — any future inference on that image ID crashes the server again.

Library-level confirmation: 17/17 test vectors confirmed against MONAI 1.5.2 and pydicom 3.0.2, including actual MONAI LoadImaged and Spacingd transforms accepting NaN geometry without error.

Impact

  • Denial of Service: A single ~132 KB DICOM upload crashes the MONAILabel inference pipeline. All active inference requests from legitimate users are aborted. Repeatable indefinitely with minimal bandwidth.
  • Silent Data Corruption: NaN values in spatial metadata propagate through the entire ML inference pipeline and produce geometrically incorrect segmentation masks. If the output writer does not crash, the result is returned with HTTP 200 and zero warnings.
  • Persistent Datastore Poisoning: The malicious DICOM is stored permanently via PUT /datastore/. Any future inference request on that image ID reproduces the crash or corruption, persisting across server restarts.
Affected MONAI Ecosystem (9 repositories):
  • MONAI Core: PydicomReader, LoadImaged, Spacingd transforms
  • - MONAILabel: REST API + DICOMweb datastore
  • - MONAI Deploy App SDK: DICOMDataLoaderOperator
  • - model-zoo, VISTA, GenerativeModels, tutorials, research-contributions
Affected DICOM Tags (any DS VR): PixelSpacing, ImagePositionPatient, SliceThickness, ImageOrientationPatient, RescaleSlope, WindowCenter/WindowWidth

Recommended Fix:

  • Add math.isfinite() validation in PydicomReader._get_affine() on all values from PixelSpacing, IPP, IOP. Raise ValueError for NaN/inf.
  • 2. Validate spatial metadata of uploaded DICOM in MONAILabel PUT /datastore/. Return HTTP 400 for invalid geometry.
  • 3. Validate spatial metadata is finite in LoadImaged/Spacingd before resampling.
  • 4. Coordinate with pydicom upstream to reject NaN/inf in DS fields in all validation modes.
Upstream: pydicom GHSA filed 2026-04-05.

Author: Paulino Calderon (paulino@calderonpale.com)

CVSS v3
9.3
EG Score
9.3CRITICALhigh confidence
EG Risk
42
EG Risk 42/100

EG Risk is EchelonGraph's 0–100 priority score. It fuses impact severity (EG Severity, the CVSS base score, never the KEV-floored or EPSS-lifted EG Score) with real-world exploitation and automatability, under weights EchelonGraph set by hand, so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner.

How it’s computed (value × EchelonGraph’s weight)
Severity93% × 45%
Impact severity (EG Severity): CVSS 9.3 of 10. Never the KEV-floored or EPSS-lifted EG Score.
Exploitation0% × 40%
No KEV listing, EG-KEV tier or EPSS when EchelonGraph scored this CVE.
Automatability0% × 15%
CISA's BOD 26-04 default: no one has published Automatable for this CVE, and CISA treats it as “no” for a CVE not in KEV.
SSVC (CISA's decision table, applied by EchelonGraph): Track at low or medium mission impact; Track* at high (mission-essential systems).
Exploitation none (no CISA value, KEV listing or exploit code on record) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). EchelonGraph holds no SSVC assessment of this CVE from CISA: none of these inputs is from Vulnrichment. EchelonGraph applied CISA's decision table to them; CISA publishes SSVC inputs and the table, not a decision for each CVE.
Action: A fixed version is listed under Patch Availability. Apply it within your standard update timelines.
EPSS PROB
—
EPSS %ILE
—
KEV
Not listed

What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)

The EG score (9.3): severity, escalated by confirmed exploitation. This CVE's 9.3 is its impact severity (EG Severity), not escalated.

EG Severity
9.3 CRITICALCVSS-B, impact only: no KEV listing, EPSS or EG-KEV tier raises it.GitHub Security Advisory CVSS
EG Likelihood
Unknown (no EPSS on record)Unknown, not low: FIRST has published no EPSS probability for this CVE.
Confirmed exploitation
None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
EG Priority
SSVC Track at medium mission impactTrack at low or medium mission impact; Track* at high (mission-essential systems).CISA BOD 26-04: 14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.Each input and its source, and whom BOD 26-04 binds: the SSVC and BOD 26-04 blocks below.

SSVC (CISA's decision table, applied by EchelonGraph)Track at low or medium mission impact; Track* at high (mission-essential systems).

A fixed version is listed under Patch Availability. Apply it within your standard update timelines.

Exploitation none (no CISA value, KEV listing or exploit code on record) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). EchelonGraph holds no SSVC assessment of this CVE from CISA: none of these inputs is from Vulnrichment. EchelonGraph applied CISA's decision table to them; CISA publishes SSVC inputs and the table, not a decision for each CVE. Mission impact is CISA's Mission & Well-being decision point, and only you can judge it. CISA's table makes it high when Mission Prevalence is Essential — the vulnerable component "directly provides capabilities that constitute at least one MEF for at least one entity" (MEF: mission essential function) — or when Public Well-Being Impact is Irreversible: "multiple fatalities are likely", the cyber-physical system "is likely lost or destroyed", "extreme or serious externalities" are imposed on other parties, or social systems such as elections or the financial grid "are destabilized and potentially collapse". CISA's decision table

BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.

The score's inputs: In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it

Published

October 27, 2026

Last Modified

October 27, 2026

Vendor Advisories for CVE-2026-48705(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Patch Availability(1)

Vendor / EcosystemFix (by version range) / PatchReleasedSource
pipmonai @ 1.6.1 (fixes < 1.6.1)—ghsa

Patches are aggregated from vendor advisories (Red Hat, Microsoft, Cisco, GitHub) and package ecosystems (OSV, GHSA). Multiple rows for the same upstream release have been deduplicated.

Weakness Classification(1)

MITRE Common Weakness Enumeration — the root-cause categories this CVE belongs to.

Data Freshness Timeline

(refreshed 4× in last 7d / 4× in last 30d)

Each row is a time one of our pipelines fetched, updated or re-scored this CVE. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. An arrow marks a change the record states ("CVSS v3 → 9.1"); EPSS and GHSA rows show the values recorded at that time, not what changed (EPSS values are rounded; hover one for the exact figures). Most recent first.

  1. 2026-11-02 01:46 UTCGHSA enrichmentGHSA-6hp3-vr39-rqw8 · GitHub severity CRITICAL · GitHub CVSS 9.3
  2. 2026-11-01 07:47 UTCGHSA enrichmentGHSA-6hp3-vr39-rqw8 · GitHub severity CRITICAL · GitHub CVSS 9.3
  3. 2026-11-01 07:47 UTCEG score recompute
  4. 2026-10-27 13:43 UTCEG score recomputeFirst assessed: 9.3 CRITICAL

Frequently asked(4)

What is CVE-2026-48705?
CVE-2026-48705 is a critical-severity vulnerability; its CVE record was published on October 27, 2026. MONAILabel Server Crash and Silent Inference Corruption via Crafted DICOM (pydicom DS/IS Validation Bypass) Summary An unauthenticated remote attacker can crash a running MONAILabel server or silently corrupt its medical AI inference results by uploading a single crafted DICOM file (~132 KB) via…
When was the CVE record for CVE-2026-48705 published?
The CVE record for CVE-2026-48705 was published on October 27, 2026. That is the record's publication date; the vulnerability itself may have been made public earlier. EchelonGraph's copy of the record carries a last-modified date of October 27, 2026; the record at its source may have been updated since.
What is the CVSS score of CVE-2026-48705?
CVE-2026-48705 has a CVSS base score of 9.3 (the CNA's own assessment, by github_m; NVD's own analysis pending).
How do I remediate CVE-2026-48705?
A fixed version for CVE-2026-48705 is listed under Patch Availability on this page: update to the version listed for your package. The vendor advisories EchelonGraph has for CVE-2026-48705 are linked in the Vendor Advisories panel on this page.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-48705

Explore →

Is Your Infrastructure Affected by CVE-2026-48705?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.