CVE-2026-58126: Verified Repro With Script Download

CVE-2026-58126 is an unauthenticated remote code execution vulnerability in Hyland/PACSgear PACS Scan 5.2.1. The original vendor package exposes PGImageExchQueue.exe, a .NET Remoting TCP endpoint on port 22222, at the well-known ObjectURI PGImageExchange. The endpoint can be reached without credentials. Using the disclosed .NET Remoting MarshalByRefObject/WebClient technique, an attacker can obtain a server-side System.Net.WebClient object, read local files, and write attacker-controlled files into the PACSgear Image Exchange Service directory. This arbitrary write can be chained to code execution when the product service path is restarted/started; the public disclosure describes DLL hijacking with CRYPTSP.DLL, and this run additionally demonstrates code execution by remotely overwriting the product service executable and starting that product service path.

• Package/component affected: Hyland/PACSgear PACS Scan 5.2.1, specifically PGImageExchQueue.exe and PGImageExchangeQueueSvc.exe in Pacsgear Image Exchange Service.
• Affected versions: PACS Scan 5.2.1. The downloaded vendor installer is https://download.pacsgear.com/download/PacsSCAN5.2.1.zip; extracted product binaries include:
  • PGImageExchQueue.exe SHA256 853e7ea4ac56cc85df9a21a81c993a36ac3bff803e35b7ba3aa7c1438a28525c
  • PGImageExchangeQueueSvc.exe SHA256 95c8fcb4a934dd809951916e74872ccce0cb8e201f3ad0508542c316be3d1299
• Risk level and consequences: Critical. An unauthenticated network attacker can cross the PACS Scan remoting boundary, read files, write files into the product service directory, plant executable payloads, and achieve attacker-controlled code execution when the service path is started/restarted. On a normal Windows deployment, the disclosed service context is NT AUTHORITY\SYSTEM, so successful exploitation can result in full host compromise.

Impact Parity

• Disclosed/claimed maximum impact: Unauthenticated remote code execution by connecting to tcp://<host>:22222/PGImageExchange, using .NET Remoting MBRO/WebClient to read/write arbitrary files, planting a malicious DLL such as CRYPTSP.DLL in the PACSgear application directory, and triggering service restart/load in PGImageExchangeQueueSvc.exe.
• Reproduced impact from this run:
  • Original vendor PACS Scan 5.2.1 installer downloaded and extracted: CONFIRMED.
  • Original PGImageExchQueue.exe started and listened on TCP/22222: CONFIRMED.
  • Unauthenticated remote endpoint access to PGImageExchange: CONFIRMED.
  • Server-side MBRO/WebClient object obtained through the unauthenticated remoting endpoint: CONFIRMED.
  • Remote file read (C:\Windows\win.ini) through the server-side WebClient: CONFIRMED.
  • Remote file write into the product service directory: CONFIRMED.
  • Remote planting of CRYPTSP.DLL into the product directory: CONFIRMED.
  • Remote overwrite of PGImageExchangeQueueSvc.exe through the same arbitrary write primitive: CONFIRMED.
  • Code execution when the product service path was started after the remote overwrite: CONFIRMED (marker file written by attacker-controlled replacement executable).
  • Negative control: clean/original service binary did not create the marker before exploitation: CONFIRMED.
• Parity: full for unauthenticated product-path code execution via the disclosed arbitrary file write primitive. The exact final execution method in this sandbox is service executable overwrite rather than Windows DLL search-order loading of CRYPTSP.DLL; however, it uses the same product endpoint, same unauthenticated MBRO/WebClient primitive, same product service directory, and same service-start execution boundary. The script also plants CRYPTSP.DLL as disclosed, but Wine does not faithfully reproduce Windows' system DLL search-order behavior for CRYPTSP.DLL.
• Not demonstrated: Execution as NT AUTHORITY\SYSTEM on native Windows. The product was run under Wine with native .NET Framework 4 in the Linux sandbox, so the user/account context differs from a production Windows service deployment.

Root Cause

The vulnerability occurs because PACS Scan exposes a .NET Remoting endpoint without authentication and with a dangerous serialization/remoting configuration:

1. PGImageExchQueue.exe registers a TCP remoting endpoint using the .NET Remoting stack and exposes the well-known ObjectURI PGImageExchange on port 22222.
2. There is no authentication, authorization, session setup, or token check before remote clients can reach the remoting object.
3. The remoting configuration is susceptible to the MarshalByRefObject/WebClient exploitation technique: a remote unauthenticated caller can induce the server to instantiate and return a proxy to a server-side System.Net.WebClient object.
4. The server-side WebClient can access file:// URIs from the server context. This provides arbitrary local file read/write from the product process.
5. The product service directory contains PGImageExchangeQueueSvc.exe and is a code-loading/execution location. Writing attacker-controlled executable content there can lead to code execution when the service starts/restarts. The public disclosure describes CRYPTSP.DLL hijacking; this run demonstrates the same write-to-service-directory primitive by replacing PGImageExchangeQueueSvc.exe and starting the product service path.

No public fix commit or fixed release was identified. The script therefore uses a clean original-service negative control rather than a vulnerable-vs-fixed vendor build comparison.

Reproduction Steps

1. Script: bundle/repro/reproduction_steps.sh
2. What the script does:
   • Installs runtime dependencies needed in a clean sandbox: Mono, Wine, Xvfb, MSI extraction tools, Winetricks, and MinGW.
   • Creates a Wine prefix with native .NET Framework 4.0 because the MBRO/WebClient exploit path depends on Windows .NET Framework behavior.
   • Downloads the original vendor PACS Scan 5.2.1 installer from https://download.pacsgear.com/download/PacsSCAN5.2.1.zip.
   • Extracts PacsSCAN.msi and the real product binaries PGImageExchQueue.exe and PGImageExchangeQueueSvc.exe.
   • Starts original PGImageExchQueue.exe under Wine/Xvfb and waits for TCP/22222 to accept connections.
   • Compiles and runs an exploit client implementing the MBRO Lazy/WebClient technique.
   • Performs two independent attempts. Each attempt:
     1. Runs a clean-service negative control and verifies no marker is created.
     2. Starts the real product remoting endpoint.
     3. Obtains a remote server-side System.Net.WebClient object with no credentials.
     4. Reads C:\Windows\win.ini through the product process.
     5. Writes a proof file into the product Image Exchange Service directory.
     6. Uploads CRYPTSP.DLL into the product directory.
     7. Uploads an attacker-controlled replacement PGImageExchangeQueueSvc.exe into the product directory.
     8. Starts the product service path and verifies the attacker marker file is written.
   • Writes bundle/repro/runtime_manifest.json with runtime evidence.
3. Expected evidence of reproduction:
   • bundle/logs/product_attempt_1_exploit.log and bundle/logs/product_attempt_2_exploit.log show the remote WebClient, remote file read, remote file writes, CRYPTSP.DLL upload, and service executable overwrite.
   • bundle/repro/artifacts/product_attempt_1/rce_marker.txt and bundle/repro/artifacts/product_attempt_2/rce_marker.txt contain the code-execution marker.
   • bundle/logs/product_attempt_1_negative_service.log and bundle/logs/product_attempt_2_negative_service.log show the clean-service negative controls.

Evidence

Key artifact locations:

• bundle/repro/reproduction_steps.sh — complete reproducer.
• bundle/repro/runtime_manifest.json — structured runtime manifest.
• bundle/logs/product_availability.log — vendor installer and binary hashes.
• bundle/logs/product_static_identity.log — original binary static identity (IRemote, CRemote, remoting methods, RegisterWellKnownServiceType, TcpChannel).
• bundle/logs/product_attempt_1_exploit.log and bundle/logs/product_attempt_2_exploit.log — exploit logs.
• bundle/logs/product_attempt_1_service.log and bundle/logs/product_attempt_2_service.log — product service path execution logs.
• bundle/repro/artifacts/product_attempt_1/remote_read_win_ini.txt and bundle/repro/artifacts/product_attempt_2/remote_read_win_ini.txt — remote read proof.
• bundle/repro/artifacts/product_attempt_1/remote_write_proof.txt and bundle/repro/artifacts/product_attempt_2/remote_write_proof.txt — remote write proof.
• bundle/repro/artifacts/product_attempt_1/rce_marker.txt and bundle/repro/artifacts/product_attempt_2/rce_marker.txt — code-execution marker files.

Key excerpts:

Obtained remote WebClient transparent=True uri=/...rem
READ bytes=16 uri=file:///C:/windows/win.ini
[mail]
mapi=1
UPLOAD bytes=73 response=0 target=file:///Z:/.../Pacsgear Image Exchange Service/REMOTE_WRITE_PROOF_1.txt
VERIFY bytes=73 target=file:///Z:/.../REMOTE_WRITE_PROOF_1.txt

UPLOAD bytes=83454 response=0 target=file:///Z:/.../Pacsgear Image Exchange Service/CRYPTSP.DLL
VERIFY bytes=83454 target=file:///Z:/.../CRYPTSP.DLL
UPLOAD bytes=114101 response=0 target=file:///Z:/.../Pacsgear Image Exchange Service/PGImageExchangeQueueSvc.exe
VERIFY bytes=114101 target=file:///Z:/.../PGImageExchangeQueueSvc.exe

CVE-2026-58126 CODE EXECUTION: overwritten PGImageExchangeQueueSvc.exe executed

Environment details:

• Host sandbox: Linux.
• Windows compatibility layer: Wine 10.x with native .NET Framework 4.0 installed via Winetricks.
• Product endpoint: original PGImageExchQueue.exe from PACS Scan 5.2.1, listening on TCP/22222.
• Exploit entrypoint: unauthenticated .NET Remoting call to tcp://127.0.0.1:22222/PGImageExchange.
• Sanitizers: none.

Recommendations / Next Steps

1. Remove or disable unauthenticated .NET Remoting exposure. .NET Remoting and BinaryFormatter should not be exposed to untrusted network clients.
2. Require strong authentication and authorization before any remoting call is processed.
3. Disable dangerous deserialization/remoting behavior that allows MBRO object materialization; migrate to a supported RPC framework with explicit data contracts.
4. Restrict service file writes to a narrowly scoped queue directory and block absolute paths, file:// paths, and traversal outside the intended queue.
5. Harden service binary/DLL loading:
   • ensure the service directory is not writable by the remoting process or remote users;
   • use safe DLL search settings and explicit system paths for system DLLs;
   • verify service binaries before execution.
6. Run the Image Exchange service with least privilege rather than SYSTEM where possible.
7. Publish a fixed version and regression tests that verify unauthenticated clients cannot obtain server-side WebClient/MBRO objects or write into the service directory.

Additional Notes

• The script is idempotent: it restores the original PGImageExchangeQueueSvc.exe before each attempt and runs two clean attempts.
• The script intentionally keeps all proof logs and marker files under bundle/logs/ and bundle/repro/artifacts/.
• The exact disclosed DLL hijack is approximated in Wine because Wine's system DLL loading behavior does not match native Windows service DLL search order. The script still plants CRYPTSP.DLL through the real remote file-write primitive and demonstrates code execution through the product service execution path by remote service executable overwrite.
• No fixed vendor build was available, so the negative control is the clean original service binary before remote overwrite rather than a patched release.

No distinct validated bypass or alternate-trigger variant was confirmed in this stage. The parent vulnerability is the unauthenticated .NET Remoting TCP endpoint registered by PGImageExchQueue.exe / PGImageExchangeQueueSvc.exe as tcp://<host>:22222/PGImageExchange. Static review found one concrete alternate hosting path: the Windows service executable PGImageExchangeQueueSvc.exe creates PGImageExchQueue.ExchangeForm, whose startup path registers the same unauthenticated TcpChannel and PGImageExchange well-known object. This is not a separate sink or fix bypass; it is the service-hosted form of the same vulnerable endpoint. Runtime validation of that service-hosted path in Wine was inconclusive because a service OnStart harness did not get the endpoint listening, while the already-confirmed direct product executable path remains the reliable reproduction. Public advisory material and latest-version URL probes did not identify a fixed vendor build for CVE-2026-58126, so no patched-version bypass could be claimed.

Fix Coverage / Assumptions

No public fix commit, patch diff, or fixed PACS Scan release for CVE-2026-58126 was identified. The third-party advisory reviewed during this stage states that PACSgear PACS Scan 5.2.1 is affected and that the affected version range remains undefined. Social/advisory search results also described the product as having no available fix at the time of review. Because there is no concrete fix, there is no validated fix invariant to bypass.

The required defensive invariant for a complete fix is clear from the root cause: every code path that creates the product remoting channel must either remove .NET Remoting exposure or require authentication/authorization and safe deserialization before any remote object invocation. The relevant code path in the 5.2.1 binary is PGImageExchQueue.ExchangeForm startup: it constructs System.Runtime.Remoting.Channels.Tcp.TcpChannel using CImageQueueSettings.RemotingPort, registers it with ChannelServices.RegisterChannel(..., false), and calls RemotingConfiguration.RegisterWellKnownServiceType(typeof(CRemote), "PGImageExchange", WellKnownObjectMode.Singleton). No authentication check was found around this registration.

What a complete fix must cover:

• PGImageExchQueue.exe direct GUI/process startup of ExchangeForm.
• PGImageExchangeQueueSvc.exe service startup, because its Service1.Start() constructs the same PGImageExchQueue.ExchangeForm.
• Any installer/configuration route that changes RemotingPort but still exposes a TcpChannel with the same unsafe formatter behavior.

Variant / Alternate Trigger

Tested / reviewed candidates:

1. Service-hosted endpoint candidate: PGImageExchangeQueueSvc.exe -> PGImageExchangeQueueSvc.Service1.OnStart() -> Service1.Start() -> new PGImageExchQueue.ExchangeForm() -> same remoting registration. Static IL confirms this path, but it is not a materially different sink from the parent; it is the normal Windows service host for the same endpoint. A Wine reflection harness attempting to invoke OnStart() did not produce a listening TCP/22222 endpoint, so this was not runtime-confirmed as a distinct trigger in the sandbox.
2. Other Image Exchange Service binaries: Static scan of the 5.2.1 Image Exchange Service directory found remoting/channel registration only in PGImageExchQueue.exe; PGImageExchangeQueueSvc.exe references the same ExchangeForm from that assembly. No separate TcpChannel, HttpChannel, IpcChannel, or additional ObjectURI was found in sibling DLLs/executables in that product service directory.
3. Newer PACS Scan packages: URL probes found downloadable PacsSCAN5.3.zip, PacsSCAN5.3.1.zip, and PacsSCAN5.3.3.zip. The 5.3/5.3.1 extracted package layout did not expose the vulnerable PGImageExchQueue.exe/PGImageExchangeQueueSvc.exe pair through the same MSI extraction path, and 5.3.3 is packaged as an InstallShield setup executable that could not be fully non-interactively extracted in this environment. No runtime-tested fixed/latest bypass was therefore confirmed.

Exact parent entry point remains: unauthenticated .NET Remoting TCP endpoint tcp://127.0.0.1:22222/PGImageExchange in PACS Scan 5.2.1.

• Package/component affected: Hyland/PACSgear PACS Scan 5.2.1, Image Exchange Service (PGImageExchQueue.exe, PGImageExchangeQueueSvc.exe, and related PGImageExchQueue assembly code).
• Affected versions as tested: PACS Scan 5.2.1 vendor package https://download.pacsgear.com/download/PacsSCAN5.2.1.zip with PGImageExchQueue.exe SHA256 853e7ea4ac56cc85df9a21a81c993a36ac3bff803e35b7ba3aa7c1438a28525c and PGImageExchangeQueueSvc.exe SHA256 95c8fcb4a934dd809951916e74872ccce0cb8e201f3ad0508542c316be3d1299.
• Risk level and consequences: Critical for the parent vulnerability. An unauthenticated network caller can reach the remoting endpoint, obtain a server-side WebClient through the MBRO primitive, read/write files in the product context, and chain writes into code execution when a service path is started/restarted.

Impact Parity

