Anatomy of a CVSS 10.0

The chatbot arrived with a reassuring label. It had been presented as suitable for healthcare, and the visible interface looked finished. I did not start with the label. I opened the application the same way any visitor could and checked what the browser had actually received.

That distinction mattered.

The finding was already in the browser

The frontend contained credentials that should never have crossed the server boundary. They were not hidden behind an authenticated admin area or available only after a complicated exploit chain. A visitor could retrieve them from the code delivered to an ordinary browser.

Those credentials opened a path into patient communication. Someone outside the organization could have sent messages in its name. No account, prior access, or interaction from a legitimate user was required.

ordinary browser
  -> delivered frontend
      -> credentials [redacted]
          -> communication path

The assessment recorded the issue as CVSS 10.0. The score described a remotely reachable problem with a low barrier to entry and consequences beyond the exposed frontend itself. CVSS communicates technical severity; FIRST explicitly warns against using it alone as an organizational risk score.¹

I am deliberately leaving out credential names, endpoints, request shapes, and the organization involved. They add nothing to the method and would turn a useful writeup into a reproduction guide.

A compliance claim is not a control

The compliance language described what the product was supposed to protect. It did not show whether the implementation enforced those boundaries.

So the review continued past the first finding. I checked the shipped frontend, its dependencies, the services it contacted, the data exposed in configuration, and the paths a user could reach without authentication. The resulting report ordered the findings by risk and gave the vendor concrete remediation work rather than a pile of scanner output.

This is the part of security work I care about: inspect the system that exists, separate verified impact from suspicion, and leave enough detail for the people responsible to fix it.

Reporting was only half the work

The critical issue was fixed after the report. I then tested the deployed version again instead of accepting “resolved” as a final state.

That follow-up became a recurring monthly review. Later checks found different classes of problems: outdated dependencies, exposed monitoring configuration, statements about data handling that did not match the implementation, and a crisis flow that needed work. A later production retest confirmed that emergency options were shown before the chatbot offered an agent.

The work settled into a repeatable sequence:

1. inspect the delivered system;
2. describe the risk without inflating it;
3. give the vendor an actionable path;
4. verify the deployed fix independently;
5. keep checking the parts that continue to change.

What changed in my own reviews

I now treat compliance labels as a pointer, never as evidence. They tell me what the implementation is supposed to protect. The code, requests, access boundaries, and follow-up tests show whether it does.

I also keep the report separate from the retest. The first document records what was true when I found it. The retest records what changed. That leaves an honest history instead of quietly rewriting the original finding after remediation.

The exposed path was closed, the fix was checked, and the review became a recurring process as the product evolved. That result matters more than the score attached to the original finding.

1. FIRST: CVSS v3.1 User Guide, on severity, environmental context, and why CVSS should not be used alone to assess risk. Accessed 2026-08-19. ↩