Dicompass blog

Overview

This advisory addresses two known security vulnerabilities identified in a third-party dependency used within DPGW. Both are fixed by the same Bouncy Castle release, so they are covered by a single advisory.

Vulnerability Details

• CVE ID: CVE-2026-8763, CVE-2026-13506
• Dependency Name:
  • org.bouncycastle:bcprov-jdk18on (direct dependency)
  • org.bouncycastle:bcpkix-jdk18on (direct dependency)
  • org.bouncycastle:bcutil-jdk18on (transitive, via bcpkix-jdk18on)
• Affected Version of Dependency: all versions < 1.85 — fixed in 1.85 (released 2026-07-12)
• Severity Score:
  • CVE-2026-8763 — Name Constraints bypass via trailing dot in rfc822Name and URI (CWE-295): NIST 9.1 Critical
    (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), CNA 9.3 Critical
    (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N)
  • CVE-2026-13506 — Lazy ASN.1 sequence forcing resets nesting-depth guard (CWE-674): NIST 7.5 High
    (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), CNA 8.7 High
    (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N)

Affected Versions of DPGW

All branches in scope bundle a vulnerable version of the library:

• 1.12 — all releases (<= 1.12.54-REL), bundles bcprov-jdk18on / bcpkix-jdk18on / bcutil-jdk18on 1.84
• 1.13 — all releases (<= 1.13.34-REL), bundles bcprov-jdk18on / bcpkix-jdk18on / bcutil-jdk18on 1.84
• 1.14 — all releases (<= 1.14.11-REL), bundles bcprov-jdk18on / bcpkix-jdk18on / bcutil-jdk18on 1.84

For completeness: 1.11 (<= 1.11.47-REL) bundles bcprov-jdk18on 1.78.1 and bcpkix-jdk18on 1.81, which also fall into the affected range. The analysis below applies to that branch unchanged.

Risk Assessment & Applicability

Usage
DPGW declares bcprov-jdk18on and bcpkix-jdk18on as direct dependencies; bcutil-jdk18on is pulled in transitively by bcpkix-jdk18on. dependency:tree -Dincludes=org.bouncycastle on 1.12, 1.13 and 1.14 shows no other Bouncy Castle artifact in the tree (the bcprov-jdk15on that org.apache.cxf:cxf-rt-ws-security would otherwise contribute is explicitly excluded in the POM).
Bouncy Castle is registered as a JCA provider in DPGWMain (and, for the CLI entry point, in CmdLineRunner) with
‘Security.addProvider(new BouncyCastleProvider());’
Security.addProvider() appends the provider to the end of the provider list — it is not inserted at position 1. Provider-less JCA lookups such as CertificateFactory.getInstance("X.509"), CertPathValidator.getInstance("PKIX") and TrustManagerFactory.getInstance("PKIX") therefore continue to resolve to the JDK’s own SUN / SunJSSE providers. Bouncy Castle is only reached where DPGW asks for it explicitly.
TLS does not go through Bouncy Castle. bctls / BCJSSE is not on the classpath. The HTTPS connectors in WebServerImpl are built with org.jsslutils.sslcontext.PKIXSSLContextFactory, which uses TrustManagerFactory.getInstance(...) and CertificateFactory.getInstance("X.509") without a provider argument, i.e. the JDK’s SunJSSE/SUN implementation. The same applies to the LDAP, e-mail and HL7 client socket factories. WS-Security (wss4j via CXF) is used only to attach an outbound UsernameToken; no inbound signature verification or Merlin crypto configuration is present.

Analysis
CVE-2026-8763 — Name Constraints bypass. In PKIXNameConstraintValidator, the dNSName path strips trailing dots before comparison, while the rfc822Name (isEmailConstrained) and URI (isURIConstrained) paths compare the extracted host with a bare equalsIgnoreCase. A leaf certificate with a SAN rfc822Name of ceo@bank.com. therefore does not match an excludedSubtrees entry of bank.com, so checkExcludedEmail never throws and the path validates. Exploitation requires two things: the vulnerable code must actually run — it is reachable only through PKIXCertPathValidatorSpi_8 → RFC3280CertPathUtilities.processCertBC, i.e. through Bouncy Castle’s own CertPathValidator/TrustManagerFactory implementation — and the trust path must contain a name-constrained intermediate CA under the attacker’s control.
Neither precondition holds in DPGW:

• No component requests a CertPathValidator, CertPathBuilder or TrustManagerFactory from the "BC" provider, and because BouncyCastleProvider is appended rather than inserted first, the provider-less lookups performed by jsslutils and by the JDK resolve to SunJSSE. Client-certificate authentication on the HTTPS connectors, and every outbound TLS client, are validated by the JDK’s own PKIX implementation, which is not affected by this CVE.
• DPGW neither issues nor consumes certificates carrying a NameConstraints extension. CAUtils.issueCert() adds only basicConstraints (CA=false), subjectKeyIdentifier and authorityKeyIdentifier — the subjectAlternativeName block in that method is commented out — and no occurrence of NameConstraints, permittedSubtrees or excludedSubtrees exists anywhere in the codebase. Without a name-constrained CA in the chain there is nothing for the bypass to bypass.

CVE-2026-13506 — ASN.1 nesting-depth guard reset. LazyEncodedSequence.force() creates a fresh ASN1InputStream with a re-initialised nesting-depth counter instead of inheriting the remaining depth from the parse that produced it. An attacker who can supply a ~40–50 KB DER structure whose content is a chain of ~10 000 nested SEQUENCEs then causes hashCode()/equals()/toDERObject()/getEncoded()/isSignatureValid() to recurse one Java frame per level with a fresh depth budget each time, producing an uncaught StackOverflowError that kills the handling thread.
The defect is only reachable where lazy evaluation is switched on. In bcprov/bcpkix 1.84 that is the case in exactly two places outside the lazy machinery itself: X509CRLHolder.parseStream() (new ASN1InputStream(stream, true)) and Bouncy Castle’s own JCE CertificateFactory CRL path. Every other entry point — including ASN1Primitive.fromByteArray() and the ASN1InputStream(byte[]) constructor — parses non-lazily and remains protected by the ordinary nesting-depth guard (org.bouncycastle.asn1.max_cons_depth, default 32).
DPGW reaches neither of the two lazy paths. It is also worth noting up front that DPGW performs no CMS, PKCS#7, timestamp (TSP), OCSP or DICOM digital-signature parsing at all — none of those Bouncy Castle APIs appear in the codebase — so the parsing surface is limited to the PEM/PKCS#10 and key-loading paths listed under Usage.

