CGM CLININET: 11 Hospital System CVEs, Root RCE and Six With No Fix

On 23 October 2026 CERT Polska published 11 vulnerabilities in CGM CLININET, a hospital information system used in Poland. Several give root code execution from the local network, and one exposes patient documents without login. Five are fixed in 2026.MS3; six have no stated fix. Upgrade, then segment the server.

This is a coordinated vulnerability disclosure, not a breach. CERT Polska's advisory does not report any exploitation, nobody has alleged that patient data was taken, and as of 24 October none of the 11 CVEs appears in the CISA Known Exploited Vulnerabilities catalog. We found no public proof of concept. What the advisory does show is that a server holding a hospital's clinical records can be taken over with root privileges by anyone who can reach it on the hospital network, and that for six of the 11 issues there is no fixed release yet.

The rest of this post sets out exactly what CERT Polska and the CVE records say, which flaws are fixed and which are not, what hospital IT and security teams can check today with real commands, and which compensating controls cover the six open issues until CGM ships a fix.

What happened

CERT Polska, the national CSIRT run by NASK, published an advisory titled "Vulnerabilities in CGM CLININET software" on 23 October 2026. It lists 11 CVE IDs, all for CGM CLININET from CompuGroup Medical (CGM), and says CERT Polska received the report and took part in coordinating the disclosure. The researcher credited is Maciej Kazulak, for every ID except CVE-2025-58403, where no researcher is named.

The same morning CERT Polska, acting as the CVE Numbering Authority, published the 11 CVE records. The National Vulnerability Database (NVD) picked them up within the hour, and the GitHub Advisory Database added entries for four of them, all rated critical.

CLININET is CGM's hospital information system (HIS) for the Polish market. CGM's own product page describes it as running in some of the largest healthcare units in Poland, in hospitals from 50 beds up to 1,500 beds, with 10 to more than 500 workstations working at the same time. It covers admissions, wards, operating theatres, pharmacy, diagnostics, electronic medical records and links to outside systems. That last point matters here, because several of the flaws sit in the parts of CLININET that talk to other systems.

Not a breach, and not the first batch

Two points help keep this in proportion.

First, nothing in the advisory says these flaws were used against any hospital. The advisory is a disclosure of weaknesses, published after a coordination process. If you run CLININET, your job this week is to patch and harden. There is no incident to respond to unless your own logs give you one.

Second, this is the third set of CLININET vulnerabilities CERT Polska has published from the same research. On 27 August 2025 it published a first batch that included code execution in the Print.pl service, several SQL injection flaws, unauthenticated endpoints that leaked session IDs, and a configuration file with database passwords readable by any local user (CVE-2025-30063). On 2 March 2026 it published a second batch that included a full authentication bypass (CVE-2025-30035), a smart card login that only checked the certificate number (CVE-2025-30042), and a SQL injection flaw in CGM NETRAAD, CGM's imaging server, that could reach data processed by CLININET (CVE-2025-10350). The 23 October batch closes out most of the remaining IDs in the range CERT Polska reserved in March 2025.

Timeline

All times are UTC and come from the records named in the source column.

The CVE IDs were reserved on 14 March 2025 and published on 23 October 2026, more than 19 months later. CERT Polska's published policy is to publish CVE entries 90 days after it sends vulnerability details to the vendor, sooner if a fix ships, and it allows that period to be extended "in justified cases". Reservation is not the same as the date of the report to CGM, and neither CERT Polska nor CGM has published the discovery date, so we will not guess it. The gap does tell you that some of these issues were known to the vendor long before they were known to the hospitals that run the software.

Who is affected

Any organisation running CGM CLININET on a release older than 2026.MS3 is affected by all 11 issues. Organisations already on 2026.MS3 are still affected by six of them, according to CERT Polska, which says each of those six was "confirmed to affect versions up to 2026.MS3 but later versions may also be vulnerable".

CERT Polska does not say how many hospitals run CLININET, and we have not found a reliable public count, so we will not offer one. CLININET is a Polish market product. We have no evidence of deployments outside Poland and this post does not assume any. We also do not name individual hospitals.

How it works

