Extended Negotiation memory leak in OFFIS DCMTK storescp
CVE-2026-50254 is a missing-release-of-memory vulnerability in the OFFIS DCMTK Toolkit affecting versions prior to 3.7.0. An unauthenticated remote client can repeatedly open a DICOM association and send an A-ASSOCIATE-RQ containing many Extended Negotiation items followed by a malformed or truncated Extended Negotiation item. This drives an error path that leaks memory instead of releasing parsed data structures. The issue is particularly impactful against storescp in its default single-process mode, where repeated crafted connection requests cause resident memory usage to grow rapidly until the process is killed or otherwise stops accepting DICOM connections. Upstream reporting identifies the fix as commit 23f181f7a.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation causes unbounded memory consumption in the affected DCMTK process, resulting in denial of service. In storescp default single-process deployments, repeated requests can exhaust available memory until the service is terminated or becomes unable to accept further DICOM connections. Service availability is lost until an operator restarts the process. No authentication, privileges, or user interaction are required.
If you can’t patch tonight, do this now.
Until a fixed build is deployed, restrict DICOM services to trusted networks, minimize exposure to untrusted clients, and avoid direct internet accessibility. Prefer multi-process or fork mode where available instead of default single-process operation to reduce the blast radius of a single crashing or leaking worker. Monitor storescp/DCMTK process RSS and connection behavior for abnormal growth and restart affected services if memory exhaustion occurs.
Patch, then assume compromise.
Upgrade OFFIS DCMTK to a version containing the vendor fix. The provided context states the issue affects versions prior to 3.7.0 and that the upstream fix was committed in commit 23f181f7a; where no packaged fixed release is yet available, apply the upstream patch or deploy a build incorporating that commit through the vendor-supported update path.
No public exploits tracked yet. Mallory keeps watching.
5 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.