Vulnerability

Applies to. PCI DSS puts the word to work in three kinds of control. 6.3.1 requires the entity to find new security vulnerabilities from industry sources such as CERT alerts, rank them, and cover its own code as well as third-party software such as operating systems and databases. 2.2.1 requires configuration standards to address known vulnerabilities, and 6.2.4 and 6.4.1 require bespoke code and public-facing web applications to be defended against common ones. 11.3.1 and 11.3.2 then test for them: internal scans at least every three months, and external scans by an ASV on the same cadence.

Example. A payment service provider subscribes to its national CERT feed and its vendors' security lists. When an advisory arrives for the message queue software it runs, the security team logs it, ranks it under 6.3.1 against where the software sits in the environment, and either schedules the patch under 6.3.3 or records why the flaw cannot be exploited in their configuration. The next quarterly internal scan confirms the fix took.

Limits. A vulnerability is a weakness, not an attack: an exploit is the code or method that uses it, and a threat is the actor or event that might. A scanner finding is a lead, not a verdict: a finding the entity can show does not apply to its configuration is documented rather than patched, and one below the entity's high-risk threshold is handled under 11.3.1.1 on the entity's own risk analysis rather than on the scan's deadline. The term also covers design and process weaknesses, not only missing patches, which is why 6.2.4 lists attack classes rather than software versions. And a vulnerability being known does not mean it is present: 6.3.3 speaks of applicable patches, and applicability is the entity's call to document.