Most of these flaws share one shape: a component that processes data from the network or from another account runs as root. When that component can be tricked into running code, the attacker gets root on the server that holds the hospital's clinical records, with no further step needed.

Here is each class in plain language. None of this is a recipe; CERT Polska's descriptions, which we summarise, stop at the level of which component is affected and what an attacker gains.

Unauthenticated access to patient documents (CVE-2025-30043)

A path on the CLININET server, spelled /DocManagment in the advisory, answers requests without checking who is asking. According to CERT Polska, an unauthenticated attacker in the adjacent network can get a list of patient documents and download them. This is the flaw that puts patient data at risk directly, without any code execution. It is fixed in 2026.MS3.

Root code execution through the admin API (CVE-2025-30047)

The administrative module talks to the server over an HTTP API that exchanges Java serialized objects. Java deserialization of data from an untrusted sender is a well known class of flaw: if the receiving side turns bytes into objects without limiting which classes it will accept, a sender can supply an object graph whose side effects run code. CERT Polska says anyone on the same local network can send such an object to this API and get code execution as root. CERT-PL scores it 9.4 under CVSS 4.0, the joint highest in the batch. It is fixed in 2026.MS3. For background on the bug class, see our explainer on Java deserialization vulnerabilities.

Root code execution through module loading (CVE-2025-30050)

RunCGI.pm loads a Perl module whose name comes from a query parameter. CERT Polska says an attacker on the adjacent network can make it import a module of the attacker's choosing, which runs as root. Also 9.4, also fixed in 2026.MS3.

Root code execution through HL7 processing (CVE-2025-30046)

HL7 is the message standard hospitals use to move orders, results and patient administration events between systems. CLININET runs several HL7 communication processes as root while they handle data from those external systems. CERT Polska says an attacker on the adjacent network who can send data to them can get code execution as root. CERT-PL scores it 9.0. There is no stated fix. This is the one to think hardest about, because HL7 listeners exist precisely to accept data from other systems.

Root code execution through document expressions (CVE-2025-30045)

The ConvExpr function turns Perl expressions into content for RTF documents. Because the code it evaluates is not properly controlled, an authenticated, high privileged user can run code as root. It needs a privileged account and some user interaction, which lowers the odds, but the result is still root. Scored 8.6, no stated fix.

Privilege escalation and weak local permissions (CVE-2025-30054, CVE-2025-30051)

The service that processes incoming HL7 messages runs as root, but its scripts and configuration files can be changed by the uhcapache account. Anyone who gets code running as uhcapache, for example through a web application flaw, can edit those files and have root run their code. Scored 9.3, no stated fix.

Separately, SysIO.pl holds the production database login and password and the RabbitMQ message broker credentials, and its permissions let any local account read it. Fixed in 2026.MS3. A close relative of this issue, CVE-2025-30063, was in the August 2025 batch, which is worth noting when you check whether earlier fixes fully closed the gap on your servers.

Network services that trust too much (CVE-2025-30052, CVE-2025-30053)

The rsync daemon on the CLININET server decides who may write files based only on the client's source IP address. An attacker who can spoof an allowed address can change files. Scored 8.8, no stated fix. The cgm-updater process listens on a network port with no authentication at all. Scored 6.9, no stated fix. CERT Polska does not say what an attacker can do through cgm-updater beyond the lack of authentication, so we will not speculate.

Weak password storage (CVE-2025-30049)

CLININET stored user passwords as unsalted MD5 hashes. Anyone who obtains the hash table can crack common passwords quickly and spot users who share a password. Fixed in 2026.MS1 and 2026.MS3. A fix in the hashing code does not change hashes that are already stored, so plan a password reset after upgrading unless CGM tells you the migration handles it.

Reflected cross site scripting (CVE-2025-58403)

A crafted link can run script in a logged in user's browser, which CERT Polska says allows session cookie theft and actions on the user's behalf. It needs the victim to click. Scored 5.1, no stated fix.

Why "adjacent network" is not reassuring in a hospital

