# Patch / Fix Analysis for CVE-2026-58126 Variant Stage

## Patch availability

No public vendor patch commit, fixed binary diff, or fixed PACS Scan release specifically addressing CVE-2026-58126 was identified during this stage.

Evidence reviewed:

- `bundle/ticket.md` identifies PACS Scan 5.2.1 as affected but does not name a fixed version.
- The VulnCheck advisory extracted during this run states `PACSgear PACS Scan <= 5.2.1` and says the affected version range remains undefined.
- Search/probe results include public commentary describing the issue as having no available fix at the time of publication.
- Direct URL probes found downloadable newer product packages (`PacsSCAN5.3.zip`, `PacsSCAN5.3.1.zip`, `PacsSCAN5.3.3.zip`) but did not identify a CVE-specific fixed build or advisory.

Because no fix artifact was available, this analysis focuses on the required complete-fix coverage and on variant candidates that a partial fix could miss.

## Vulnerable code paths and sink

The parent vulnerable sink is the .NET Remoting registration in the PACS Scan Image Exchange component. Static IL review of the original PACS Scan 5.2.1 product binary shows:

- File: `Program Files/Pacsgear/Pacsgear Image Exchange Service/PGImageExchQueue.exe`
- Class/function: `PGImageExchQueue.ExchangeForm` startup path
- Relevant behavior:
  - Reads `CImageQueueSettings.RemotingPort` (default initialized to `22222`).
  - Constructs `System.Runtime.Remoting.Channels.Tcp.TcpChannel` with that port.
  - Calls `ChannelServices.RegisterChannel(channel, false)`.
  - Calls `RemotingConfiguration.RegisterWellKnownServiceType(typeof(PGImageExchQueue.CRemote), "PGImageExchange", WellKnownObjectMode.Singleton)`.
  - `CRemote` extends `MarshalByRefObject` and implements product remote-control methods.

The vulnerable trust boundary is network/API remote: an unauthenticated caller can connect to `tcp://<host>:22222/PGImageExchange`. The dangerous sink is not the product methods themselves only; it is the unauthenticated .NET Remoting dispatch/deserialization surface, which can be abused with the MBRO/WebClient primitive to obtain server-side file read/write.

## What a complete fix must change

A complete fix should enforce at least one of these invariants across every host that can register the remoting endpoint:

1. Remove the .NET Remoting TCP endpoint entirely, or bind it only to a trusted local interface unavailable to untrusted callers.
2. Require strong authentication and authorization before any remoting dispatch reaches `PGImageExchange`.
3. Disable or replace unsafe .NET Remoting/BinaryFormatter-style object activation/deserialization that enables the MBRO/WebClient primitive.
4. Ensure the service/application directory cannot be overwritten by the process identity even if a file-write primitive is discovered.

The fix must cover all startup modes that instantiate `PGImageExchQueue.ExchangeForm`, not just the `PGImageExchQueue.exe` filename.

## Fix assumptions that would be unsafe

Because the service executable delegates into the same form/assembly, a narrow fix could be incomplete if it assumes any of the following:

- **Assumption: only `PGImageExchQueue.exe` registers `PGImageExchange`.** Static review shows `PGImageExchangeQueueSvc.exe` creates `PGImageExchQueue.ExchangeForm` in `Service1.Start()`, so service startup can reach the same registration logic.
- **Assumption: product remote methods are harmless.** The exploit reaches the .NET Remoting infrastructure/serialization sink and obtains a server-side `WebClient`; simply auditing `CRemote.ClearJobs`, `GetLog`, `Ping`, etc. is not sufficient.
- **Assumption: changing the final DLL hijack target fixes RCE.** The parent exploit demonstrates arbitrary file write into the service directory. Blocking one DLL name such as `CRYPTSP.DLL` does not remove the file-write primitive or other service-path code-loading possibilities.
- **Assumption: newer installer packaging alone proves the issue fixed.** Newer package layout changed between 5.2.1 and 5.3.x, but no CVE-specific patch notes or runtime proof of a fixed endpoint were available.

## Code paths/inputs not covered by a narrow fix

The following paths require explicit coverage by any final patch:

- `PGImageExchQueue.exe` direct process startup.
- `PGImageExchangeQueueSvc.exe` service startup: `Program.Main()` -> `ServiceBase.Run()` -> `Service1.OnStart()` -> `Service1.Start()` -> `new PGImageExchQueue.ExchangeForm()`.
- Any configurable `RemotingPort` value that still exposes a `TcpChannel` and `PGImageExchange` ObjectURI.
- All deserialization/remoting message types accepted by the channel, not only ordinary product method calls.

## Behavior before and after the fix

### Before fix (observed in 5.2.1)

- `PGImageExchQueue.exe` listens on TCP/22222 with ObjectURI `PGImageExchange`.
- No credentials are required.
- The MBRO/WebClient primitive can read `file:///C:/windows/win.ini` and upload files to the product directory.
- The arbitrary write can be chained to product-path code execution when the service path is started/restarted.

### After fix (not available for direct testing)

Expected fixed behavior should be:

- Unauthenticated connections to `tcp://<host>:22222/PGImageExchange` fail before remoting object dispatch, or the endpoint is absent.
- MBRO/WebClient payloads cannot instantiate/use server-side `WebClient` objects.
- Both direct executable and Windows service startup modes exhibit the same protected behavior.
- Attempts to write into code-loading locations through the remoting channel fail.

## Threat model / security-scope review

No `SECURITY.md` exists because this is a closed-source vendor product package, not a public repository. Available vendor PDFs and documentation were reviewed from the installer package and public Hyland documentation. The available technical-specification material discusses operational requirements such as antivirus exclusions, Windows security patches/updates, and FIPS compliance, but it does not define a policy excluding unauthenticated network remoting from security scope. Public advisory material classifies the issue as missing authentication for a critical function and unsafe deserialization of untrusted data. Therefore the parent class is in scope: attacker-controlled network input crosses a product service boundary without authentication.

## Variant/bypass conclusion

No distinct validated bypass was found. The only concrete alternate path identified is service-hosted startup of the same endpoint via `PGImageExchangeQueueSvc.exe`, which is important for patch coverage but not a materially separate variant because it reaches the same `ExchangeForm` registration and same `PGImageExchange` sink. Since no fixed build was available, no patched-version bypass can be claimed. The recommended outcome for the Coding/fix stage is to patch the central remoting registration and add tests for both the direct executable and service-hosted startup paths.