Causal model
What has to happen for this consequence to hold?
2 candidate paths · explicit source, inference, and assumption boundaries.
Authority · Co-dominant path
Firmware trust root
A network update that does not verify signatures can replace the station's trusted firmware and persist beneath application-level controls.
Network update accepts unsigned firmware
The cited station update path is network-reachable without authentication and does not require a valid firmware signature.
EvidenceNVD
Protocol knowledge is the main upload barrier
Once an attacker can speak the update protocol, no cryptographic signature check remains to reject the uploaded image, making the network operation straightforward.
EvidenceNVD
Uploaded code becomes station firmware
An accepted image executes below ordinary application controls and replaces the code the station treats as trusted firmware.
EvidenceNo direct citation — inspect the declared inference or assumption.
Firmware trust is no longer defensible
The station can no longer distinguish vendor-authorized firmware from attacker code, giving the replacement image persistent control over station behavior. No field exploitation or patient harm is asserted.
EvidenceNo direct citation — inspect the declared inference or assumption.
Trust must be re-established across the deployment
Recovery is modeled as verifying or reprovisioning affected stations with a signature-enforcing trust root, not merely restarting the application.
EvidenceNo direct citation — inspect the declared inference or assumption.
Decision rationale
Why this band?
The compact score is separated into the facts and judgments that produced it.
Reach and effort
- Reachability
RE 4 - Remote station access
NVD classifies the path as network-accessible with no privileges required, so an attacker does not need local contact with a station.
- Execution complexity
EC 4 - No signature barrier
The update path does not require a valid vendor signature; after the protocol is understood, no cryptographic check blocks the upload.
- Exposure
EX 4 - Reach and effort are both unrestricted
Exposure remains at the shared upper bound because remote reachability and low execution effort support the same conclusion.
Consequence
- Physical / safety
PH 3 - Transport disruption can narrow clinical safety margins
Stations move blood, medication, and specimens; unsafe routing or stoppage is treated as safety-significant, although this record documents no patient harm.
- Data / perception
DP 3 - Firmware and device state are exposed
Replacement firmware can observe or alter proprietary station state, but the path does not depend on falsified perception directly driving a safety decision.
- Authority
AT 4 - Firmware becomes the highest device authority
Code installed as trusted firmware can persist beneath application permissions and govern the station's core behavior.
Scale and recovery
- Chainability
CH 4 - One upload crosses multiple control layers
The path moves from network input through the update service into persistent firmware and then into physical station operation.
- Reuse scale
SR 4 - The update pattern is reusable across stations
The model assumes deployed stations share the same unsigned update mechanism, allowing the technique to be repeated without a new exploit design.
- Execution scale
SX 4 - Remote installation can extend across a deployment
Each exposed station accepts the same network update operation, so repeated uploads do not require opening or physically visiting the devices.
- Recovery burden
OR 4 - Recovery must restore firmware provenance
Assurance returns only after affected stations are verified or reprovisioned behind a signature-enforcing root of trust.
Confidence and status
- Evidence strength
EV 2 - Advisory-backed, not independently reproduced
The assessment uses the public NVD advisory and reported vector; this registry has not reproduced the firmware upload.
- Liveness
LS Partially mitigated - Partial mitigation leaves deployment uncertainty
The record treats the issue as partially mitigated because residual station state and rollout coverage are not independently verified here.
Decision trail
How the final band follows
- Base bandEMERGENCY
- No adjustment
The EMERGENCY base band remains final because no separate cap or systemic uplift applies. Code installed as trusted firmware can persist beneath application permissions and govern the station's core behavior.
- Final candidate bandEMERGENCY
Technical vector
CPATH:1.0-candidate/TT:FIRMWARE_TRUST_ROOT/RE:4/EC:4/EX:4/PH:3/DP:3/AT:4/CH:4/SR:4/SX:4/OR:4/EV:2/LS:PARTIALLY_MITIGATEDRead the scoring method →Systemic · Co-dominant path
Fleet control plane
The shared unsigned-update path can be repeated across networked stations, turning a device weakness into deployment-wide operational authority.
Each station exposes the same unsigned update path
The cited update mechanism is reachable over the network without authentication and accepts firmware that lacks a valid signature.
EvidenceNVD
One protocol can be reused across the PTS
If deployed stations share the reported update service, the same straightforward upload can be directed at additional stations without physical access.
EvidenceNo direct citation — inspect the declared inference or assumption.
Firmware governs routing and station behavior
Replaced firmware can exercise command authority over station availability, tube routing, and local behavior across the affected deployment.
EvidenceNo direct citation — inspect the declared inference or assumption.
Repetition becomes a fleet control problem
Coordinated compromise of multiple stations could disrupt transport operations beyond a single device. This is a modeled deployment consequence, not evidence of exploitation in the field.
EvidenceNo direct citation — inspect the declared inference or assumption.
Every affected station must return to trusted firmware
Recovery is modeled as coordinated verification or reprovisioning across the deployment because leaving one station on the unsigned path preserves the control gap.
EvidenceNo direct citation — inspect the declared inference or assumption.
Decision rationale
Why this band?
The compact score is separated into the facts and judgments that produced it.
Reach and effort
- Reachability
RE 4 - Network reach does not stop at one station
NVD records a network vector with no privileges required, and the fleet model applies that access condition to each exposed station.
- Execution complexity
EC 4 - The same low-effort upload can be repeated
Missing signature enforcement removes the per-station cryptographic barrier once the update protocol is known.
- Exposure
EX 4 - Fleet attempts retain maximum exposure
Repetition does not reduce the underlying network reach or add a new execution hurdle, so exposure stays bounded by two equally permissive inputs.
Consequence
- Physical / safety
PH 2 - Multi-station disruption can affect care logistics
Coordinated routing or availability failures could delay blood, medicine, or specimen movement; no severe individual harm is claimed as observed.
- Data / perception
DP 2 - Operational logistics state is in scope
Fleet firmware can expose or alter routing and station state, while this path does not rely on highly sensitive perception data.
- Authority
AT 3 - Deployment command authority is reachable
Repeated firmware replacement can govern service behavior across the PTS, a broader operational authority than control of one application process.
Scale and recovery
- Chainability
CH 4 - Device compromise bridges into deployment operations
The shared update mechanism links network access, persistent firmware control, and coordinated transport behavior across system boundaries.
- Reuse scale
SR 4 - Shared station design enables reuse
The fleet conclusion assumes the same update protocol and missing signature check are present across deployed stations.
- Execution scale
SX 4 - Execution can be coordinated remotely
Multiple stations can be targeted over the network without visiting each device, making deployment-scale execution plausible under the stated assumption.
- Recovery burden
OR 4 - Remediation is deployment-wide
Recovery must identify, verify, and reprovision every exposed station; incomplete coverage leaves an unsigned firmware entry point behind.
Confidence and status
- Evidence strength
EV 2 - Public report supports the weakness, not fleet execution
NVD supports the network unsigned-update condition; this registry has not reproduced coordinated compromise across a deployment.
- Liveness
LS Partially mitigated - Partial mitigation does not prove fleet closure
The model records partial mitigation while rollout coverage and residual exposed stations remain unverified in this assessment.
Decision trail
How the final band follows
- Base bandCRITICAL
- Systemic uplift
The CRITICAL base band rises to EMERGENCY because the same unsigned update path can be repeated across networked stations and recovery requires coordinated deployment-wide verification or reprovisioning.
- Final candidate bandEMERGENCY
Technical vector
CPATH:1.0-candidate/TT:FLEET_CONTROL_PLANE/RE:4/EC:4/EX:4/PH:2/DP:2/AT:3/CH:4/SR:4/SX:4/OR:4/EV:2/LS:PARTIALLY_MITIGATEDRead the scoring method →Triage implication
Verify the authority transition before acting on the band.
Triage beyond the first device: verify whether the reusable condition, propagation mechanism, and recovery dependency actually exist across the deployment.
Evidence ledger
Public sources used by this record.
Every named source includes a public link. Path review remains separate from citation coverage.
- advisoryNVD
NVD
Published baseline
Keep exploit severity and consequence reasoning distinct.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HCVE recordsCVE-2021-37160
Original scorer notes
The source narrative behind the structured explanation.
Retained for provenance and historical review, not as the recommended way to understand the assessment.
Read the original scorer notes
Assessment
CFSE Consequence Paths assesses Swisslog Translogic PTS unsigned firmware update at EMERGENCY — the worst of 2 risk paths (authority). The dominant consequence is loss of the device’s firmware trust root.
Vulnerability
Swisslog Translogic PTS unsigned firmware update. Reported attack vector: Network.
CFSE Consequence Paths analysis
The vulnerability is decomposed into one risk path per terminal consequence. Each path is scored on its exposure (reachability × execution complexity) and the authority, perception, and physical/safety it reaches, together with its scale of reuse, scale of execution, and recoverability.
FIRMWARE_TRUST_ROOT → EMERGENCY
CPATH:1.0-candidate/TT:FIRMWARE_TRUST_ROOT/RE:4/EC:4/EX:4/PH:3/DP:3/AT:4/CH:4/SR:4/SX:4/OR:4/EV:2/LS:PARTIALLY_MITIGATED
Exposure EX=4 (reachability and complexity-bound) · bands PH=CRITICAL · DP=CRITICAL · AT=EMERGENCY → base EMERGENCY · uplift fleet-reachable authority, recall-class recovery → assessed EMERGENCY.
Nexus Control Panel accepts unauthenticated/unsigned firmware over network (RE4 network-reachable, AV:N/PR:N). No signature check means once the protocol is known, the upload is a trivial network operation (EC4). Installing attacker firmware is a root-of-trust failure giving full persistent station control (AT4). Persistent malicious firmware on stations that move blood/meds/specimens reduces safety margins and enables unsafe actuation of physical transport (PH3). Firmware/proprietary device state is the data class (DP3, perception does not directly drive safety decisions so perception_feeds_action=false). Crosses network->device->firmware->physical boundaries and is a reusable persistence bridge (CH4, boundary_crossing). Same firmware path across all deployed stations (SR4). Recovery required a root-of-trust retrofit that could not ship in the main release, i.e. fleet-wide reprovision (OR4, recovery_needs_fleet_action=true). Report-backed, not reproduced (EV2). Not known exploited in the wild (active_exploitation=false).
FLEET_CONTROL_PLANE → EMERGENCY
CPATH:1.0-candidate/TT:FLEET_CONTROL_PLANE/RE:4/EC:4/EX:4/PH:3/DP:2/AT:3/CH:4/SR:4/SX:4/OR:4/EV:2/LS:PARTIALLY_MITIGATED
Exposure EX=4 (reachability and complexity-bound) · bands PH=CRITICAL · DP=HIGH · AT=CRITICAL → base CRITICAL · uplift fleet-reachable authority, recall-class recovery → assessed EMERGENCY.
The same unsigned-firmware weakness is network-reachable across every station of the PTS (RE4, SX4 fleet-scale remote without per-device physical access). Trivial single-protocol push (EC4). Because all stations share the identical firmware path and lack signature verification, an attacker can install firmware fleet-wide and exercise the deployment’s control plane / command authority over tube routing and station behavior (AT3 service/command authority across the network rather than a unique signing-root act here). The fleet-scale manipulation of station availability and tube routing is primarily an operational/availability disruption with no demonstrated severe individual harm at the control-plane layer (PH2). Logistics/operational state data (DP2). Cross-domain reusable authority transfer across the PTS network (CH4, boundary_crossing). Shared firmware/credential path (SR4). Remediation needs fleet-wide root-of-trust retrofit (OR4, recovery_needs_fleet_action=true). Report-backed evidence (EV2), partially mitigated, not exploited in wild.
Published baseline
- v3.1 9.8 CRITICAL —
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H— NVD
The published baseline above is retained for source review. The registry records the reachable consequence path, including deployment-specific cyber-physical consequence, physical/safety impact, scale, and recovery burden.
Sources
CFSE Consequence Paths Registry 1.0-candidate, CPATH-2026-0009 (“Swisslog Translogic PTS unsigned firmware update”), paths.cfse.ai/CPATH-2026-0009 (published 2026-06-03).