Seven of the 11 records use the adjacent or local attack vector in their CVSS scores. That can read like a comfort. In most hospitals it is not. The networks are large, they carry thousands of workstations, they share segments with medical devices and building systems that are hard to patch, and they are reachable by vendors, contractors and remote support tools. A single phished workstation in the clinical network, or a compromised device on a flat VLAN, is "adjacent". The question to ask is not whether an attacker is on the internet, but how many hosts on your network can open a TCP connection to the CLININET application server today. For many hospitals the honest answer is most of them.

Technical details

Every value below comes from the CERT Polska advisory of 23 October 2026, the CVE records CERT-PL published on CVE.org, the NVD records, or the GitHub Advisory Database. CVSS scores are CVSS 4.0 base scores assigned by CERT-PL as the CNA; NVD has not added its own scores. CERT Polska's advisory page itself does not show scores.

All 11 CVEs with affected versions and fix status

The two release lines named for CVE-2025-30049 suggest CGM shipped the hashing fix in two maintenance lines, 2026.MS1 and 2026.MS3. The advisory does not explain this, so confirm with CGM which line you are on and whether your build includes it.

One discrepancy to flag. For CVE-2025-58403, the CERT Polska advisory lists the vulnerable versions as "All through 2026.MS3", while the CVE record on CVE.org lists the affected range as up to and including 2025.MS3. The advisory's description text also says the flaw was confirmed up to 2026.MS3. We treat the advisory as the more complete source and assume 2026.MS3 is affected until CGM says otherwise.

CVSS 4.0 vectors

These are the vectors exactly as published by CERT-PL in the NVD records, with the unset supplemental and environmental metrics removed for readability.

Three readings from the vectors are useful for planning:

1. CVE-2025-30047 and CVE-2025-30050 need no privileges (PR:N), no user interaction (UI:N) and no special conditions (AT:N), from the adjacent network. They are fixed in 2026.MS3, which is why the upgrade is the first priority.
2. CVE-2025-30046 is equally severe in impact but carries AT:P, meaning some attack requirement must be present, which fits an attacker needing to be able to deliver data to the HL7 processes. Restricting who can deliver that data is therefore a direct mitigation.
3. Every root code execution vector carries high subsequent system impact (SC:H/SI:H/SA:H). CERT-PL is telling you that taking over the CLININET server is expected to affect the systems connected to it.

Advisory and record identifiers

The GitHub entries carry no package name or ecosystem, because CLININET is not distributed through a package registry. That has a practical consequence: dependency scanners that match findings to package names will not raise these CVEs for you. You have to know you run CLININET, and which release, from your own asset inventory.

Named files, accounts and services

• /DocManagment: the unauthenticated document path (CVE-2025-30043). Note the spelling.
• ConvExpr: the function that evaluates Perl expressions into RTF content (CVE-2025-30045).
• RunCGI.pm: the component that imports a module named in a query parameter (CVE-2025-30050).
• SysIO.pl: the configuration file holding production database and RabbitMQ credentials (CVE-2025-30051).
• uhcapache: the account that can modify root run HL7 scripts and configuration (CVE-2025-30054).
• cgm-updater: the unauthenticated network listener (CVE-2025-30053).
• rsyncd: the rsync daemon that trusts source IP only (CVE-2025-30052). The rsync daemon listens on TCP port 873 by default, according to the rsyncd.conf manual; CERT Polska does not say which port CLININET uses.
• From the earlier batches, the web application lives under paths starting /cgi-bin/CliniNET.prd/, and the August 2025 advisory notes internal endpoints, often containing /int/ in the path, that were reachable on port 443. Those are useful anchors for reverse proxy rules and log searches.

What is not published

There are no indicators of compromise, because no compromise has been reported. CERT Polska does not publish port numbers for the admin API or cgm-updater, file paths on disk, hashes of fixed builds, or a fix timeline for the six open issues. We did not find a public CGM security bulletin for this batch. Ask CGM support for the release notes of 2026.MS3 and for written fix dates for the open items.

What to do now

The order below puts the cheapest, highest value steps first. Run commands on the CLININET application server only with your change process and, where the vendor contract requires it, with CGM support involved. Several steps change file permissions or network rules on a clinical system; test them in a non production environment if you have one, and agree a rollback.

1. Confirm your release and plan 2026.MS3

