A vulnerability scanner report lists an unpatched web application flaw with base score 7.5. Threat intelligence now shows exploit code maturity changed from Unproven to Functional, and active exploitation attempts are appearing in honeypot logs. Which action should the vulnerability analyst take first?

CVSS separates inherent severity from threat context. The base score describes the vulnerability's intrinsic impact and exploitability, while threat metrics such as exploit code maturity capture how readily weaponization exists in the wild. When exploit code maturity increases, the effective risk rises even if the base score remains fixed, so a vulnerability analyst should reassess remediation priority and move the finding earlier in the queue. Keeping the remediation schedule unchanged because the base score did not change ignores the purpose of threat metrics; the base score is not the whole risk picture. Reducing priority because exploit maturity is not part of the base metric mistakes the metric's role, since temporal or threat evidence is meant to adjust operational urgency. Waiting for a vendor advisory before changing priority delays action despite independent exploitability evidence, and vendor guidance is not required to recognize increased risk from observed exploitation. Exam caveat: CS0-004 expects analysts to combine CVSS severity with threat context and business exposure, not to treat a static score as final. Operational check: compare the current threat metrics against the prior assessment, document the exploit-maturity change, and escalate the ticket to the remediation owner with a revised due date.