Status
Not Affected

Impact on DPGW

No impact.

CVE-2026-8763 cannot be triggered because Bouncy Castle’s PKIX certificate path validator is never selected — all certificate chain validation, including client-certificate authentication on the HTTPS connectors, is performed by the JDK — and because no certificate handled by DPGW carries a Name Constraints extension.
CVE-2026-13506 cannot be triggered because the lazy ASN.1 evaluation mode that resets the depth guard is only enabled on Bouncy Castle’s CRL parsing paths, which DPGW does not use: it generates CRLs rather than parsing them, and reads CRL files through the JDK’s CertificateFactory. All Bouncy Castle parsing of externally supplied data in DPGW is non-lazy and remains covered by the standard nesting-depth limit.

Remediation & Mitigations

Scheduled fix
Although DPGW is not affected, the vulnerable dependency version will be cleared from the builds as hygiene. Bouncy Castle will be updated from 1.84 to a release >= 1.85 (current upstream release 1.86, published 2026-09-11) for bcprov-jdk18on, bcpkix-jdk18on and the transitively managed bcutil-jdk18on:

• 1.14 — 1.14.12-REL (release date not yet fixed)
• 1.13 — 1.13.35-REL (release date not yet fixed)
• 1.12 — 1.12.55-REL (release date not yet fixed)

User Actions
No user action required.

Overview

This advisory addresses a known security vulnerability identified in a third-party dependency used within DPGW.

Vulnerability Details

• CVE ID: CVE-2023-3438
• Dependency Name: Trellix MOVE AntiVirus – Windows install service (mvagtsce.exe)
• Affected Version of Dependency: <=4.10.0
• Severity Score: NIST 7.8 High, CNA 4.4 Medium

Affected Versions of DPGW

All DPGW versions with the digi module in use (1.11.x – 1.14.x), when the digitization station is installed by the standard installation script with the default installation path C:\Program Files\DicompassDigi

Risk Assessment & Applicability

Usage
DPGW does not bundle, depend on or install Trellix MOVE AntiVirus. The vulnerable product is not part of any DPGW delivery.
The digi module of DPGW controls the Dicompass Capture program, which runs on a separate Windows digitization station. Capture is installed by the installation script install.cmd (repository dpgw/install-digi) into %DIGI_PATH% – by default C:\Program Files\DicompassDigi – and is registered as the Windows service Dicompass Capture Service by its own self-install switch "%DIGI_PATH%\%CAPTURE_VERSION%\DicompassCapture.exe" -si. The service runs under LocalSystem.

Analysis
CVE-2023-3438 is an unquoted Windows service path (CWE-428) in Trellix MOVE AntiVirus. Exploitation requires the Trellix MOVE install service mvagtsce.exe version 4.10.0 or earlier to be present on the machine. DPGW never ships this software, therefore the CVE itself is not applicable to any DPGW component.
The reason this CVE is reported against a DPGW digitization station is the same weakness class in the Dicompass Capture Service registration: the service ImagePath written by DicompassCapture.exe -si is not enclosed in quotation marks, while the default installation path C:\Program Files\DicompassDigi contains a space. Windows therefore also probes C:\Program.exe before the intended binary.
The practical exploitability of this on a digitization station is very limited:

• planting C:\Program.exe requires the ability to create a file in the root of the system drive, which the default Windows ACL grants only to members of the Administrators group – an attacker who already holds that privilege gains nothing
• the station is a dedicated single-purpose appliance running Windows 10; interactive logon for non-administrative accounts is not part of the standard deployment
• the planted binary is only executed on the next start of the service, i.e. after a service restart or a reboot performed by the operator

Status
Affected

Severity Score in the context of DPGW: 2.0 Low CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U/MPR:H

Impact on DPGW

If an attacker were to successfully exploit this vulnerability in the context of our software, the potential impact would be:

• local privilege escalation to LocalSystem on the digitization station, giving full control over the captured images and videos stored on that station before they are sent to DPGW
• no impact on the DPGW server itself, on the archive or on data of other stations

Remediation & Mitigations

Scheduled fix
The unquoted ImagePath is written by the Capture self-installation routine, so the correction belongs to Dicompass Capture. The service registration will be changed to enclose the binary path in quotation marks in an upcoming Capture release; no change to the DPGW server is required.

User Actions
Trellix MOVE AntiVirus is not part of the DPGW delivery – if it is installed on the station by the customer, update it to a version newer than 4.10.0 according to the Trellix advisory SB10404.
For the Dicompass Capture Service the exposure can be checked and mitigated without waiting for the fix:

• resolve the service key name with sc getkeyname "Dicompass Capture Service" and inspect the registration with reg query "HKLM\SYSTEM\CurrentControlSet\Services\<key name>" /v ImagePath
• if the value is not enclosed in quotation marks, correct it with sc config "<key name>" binPath= "\"C:\Program Files\DicompassDigi\capture\DicompassCapture.exe\""
• verify that the root of the system drive C:\ does not allow file creation by non-administrative accounts
• do not grant interactive or remote logon on the digitization station to non-administrative accounts

Overview

This advisory addresses several known security vulnerabilities identified in a third-party dependency used within DPGW: the embedded Eclipse Jetty web server.

Vulnerability Details

• CVE ID: CVE-2026-10050, CVE-2026-10051, CVE-2026-6790, CVE-2026-8384
• Dependency Name: org.eclipse.jetty (jetty-server, jetty-ee10-servlet/servlets, jetty-rewrite, jetty-ee10-proxy, jetty-http2-server, jetty-alpn-*, jetty-client — all resolved via the jetty.version property)
• Affected Version of Dependency:
  • CVE-2026-10050, CVE-2026-10051: Jetty 12.0.0–12.0.35 and 12.1.0–12.1.9 (fixed in 12.0.36 / 12.1.10)
  • CVE-2026-6790, CVE-2026-8384: Jetty 12.0.0–12.0.34 and 12.1.0–12.1.8 (fixed in 12.0.35 / 12.1.9)
  • DPGW 1.13 ships Jetty 12.1.8, which is within all four affected ranges.
