Nine CVSS 9.8 Findings in an Isolated VLAN

CVSS scores the severity of a defect in the abstract; the report needs organisational risk, which is likelihood in this environment multiplied by business impact.

• Laboratory VLAN OpenSSL (9.8). There is no reachable path from an untrusted network, no lateral route out of the VLAN, and no data of the kind the threat model cares about. Compensating controls (segmentation) remove most of the likelihood. Exploiting it also forces a clinical-safety review that could disrupt patient services for a finding the client cannot act on faster anyway. Do not exploit; report with contextual justification and a note that the score reflects the flaw, not the exposure.
• Portal XSS (7.5). Internet-facing, so reachable by the threat model's threat actors, but the application owner mitigates via WAF blocking and the impact requires a victim. Validate cheaply - one or two bounded payload variants to test whether the WAF can be bypassed - and stop before the ticket volume becomes noise. This is worth limited time precisely because the WAF is an unverified assumption.
• Interface engine deserialization (8.1). It matches the third priority scenario, it is unauthenticated, and the service account behind it is broad. This is where the remaining hours go, because a confirmed compromise here sits directly on a threat-model path and changes a "should patch" ticket into a board-level risk.

State the reasoning in the report: the lab finding is documented but not exploited, and the client is told why.

Treat "exploit available, not verified" as unproven. The verification must be non-destructive and must generate evidence that survives a retest.

1. Fingerprint precisely: library name and version, the listener, whether an authentication barrier exists. If the vulnerable version is confirmed, the finding is credible even without a payload.
2. Send one benign callback payload - an out-of-band DNS or HTTP hit to a listener you control - rather than a reverse shell or a file write. A single callback proves code execution with no side effects and no interaction with patient data.
3. If the callback is blocked, try a single timing probe (one deliberate delay in the response) and record the delta once, not repeatedly.
4. Capture the request, the response, the callback log with timestamps, and the exact command or payload used.
5. Watch the clock against the day-three call. If verification is not achievable, issue the finding as "potential, unconfirmed" with explicit language, and make the remediation advice independent of confirmation - patch or enforce a deserialization allowlist - so the patch team is not blocked waiting for your proof.

Never claim exploitability you did not observe; a retest six weeks later that contradicts the report damages the whole document.

A compensating control reduces likelihood; it does not delete the finding, and it must be shown to work before it is credited.

• Segmentation genuinely reduces the laboratory OpenSSL risk, and the report should say so in the risk rationale. It does not change the patch obligation, because segmentation drifts - a firewall rule added for a vendor will reopen the path.
• The WAF in blocking mode is an assumption until tested. Your bounded bypass attempts are what convert the assumption into evidence: if one payload variant got through, the control cannot be credited at all; if none did, credit it and note the test date and the ruleset version.
• No compensating control exists on the interface engine, so nothing changes there.

Then handle the disagreement procedurally: publish the scoring method (CVSS base plus the threat-model scenario and exposure modifiers), show the inputs, and let the risk owner make the call. The report is a technical opinion; the client owns the residual risk. If they still disagree, keep your rating and record their rationale in a short note rather than silently downgrading - a tidied-over rating is the thing that gets discovered after an incident. Offer the retest criteria that would justify changing it.