187 Criticals and One Real Problem

Verify capability, not the banner. Version strings are exactly what a backport invalidates.

Method:

• Negotiate SMB1 directly against one representative server and record whether the dialect is accepted (for example an SMB protocol-dialect probe, or a controlled smbclient connection attempt that prints the negotiated dialect).
• Pull the actual build number and installed update list, and compare against the vendor's advisory for the backported fix rather than the upstream patch level.
• Cross-check the registry or SMB server configuration for SMB1 enablement.
• Sample a second server to rule out configuration drift.

Then record the verdict with evidence: "SMB1 dialect refused; build contains vendor backport per advisory X; scanner matched banner only." Downgrade to informational with the verification method in the report.

If the dialect is accepted, the finding stands regardless of patch level, and you escalate the true reachable exposure. Either way the client gets a defensible conclusion rather than a plugin ID.

The plaintext service-account credential outranks the 8.8 patch by a wide margin, despite the numeric score.

Reasoning chain for the credential: it exists, it is readable by any authenticated user, it is current (backup software), and it is local administrator on 380 hosts - roughly two-thirds of the estate. That is a single hop from any low-privilege foothold to near-estate-wide administrative control, with no exploit development and no user interaction. Blast radius and exploitability are both maximal; the CVSS-equivalent is effectively a 9+ because the only prerequisite is a domain account, which every employee has.

For the 8.8: the CVSS vector demands prior local administrator rights, so its environmental score drops sharply against a threat model where the attacker starts with a standard user. It matters for defense-in-depth and for privilege-escalation chains, but it does not create an entry point.

Present both with an attack narrative - "an attacker who phishes one help-desk account reads the share and owns 380 hosts" - so the board sees risk rather than a sorted list.

Do not delete them, and do not simply comply to keep the relationship smooth. Both options misrepresent the work and expose your firm.

Instead, restructure the deliverable:

• Reclassify each disputed item as "validated false positive," "validation inconclusive," or "confirmed," and add the evidence and method beside each one.
• Move validated false positives to an appendix that states the count, the cause (banner matching against backported builds), and what was done to verify, so the volume is visible but not alarming.
• Keep the raw scanner output as an artefact of record.

Explain the rationale in risk terms: a board pack that silently drops 187 items invites the question of what else was dropped, and if an incident follows, the report's credibility - and the tester's - is the casualty. Offer the appendix as the compromise.

If the director insists on deletion, escalate to your engagement manager; the report must remain an accurate record of what was tested and validated.