Skip to content

Distinguish physical access from software/firmware weaknesses that are discovered by opening the physical enclosure #38

Description

@GeorgesBolssens-Toreon

Rule 4.1.5.2 is being interpreted in different ways by two CNAs, leading to a discrepancy in understanding whether the rule creates a way out of assigning a CVE subsequent to physical attacks.

The crux: "If an underlying vulnerability is discovered after opening the case, is it disqualified from being assigned a CVE?"

We argue no, the CNA we are reporting to says yes.

Current text (v4.0):

4.1.5.2 Physical theft, damage, or destruction are not by themselves cybersecurity Vulnerabilities. CNAs SHOULD NOT determine physical access to a processor, memory, bus, or other hardware component to be a cybersecurity Vulnerability.

The "by themselves" qualifier in sentence 1 is load-bearing; its absence in sentence 2 makes the second sentence read as a flat exclusion of any weakness reachable via an internal interface, which collapses the vector/weakness distinction that CVSS and CWE otherwise preserve.

Proposed text:

4.1.5.2 Physical theft, damage, destruction, or the act of physically accessing a processor, memory, bus, or other internal hardware component (e.g., by opening an enclosure and attaching probes to test points) are not by themselves cybersecurity Vulnerabilities.

4.1.5.2.1 A software or firmware weakness is not excluded from CVE eligibility solely because the reporter's demonstration involved a physical interface. Such weaknesses are evaluated under 4.1.5 and 4.1.5.1 on the basis of the weakness itself (e.g., CWE-312, CWE-306, CWE-798, CWE-327).

4.1.5.2.2 A physical interface that is externally exposed and user-facing (e.g., a labeled serial or USB port intended for user operation) that grants privileged access without authentication SHOULD be determined to be a Vulnerability under 4.1.5.1.

Happy to iterate on wording.

Activity

  1. zmanion commented on Apr 29, 2026

    @zmanion
    Collaborator

    SPWG briefly discussed this today.

    May involve threat model, e.g., Product is designed to defend against certain classes of physical attack, as noted in 4.1.5 and 4.1.5.1.

    The distinctions that an external console port lacks labeling or that the interface is only available by cracking the case may be too narrow to write into the rule.

  2. GeorgesBolssens-Toreon commented on Apr 30, 2026

    @GeorgesBolssens-Toreon
    Author

    Agreed that the level of detail I put forth in the proposed 4.1.5.2.2 is too narrow.

    My broader point was to disambiguate the misunderstanding outlined in the initial issue as per my proposed 4.1.5.2.1.

    If there is no "4.1.5.2.2", making it a sub-paragraph seems nonsensical and could also be written as a clarification of 4.1.5.2.

    Proposal (changes in bold):
    4.1.5.2 Physical theft, damage, or destruction are not by themselves cybersecurity Vulnerabilities. CNAs SHOULD NOT determine physical access to a processor, memory, bus, or other hardware component to be a cybersecurity Vulnerability. Software or firmware weaknesses SHOULD NOT be excluded from CVE eligibility, solely because the attack vector was physical ("AV:P" in CVSSv3.x and CVSSv4 ). Vulnerabilities that are exposed by physically opening a device's enclosure SHOULD be evaluated on their own merits, regardless of the value of the AV-dimension of the CVSS vector.

    Looking forward to your response

  3. added
    4.4.0Candidates for 4.4.0
    and removed
    4.3.0Candidates for 4.3.0
    on Sep 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    4.4.0Candidates for 4.4.0

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions