Vendor-issued patches for CVEs: what they are and why applying them matters

“Apply vendor-issued patches for CVEs” turns up in security awareness training, audit checklists and every government advisory about a newly exploited flaw. This guide explains what the phrase means, why it is the single most effective control against known vulnerabilities, and how a small or mid-sized organisation can apply patches quickly without breaking things.

By Alex Martyushin, founder & risk consultant · Updated 30 October 2026 · 12 min read

What a CVE is

CVE stands for Common Vulnerabilities and Exposures. It is a public catalogue that gives each disclosed security vulnerability a unique identifier, such as CVE-2026-109618 — the year the ID was reserved, followed by a sequence number. The ID lets vendors, security tools, advisories and your IT team talk about exactly the same flaw.

• Who runs it: the CVE Program is operated by MITRE, with sponsorship from the US Cybersecurity and Infrastructure Security Agency (CISA).
• Who assigns IDs: CVE Numbering Authorities (CNAs). Many large vendors are CNAs for their own products, as are some security researchers and national CERTs.
• What a CVE record contains: a short description, the affected products and versions, and references such as the vendor advisory. Severity scores are added by the CNA or by databases such as the US National Vulnerability Database (NVD).

A CVE is not a threat in itself. It tells you that a weakness exists and has been disclosed. Whether it matters to you depends on whether you run the affected version, how exposed it is and whether attackers are using it.

What vendor-issued patches are

A vendor-issued patch is a fix released by the organisation that makes and maintains the product — Microsoft for Windows, Apple for iOS, the PHP project for PHP, a firewall maker for its firmware. “Vendor-issued” distinguishes it from unofficial fixes, third-party “virtual patches” or your own workarounds. Official patches are tested by the people who know the code and come with an advisory explaining what they fix.

Backports catch people out. A scanner that compares version numbers may flag a patched distro package as vulnerable, or miss an unpatched one. Check the distribution’s security tracker for the CVE rather than relying on the version string alone.

Why applying patches promptly is the key control

Publishing a patch also publishes a map. Once a fix is out, attackers can compare the patched and unpatched code to understand the flaw and build an exploit, and the CVE record tells them which products to look for. From that moment the risk to unpatched systems typically rises, not falls.

• Known vulnerabilities are a leading way in. Government agencies including CISA, the UK NCSC and the Australian Signals Directorate repeatedly report that attackers exploit vulnerabilities for which patches have long been available.
• Exploitation can start very quickly. For some high-profile flaws, attacks begin within days of disclosure — or before, as with PHP2Shell in October 2026, where an exploitation attempt was reported before the fix was published.
• Mass scanning is cheap. Attackers scan the whole internet for vulnerable versions of popular software. Being small does not make you invisible.
• Patching removes the weakness. Other controls — firewalls, detection, backups — reduce the chance or the impact of exploitation. A patch closes the hole itself.

That is why every mainstream baseline, from Cyber Essentials to the Essential Eight to the CIS Controls, includes timely patching as a core requirement, and why “apply vendor-issued patches for CVEs promptly” is the right answer to the training-quiz question.

How to find the patch for a CVE

1. Start with the vendor advisory. Search the vendor’s security advisory or release notes page for the CVE ID. It lists affected and fixed versions and any interim mitigations.
2. Check the CVE record and the NVD entry. Both link to vendor advisories and other references. The NVD may also show a CVSS score and affected product configurations.
3. For Linux packages, use the distribution’s tracker. Debian, Ubuntu, Red Hat and others publish per-CVE pages showing which package versions contain the fix.
4. Check CISA’s Known Exploited Vulnerabilities (KEV) catalogue. If the CVE is listed, the entry includes a required action — usually “apply mitigations per vendor instructions” — and confirms active exploitation.
5. Ask your provider. For hosted, managed or cloud services, the patch may be theirs to apply. Ask for written confirmation and the date — this is where a third-party risk assessment pays off.

