Medical imaging does not usually enter an internet exposure report until a researcher publishes a port scan. MONAILabel changes that assumption because it combines a model server, a web interface and DICOM processing in a package that teams may launch quickly for evaluation.

On 28 October 2026, ZoomEye returned 89 assets for title="MONAILabel" with sub_type=all. The application fingerprint query app="MONAILabel" returned 0. The title count identifies pages whose HTML title exposes the product name. It does not tell us whether inference is enabled, whether the DICOM endpoint is public or which model is loaded.

Why a visible page is a useful starting point

A MONAILabel server may hold model files, dataset paths and API keys for object storage or experiment tracking. It may also accept image uploads and start long inference jobs. Public visibility of the product name is a reason to identify the owner and test the network boundary.

The advisory for CVE-2026-48705 makes the input path especially relevant. The issue involves a pydicom DS and IS validation bypass that can crash MONAILabel and may corrupt inference output. The affected MONAI versions are before 1.6.1, and affected pydicom versions span 0.9.7 through 3.0.2.

A title match does not establish either dependency version. It only says that a page identified itself as MONAILabel at collection time. Use that signal to find the deployment record and inspect the running container or environment.

Separate the three MONAILabel surfaces

The web application, the REST API and the DICOM path have different access requirements. A team may protect the browser dashboard with a reverse proxy but leave the API reachable from a broader network. Another deployment may expose only a static title page while the model service runs elsewhere.

Record the URL, certificate, DNS name and resolved address for each match. Compare those with the application inventory and the team that owns the imaging workflow. If the page belongs to a vendor, cloud provider or public demo, note that fact rather than counting it as a hospital endpoint.

For owned deployments, check authentication at the API boundary, the network policy around DICOMweb or shared-folder inputs, and the process account's access to patient data. Collect the running monai and pydicom versions from inside the actual container.

Use a controlled verification path

After upgrading MONAI to 1.6.1 or later and pydicom to 3.0.3 or later, rebuild the serving image and verify the versions in the process. Send a known-good study through the normal route. Then use a malformed numeric DICOM field to confirm that validation fails before inference, without using real patient data.

Limit the API to known users and services. A default unauthenticated launch mode is not a safe production configuration even when the server is behind a VPN. Add request limits and queue isolation so a malformed study cannot exhaust the service that schedules clinical work.

Compare what the index can and cannot see

A title query is sensitive to page changes. If a deployment uses a custom title, removes the default page or sits behind an authentication flow that returns a generic login, the product may not appear in the result. The 89 matches should therefore be treated as a lower-bound observation for this naming method, not a census.

The zero application fingerprint is also useful. It tells the team not to claim a complete product population from one field. A repeat review should keep both dorks, the exact time and the selected scope. When ownership changes or a new image is deployed, the count may move for reasons unrelated to security.

External visibility is a prompt for an inventory conversation. The security outcome comes from matching the MONAILabel service to an owner, a model, a data path and a patched imaging stack.

References