• Severity Score (base):
  • CVE-2026-10050 — 8.7 High (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:N digest-auth bypass; GHSA-2fvj-hgj9-j2gr)
  • CVE-2026-10051 — 4.0 Low (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N; GHSA-f4v5-65jj-pcr2)
  • CVE-2026-6790 — Low (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N; GHSA-7p3p-8qv8-m2vh)
  • CVE-2026-8384 — 5.3 Medium (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N; GHSA-w7x5-g22v-xqhr)

Affected Versions of DPGW

• 1.13 — all releases (<= 1.13.29-REL), which bundle Jetty 12.1.8
  The 1.14 branch is not affected: it already ships Jetty 12.1.10 (from 1.14.08-REL; the branch HEAD is on 12.1.11), which is at or above the fixed version for all four CVEs. DPGW versions on the Jetty 12.0.x line are tracked separately.

Risk Assessment & Applicability

Usage
DPGW embeds Eclipse Jetty as its HTTP/HTTPS server (WebServerImpl). Plain connectors serve HTTP/1.1; HTTPS connectors additionally negotiate HTTP/2 via ALPN. DPGW uses jetty-server, the EE10 servlet stack, jetty-rewrite, and jetty-ee10-proxy (three transparent proxy servlets). Outbound HTTP initiated by DPGW itself uses Apache HttpClient 5, not Jetty’s HTTP client. Access-control decisions are made in AuthFilter based on the request path (getRequestURI()/getServletPath().startsWith(...)).

Analysis
CVE-2026-10050 — Jetty HTTP client Digest authentication bypass (base 8.7 High)
The flaw is in Jetty’s client-side DigestAuthentication, which computes Digest hashes using ISO-8859-1, allowing password character collisions. Not applicable to DPGW. DPGW does not use Jetty’s HTTP client for any deliberate outbound request (it uses Apache HttpClient 5), and never configures Digest/Basic authentication or an AuthenticationStore. Jetty’s client is only reached transitively through the transparent proxy servlets, which configure no authentication at all, so the vulnerable code path is never exercised.

CVE-2026-10051 — HTTP/1.1 trailer leak across requests (base 4.0 Low)
A first request’s trailers are retained and leaked into subsequent requests on the same persistent connection. Not applicable to DPGW. DPGW never reads or writes HTTP trailer fields (getTrailerFields/Trailer are unused), so leaked trailers are never consumed.

CVE-2026-6790 — request authority vs. Host header mismatch (base Low)
Jetty does not strictly enforce that the request authority matches the Host header, enabling redirect/virtual-host/reverse-proxy edge cases. Not applicable in DPGW’s standard deployment. DPGW does not install a ForwardedRequestCustomizer and does not make access-control or routing decisions from the Host authority; the server name is used only to construct redirect/callback URLs. DPGW is run standalone (own TLS termination), not as a virtual-host reverse-proxy backend relying on this behaviour.

CVE-2026-8384 — unresolved path traversal in request URI (base 5.3 Medium)
Jetty returns the unresolved request path (e.g. /public/../admin/x rather than the normalized /admin/x) for URIs containing traversal/parameter sequences. Jetty’s own alias checker still blocks direct file traversal, but downstream applications that make security decisions on the raw path can be misled. This is the applicable concern for DPGW: AuthFilter gates access using path-prefix checks (startsWith("/private/"), "/dw/", "/replica/", "/capture/"). A crafted, unresolved URI could cause these prefix checks to be evaluated against a non-canonical path, risking an incorrect authorization or routing decision.

Status
Affected

Severity Score in the context of DPGW: 5.3 Medium CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
The DPGW-context severity is governed by CVE-2026-8384, the only CVE whose vulnerable code path DPGW meaningfully exercises. CVE-2026-10050 (base 8.7 High), CVE-2026-10051 and CVE-2026-6790 are not applicable to DPGW’s usage and do not contribute to the effective severity.

Impact on DPGW

A remote, unauthenticated attacker could craft a request URI containing path-traversal/parameter sequences that Jetty forwards to the application in unresolved form. Because AuthFilter authorizes requests by matching path prefixes, a non-canonical path could lead to an incorrect access-control decision (integrity impact, Low). Direct file-system traversal remains blocked by Jetty’s alias checker, and the other three CVEs are not exploitable in DPGW’s configuration.

Remediation & Mitigations

Fix
Upgrade the embedded Jetty to a fixed version — 12.1.10 or later on the 12.1.x line (12.1.9 fixes CVE-2026-6790/CVE-2026-8384; 12.1.10 additionally fixes CVE-2026-10050/CVE-2026-10051). The 1.14 branch already ships this (Jetty 12.1.10 in 1.14.08-REL; 12.1.11 on branch HEAD).

Scheduled fix
– 1.13 — 1.13.30-REL (2026-07-23) – bump jetty.version from 12.1.8 to 12.1.11

User Actions

• Upgrade to a DPGW 1.13.x release that bundles Jetty 12.1.10 or later once available.
• Interim mitigation: front DPGW with a reverse proxy that normalizes/rejects request URIs containing ../; path-parameter traversal sequences, and restrict network exposure of the web tier to trusted clients.

Overview

This advisory addresses a security vulnerability in DPGW’s own authentication layer (not a third-party dependency). Under specific authentication configurations, the authenticated user identity can leak from one HTTP request to a subsequent request served by the same pooled worker thread, allowing one user’s request to be processed under another user’s identity.

Vulnerability Details

• CVE ID: None (internally identified)
• Component: DPGW Security Manager (org.medoro.dpgw.base.priv.security2.SecurityManager2) and the request authentication filters (Security2FilterHandler, AuthFilter, and the ESB / OAuth2 / GoldDigger login handlers)
• Vulnerability Class: CWE-488 (Exposure of Data Element to Wrong Session) / CWE-384 (Session Fixation) / improper cleanup of thread-local security context on a pooled thread
• Severity Score: 7.8 High (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N)

Affected Versions of DPGW

Affected only when ESB authentication or OAuth2 authentication is enabled (the GoldDigger “open” authentication filter shares the same defect).

• 1.11 — all releases (<= 1.11.47-REL), no fix yet
• 1.12 — all releases (<= 1.12.51-REL), no fix yet
• 1.13 — releases <= 1.13.29-REL (fixed on the branch, ships in the next 1.13.x release)
• 1.14 — all releases (<= 1.14.08-REL), no fix yet
• main / devel — unreleased, not yet fixed

Risk Assessment & Applicability

Usage
DPGW authenticates HTTP requests through a chain of servlet filters. The authenticated Principal is held per-thread in a ThreadLocal<Principal> inside SecurityManager2 (login() sets it, logout() clears it via ThreadLocal.remove()). Requests are served by pooled Jetty worker threads, so the thread-local must be cleared at the end of every request; otherwise the value persists on the thread and is visible to whatever request the pool assigns to that thread next.
Clearing is performed by AuthFilter in finally { sm2.logout(); } blocks — but only on the request paths that flow through chain.doFilter(...). The trusted-user login sink used by the federated login flows, TrustedUserAuthenticateAction.authenticateAndLoginToSession(), calls sm.login(principal) (populating the thread-local) and stores the principal in the HTTP session, but is not paired with a scoped logout.

Analysis
The ESB, OAuth2 and GoldDigger login flows complete the request by writing a redirect/response and returning without calling chain.doFilter(...), so AuthFilter‘s cleanup finally blocks are never reached:

