Orthanc upload paths and DICOM heap overflow
Orthanc takes DICOM input as part of its normal job, which is exactly why the upload path matters. A server that accepts files from the network and hands them straight into parsing code inherits every sharp edge in that parser. If the input path accepts attacker-controlled data without strict limits, the parser becomes the place where the damage starts.
That matters because DICOM is not a tidy little format. Tags, sequences, encapsulated data and optional fields create plenty of room for mismatched lengths and awkward edge cases. A malformed object does not need to look dramatic on disk. It only needs to persuade the parser to allocate the wrong size, copy too much data or trust a length field that should have been rejected.
Heap corruption through malformed DICOM objects
Heap corruption in this setting usually starts with a bad assumption. A parser reads metadata, allocates memory, then processes content that no longer matches the earlier bounds check. If the write runs past the allocated chunk, the heap state changes in ways that are hard to predict and easy to abuse.
The practical failure is not just a crash. An out-of-bounds write can smash adjacent allocator metadata or application data, which is where a parsing bug stops being a nuisance and starts being security-relevant. In a PACS workflow, that is especially awkward because the file often arrives through normal hospital traffic. The server is doing exactly what it is meant to do, only with malicious input in the queue.
The key point is simple: file parsing is attack surface, not housekeeping. When a DICOM object reaches a decoder automatically, the parser gets no second chance to ask whether the length field feels honest today.
Pydicom, GDCM, and the boundary between parsing and decoding
Pydicom and GDCM sit on different sides of the same problem. One layer interprets the structure, another handles more specific decoding work, but both depend on boundaries being handled cleanly. If parsing code accepts malformed content and passes it along without tight validation, the next stage inherits a broken assumption.
That boundary matters because bugs rarely stay in one layer. A parser may treat input as valid enough to continue, then a decoder allocates based on that decision and writes into heap memory with the wrong limits. The result is a memory corruption issue that can appear far from the point where the input first went wrong.
The safer posture is boring. Reject inconsistent lengths, fail early on malformed structures, and treat any path that moves from parse to decode as hostile until the data has passed strict checks. In DICOM handling, “probably fine” is how people end up reading crash dumps.
Checking the fix against real upload traffic
A fix only counts if it survives real uploads, not just a neat sample file in a test harness. DICOM traffic in production is messy, varied and full of old habits from devices that never met a modern fuzzing campaign. Validation has to hold up against that noise without breaking legitimate studies.
The useful test is to push the upload path with malformed objects, oversized fields and edge-case metadata while watching for allocator faults, rejected parses and silent truncation. A patch that blocks the bad input and keeps normal studies flowing has done its job. A patch that just moves the crash to another layer has not.
Orthanc, Pydicom and GDCM all sit inside the same ingestion chain, so the fix needs to hold across the full path from upload to decode. If any stage still trusts the file too much, the heap will remind everyone why parser boundaries exist.
