If you disclose vulnerabilities long enough, you will eventually have the same conversation over and over again. The vendor validates the bug, engineering reproduces it, and then the CVSS score starts shrinking.

Network becomes Adjacent because the product is “normally” behind a firewall. Low Attack Complexity becomes High because the proof of concept took a lot of work. A basic account becomes High Privileges because an attacker has to log in. High Availability impact becomes Low because a customer could restore from backup. A supported but disabled feature is treated as though it does not exist.

None of those surrounding facts are necessarily false. The problem is that they are frequently placed in the wrong part of the scoring system—or counted two or three times—until the final number describes the vendor’s preferred deployment story instead of the vulnerability.

I have spent a surprising amount of time writing the same explanations in disclosure threads, so this post has two goals. First, it gives me something durable to point to the next time a score gets negotiated one metric at a time. Second, it gives other researchers a practical framework for handling the same pushback without turning every disagreement into a week-long argument.

The first thing to get straight is that CVSS is not a complete risk assessment. It is a standardized way to describe the technical severity and characteristics of a vulnerability.

The CVSS v3.1 specification divides that description into three groups:

1. Base metrics describe intrinsic characteristics that should remain consistent across time and user environments.
2. Temporal metrics describe things that change over time, such as exploit maturity and the availability of an official fix.
3. Environmental metrics let a consumer account for its own deployment, compensating controls, and the importance of the affected asset.

That separation matters. “Our customers put this behind a firewall” may be useful environmental context. “A patch is already available” belongs in remediation information and may affect a Temporal score. “This is embarrassing,” “we have only three customers on that release,” and “a Critical finding triggers an executive escalation” may all affect business risk, but none of them changes the intrinsic behavior of the vulnerable code.

FIRST is explicit that customer count, potential monetary loss, and public sentiment are outside CVSS. Those may belong in a risk register. They do not belong smuggled into Attack Complexity.

Attack Vector describes how an attacker reaches the vulnerable component. Network means exploitation is possible across one or more network hops. Adjacent is narrower, but it is not limited exclusively to Layer 2; CVSS v3.1 also allows Adjacent for a genuinely secure or limited administrative domain, such as a secure VPN into an administrative zone.

That nuance is important. “Internal” does not automatically mean Network, and it does not automatically mean Adjacent either. The questions are technical:

1. Is the vulnerable service bound to the network stack?

2. Can the attack cross routers or leave the logically adjacent administrative domain?

3. Is the restriction enforced by the vulnerable product, by the protocol, or by a separate deployment control?

4. Is the exploitable configuration reasonable and supported?

5. Can customers operate the feature in a supported configuration where it is reachable from a wider network?

In one disclosure exchange, the first explanation for lowering the score was:

“Adjacent Network because the attacker needs to be in the [internal] network.”

That statement describes a threat model, but it does not finish the CVSS analysis. The v3.1 specification says Network should still be used when an attacker must be on the same intranet if the attack can originate outside a logically adjacent administrative domain. Conversely, a service truly limited to a secure administrative zone may justify Adjacent. The words “internal network” by themselves do not tell us which one applies.

In another disclosure exchange, a product endpoint was described as localhost-only because its configured address contained 127.0.0.1. The implementation told a different story: the service used a wildcard listener, delegated the socket to an operating-system shared-port service, and accepted a demonstrated connection from a separate host. A negative scan from one vendor test system showed that a firewall blocked the port on that system; it did not turn a wildcard network listener into a loopback socket.

This is the distinction researchers should keep returning to:

1. Software behavior: What interface does the component expose and accept?

2. Deployment control: What firewall, ACL, VPN, or segmentation prevents traffic from reaching it here?

CVSS already has a clean way to communicate both. The v3.1 User Guide’s firewall example keeps AV:N in the Base vector and applies MAV:A in the Environmental vector for a component confidently protected on a secure network.

In another exchange, the responding team made a similar argument about a management interface that was disabled by default and could be protected with source-address controls:

“The affected management interface is disabled by default.”

“Attack Vector should be Adjacent (AV:A) rather than Network (AV:N).”

Default state matters to exposure and operational risk, but CVSS v3.1 says to assume the vulnerable component is in a required, reasonable configuration. Enabling a supported management feature is not inherently unreasonable merely because the default is off. Optional ACLs are valuable mitigations, but optional deployment controls should not silently rewrite the Base vector.

There is a legitimate exception: if exploitation requires a configuration that deliberately disables a security feature or directly contradicts documented supported guidance, that may be an unreasonable configuration. The important thing is to prove that exception, not simply repeat “disabled by default.”

Attack Complexity is probably the most routinely misunderstood metric in CVSS v3.1. It does not measure how smart the researcher had to be, how many lines are in the proof of concept, how obscure the protocol is, or whether a custom tool was required.

One program stated the misunderstanding unusually plainly:

“Attack Complexity is high (the description of all attacks is very complex and tooling is involved).”

