# Variant RCA Report: CVE-2026-58126 ## Summary 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://: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. ## Impact - **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.