How to prioritise: CVSS, EPSS and CISA KEV

You cannot apply every patch on the day it is released, so you need a rule for what goes first. Three free signals do most of the work:

A simple rule for a small organisation: known exploited or internet-facing and critical first, everything else in the normal patch cycle. Our vulnerability management process guide turns these signals into a full priority matrix with example SLAs, exceptions and reporting — this page does not repeat it.

Patching timeframes: what frameworks expect

Most frameworks count from the patch’s release, not from when you noticed it. The table summarises benchmarks commonly used by organisations in the UK, Australia and the US. They change, so check the current text before relying on a specific figure.

Private companies are not bound by CISA directives, but many use them as a benchmark for internet-facing systems. For payment environments, see the PCI DSS compliance checklist.

A practical patching routine

1. Know what you run

You cannot patch what you do not know exists. Keep an inventory of devices, operating systems, applications, plugins, firmware and cloud services, with versions and owners. Include the things that are easy to forget: the website’s CMS plugins, the office router, the VPN appliance, the PHP runtime on a hosting account.

2. Watch for patches

Subscribe to security advisories for your key vendors and to CISA’s KEV updates. Most endpoint management and scanning tools can do this for you, but a person should still own the list.

3. Assess and decide

For each relevant patch, decide the priority using the signals above and the target date. Emergency patches for known-exploited flaws on exposed systems should bypass the normal monthly cycle.

4. Test proportionately

Testing protects against patches that break things — a real, if less common, risk. Match the test to the system:

• Pilot rings. Deploy to a small group of machines first (IT staff, a test server), then widen after a day or two without problems.
• Critical business systems. Test in a staging copy where you have one; otherwise schedule the update for a quiet period with the system owner on hand.
• Emergency patches. Shorten or skip extended testing when a flaw is being actively exploited on an internet-facing system. The risk of compromise usually outweighs the risk of a faulty patch.

5. Have a rollback plan

Before patching anything important, know how you would undo it: a snapshot or backup taken immediately before, the uninstall or downgrade path, and who decides to roll back. Rolling back should be rare and temporary — a rolled-back patch means the vulnerability is open again, so record it and apply mitigations until a fixed version is available.

6. Verify

“Deployed” is not “installed”. Confirm with a rescan or the management tool that the fixed version is running — and that the service was restarted if needed. Many incidents start on machines that were “patched” on paper.

What to do when no patch exists

Sometimes a CVE is published, or exploited, before the vendor has a fix — or the product is end of life and will never be fixed. You still have options:

A web application firewall rule or intrusion prevention signature (often called a “virtual patch”) can reduce exposure, but it is a mitigation, not a fix. Treat it as temporary.

Where patching belongs in the risk register

Individual patches belong in your patching tool or ticket queue, not in the risk register. The register is for the situations where patching cannot do its job: a system that cannot be patched, a dependency on a supplier, a recurring failure to meet your timeframes, or an exception that has outlived its expiry date. The October 2026 PHP2Shell vulnerabilities are a good illustration — our PHP2Shell risk register guide walks through the lasting risks one event can reveal.

Scores are illustrative residual scores on a 5×5 risk matrix. Two key risk indicators tell you whether patching is working: the percentage of critical patches applied within target, and the number of known-exploited vulnerabilities open on internet-facing systems (target: zero).

Common mistakes

• Waiting for the monthly cycle. Known-exploited flaws on exposed systems need an emergency route.
• Patching only Windows. Firewalls, VPNs, routers, web servers, plugins and runtimes are frequent targets and often forgotten.
• Trusting version numbers alone. Backports and unrestarted services make version checks misleading; verify.
• Assuming the host or supplier has patched. Ask and get confirmation.
• Endless testing. Testing that takes longer than the attacker needs is not risk reduction.
• Exceptions without expiry. An unpatched system with no end date is an accepted risk nobody accepted.
• Forgetting compromise. If exploitation started before you patched, the patch does not undo it.