That is not what the metric measures. AC:H is for conditions beyond the attacker’s control: winning a race, defeating an exploit mitigation, obtaining a target-specific secret, positioning for a man-in-the-middle attack, or satisfying another condition that prevents repeatable exploitation at will. CVSS assumes the attacker already understands the weakness and the target’s general configuration.

If the exploit is deterministic once a request reaches the vulnerable component, AC is usually Low even if discovering the bug took six weeks and the final proof of concept depends on a large custom toolchain.

The same distinction applies to reconnaissance. In another report, the vendor argued that exploitation required non-public record identifiers and therefore justified AC:H. The vulnerable service itself enumerated those identifiers on demand, in-band, without authentication. They were an output of the attack workflow, not an external condition the attacker had to somehow arrange.

A useful test is:

Can the attacker perform the required preparation against the target, at will, 
and then expect repeatable success?

If yes, the workflow may be involved, but that does not necessarily make the attack complex in the CVSS sense.

Also avoid double-counting. If the “complex condition” is simply that the attacker needs a valid account or session, that fact normally belongs in Privileges Required. It should not automatically become PR:L plus AC:H for the same prerequisite.

Scope is not “did the attack reach another machine?” It asks whether exploitation of one vulnerable component affects resources governed by a different security authority. An application, operating system, firmware environment, sandbox, or tenant boundary may each enforce a separate authority.

This is often the hardest v3.1 metric because the researcher can observe behavior but may not know every intended trust relationship inside the product. The vendor may genuinely have better architectural evidence here.

One exchange is a useful example. The researcher initially argued that an unauthenticated request crossing from a web application into unrestricted root command execution changed Scope. The responding team argued that the management plane, privileged services, and system resources belonged to one intended system-level authority. The researcher ultimately conceded Scope while preserving the Network and Low Complexity positions.

That was a reasonable concession. It also produced a revealing design question: if the product’s stated position is that there is intentionally no meaningful security boundary between an unauthenticated web requester and root-controlled system resources, the score may be Scope Unchanged—but the architecture deserves scrutiny of its own.

Do not use Scope as a generic multiplier for “this feels bad.” Identify:

1. The vulnerable component that contains the flaw.
2. The impacted component suffering the direct consequence.
3. The authority that governs each component.
4. The intended path, if any, across that boundary.
5. The access the attacker had before exploitation versus after it.

If those cannot be named, the Scope argument is probably not finished.

Confidentiality, Integrity, and Availability describe the direct outcome of successful exploitation, relative to the attacker’s starting privileges. They do not describe how uncomfortable the outcome is for either party.

• Confidentiality asks what protected information can be disclosed and whether the loss is limited or directly serious.
• Integrity asks what protected data or resources can be modified and how much control the attacker has over the consequence.
• Availability asks whether the impacted component’s service or resources can be partially or fully denied, and whether that denial is sustained or persistent.

“Only some data” can still be High if the subset includes administrator credentials, private keys, or similarly consequential material. Conversely, reading a small, uncontrolled fragment is not automatically High merely because the finding is an information disclosure.

The same care applies to arbitrary file operations. Deleting a harmless temporary file does not prove A:H. Demonstrating that the same primitive can remove the application, its database, operating-system dependencies, or other files reachable by a privileged service is much stronger evidence of persistent, serious loss. If the service continues functioning while merely serving altered content, the effect may be Integrity rather than Availability. Prove the reachable paths, service identity, and resulting behavior.

Backups and recovery plans are important operational controls, but they do not change what the attacker can cause at the moment of exploitation. Recovery is handled more explicitly as a Supplemental metric in CVSS v4.0. In a v3.1 discussion, restoration procedures belong in the surrounding risk and remediation analysis, not as an unexplained reduction in Base Availability.

Keeping deployment and remediation facts out of the Base vector does not mean hiding them. Good disclosure gives those facts prominent treatment.

In one exchange, both sides agreed the final advisory should state that:

• The management interface is disabled by default.
• Customers must enable it before it becomes reachable.
• Management access should be restricted to trusted networks and source addresses.
• The affected release is end-of-life.
• A fixed release is available.
• Internet reachability and hypothetical lateral movement should not be overstated.

That is what responsible coordination looks like. The researcher can preserve a defensible Base vector while documenting the facts customers need to calculate their own exposure. A vendor can publish a lower Environmental score for its reference deployment alongside the Base score. Both can be true at the same time.

Not every scoring disagreement is manipulation. Researchers can overstate impact, misunderstand product boundaries, or submit a worst-case chain without proving every step. Vendors can possess architectural and deployment details the researcher does not. Researchers also have reputational and financial incentives to argue upward.

But vendors and bounty programs face equally real incentives to argue downward, and pretending those incentives do not exist makes the process less trustworthy.

Remediation SLAs

