Uvicorn

General Information

Field	Value
Package Name	uvicorn
Manufacturer / Vendor	Encode (maintained by Marcelo Trylesinski (Kludex) and community contributors)
Software Category	Framework
Primary Documentation	Documentation, GitHub, PyPI, Settings Reference
Programming Language(s)	Python
License	BSD-3-Clause License
Deployed Version(s)	>=0.38.0 (version-locked at 0.38.0–0.40.0 across services)
Most Recent Available Version	0.40.0
Last Review Date	2026-01-27

Overview

Uvicorn is a lightning-fast ASGI (Asynchronous Server Gateway Interface) web server implementation for Python. It provides the runtime environment that actually executes async web applications, handling HTTP requests and WebSocket connections with high performance. Built on uvloop (a Cython-based alternative to asyncio's event loop) and httptools (an HTTP parser), Uvicorn achieves performance levels 2–4 times faster than standard Python asyncio implementations.

Within the medical device software, Uvicorn serves as the production ASGI server that runs all FastAPI-based microservices. It is the critical infrastructure component enabling the distributed service architecture:

• API Gateway: Runs the client-facing FastAPI application that exposes clinical endpoints for diagnosis support, severity assessment, device information, and authenticated resources. Configured with multi-worker support for production throughput
• Control Plane: Hosts the orchestration service that coordinates clinical workflows, routes requests to downstream services, and manages distributed tracing via correlation IDs
• Expert Orchestrator: Runs the coordination service that distributes inference requests to 50+ expert microservices and aggregates clinical results
• Report Builder: Hosts the medical report generation service that produces canonical clinical reports from aggregated expert results
• Expert Microservices: The legithp-expert core library provides a reusable run_server() function that standardizes Uvicorn configuration across all 50+ clinical expert services (classifiers, segmenters, detectors)
• Correlation ID integration: Custom logging configuration via get_uvicorn_log_config() integrates Uvicorn with the device's correlation ID tracking system for end-to-end request tracing

Uvicorn was selected over alternatives (Gunicorn with uvicorn workers, Hypercorn, Daphne) due to:

• Native ASGI support optimized for FastAPI and Starlette applications
• High performance from uvloop and httptools when installed with [standard] extra
• Simple, focused implementation with minimal dependencies
• Multi-worker process support for production scalability
• Configurable logging integration for correlation ID propagation
• Programmatic API via uvicorn.run() for embedded server control
• Active maintenance with regular updates and responsive maintainers
• BSD-3-Clause license permitting commercial use in medical device software

Functional Requirements

The following functional capabilities of this SOUP are relied upon by the medical device software.

Requirement ID	Description	Source / Reference
FR-001	Run ASGI applications with configurable host and port binding	uvicorn.run(app, host=..., port=...)
FR-002	Support multi-worker process mode for production scalability	workers parameter in uvicorn.run()
FR-003	Configure keep-alive timeout for HTTP connections	timeout_keep_alive parameter
FR-004	Provide custom logging configuration for structured log output	log_config parameter with dict configuration
FR-005	Control access logging independently of application logging	access_log parameter (True/False)
FR-006	Set log level for server messages	log_level parameter (debug, info, warning, error)
FR-007	Accept both application objects and import strings	app parameter as FastAPI instance or "module:app"
FR-008	Graceful shutdown handling for clean service termination	SIGINT/SIGTERM signal handling
FR-009	HTTP/1.1 protocol support for standard web communication	Built-in httptools parser
FR-010	WebSocket protocol support for real-time connections	websockets library integration via [standard] extra

Performance Requirements

The following performance expectations are relevant to the medical device software.

Requirement ID	Description	Acceptance Criteria
PR-001	Request handling shall introduce minimal latency overhead	Server overhead < 1ms per request excluding application processing
PR-002	Concurrent connections shall be handled efficiently via async I/O	Support hundreds of concurrent connections without thread exhaustion
PR-003	Multi-worker mode shall scale throughput with available CPU cores	Linear throughput scaling with worker count up to CPU core limit
PR-004	Memory usage shall remain stable under sustained connection load	No memory leaks during continuous server operation
PR-005	Graceful shutdown shall complete within acceptable timeout bounds	Clean shutdown within configured timeout period

Hardware Requirements

The following hardware dependencies or constraints are imposed by this SOUP component.

Requirement ID	Description	Notes / Limitations
HR-001	x86-64 or ARM64 processor architecture	Pre-built wheels available for common platforms
HR-002	Network interface for HTTP communication	Required for all API endpoints
HR-003	Sufficient system memory for connection handling	Memory scales with concurrent connection count and workers

Software Requirements

The following software dependencies and environmental assumptions are required by this SOUP component.

Requirement ID	Description	Dependency / Version Constraints
SR-001	Python runtime environment	Python >=3.10
SR-002	ASGI application framework	FastAPI, Starlette, or any ASGI-compliant application
SR-003	High-performance event loop (standard extra)	uvloop >=0.14.0 (Cython-based asyncio replacement)
SR-004	HTTP protocol parser (standard extra)	httptools >=0.5.0 (optimized HTTP parsing)
SR-005	WebSocket support (standard extra)	websockets library for WebSocket protocol handling

Known Anomalies Assessment

This section evaluates publicly reported issues, defects, or security vulnerabilities associated with this SOUP component and their relevance to the medical device software.

Anomaly Reference	Status	Applicable	Rationale	Reviewed At
CVE-2020-7695 (HTTP response splitting)	Fixed	No	High severity HTTP response splitting via unescaped CRLF sequences in header values. Fixed in Uvicorn 0.11.7; the device uses version-locked 0.38.0–0.40.0 which includes the fix	2026-01-27
ANSI escape sequence injection (logging)	Open	No	Request URLs with percent-encoded escape sequences can inject ANSI codes into log output when rendered in terminal emulators. Not exploitable in production: device logs are written to structured logging systems, not terminals; all API inputs are validated before processing	2026-01-27

Uvicorn is actively maintained by Marcelo Trylesinski (Kludex) and the Encode community with a strong track record of security response. The project maintains a security policy for coordinated disclosure. According to Snyk's vulnerability database, the deployed versions (0.38.0–0.40.0) are not affected by any known exploitable vulnerabilities. The GitHub repository shows no published security advisories.

The device's usage pattern minimizes attack surface exposure:

• Version locking: Requirements lock files pin Uvicorn versions across all services: core services (API Gateway, Control Plane) at 0.38.0, expert microservices ranging from 0.38.0 to 0.40.0. All locked versions include the fix for CVE-2020-7695 (fixed in 0.11.7)
• Authenticated endpoints: All clinical endpoints require valid JWT authentication; Uvicorn only handles the transport layer while FastAPI enforces authentication
• Structured logging: Production services use JSON-structured logging to centralized log aggregation systems, not terminal output, eliminating ANSI escape sequence concerns
• Input validation: All request data is validated by Pydantic models at the FastAPI layer before any processing occurs
• Container isolation: Each microservice runs in isolated containers with restricted filesystem and network access
• Correlation ID tracking: Custom logging configuration integrates with the device's correlation ID system, enabling security audit trails across distributed services
• Keep-alive configuration: Timeout settings are configured to prevent connection exhaustion from slow clients
• Multi-worker isolation: Worker processes provide process-level isolation; a crash in one worker does not affect others

Risk Control Measures

The following risk control measures are implemented to mitigate potential security and operational risks associated with this SOUP component:

• Version locking via requirements_lock.txt ensures reproducible, auditable deployments with known-secure versions
• FastAPI authentication layer prevents unauthenticated access to clinical endpoints
• Pydantic validation rejects malformed requests before processing
• Structured JSON logging eliminates terminal-based escape sequence risks
• Container isolation limits potential impact of any exploitation
• Correlation ID logging enables forensic analysis of security events
• Keep-alive timeouts prevent resource exhaustion from connection hoarding

Assessment Methodology

The following methodology was used to identify and assess known anomalies:

• Sources consulted:

  • National Vulnerability Database (NVD) search for "uvicorn"
  • GitHub Security Advisories for encode/uvicorn
  • Snyk vulnerability database for Uvicorn
  • CVE Details for Encode Uvicorn
  • PyPI package security reports
  • Uvicorn GitHub issues and release notes

• Criteria for determining applicability:

  • Vulnerability must affect deployed versions (Uvicorn 0.38.0–0.40.0)
  • Vulnerability must be exploitable through the device's operational context (production server, structured logging)
  • Attack vector must be reachable through the device's interfaces
  • Input validation, authentication, and isolation controls must not mitigate the vulnerability

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003, JD-004
• Approver: JD-001