# CVE explained: what PHP2Shell tells security teams

> CVE explained through the PHP2Shell vulnerability. Learn what a CVE is, how CVSS, KEV, and EPSS help teams decide what to fix first, and how enterprises can shorten the time from a published CVE to a merged fix.

URL: https://factory.com/articles/cve-explained
Published: 2026-10-23
Updated: 2026-10-23

When PHP shipped emergency fixes for PHP2Shell on October 21, 2026, security teams everywhere got the same alert with two IDs attached, CVE-2026-109618 and CVE-2026-109619. Within hours, scanners, vendors, and government agencies were all using those IDs to describe the same problem. That shared name is what a CVE is for.

A CVE is a public ID for a specific security flaw in a specific piece of software. It tells you which issue everyone is talking about. It does not tell you how urgent it is for your company, or how long it will take to fix. This guide uses PHP2Shell to explain what a CVE is, how teams decide which ones to fix first, and why the real challenge for most enterprises is turning a CVE into a merged fix quickly.

## CVE explained: what the ID means

CVE stands for Common Vulnerabilities and Exposures. The [CVE Program](https://www.cve.org/About/Overview) started in 1999, is run by MITRE, and is sponsored by the US Cybersecurity and Infrastructure Security Agency (CISA). Its job is to identify and catalog publicly disclosed vulnerabilities.

Each ID follows the pattern CVE, year, and a number, for example CVE-2026-109619. The year shows when the ID was assigned or the issue was made public, not necessarily when the bug was introduced. Each ID points to a CVE Record with a short description, the affected products and versions, and references such as vendor advisories.

IDs are assigned by CVE Numbering Authorities, known as CNAs. These include software vendors, open source projects, security firms, and national response teams. A large vendor typically acts as the CNA for its own products, which is why a fix and its CVE often appear on the same day.

A CVE is only an identifier. It does not say how dangerous a flaw is, whether anyone is exploiting it, or whether it affects your systems. Those answers come from other sources.

## How CVE severity is scored

The Common Vulnerability Scoring System, or [CVSS](https://www.first.org/cvss/), rates how severe a vulnerability is on a scale from 0 to 10. It is maintained by FIRST, a global forum of incident response teams. Version 4.0 was released in November 2023 and is now common in advisories.

A CVSS score reflects things like whether the attack works over a network, whether the attacker needs to log in, and what they could do after succeeding. Scores of 9.0 and above are labeled critical. The two PHP2Shell vulnerabilities, for example, scored 9.2 because they allow unauthenticated remote code execution.

The US [National Vulnerability Database](https://nvd.nist.gov/), run by NIST, adds analysis and scores to many CVE Records. Vendors often publish their own scores too, and the numbers do not always match.

CVSS measures severity. Risk to your organization also depends on where and how the software runs. A critical bug in a library you do not ship does not matter to you. A medium-rated bug in an internet-facing login service might matter a lot.

## Deciding which CVEs to fix first

Most enterprises see far more CVEs than they can fix at once. Two public sources help narrow the list.

CISA's [Known Exploited Vulnerabilities catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog), or KEV, lists CVEs with reliable evidence of active exploitation. US federal agencies are required to fix KEV entries by set deadlines, and many private companies use the catalog as a priority list.

The Exploit Prediction Scoring System, or [EPSS](https://www.first.org/epss/), also from FIRST, estimates the probability that a CVE will be exploited in the next 30 days. It helps rank the long tail of issues that are not yet in KEV.

A practical order of work looks like this.

1. Fix CVEs that are actively exploited and affect systems exposed to the internet.
2. Fix critical and high CVEs with a high EPSS score in systems that handle sensitive data.
3. Schedule the rest into normal dependency and upgrade work, with an owner and a date.

Context matters at every step. Whether the vulnerable code is reachable, whether a control already blocks the attack, and who owns the service all change the answer.

## Why CVE remediation stalls in large organizations

Finding a CVE is usually fast. Scanners match package versions against advisories within hours of publication. The slow part comes after.

Each affected repository needs someone to read the advisory, update the dependency or base image, deal with breaking changes, get tests passing, and open a pull request. Then the owner has to review and merge it, and the change has to reach production. Multiply that by dozens or hundreds of repositories, each with its own owner and backlog, and a single CVE can take weeks to close everywhere.

Security teams feel this as a growing pile of open findings. Engineering teams feel it as a stream of interruptions that compete with planned work. The CVE is well understood the whole time. The bottleneck is the engineering effort needed to ship the fix.

## How Factory turns a CVE into a pull request

Factory is a platform for building a software factory, where agents called Droids take work from a signal to a reviewed pull request. A CVE alert is a clear example of that kind of signal.

**Start from the alert.** [Factory Automations](https://docs.factory.com/software-factory/automations) can start a Droid on a schedule, on a GitHub event, or from an inbound webhook, such as a scanner or advisory feed. Each run has clear instructions and a defined identity.

**Do the repetitive work in parallel.** A Droid can check whether a repository uses the affected version, update the dependency, fix resulting build errors, run the tests, and open a pull request that explains the change and links the advisory. The same work can run across many repositories at once.

**Check the fix before people review it.** Factory's [security review](https://docs.factory.com/software-factory/security-review) can review each pull request for new security issues. Repository owners still approve and merge, so humans keep the final decision.

**Run it where your code lives.** Teams with strict data rules can deploy Factory in their own environment with [Factory Private](https://factory.com/deployment/factory-private). Because Factory is model-agnostic, teams can use the models they have approved instead of being tied to one provider.

The result is less time between a published CVE and a merged fix, without giving up review or control.

If you are working on CVE remediation across many repositories, use the form below to talk with the Factory team.

## Frequently asked questions

### What is a CVE?

A CVE (Common Vulnerabilities and Exposures) is a public ID for a specific security flaw in a specific piece of software. The CVE Program is run by MITRE and sponsored by CISA, and IDs are assigned by CVE Numbering Authorities such as software vendors, open source projects, and security firms.

### Does a CVE tell you how dangerous a vulnerability is?

A CVE is only an identifier. Severity comes from a CVSS score, evidence of active exploitation comes from the CISA Known Exploited Vulnerabilities catalog, and whether it affects you depends on where and how the software runs in your environment.

### What is the difference between CVSS, KEV, and EPSS?

CVSS rates how severe a vulnerability is on a scale from 0 to 10. CISA KEV lists CVEs with reliable evidence of active exploitation. EPSS estimates the probability that a CVE will be exploited in the next 30 days.

### Which CVEs should a team fix first?

Start with actively exploited CVEs in systems exposed to the internet. Next, fix critical and high CVEs with a high EPSS score in systems that handle sensitive data. Schedule the rest into normal dependency work with an owner and a date.

### Why does CVE remediation take so long in large organizations?

Scanners find affected packages within hours. The slow part is updating, testing, reviewing, and merging the fix in every affected repository, each with its own owner and backlog.

### How does Factory help with CVE remediation?

Factory Automations can start a Droid from a scanner alert or advisory feed. The Droid updates the dependency, runs the tests, and opens a pull request that links the advisory, across many repositories in parallel. Repository owners still review and merge each change.

## Further reading

- [What the PHP vulnerability means for enterprise](https://factory.com/articles/php-vulnerability-enterprise)
- [Private AI security remediation](https://factory.com/articles/private-ai-security-remediation)
- [SBOM automation for coding agent changes](https://factory.com/articles/sbom-automation-coding-agents)
- [Security review docs](https://docs.factory.com/software-factory/security-review)