• ESB: ESBTokenAuthFilterHandler.filterAction() (/openviewer) → authenticateAndLoginToSession() (→ sm.login) → filterAction.sendRedirect(...) and return. No logout(), no chain().
• OAuth2: OAuth2AuthorizeServletV1 (/public/auth/v1/oauth2/authorize/*) → AuthorizeHandler.loginUser() → OAuth2Login.loginUser() → authenticateAndLoginToSession() (→ sm.login). Because the endpoint is under /public/..., AuthFilter routes it through its else branch, which chains without a finally-logout.
• GoldDigger: GoldDiggerAuthenticationWebFilter.filterAction() (/openzauth/*) — same login-then-redirect pattern.

After such a login request completes, the ESB/OAuth2/GoldDigger user’s Principal remains in the thread-local on that Jetty worker thread. When the pool next assigns that thread to a different, otherwise-unauthenticated request, the security layer treats the request as already authenticated as the leftover user — the trust points that read the thread-local instead of re-deriving identity from the request/session are AuthFilter (if (sm2.getCurrentPrincipal().isPresent()) { ... }) and OAuth2AuthorizeServletV1 (sm.getCurrentPrincipal().isPresent()).
The exposure window is the first reuse of that thread shortly after a successful login: the request that inherits the identity is served under it and then logs out, clearing the value. An attacker cannot control which pooled thread serves their request and cannot force the timing, so exploitation is a race dependent on a concurrent legitimate login (reflected in AC:H). When it succeeds, the impact is full impersonation of the affected user — read access to that user’s data and the ability to act as them — hence C:H/I:H. There is no availability impact.

Status
Affected

Severity Score in the context of DPGW: 7.8 High CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Network-reachable (AV:N) with no attacker credentials required (PR:N). Attack complexity is High (AC:H) because success requires winning a race for the specific pooled thread immediately after a victim’s federated login. The identity takeover yields high confidentiality and integrity impact (C:H/I:H) against a medical imaging system; no availability impact (A:N).

Impact on DPGW

When ESB or OAuth2 authentication is enabled, a request can be processed under a different user’s identity for the first reuse of a pooled worker thread following that user’s login. This constitutes an authentication/authorization bypass: the inheriting request gains the leftover user’s roles and data access, enabling unauthorized viewing of another user’s studies/patient data and actions performed under their identity. Deployments that do not enable ESB or OAuth2 (or GoldDigger open) authentication are not affected.

Remediation & Mitigations

Fix
The fix ensures the thread-local security context is always cleared at the end of every request, regardless of which handler performed the login, by wrapping the outermost /* filter handler’s request processing in a finally { sm.logout(); }:
– 1.13 — commit d42c8925c3 (“fix(Security): ensure proper logout in Security2FilterHandler”); ships in the next 1.13.x release (after 1.13.29-REL).
Because Security2FilterHandler is the outermost /* handler, its finally-logout runs even when an inner ESB/OAuth2/GoldDigger handler short-circuits with a redirect, so it covers all of the leaking paths.

Scheduled fix
The same fix is to be ported to the remaining maintained branches:

• 1.14 — 1.14.09-REL (2026-07-28)
• 1.12 — 1.12.53-REL (2026-07-23)
• 1.11 — pending
• main / devel — pending

User Actions

• Interim mitigation: if ESB, OAuth2 or GoldDigger open authentication is not required, disable it until the patched release is deployed. Deployments using only standard cookie/session or DPGW-token authentication (whose paths already clear the thread-local) are not exposed.
• Upgrade to a DPGW release containing the fix once available for the branch in use.

Overview

This advisory addresses a known security vulnerability identified in a third-party component used within DPGW. Unlike most advisories in this tracker, the affected component is not a bundled Java dependency but the external 7-Zip binary that DPGW invokes on the host/container to extract user-uploaded archives.

Vulnerability Details

• CVE ID: CVE-2026-14266
• Dependency Name: 7-Zip (7z / 7zip system binary; installed in the DPGW container via dnf install 7zip from EPEL)
• Affected Version of Dependency: 7-Zip 21.07 – 26.01 (fixed in 26.02)
• Severity Score: ZDI/CNA 7.0 High (CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H)

Affected Versions of DPGW

• <= 1.14.08-REL (container bundles the 7zip binary and uses it for archive import)
• <= 1.13.29-REL (container bundles the 7zip binary and uses it for archive import)

The 1.12 and 1.11 branches do not ship the 7-Zip-based archive extraction feature (SevenZipExtractor / ImportInput7Zip / the @sevenzip-command parameter are absent) and do not bundle the 7zip binary in their container images. Those branches are not affected.

Risk Assessment & Applicability

Usage
DPGW uses the external 7-Zip binary to unpack archives uploaded by users during DICOM import. The upload endpoint /private/dicom-import (DicomImportServlet) accepts zip, 7z, rar and iso archives (including password-protected ones); when the @sevenzip-command global parameter is set (default 7z), SevenZipExtractor shells out to the binary as 7z x -y -o<dir> [-p<password>] <file> (ProcessBuilder) and the archive contents are extracted server-side. The binary is provided by the host system — in the standard container image it is installed with dnf install -y ... 7zip (from EPEL); in bare-metal deployments the operator installs the 7zip OS package (documented in the Release Notes).

Analysis
CVE-2026-14266 is a heap-based buffer overflow in 7-Zip’s XZ decompression code. When 7-Zip decodes crafted XZ-compressed chunked data, it corrupts the heap and may execute arbitrary code in the context of the process performing the extraction. The vulnerability is triggered purely by extracting a malicious archive — no separate configuration or feature toggle is required beyond decompression itself. It affects every 7-Zip release from 21.07 through 26.01 and is fixed in 26.02.
DPGW exercises exactly this code path: it invokes the system 7-Zip binary to extract archive content supplied by a user. An attacker who can reach the DICOM import feature can therefore submit a crafted archive that causes code execution as the DPGW service account (uid 1000 inside the container).
The attack is gated by DPGW’s authorization model. The /private/dicom-import endpoint requires an authenticated principal holding ROLE_LOCDATA_IMPORT together with one of the import sub-roles (ROLE_LOCDATA_IMPORT_ARCHIVE, ROLE_LOCDATA_USER_READ or ROLE_LOCDATA_STATION_READ). It is not reachable anonymously. However, once an authorized user (or a stolen/forged session of one) uploads the archive, extraction runs automatically server-side with no further interaction, so the practical scenario is a malicious or compromised authorized user, or an authorized user tricked into importing an attacker-supplied archive.

Status
Affected

Severity Score in the context of DPGW: 7.5 High CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
The base ZDI score assumes a desktop scenario (a victim opens a local malicious file: AV:L, PR:N, UI:R). In DPGW the picture differs: the payload is delivered over the network by an authenticated upload (AV:N), the attacker must hold import privileges (PR:L), and extraction is triggered server-side automatically without a separate victim interaction (UI:N). Attack complexity remains high (AC:H) because reliable heap-overflow exploitation is difficult, and the impact remains High/High/High because successful exploitation yields code execution as the DPGW service account.

Impact on DPGW

Successful exploitation would allow an authenticated user with DICOM-import privileges to achieve remote code execution as the DPGW service account inside the container, by uploading a crafted archive. This could lead to:

• arbitrary code execution in the DPGW process context (uid 1000);
• read/write access to storage and data reachable by the DPGW service account;
• potential lateral movement or service compromise depending on the deployment.

Deployments that do not grant import roles to untrusted users, and that keep the web tier reachable only from trusted networks, have a correspondingly reduced exposure — but any authorized importer able to reach the endpoint can trigger the vulnerable code path.

Remediation & Mitigations

Scheduled fix
he fix is an update of the external 7-Zip binary to 26.02 or later; no DPGW Java code change is required. For the standard container image this means rebuilding the DPGW image once the base repositories (EPEL) provide 7-Zip 26.02+, so that dnf install 7zip pulls the patched binary. This will roll into the maintained 1.13 and 1.14 branches as part of routine image maintenance.

• 1.14 branch — image rebuild bundling 7-Zip 26.02+
• 1.13 branch — image rebuild bundling 7-Zip 26.02+

User Actions

• Containerized deployments: upgrade to a DPGW image built with 7-Zip 26.02 or later. Operators can check the bundled version by running 7z (or the value of @sevenzip-command) inside the container and confirming the reported version is 26.02+.
• Bare-metal deployments: update the host 7zip OS package to 26.02 or later.
• Interim mitigation: restrict DICOM-import roles (ROLE_LOCDATA_IMPORT and the import sub-roles) to trusted users only, and/or unset the @sevenzip-command global parameter to disable server-side archive extraction until the binary is patched (this disables import of 7z/rar/iso and password-protected archives).

Overview

This advisory addresses a known security vulnerability identified in a third-party dependency used within DPGW.

Vulnerability Details

• CVE ID: CVE-2026-64607 (CWE-772, Missing Release of Resource after Effective Lifetime; disclosed 2026-08-13, finder Yu Bao, PayPal Cyber Security Team)
• Dependency Name: org.apache.httpcomponents.client5:httpclient5
• Affected Version of Dependency: 5.0-alpha1 – 5.6.2 — fixed in 5.6.3 (5.6.4 is the current release)
• Severity Score: 5.3 Medium (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, CISA-ADP). NVD has not yet published its own analysis; the ASF rates the issue Important.

Affected Versions of DPGW

All maintained branches declare httpclient5 as a direct, explicitly pinned dependency and bundle a vulnerable version:

• 1.12 — all releases (<= 1.12.53-REL), bundles httpclient5 5.4.4
• 1.13 — all releases (<= 1.13.32-REL), bundles httpclient5 5.5.1
• 1.14 — all releases (<= 1.14.09-REL), bundles httpclient5 5.6.1

Risk Assessment & Applicability

Usage
DPGW uses Apache HttpClient 5 as its general-purpose outbound HTTP client. It is not used to serve inbound requests — that is Jetty’s role — so the vulnerable component is only exercised when DPGW acts as a client against a remote endpoint.
Outbound clients are centrally constructed by org.medoro.dpgw.base.priv.webclient.WebClientFactoryImpl.createHttpClientBuilder(...), which builds a classic (blocking) I/O CloseableHttpClient on top of a PoolingHttpClientConnectionManager (PoolConcurrencyPolicy.STRICT, maxConnTotal / maxConnPerRoute taken from the named WebClientParameters configuration). Roughly 130 source files reference org.apache.hc.*; the classic client is the variant used almost everywhere, including:

• org.medoro.dpgw.web.common.replica.CentralServerConnection — replication sync against the central server
• org.medoro.dpgw.modules.cloudpacsclient.priv.* — CloudPACS API calls
• org.medoro.dpgw.modules.dexclient.priv.* — DEX control connection
• org.medoro.dpgw.dicom.plugin.CStoreStowRSPlugin / CStoreToStowRSPlugin / CStoreToDrSejfPlugin / CMoveToCloudPACSPlugin — DICOMweb / STOW-RS forwarding
• org.medoro.dpgw.base.pub.license.LicenseServer, OAuth2WebClientFactoryPlugins, JWTWebClientFactoryPlugins, HelpDownloader, SharedUserAccountServlet, DPGWHttpClient

The async I/O client (HttpAsyncClientBuilder, used by SSEClient and by CentralServerConnection for its SSE channel) is built by createHttpAsyncClientBuilder(...) and is not affected by this defect.

Response content decoding is enabled by default: WebClientParameters.httpCompression defaults to true, and WebClientFactoryImpl only calls disableContentCompression() when it is explicitly set to false. The ContentCompressionExec interceptor — where the defect lives — is therefore present in the default execution chain of every configured web client.

Analysis
CVE-2026-64607 is a connection-leak defect in HttpClient’s classic I/O execution chain. When a response carries a Content-Encoding header whose value is not a supported/registered encoding, the content-decoding stage fails before the response entity is consumed, and the underlying connection is not released back to the connection manager. Each such response permanently removes one connection from the pool. Once the pool’s maxConnTotal / maxConnPerRoute limit is reached, subsequent requests block until the connection-request timeout expires and then fail — a denial-of-service condition for that client. The async I/O model is not affected.

In DPGW the vulnerable code path is reachable: the classic pooled client is the default, and content decoding is on by default.

Exploitation is, however, not a generic network attack. The malformed response has to come from an HTTP endpoint DPGW is configured to call — the replication central server, a CloudPACS instance, a DEX control server, a DICOMweb/STOW-RS peer, the license server, or a configured OAuth2/JWT identity provider. All of these are administratively provisioned, and connections are made over TLS with strict protocol and hostname validation (DefaultClientTlsStrategy, TLS 1.2/1.3). An attacker must therefore either compromise one of these configured peers or hold a TLS man-in-the-middle position, which substantially raises attack complexity.

The blast radius is also bounded by how DPGW manages client lifetimes. Most call sites build a client per operation inside a try-with-resources block; closing the client discards its pool, so any leaked connection is reclaimed at the end of that operation. The meaningful exposure is the small set of long-lived pooled clients that persist across operations — most notably CentralServerConnection.syncHttpClient (cached replication sync client) and the DEX control connection — where leaked connections accumulate until the pool is exhausted. The effect is degradation of the affected integration (e.g. replication or cloud PACS traffic stalls), not compromise of the gateway or of stored data; confidentiality and integrity are unaffected.

Status
Affected

Severity Score in the context of DPGW: 3.7 Low CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
The vector is lowered from the published AC:L to AC:H because the attacker must control, compromise, or impersonate a remote endpoint that DPGW is explicitly configured to contact over TLS; it is not reachable by an arbitrary network party. Availability impact remains Low: exhaustion is confined to a single named web client’s pool and degrades that one integration.

Impact on DPGW

A malicious or malfunctioning remote peer that returns responses with an invalid or unsupported Content-Encoding header can progressively exhaust the connection pool of the DPGW web client talking to it. Practical consequences are stalled or failing replication sync, CloudPACS API calls, DEX control traffic, or DICOMweb forwarding towards that peer, until DPGW is restarted or the affected client is rebuilt. There is no impact on confidentiality or integrity of patient data, and no impact on DPGW’s inbound (Jetty) request handling.

Remediation & Mitigations

Scheduled fix
Upgrade the bundled org.apache.httpcomponents.client5:httpclient5 to 5.6.3 or later (current release: 5.6.4). The bump will roll into the maintained branches as part of routine dependency maintenance:

• 1.14 — pending (5.6.1 → 5.6.4)
• 1.13 — pending (5.5.1 → 5.6.4)
• 1.12 — pending (5.4.4 → 5.6.4)

User Actions
No user action is required in a standard deployment, where all configured web-client endpoints are trusted, administratively provisioned systems.

Where a remote endpoint is less trusted, exposure can be removed before the dependency upgrade by disabling response content decoding on the affected web client — set httpCompression="false" on the relevant WebClientParameters configuration entry. This takes ContentCompressionExec out of the execution chain entirely, at the cost of losing gzip/deflate response compression for that client.

Symptoms of an ongoing leak are repeated connection-request timeouts against a single endpoint while that endpoint is otherwise reachable; restarting DPGW clears the exhausted pools.

Overview

This advisory addresses a known security vulnerability identified in a third-party dependency used within DPGW.

Vulnerability Details

• CVE ID: CVE-2026-59949 (GitHub advisory GHSA-xx22-p4ch-683r; insufficient validation of byte array arguments at a JNI boundary)
• Dependency Name: at.yawk.lz4:lz4-java (1.12 / 1.13 / 1.14 branches)
• Affected Version of Dependency: at.yawk.lz4:lz4-java <= 1.11.0 — fixed in 1.11.1 (released 2026-07-06)
• Severity Score: 6.5 Medium (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:H)

Affected Versions of DPGW

All maintained branches bundle a vulnerable version of the library:

• 1.12 — all releases (<= 1.12.53-REL), bundles at.yawk.lz4:lz4-java 1.11.0
• 1.13 — all releases (<= 1.13.30-REL), bundles at.yawk.lz4:lz4-java 1.11.0
• 1.14 — all releases (<= 1.14.08-REL), bundles at.yawk.lz4:lz4-java 1.11.0

Risk Assessment & Applicability

Usage
DPGW declares lz4-java as a direct dependency and uses it exclusively for XXHash64 hashing — the LZ4 compression/decompression API (LZ4Factory, net.jpountz.lz4.*) is not referenced anywhere in the codebase, and dependency:tree confirms the artifact is not pulled in transitively by any other component.

XXHash64 is used at the following call sites:

• org.medoro.dpgw.base.pub.hash.XXHash64InputStream / XXHash64OutputStream — checksum streams (java.util.zip.CheckedInputStream/CheckedOutputStream subclasses) used by the storage module (HashAlgorithm.XXH64) to compute content hashes of stored objects while they are read/written.
• org.medoro.dpgw.digi.HashUtils.xxh64(Path) — hashes a file from disk with a fixed 64 KiB buffer.
• org.medoro.dpgw.core.db.DB.calculateLiquibaseHash() — hashes bundled Liquibase changelog resources at startup with a fixed 8 KiB buffer.
• org.medoro.lib.utils.LogHashUtils, NaturalMapHasher, ShareLinksAPIImpl — obtain the hasher via XXHashFactory.fastestJavaInstance().

The first three obtain the hasher via XXHashFactory.fastestInstance(), which selects the JNI/native implementation where available, so the vulnerable code path is present in the build. The remaining three use fastestJavaInstance() (pure-Java implementation), which does not cross the JNI boundary at all.

Analysis
CVE-2026-59949 is a missing-argument-validation defect in lz4-java’s JNI-based XXHash implementations. The native hash(...) / update(...) entry points do not validate the byte array reference or the off/len range before handing them to native code, allowing two failure modes:

• Null array: hash(null, 0, 0, seed) or update(null, 0, 0) reaches GetPrimitiveArrayCritical with a null reference, producing a fatal JVM crash.
• Out-of-bounds range: a call such as update(new byte[16], 0, Integer.MAX_VALUE) lets native code read far past the end of the Java array, again crashing the JVM.

The impact is denial of service through abrupt JVM termination (A:H), with a limited confidentiality component (C:L) from the out-of-bounds read. Critically, exploitation requires the attacker to influence the array object, offset, or length arguments passed to the native API. The upstream advisory states explicitly that normal usage patterns, where only the contents of the array are attacker-controlled, are not affected.

DPGW’s usage falls entirely into that unaffected pattern:

• Every native call site passes a locally allocated, fixed-size buffer with the range (buf, 0, read), where read is the return value of InputStream.read(buf) — by contract non-negative and never greater than buf.length. The array reference is never null and never externally supplied.
• The two checksum streams delegate through java.util.zip.CheckedInputStream/CheckedOutputStream. In CheckedInputStream.read(b, off, len) the range is validated by the underlying stream’s read before Checksum.update is invoked; in CheckedOutputStream.write(b, off, len) the wrapped OutputStream.write is called first and rejects an invalid range before the checksum update is reached. In both cases the offset/length originate from DPGW’s internal copy loops, not from remote input.
• Attacker-supplied data (DICOM objects, uploaded documents) only ever reaches the hasher as array contents, never as an array reference, offset, or length.

There is therefore no path by which a remote or local actor can steer the offset, length, or array reference reaching the native XXHash entry points.

Status
Not affected

Impact on DPGW

No impact. The vulnerable JNI argument-validation gap can only be triggered by a caller that supplies a null array or an out-of-range off/len pair. All DPGW call sites pass internally allocated buffers with ranges derived from InputStream.read return values, so the crash condition cannot be reached — including on the 1.11 branch, where the abandoned org.lz4:lz4-java 1.8.0 artifact has no upstream fix.

Remediation & Mitigations

Scheduled fix
Although DPGW is not affected, the vulnerable dependency version will be cleared from the builds as hygiene:
– 1.14 / 1.13 / 1.12 — bump at.yawk.lz4:lz4-java 1.11.0 → 1.11.1 in the next routine release of each branch.

User Actions
No user action required.

Overview

This advisory addresses a known security vulnerability identified in a third-party dependency used within DPGW.

Vulnerability Details

• CVE ID: None assigned (GitHub advisory GHSA-r7wm-3cxj-wff9; CWE-770, Allocation of Resources Without Limits or Throttling)
• Dependency Name: com.fasterxml.jackson.core:jackson-core
• Affected Version of Dependency: < 2.18.8, 2.19.0 – 2.21.3, and 2.22.0 (fixed in 2.18.8 / 2.21.4 / 2.22.1). The DPGW 1.12 branch bundled 2.21.3, which falls in the affected range.
• Severity Score: 8.7 High
  (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N)

Affected Versions of DPGW

• <= 1.12.51-REL (the 1.12 branch declares jackson-core as a direct, explicitly pinned dependency and shipped the vulnerable 2.21.3)

jackson-core is directly managed in the POM only on the 1.12 branch; on the other maintained branches it is pulled in transitively. This advisory tracks the 1.12 branch, where the dependency was explicitly bundled and has now been updated.

Risk Assessment & Applicability

Usage
DPGW uses Google Gson as its primary JSON library; it does not use Jackson for its own JSON handling and contains no direct references to the Jackson streaming API. jackson-core is present only as a transitive dependency — principally via com.auth0:java-jwt (JWT parsing, which uses the blocking ObjectMapper on a complete in-memory token string) and the Azure Storage SDK (which serializes with azure-json, not Jackson streaming). On the 1.12 branch, jackson-core is additionally pinned as a direct managed dependency to control the resolved version.

Analysis
GHSA-r7wm-3cxj-wff9 is an incomplete fix of a prior advisory (GHSA-72hv-8253-57qq). Jackson’s non-blocking asynchronous streaming parser fails to enforce the configured maxNumberLength limit (default 1000) when a JSON number’s integer digits arrive across multiple input chunks without a terminating byte. An attacker streaming a long run of digits in small chunks can force the parser to accumulate characters up to the maxStringLength limit (20 MiB default) — an amplification of roughly 20,000× over the configured number-length cap — leading to memory exhaustion (denial of service).

The vulnerable code path is reachable only through the non-blocking parser — JsonFactory.createNonBlockingByteArrayParser() / createNonBlockingByteBufferParser() (NonBlockingJsonParser) — which must be explicitly fed chunked input, typically from a reactive / non-blocking streaming pipeline.

DPGW never instantiates the non-blocking parser: there is no direct Jackson usage anywhere in the codebase, and no reactive pipeline that feeds chunked bytes into a Jackson async parser. The only component that actually parses JSON with Jackson (java-jwt) uses the standard blocking parser on a fully-buffered in-memory string, which is not affected by this issue. The vulnerable code path is therefore unreachable in DPGW.

Status
Not affected

Impact on DPGW

No impact. The vulnerability is confined to Jackson’s non-blocking asynchronous parser, which DPGW does not use. The jackson-core artifact is only ever exercised through blocking, fully-buffered parsing by transitive consumers, so the memory-exhaustion condition cannot be triggered.

Remediation & Mitigations

Scheduled fix
Although DPGW is not affected, the vulnerable dependency version was cleared from the 1.12 build as hygiene: jackson-core was updated 2.21.3 → 2.21.5 (commit d4c148f506, 2026-07-23). This will ship in the next 1.12 release:
– 1.12.52-REL — bundles jackson-core 2.21.5

User Actions
No user action required.

Overview

This advisory addresses a known security vulnerability identified in a third-party dependency used within DPGW.

Vulnerability Details

• CVE ID: CVE-2026-54291
• Dependency Name: org.postgresql:postgresql (PostgreSQL JDBC Driver, pgjdbc)
• Affected Version of Dependency: 42.7.4 – 42.7.11 (fixed in 42.7.12)
• Severity Score: NIST 5.9 Medium
  (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N); CNA (GitHub) 8.2 High (CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N)

Affected Versions of DPGW

• <= 1.14.08-REL (bundles pgjdbc 42.7.11)
• <= 1.13.29-REL (bundles pgjdbc 42.7.11)
• <= 1.12.51-REL (bundles pgjdbc 42.7.11)

The 1.11 branch (currently 1.11.47-REL) ships pgjdbc 42.7.3, which predates the vulnerable code and is not within the affected range.

Risk Assessment & Applicability

Usage
DPGW uses the PostgreSQL JDBC driver (pgjdbc) as the client driver for its application database. The database connection is configured in the <database> section of dpgw.xml via the connection-url parameter; the default and documented value is jdbc:postgresql://localhost/.... DPGW does not set the channelBinding connection property, nor does it enable TLS on the database connection (sslmode / ssl are not configured in any shipped or example configuration).

Analysis
CVE-2026-0636
CVE-2026-54291 is a silent channel-binding authentication downgrade in pgjdbc. When a client requests channelBinding=require over a TLS connection, the SCRAM client returns empty byte arrays instead of failing when it encounters a TLS certificate signed with an unsupported signature algorithm. This lets an active man-in-the-middle on the TCP/TLS path between the JDBC client and the PostgreSQL server downgrade SCRAM-SHA-256-PLUS (with channel binding) to plain SCRAM-SHA-256 (without it), defeating the MITM protection that channel binding is meant to guarantee. Exploitation requires an attacker positioned on the network path between the application and its database.

In the deployment configuration covered by this advisory — the PostgreSQL database residing on the same host as DPGW and accepting only localhost connections — the DPGW-to-database traffic never leaves the host. There is no network segment for an attacker to occupy, so the man-in-the-middle precondition of the vulnerability cannot be met. This matches DPGW’s default and documented configuration (jdbc:postgresql://localhost/...). In addition, DPGW does not request channel binding and does not use TLS for the database connection, so the vulnerable negotiation path is not exercised in the first place.

Status
Not affected

Impact on DPGW

No impact for deployments where the PostgreSQL database is co-located on the DPGW host and reachable only via localhost. With no network path between DPGW and the database, the man-in-the-middle prerequisite of CVE-2026-54291 cannot be satisfied.

Note: Deployments that connect DPGW to a PostgreSQL instance over a network (for example a database on a separate host, as used in some multi-site/replication setups) and that rely on channelBinding=require for MITM protection should treat the driver as vulnerable and apply the fix below. Standard DPGW deployments do not use this configuration.

Remediation & Mitigations

Scheduled fix
The driver has been updated to a fixed version on the development line:
– main (next release line) — pgjdbc bumped to 42.7.13 (commit chore(Security): bump postgres due to CVE-2026-54291)

Since DPGW is Not Affected in the standard localhost database configuration, the pgjdbc 42.7.12+ bump will roll into the maintained 1.12 / 1.13 / 1.14 branches as part of routine dependency maintenance rather than as an emergency release. The 1.11 branch is unaffected at the dependency level (pgjdbc 42.7.3) and needs no change.

User Actions
No user action required for the standard configuration (database on the same host, localhost-only connections).

Operators can confirm they are in the unaffected configuration by checking that the connection-url in the <database> section of dpgw.xml points to localhost (or 127.0.0.1) and that PostgreSQL is configured to accept only local connections. Operators running DPGW against a remote PostgreSQL database over an untrusted network should upgrade to a DPGW build bundling pgjdbc 42.7.12 or later.

Overview

This advisory addresses a known security vulnerability identified in a third-party dependency used within DPGW.

Vulnerability Details

• CVE ID: CVE-2026-9828
• Dependency Name: ch.qos.logback:logback-classic (logback-core)
• Affected Version of Dependency: <= 1.5.32
• Severity Score: CNA 2.9 Low (CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N/E:P/RE:L/U:Green); NIST score not yet published

Affected Versions of DPGW

• <= 1.14.08-REL
• <= 1.13.29-REL
• <= 1.12.51-REL
• <= 1.11.47-REL

Risk Assessment & Applicability

Usage
DPGW uses Logback as its logging framework, initialized at startup by DPGWMain, and configured via conf/logback.xml. No DPGW deployment configures a SocketAppender or a socket-based log receiver.

Analysis
CVE-2026-0636
CVE-2026-9828 affects Logback’s HardenedObjectInputStream, a class used exclusively by Logback’s SimpleSocketServer and SimpleSSLSocketServer components to deserialize ILoggingEvent objects received over a network socket from a remote SocketAppender. In affected versions (through 1.5.32 inclusive), the hardening allow-list accepts a broader set of java.lang/java.util classes than intended, letting a party able to send crafted serialized data to such a socket server instantiate restricted objects and bypass the intended restriction. Exploitation requires the target application to actually run a SimpleSocketServer/SimpleSSLSocketServer instance reachable by the attacker; no remote code execution has been demonstrated, only a restriction bypass.

DPGW never instantiates or launches ch.qos.logback.classic.net.SimpleSocketServer or SimpleSSLSocketServer, and none of its logback.xml configurations (default or site-specific) define a SocketAppender or socket receiver. Logback is used purely as an in-process logging library, so the vulnerable deserialization code path is never reachable, locally or remotely.

Status
Not affected

Impact on DPGW

No impact. The vulnerable component is never invoked by DPGW.

Remediation & Mitigations

Scheduled fix
Not required for security reasons, but logback has already been bumped to the fixed version (1.5.37) as part of routine dependency maintenance on 2026-07-03. This will ship in the next release of:
– main / 1.14 branch (currently 1.14.08-REL)
– 1.13 branch (currently 1.13.29-REL)
– 1.12 branch (currently 1.12.51-REL)
The 1.11 branch (currently 1.11.47-REL, logback 1.5.16) has not received this bump. Since DPGW is Not Affected, no dedicated fix is scheduled for 1.11 at this time.

User Actions
No user action required.