CVE, CVSS, KEV and PoC explained

Why the labels matter

A vulnerability advisory is not one fact. It is a bundle of claims from different organisations, made at different times, with different evidence. Reading it well means separating the claims instead of averaging them into a feeling of “critical” or “probably fine”.

PHP2Shell is a useful example because the same two CVEs appear with a CVSS 9.2, a CVSS 9.8, a KEV absence, a public PoC, observed attempts and no confirmed mass compromise. None of those statements contradicts the others.

CVE and GHSA are identifiers, not severity

A CVE ID identifies a vulnerability record. A GHSA ID identifies a GitHub security advisory. Neither tells you how serious the issue is, whether a fix exists or whether anyone exploited it.

The PHP2Shell pair has both:

• CVE-2026-109618 / GHSA-w8hw-w9fx-j79w — RCE via OOM corruption;
• CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp — RCE via stale global state.

The GHSA record is useful because it carries structured affected-version ranges and the maintainer’s patched versions. The CVE record is useful because it is the shared identifier used by governments, scanners and other advisories. Read both when they disagree, and note which one you are quoting.

CVSS: always record the version and the assessor

CVSS is a scoring system, and different versions are not interchangeable. A CVSS v3.1 score and a CVSS v4.0 score can describe the same vulnerability with different numbers because the metrics and weighting changed.

For CVE-2026-109618:

• PHP’s advisory publishes CVSS v4.0 9.2 with the vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N.
• NVD publishes CVSS v3.1 9.8 with CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

Both can be correct. The v4.0 vector says the attack complexity is high and the attack requires a prepared condition; the v3.1 vector says low complexity. They are different assessments, not a contradiction to be resolved by picking the scarier number.

A good citation looks like: “CVSS v4.0 9.2 (PHP Security Team)” or “CVSS v3.1 9.8 (NVD)”. A bad citation looks like: “CVSS 9.8/9.2”, which implies a precision the sources do not support.

CISA KEV: a catalog of known exploitation, not a complete map

The Known Exploited Vulnerabilities catalog lists vulnerabilities that CISA has determined are being exploited. It is used for US federal remediation deadlines, and it is a useful signal for everyone else.

Two traps:

1. Absence is not safety. A CVE can be exploited without being in KEV. KEV updates lag, and it is not a global incident database. The PHP2Shell CVEs were not in the KEV JSON catalog version 2026.10.21 when this site checked, while vendors were reporting attempts. Both facts are true.
2. Presence is not a victim count. A KEV listing means known exploitation, not a number of compromised organisations. CVE-2019-11043 and CVE-2014-0160 are in KEV; the catalog does not tell you how many hosts were affected.

Some secondary reports claimed PHP2Shell was added to KEV on 21 October. This site checked the official JSON feed and did not find either CVE. When a secondary claim and the primary structured feed disagree, record the disagreement and prefer the feed you can inspect.

PoC, attempt, compromise: four different evidence states

These labels get collapsed in headlines. Keep them separate:

For PHP2Shell, the public record supports the first three in varying degrees. Wiz demonstrated laboratory RCE against container images. Amazon observed a honeypot attempt on 17 October. Cloudflare observed attack traffic. WatchTowr said the PoCs it tested did not achieve RCE. A confirmed mass compromise of production sites is not established in the sources reviewed for this site.

A failed PoC is not reassurance. It may be the wrong target, the wrong version, the wrong memory layout or simply broken code. The underlying flaw can still be exploitable by someone with better code.

“No evidence found” is a statement about a search

A sentence like “no evidence of exploitation was found in the sources checked” is bounded by the sources, the time and the search. It is not the same as “this was never exploited”. A sentence like “CISA has not observed exploitation” is bounded by CISA’s visibility. It is not a global all-clear.

When you write or read an assessment, keep the boundary visible. “No confirmed compromise has been publicly documented as of the stated research cut-off” is a defensible sentence. “Nobody was compromised” is not.

A practical reading order

1. Primary vendor advisory. Affected versions, fixed versions, conditions, interim controls. This is the spine.
2. Structured advisory record. GHSA or the vendor’s machine-readable data. Check version ranges and patched versions.
3. NVD or another scoring source. Record the CVSS version and assessor separately.
4. Government or CERT advisory. Look for the evidence cut-off and the operational advice.
5. Vendor research. Mechanism and lab reproduction. Label it as vendor research.
6. Media reporting. Use it for timeline and context, and follow its links to the primary source.
7. KEV or other exploitation catalog. Check the date and the catalog version. Do not infer absence of exploitation from absence in the catalog.

If two sources conflict, write down both claims and the reason they differ. Do not let the most recent page overwrite a verified earlier fact. That rule is why this site records the PHP release date without inventing a release time: the official pages disagree on the time, so the honest record is the date.