Find out which CLININET release each environment runs (production, test, training, disaster recovery). The release identifier is in CGM's format, such as 2025.MS4 or 2026.MS3. If you cannot find it in the application's About screen, ask CGM support to confirm it in writing.

Then book the 2026.MS3 upgrade. It fixes CVE-2025-30043, 30047, 30049, 30050 and 30051, including the two 9.4 root code execution flaws and the patient document exposure. If you are on a release older than 2025.MS4, you are also missing fixes from the March 2026 batch, including the authentication bypass CVE-2025-30035, and possibly fixes from the August 2025 batch.

2. Map what can reach the server

On the CLININET application server, list every listening socket and the process and account behind it:

# Listening TCP and UDP sockets with owning process (run as root)
ss -tulpn

# Which account each relevant process runs as
ps -eo user,pid,ppid,cmd --sort=user | grep -Ei 'java|rsync|hl7|cgm-updater|perl' | grep -v grep

Write down the ports used by the Java admin API, the HL7 listeners, rsyncd and cgm-updater. Ask CGM to confirm which ports are expected, so you are not guessing.

From a normal user workstation VLAN, check which of those ports answer. Run this only against your own systems and with permission:

# Replace HIS_IP and the port list with the values you recorded
nmap -Pn -sT -p 873,PORT_ADMIN_API,PORT_UPDATER,PORT_HL7 HIS_IP

Every port that answers from a user VLAN is exposure that CERT Polska's "adjacent network" wording covers.

3. Restrict the network paths, especially for the six open CVEs

Put the CLININET application server in its own segment with a default deny policy, then allow only what is needed:

Because rsyncd in this case trusts source IP only, IP allow lists on the server are exactly the control that CVE-2025-30052 bypasses. The useful control is upstream: anti spoofing at the switch and router (for example unicast reverse path forwarding, DHCP snooping with IP source guard, and dynamic ARP inspection, where your hardware supports them), so that a host on a user VLAN cannot claim an allowed address.

On the server itself, review the rsync daemon configuration:

grep -nE '^\s*(\[|hosts allow|hosts deny|auth users|secrets file|read only|uid|gid)' /etc/rsyncd.conf

The rsyncd.conf manual describes auth users and secrets file as the options that add a username and password challenge on top of host checks, and read only as the default for modules. Whether CLININET still works with those enabled is a question for CGM; do not change them on production without the vendor's agreement. Also note the manual's point that rsync daemon traffic is not encrypted.

4. Fence off /DocManagment and the admin paths at the proxy

Until you run 2026.MS3, CVE-2025-30043 lets anyone who reaches the web server list and download patient documents. If CLININET sits behind a reverse proxy, limit that path to the client ranges that legitimately use it. An example for nginx, to adapt and test:

# Limit the unauthenticated document path to known clinical client ranges
location ^~ /DocManagment {
    allow 10.10.20.0/24;   # example: clinical workstation range
    deny  all;
    proxy_pass https://clininet_backend;
}

This narrows exposure; it does not add authentication. Blocking the path outright may break document features, so check with CGM which clients call it.

5. Fix local permissions and rotate secrets

Check who can read SysIO.pl and what uhcapache can modify:

# Locate SysIO.pl and show its mode and owner
find / -xdev -name 'SysIO.pl' -exec stat -c '%A %U:%G %n' {} \; 2>/dev/null

# Files owned by uhcapache (review anything a root process executes or reads)
find / -xdev -user uhcapache -type f -printf '%M %u:%g %p\n' 2>/dev/null | head -200

# For each script a root HL7 process runs, confirm uhcapache cannot write it
sudo -u uhcapache test -w /path/to/hl7/script && echo "WRITABLE by uhcapache"

If SysIO.pl is readable by every local account, it should be readable only by the account that needs it; CVE-2025-30051 is fixed in 2026.MS3, and CGM should tell you the correct owner and mode. After the permissions are fixed, assume the credentials it held were readable and rotate them: the production database account, and the RabbitMQ user. For RabbitMQ:

rabbitmqctl list_users
rabbitmqctl list_connections user peer_host
rabbitmqctl change_password CLININET_RABBIT_USER 'NEW_STRONG_SECRET'