Many organizations tie remediation deadlines, escalation paths, and executive reporting to severity bands. Moving a finding from Critical to High—or High to Medium—can change the clock, the approvals required, and which team owns the response.

In one disclosure thread, the responding team made that relationship explicit:

“Before we finalize the severity and SLA classification on our side, we would like to request a short working session … in the context of typical [supported] deployment patterns.”

That does not prove bad faith. It does show why the distinction between Base severity and deployment-specific risk needs to remain disciplined: the organization applying the score may also benefit operationally from the lower band.

Public Perception

A Critical CVE attracts attention. It appears differently in vulnerability scanners, customer dashboards, procurement reviews, cyber-insurance questionnaires, and headlines. Product teams understandably want the public record to include mitigations and realistic deployment context.

The answer is not to flatten the Base score. Publish the vector, the affected configurations, the Environmental assumptions, the exploitability caveats, the patch, and the vendor’s own risk rating. More information produces a more accurate public record; one artificially compressed number does not.

Bug Bounty Payouts

Where bounty tables are tied directly to severity, CVSS becomes a payment calculator. In one exchange, the program moved a report from 8.1 High to 5.1 Medium using Adjacent, High Complexity, and High Privileges. After an extended discussion it corrected AC and UI, ending at 6.3 Medium and awarding $500, while Availability remained disputed.

It is impossible to infer motive from a score change alone. The structural conflict is still obvious: when the party deciding the metric also writes the check, every ambiguous value has a dollar amount attached to it. Programs should publish target-specific scoring rules upfront, disclose any hard severity ceilings, and use independent mediation for disputed metrics.

One program representative eventually acknowledged the concern that a target-wide interpretation could create an undocumented ceiling. That is the correct issue to surface. Advertising Critical reward ranges while applying fixed assumptions that make Critical mathematically unreachable is not a transparent bounty policy.

Patch Scope And CVE Count

Treating several weaknesses as one chain can reduce patch work, advisory length, and CVE count. Sometimes that consolidation accurately reflects one root cause. Sometimes it hides independent weaknesses behind the first gate in the chain.

The clean test is counterfactual: after fixing the prerequisite, can an attacker with the now-required privileges still trigger the downstream unintended behavior? If yes, the attack path changed, but the downstream weakness may remain. Score it with the appropriate PR value, document the chain separately, and decide CVE counting on its own merits.

The following template covers most scoring pushback without turning the response into a personal argument:

Thank you for validating the finding and providing your proposed score. To make sure we are comparing the same assumptions, please provide the complete CVSS vector and the technical rationale for each metric that differs from the submitted vector.

I agree that the following deployment and remediation facts should be stated prominently: [default state, network controls, affected versions, EOL status, workaround, and patch availability].

I do not believe those facts change the Base metric(s) [list metrics], because [brief technical explanation tied to the applicable CVSS definition]. They can be represented with [Temporal or Environmental metrics] and in the advisory’s deployment guidance.

The demonstrated exploit requires [actual prerequisites] and results in [direct demonstrated impact]. It does not require [race, target-specific secret, separate user action, administrative privilege, or other disputed condition].

My proposed Base vector remains [vector]. If useful, I am happy to calculate a separate Environmental vector for the deployment model you described so both the intrinsic severity and customer-specific risk are communicated accurately.

Keep the tone boring. The goal is not to win a debate on the Internet. The goal is to leave a technically defensible record that another analyst can reproduce.

Researchers should not be the only ones showing their work. A defensible vendor response should include:

• The complete proposed vector, not just a score or severity label.
• A metric-by-metric rationale tied to the scoring specification.
• Evidence for deployment claims, including whether controls are product-enforced or customer-configured.
• Separate Base, Threat/Temporal, and Environmental assessments where appropriate.
• A clear explanation of whether the score controls remediation SLA or bounty payment.
• Published target-specific exceptions or severity ceilings before researchers invest time testing.
• Independent review when the score materially changes a payout.

CVSS disagreements are normal. The researcher sees the exploit path. The vendor sees the product architecture, customer deployments, support obligations, and patch pipeline. A bounty program may also see a payment tier. Those perspectives are different, and all of them can contain useful facts.

The scoring methodology exists to keep those facts in consistent buckets. Base severity describes the vulnerability. Temporal or Threat metrics describe what has changed over time. Environmental metrics describe a particular deployment. The broader risk process handles exposure, business impact, public perception, safety, remediation capacity, and everything else that does not fit cleanly into the vector.

When a score starts moving, slow the conversation down. Ask for the vector. Identify the disputed metric. Ask what technical condition supports it. Test that condition. Put deployment controls where deployment controls belong. Put privileges in Privileges Required. Put separate-user actions in User Interaction. Put direct, demonstrated consequences in Impact.

• CVSS v3.1 Specification Document
• CVSS v3.1 User Guide
• CVSS v3.1 Calculator
• CVSS v4.0 Overview
• CVSS v4.0 Specification Document