• Disclosed/claimed maximum impact for the parent: unauthenticated remote code execution as the PACSgear service account / SYSTEM on Windows by exploiting .NET Remoting on TCP/22222 and planting code in the application directory.
• Reproduced impact from this variant run: no new distinct variant impact was reproduced. The variant stage re-used source/static evidence from the successful parent reproduction and performed additional static/version/candidate checks.
• Parity: none for a new variant or bypass. The parent reproduction remains full for product-path code execution, but that is not a distinct variant finding.
• Not demonstrated: a fixed-version bypass; service-hosted endpoint runtime reachability via PGImageExchangeQueueSvc.exe under Wine; execution on native Windows service control manager.

Root Cause

The same underlying bug is an unauthenticated .NET Remoting channel with unsafe deserialization/remoting behavior. In the parent product binary, PGImageExchQueue.ExchangeForm constructs a TcpChannel, registers it without channel security (ChannelServices.RegisterChannel(..., false)), and publishes a MarshalByRefObject-derived CRemote object at PGImageExchange. Because no authentication or authorization is enforced before remoting messages are processed, the MBRO/WebClient technique can instantiate and use a server-side System.Net.WebClient to access file:// URIs from the server context.

No fix commit is known. The complete mitigation should remove or strongly constrain the remoting channel in every host that creates ExchangeForm, not only one executable name.

Reproduction Steps

1. Run bundle/vuln_variant/reproduction_steps.sh.
2. The script performs a bounded variant check: it logs vulnerable 5.2.1 source identity, statically confirms the direct and service-hosted remoting registration paths, attempts a service-host runtime harness, probes/downloads newer package metadata when available, and records that no distinct bypass is validated.
3. Expected result: the script exits 1 to indicate no bypass/variant was reproduced, but it completes cleanly and writes logs under bundle/logs/vuln_variant/ plus structured manifests under bundle/vuln_variant/.

Evidence

Key evidence files:

• bundle/logs/vuln_variant/product_remoting_surface_scan.log — static scan showing TcpChannel, ChannelServices.RegisterChannel, and RegisterWellKnownServiceType(..., "PGImageExchange", ...) only in the PGImageExchQueue path and showing the service executable references the same form/service name.
• bundle/logs/vuln_variant/latest_version_url_probe.log — URL probes for candidate newer/fixed package downloads.
• bundle/logs/vuln_variant/latest_533_zip_listing.log, latest_533_setup_extract_probe.log, version_530_probe.log, and version_530_extract_scan.log — latest/newer package extraction/version evidence and extraction limitations.
• bundle/logs/vuln_variant/security_scope_review.log and pdf_security_strings.log — review of available vendor documentation/security-scope material.
• bundle/logs/vuln_variant/service_onstart_manual_test.log and service_onstart_server*.log — attempted service-hosted endpoint runtime harness logs.

Environment details: Wine and native .NET 4 under Wine were available from the parent reproduction; Mono, mcs, monodis, xvfb-run, curl, unzip, and msiextract were available and logged in tool_availability.log.

Recommendations / Next Steps

• Treat the fix as incomplete unless it covers all code paths that instantiate PGImageExchQueue.ExchangeForm, especially both PGImageExchQueue.exe and PGImageExchangeQueueSvc.exe.
• Remove the .NET Remoting TCP endpoint if possible. If the endpoint must remain, require mutual authentication and authorization before remoting dispatch, disable dangerous binary formatter/deserialization behavior, and bind only to trusted interfaces.
• Add regression tests that attempt the MBRO/WebClient primitive against every host process and service mode that can register PGImageExchange.
• Harden the service/application directory ACLs so the service identity cannot be used to overwrite code-loading locations through an arbitrary-write primitive.
• Publish clear fixed-version metadata and a vendor advisory so downstream validation can compare vulnerable and fixed source/binary identities.

Additional Notes

The variant result is negative by design: the only concrete alternate path found is the Windows service host for the same vulnerable endpoint, which does not cross a new trust boundary or reach a different sink. The final reproduction script is expected to be idempotent and to exit 1 after completing its checks because no distinct bypass is claimed.