Then update the configuration file the way CGM documents. Do the same with your database's own tools.

For CVE-2025-30054, the fix is not shipped, so the compensating step is to make root run HL7 scripts and their configuration owned by root and not writable by uhcapache, with CGM's agreement. Treat any finding from the test -w check above as urgent.

6. Reset passwords after the hashing fix

CVE-2025-30049 means stored passwords were unsalted MD5 before 2026.MS1 or 2026.MS3. Ask CGM whether the upgrade rehashes existing passwords at next login or leaves old hashes in place. Either way, force a reset for privileged accounts first, then all users, and make sure nobody reuses their CLININET password elsewhere, especially for the domain account.

7. Look for signs of misuse in logs you already have

No indicators exist, but you can look for traffic that should not be there. Adjust paths to where your web server writes logs:

# Which client IPs requested the document path, most frequent first
grep -h '/DocManagment' /var/log/httpd/*access* /var/log/apache2/*access* 2>/dev/null \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -50

# Requests to RunCGI from unexpected clients
grep -h 'RunCGI' /var/log/httpd/*access* /var/log/apache2/*access* 2>/dev/null \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -50

Compare the client addresses against the ranges that should use those paths. An unknown workstation hitting /DocManagment repeatedly is worth an investigation, not a conclusion.

For the Java admin API, OWASP's deserialization guidance lists three markers of Java serialized data in captured traffic: the bytes AC ED 00 05 in hex, the string rO0 in Base64, and the content type application/x-java-serialized-object. Legitimate admin traffic will contain these, so the signal is the source, not the content. With a packet capture taken at the server's segment:

# Hosts sending Java serialized HTTP bodies to the CLININET server
tshark -r his_segment.pcap -Y 'ip.dst==HIS_IP && tcp contains ac:ed:00:05' \
  -T fields -e ip.src | sort | uniq -c | sort -rn

Any source that is not a known admin workstation deserves a closer look.

8. Ask CGM the right questions, in writing

• Which releases fix each of the 11 CVEs, and what are the target dates for CVE-2025-30045, 30046, 30052, 30053, 30054 and 58403?
• What ports and hosts does each CLININET service need, so we can set a default deny policy without breaking anything?
• Does 2026.MS3 rehash existing passwords?
• What are the correct owner and mode for SysIO.pl and the HL7 scripts?
• Is there a supported way to disable cgm-updater or restrict it to a single update source?
• Can the HL7 processes run as a non root account in a future release?
• Does the fixed admin API in 2026.MS3 stop using Java serialization, or does it apply a deserialization filter of the kind JEP 290 introduced (configured through jdk.serialFilter)?
• Will CGM provide a software bill of materials for CLININET releases?

What changed since first reports

The disclosure is one day old at the time of writing, and the record has been stable. As of 24 October:

• The CERT Polska advisory has not been updated since publication.
• NVD lists all 11 records as "Deferred". The only scores are CERT-PL's CVSS 4.0 scores.
• The four GitHub advisories remain marked unreviewed, with no package mapping.
• None of the 11 CVEs is in the CISA KEV catalog (catalog version 2026.10.23).
• We found no CGM security bulletin, no public proof of concept and no report of exploitation.
• Some early summaries said no CVSS scores were available, because the advisory page does not show them. CERT-PL did publish CVSS 4.0 scores, in the CVE records.

Open questions

• Fix dates for six CVEs. CERT Polska gives none. Until CGM does, hospitals on 2026.MS3 rely on compensating controls for two root code execution paths (CVE-2025-30046 and 30045), a root privilege escalation (30054), an rsync write path (30052), an unauthenticated listener (30053) and a cross site scripting flaw (58403).
• The CVE-2025-58403 version range. The advisory and the CVE record disagree (2026.MS3 against 2025.MS3).
• Install base. No public figure. CGM's page speaks of the largest healthcare units in Poland but gives no count.
• What cgm-updater can do. The advisory says only that it listens without authentication.
• Why coordination took more than 19 months from ID reservation. Not explained publicly, and not ours to guess.
• Whether earlier batch fixes hold. CVE-2025-30051 and the earlier CVE-2025-30063 both concern a configuration file with database credentials readable by local users. Hospitals should check the current state rather than assume the earlier fix covered it.

What would have helped

None of this is about blame. CGM fixed five issues before publication and fixed many more in earlier batches, and the coordination process is what got these details to hospitals at all. The lessons below are for any organisation that runs a vendor system holding sensitive data on a shared internal network.

Practices any team can use

1. Treat the internal network as hostile for crown jewel systems. A hospital information system should sit in its own segment with a default deny policy and an allow list per service. With that in place, the "adjacent network" flaws in this batch shrink from "any workstation" to "a handful of named hosts".
2. Know which release of every clinical system you run. These CVEs carry no package name, so no dependency scanner will find them for you. A simple register of vendor systems, release identifiers and upgrade dates, reviewed monthly, is what turns a CERT Polska advisory into a same day answer.
3. Subscribe to the right feeds. CERT Polska publishes advisories at cert.pl, and CVE records for vendor products appear on CVE.org and NVD. Watch for your vendors' names, not just CVE severity.
4. Write security terms into vendor contracts. Fix timelines by severity, notification when a CVE is reserved or a researcher reports a flaw, a supported list of required ports and accounts, an SBOM per release, and a commitment not to run network facing processes as root. Our post on responding when a hospital contract asks for a patch timeline covers the same conversation from the supplier side.
5. Make vendor upgrades routine. Hospitals often delay HIS upgrades because they are disruptive. A tested upgrade path and a staging environment make it possible to move to a fixed milestone release in weeks rather than quarters.
6. Never deserialize untrusted Java data without a filter. For Java services you build yourself, JEP 290 added serialization filters to the JDK, set globally with the jdk.serialFilter property, that accept only the classes you list and cap depth, references, array sizes and stream size. Better still, avoid Java native serialization on network APIs. Our post on deserializing untrusted data safely walks through the controls.
7. Least privilege on the server. Network facing processes running as root, world readable credential files and service scripts writable by a web account are each findable with the commands above. A yearly configuration review of the HIS server, with the vendor present, catches them.
8. Rotate secrets after any exposure, real or possible. A credential that sat in a world readable file should be rotated even if nobody read it.
9. Anti spoofing at the network edge of the segment. Several protocols in hospitals still authenticate by IP. Switch features that stop a host from claiming another host's address make those checks mean something.
10. Plan for regulation. NIS2 lists healthcare providers among the sectors it covers, requires measures that explicitly include supply chain security and "vulnerability handling and disclosure", and sets reporting deadlines of an early warning within 24 hours and an incident notification within 72 hours of becoming aware of a significant incident. Poland implements NIS2 through its national cybersecurity system act (KSC). A disclosure like this one is not a reportable incident by itself, but it is exactly the kind of supplier risk the directive expects you to manage. Our post on Austria's NIS2 law coming into force covers how another member state approached the same duties.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues its findings as SGZ advisories before they reach public CVE databases. It covers seven open source package ecosystems. CGM CLININET is a proprietary hospital system, not an open source package, so it is outside what Zero-Day Discovery covers. The researcher who found them is credited above.

Gold Open Source at gold.safeguard.sh is a free, no login source of CVE intelligence for open source components, with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a GitHub Action that gates CI. Gold Registry at registry.safeguard.sh provides hardened, signed open source components and container images. CLININET is proprietary software, so the fix for these 11 CVEs has to come from CGM. Where Gold is relevant is the open source code hospitals and their suppliers build around the HIS: interface engines, integration services, Java libraries and container images. For those, the right habit is the one this incident illustrates for the vendor product: know your versions, pull fixed and signed components from a curated source, and rebuild fast.

Where Safeguard fits

Being straightforward about it: Safeguard cannot patch CLININET, cannot see your hospital network, and would not have prevented or detected anything described in this advisory. It helps with the parts of the problem that live in software you or your suppliers build.

• Inventory of your own integration code. Hospitals and integrators often run their own HL7 bridges, document converters and reporting services next to the HIS. safeguard scan --dir . on a repository, safeguard scan --image NAME on a container image, or safeguard scan --sbom FILE on a supplier's SBOM produces a full dependency inventory with vulnerability matches, and the platform shows which projects contain a given component and version.
• Vendor SBOMs. If CGM or another supplier gives you an SBOM for a release, scanning it with --sbom tells you which open source components that release carries and which known vulnerabilities apply to them. It will not tell you about flaws in the vendor's own code, like these 11.
• Deserialization risk in code you own. Java deserialization flaws often hinge on which libraries are on the classpath. Reachability analysis ranks whether the vulnerable code paths in your dependencies are actually called, so the libraries that matter get upgraded first, and autonomous remediation can open the upgrade pull request (it ships switched off, so your team chooses what runs on its own).
• Vendor and risk tracking. The compliance suite includes Vendors and Risks views, so a supplier like the HIS vendor, its open CVEs and the compensating controls you applied can be recorded as a tracked risk with evidence, which is the record a NIS2 or KSC audit will ask for.
• Policies and gates. For code you ship, gates can block a build that introduces a known vulnerable component.

To try the CLI on your own code, download Safeguard from safeguard.sh/download and follow the CLI documentation.

For the general method of answering "where do we run this component?" in an incident, see SBOM incident response: finding affected products fast. For how this disclosure fits with the rest of the month, see October 2026 security incidents and what would have helped.

Common mistakes and troubleshooting

• Assuming 2026.MS3 closes everything. It closes five of 11. The six open issues include two root code execution paths and a root privilege escalation.
• Reading "adjacent network" as low risk. In a large hospital network almost everything is adjacent unless you have segmented it.
• Relying on IP allow lists for rsync. CVE-2025-30052 is precisely an IP check being bypassed by spoofing. Fix spoofing at the switch, or add authentication with vendor approval.
• Changing permissions without telling the vendor. Tightening SysIO.pl or HL7 scripts can break services if the wrong account is left without access. Agree the target owner and mode with CGM and test first.
• Fixing the file but not rotating the secret. A credential that was world readable stays exposed until it is changed.
• Skipping password resets after the hashing fix. A new hashing scheme does not protect hashes already stored under the old one.
• Waiting for a dependency scanner to flag it. These CVEs have no package mapping. Asset inventory has to come from you.
• Blocking /DocManagment outright without checking. You may break document workflows. Restrict by client range first, then remove access once 2026.MS3 is in.
• Treating the absence of IOCs as an all clear. There are no IOCs because no attack has been reported. Your own logs are the only evidence you will have.
• Forgetting test, training and DR copies. Non production CLININET environments often hold copies of real patient data and lag behind on upgrades.

FAQ

Was patient data stolen in the CGM CLININET disclosure?

No breach has been reported. CERT Polska's advisory describes vulnerabilities, including one that would allow unauthenticated download of patient documents from the adjacent network, but it does not report any exploitation, and nobody has alleged that data was taken.

Which CLININET version fixes these vulnerabilities?

2026.MS3 fixes CVE-2025-30043, 30047, 30050 and 30051. CVE-2025-30049 is fixed in 2026.MS1 and 2026.MS3. The other six, CVE-2025-30045, 30046, 30052, 30053, 30054 and 58403, are confirmed to affect versions up to 2026.MS3 and have no stated fix.

What is CVE-2025-30047?

A Java deserialization flaw in the HTTP API used by CLININET's administrative module. According to CERT Polska, an attacker on the same local network can send a crafted serialized object and get code execution as root. CERT-PL scores it 9.4 under CVSS 4.0. It is fixed in 2026.MS3.

Are these vulnerabilities being exploited?

Not as far as public sources show. CERT Polska does not mention exploitation, none of the 11 CVEs was in the CISA KEV catalog as of 23 October 2026, and we found no public proof of concept.

Can these flaws be exploited from the internet?

Most of the high severity ones are scored with the adjacent or local network vector, which means an attacker needs a foothold on the hospital network or the ability to reach the server from it. The exceptions in the vectors are CVE-2025-30049, 30052, 30053 and 58403, which use the network vector. If your CLININET server or any of its services are reachable from the internet, treat that as urgent.

What should we do about the six CVEs without a fix?

Restrict network access to the HL7 listeners, rsyncd and cgm-updater to the specific hosts that need them, stop IP spoofing on the hospital network, make sure root run HL7 scripts are not writable by uhcapache, limit privileged accounts that can use document expressions, and ask CGM in writing for fix dates.

How many hospitals use CGM CLININET?

There is no public figure in the advisory or the CVE records. CGM says CLININET is deployed in some of the largest healthcare units in Poland, for hospitals from 50 to 1,500 beds, but gives no count.

Is this the first time CLININET vulnerabilities have been disclosed?

No. CERT Polska published earlier CLININET batches on 27 August 2025 and 2 March 2026, from the same research. Those included SQL injection, session exposure, an authentication bypass and code execution flaws, fixed in releases from 2024.MS4, 2025.MS1 and 2025.MS4.

Does NIS2 require us to report this?

A vulnerability disclosure is not a significant incident on its own, so it is not something you report under NIS2's 24 hour and 72 hour deadlines. If you find evidence of misuse on your CLININET server, that changes, and Poland's KSC rules on incident reporting apply. NIS2 does expect healthcare providers to manage supplier risk and vulnerability handling, which is what this post's checklist covers.

Could Safeguard have found or fixed these vulnerabilities?

No. CLININET is a proprietary vendor product outside the open source ecosystems Safeguard's Zero-Day Discovery covers, and only CGM can ship the fixes. Safeguard helps with inventory, vulnerability matching and fix pull requests for the open source code and container images you and your suppliers build around systems like this.

Fix it without waiting for upstream

For CLININET itself the honest limit at the end of this section applies in full: the fix has to come from CGM. The same gaps, though, exist in the open source code that hospitals and their integrators build around the HIS, and there you do not have to wait.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows CLININET, and none of them could patch it. They show the workflow for the open source code around it: the integration services, document converters and container images that hospital IT teams and their suppliers build and run next to the HIS.

The first demo is a real CLI session that fixes a lodash CVE in a sample repository: the assistant reads the finding and the advisory, asks before each command, edits package.json, runs the install and the tests with your approval, and pushes nothing. For a hospital integration team, the same flow applies to an HL7 bridge or a Java reporting service: scan the repository, ask the assistant to move a vulnerable library to its fixed version, and approve each step.

Click through it at your own pace, or open it full screen.

The second demo is a real desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then approve or deny each command and file edit, and it ends with the upgrade done and tests passing. For a team that keeps its integration code on a locked down build machine inside the hospital network, this is how you would direct that work without giving an assistant free rein over the machine.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: you send work to a computer running the CLI and approve each command on the phone with Allow once, Allow for turn or Deny. When an advisory like this one lands out of hours, the on call engineer can start the inventory scan of the integration repositories and approve each command from the phone, with nothing running unattended.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• CERT Polska: Vulnerabilities in CGM CLININET software (23 October 2026)
• CERT Polska: CLININET advisory of 27 August 2025 (CVE-2025-2313 and others)
• CERT Polska: CLININET and NETRAAD advisory of 2 March 2026 (CVE-2025-10350 and others)
• CERT Polska: Coordinated vulnerability disclosure policy
• NVD: CVE-2025-30047
• NVD: CVE-2025-30043
• NVD: CVE-2025-30046
• NVD: CVE-2025-30050
• NVD: CVE-2025-30054
• NVD: CVE-2025-58403
• CVE.org: CVE-2025-30047 record
• CVE.org: CVE-2025-58403 record
• GitHub Advisory Database: GHSA-hjw9-7f25-8h43 (CVE-2025-30047)
• GitHub Advisory Database: GHSA-cwv2-4c7h-2v4g (CVE-2025-30050)
• GitHub Advisory Database: GHSA-q872-9p8m-4vww (CVE-2025-30046)
• GitHub Advisory Database: GHSA-xr4f-2f7f-gcx6 (CVE-2025-30054)
• CGM: CGM CLININET product page (Polish)
• CISA: Known Exploited Vulnerabilities catalog
• OWASP: Deserialization Cheat Sheet
• OpenJDK: JEP 290, Filter Incoming Serialization Data
• rsyncd.conf manual page
• EUR-Lex: Directive (EU) 2022/2555 (NIS2)

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.