How to tell if the software you host yourself is still patched

How to tell if the software you host yourself is still patched

On 8 October 2026 the US Cybersecurity and Infrastructure Security Agency added five vulnerabilities to its Known Exploited Vulnerabilities catalog. None of them is new. The newest, a flaw in Strapi, was published in April 2023; the oldest, in ProFTPD, dates from May 2015. Each has had a fixed release for years, although, as the Strapi case shows, not every older version line ever received one. Each was added because attackers are using it against systems that never received that patch. This guide uses those five entries to teach a method you can run yourself: how to find out whether the self-hosted or on-premises software you operate is still supported, still patched, and still safe to leave alone, and what to do when the answer is no.

Everything below can be done with a browser and a spreadsheet. We name vendors because the evidence has to come from somewhere, not because any of them is better or worse than another. The pages quoted were read on 9 October 2026, and each is listed with its date at the end.

Five old flaws, one pattern

The five entries, with dates taken from the catalog itself (version 2026.10.08) and the National Vulnerability Database, are these.

• ISC BIND, CVE-2015-5477, published 29 July 2015: a crafted TKEY query makes the named process stop. NVD lists BIND 9.x before 9.9.7-P2 and 9.10.x before 9.10.2-P3 as affected.
• ProFTPD, CVE-2015-3306, published 18 May 2015: the mod_copy module in ProFTPD 1.3.5 lets a remote attacker read and write arbitrary files. NVD records a base score of 10.0.
• Apache Struts, CVE-2016-3081, published 26 April 2016: arbitrary code execution through the method: prefix when Dynamic Method Invocation is on, in 2.3.19 to 2.3.28. The Struts project shipped 2.3.28.1 with the fix on 19 April 2016, a week before the CVE was published.
• ONLYOFFICE Docs, CVE-2021-3199, published 26 January 2021: directory traversal in the upload handler when JWT is used, scored 9.8 by NVD. The ONLYOFFICE changelog lists the fix under version 5.6.3.
• Strapi, CVE-2023-22894, published 19 April 2023: an administrator can infer sensitive user details through the query filter. NVD scores it 4.9, and its configuration data lists Strapi from 3.2.1 up to but not including 4.8.0.

All five carry a due date of 11 October 2026, three days after they were added. CISA's Binding Operational Directive 26-04, issued 10 June 2026, applies to US federal civilian agencies, not to you. Its text still shows how the people who wrote the catalog think about time: the clock starts when a vulnerability is added to the catalog, and where a forensic check of the asset is also required, remediation is due within three days.

The Strapi entry carries the most useful lesson. Read the NVD range again: affected from 3.2.1, fixed in 4.8.0. Version 3 is inside the affected range and the fixed version is a different major release. A team running Strapi 3 could never have installed a patch for this flaw. The only fix was to migrate, and Strapi's own announcement says that support for version 3 ended on 31 December 2022, less than four months before the CVE was published. Nobody told those users about this flaw, because there was no longer anyone whose job it was to tell them.

That is the pattern across all five. The software kept running. Nothing broke, nothing alerted, and the absence of trouble was read as evidence of safety. The rest of this guide is about replacing that assumption with checks.

Three words that mean different things

Vendors use a small vocabulary and mean different things by it, so settle the terms before you read any policy.

End of life usually describes the product or version as a whole. The vendor will not release it, fix it or, in many cases, sell it any more. Apache puts it plainly on its end-of-life page: when a Struts version reaches end of life, the project "no longer provides security patches, bug fixes, or updates for that branch", and end-of-life versions get no support from the project at all.

End of support is narrower and is where most disputes start. It describes the date after which a vendor stops answering tickets, accepting bug reports or issuing a class of fix. Microsoft's Fixed Lifecycle Policy shows how much can sit inside one product. Mainstream Support lasts a minimum of five years and includes design changes and non-security updates. Extended Support follows, with security updates and paid support but no new features. After that comes a phase where security updates exist only through the paid Extended Security Update program. A product can be out of mainstream support and still be patched; it can be past extended support and be patched only if you pay. "Supported" is therefore never a yes or no answer. Ask which phase you are in and what that phase includes.

Long-term support, or LTS, is a promise made at release: this branch will receive fixes for a stated period, with a conservative change policy. It is a property of a branch, not of a product, and it still ends. Ubuntu's release cycle page says LTS releases get five years of standard security maintenance, with Ubuntu Pro extending security coverage to ten years and an add-on to fifteen. Its table puts the end of standard maintenance for 20.04 LTS at May 2025, for 22.04 at May 2027 and for 24.04 at May 2029. An LTS tag on a download page tells you nothing about the date, so read the date.

Two more details trip people up. Some vendors keep a branch under security-only maintenance for part of its life: ISC describes its BIND stable branches as getting feature updates and bug fixes for about a year, then critical fixes, then only security patches, over a total of four years. And some vendors end a branch while the product continues. Strapi 3 and Strapi 4 both ended while the product lived on as version 5, and a vendor can be fully active while your version receives nothing.

Where each vendor says it, and how the wording differs

There is no standard place to look, and the wording changes from vendor to vendor. The pages below were each read for this guide, and they show the range.

Strapi publishes its support table in the security policy file of its GitHub repository. It lists version 5 as the only supported line, version 4 as end of life with security updates until April 2026, and version 3 as end of life since November 2022. Its blog post of 30 November 2022, updated 22 May 2026, gives a different date for version 3: support until 31 December 2022, with versions 3.6.10 and 3.6.11 as the last releases. Strapi's migration documentation says version 4 reached end of life on 30 April 2026 and that release 4.26.2, dated 9 June 2026, was the last. Two Strapi pages therefore disagree by about a month on the version 3 date. The conflict is small, and it matters as a habit: when two official pages differ, write down both and plan to the earlier one.

The same page explains how a self-hosting user learns about flaws. Reports go through GitHub security advisories, fixes typically ship within a few days, and detailed disclosure follows after an embargo of two to eight weeks. Paying customers and partners get advance notice. Users on the free tier learn from release notes and the advisory itself, which the policy says makes watching the releases page the best early warning.

The Apache Struts project keeps a separate end-of-life page with a table: Struts 2.5.x ended on 30 October 2023, 2.3.x on 12 September 2019 and 1.x on 5 April 2013. The Struts flaw in the catalog affects 2.3, a branch that had been unsupported for seven years when it was added. The project also notes that third-party vendors sell extended security support for end-of-life versions, so an end-of-life branch is not necessarily unfixable, only unfixed by the people who wrote it.

ISC publishes a BIND software support policy, last updated 11 May 2026. Development branches (odd numbers) are kept for 24 months and stable branches (even numbers) for four years in total. BIND 9.16 was declared end of life in March 2024, and 9.18 is scheduled to reach end of life in June 2026, which means any server still on 9.18 has been outside the policy since this summer. Notice that this is a calendar in a document, not a message to your inbox.

ONLYOFFICE has no dated lifecycle table that we could find. Its changelog on GitHub, which we read on 9 October 2026 and whose latest entry is version 9.4.0, is the evidence. It lists a path traversal fix in 5.6.2 (the savefile parameter) and the CVE-2021-3199 fix in 5.6.3, both filed under back-end fixes. A vendor with no published end-of-life dates is also giving you an answer: you have to infer support from release activity and ask for the policy in writing.

Red Hat's life cycle page for RHEL 8, 9 and 10 describes ten years across three phases, then an Extended Life Phase in which, in its words, "no bug fixes, security fixes, hardware enablement or root-cause analysis will be available". Separate paid add-ons extend that further. The operating system your application runs on has its own calendar, and a fully supported application on an unsupported operating system is not a supported deployment.

What we counted in the CISA catalog

The catalog is the strongest single source on what attackers are using, and CISA publishes it as a JSON feed. CISA describes it as the authoritative source of vulnerabilities exploited in the wild and advises organisations to use it as an input to prioritisation. We downloaded the feed on 9 October 2026 (catalog version 2026.10.08, 1,739 entries) and counted. Years below refer to the year in the CVE identifier, which is when the number was reserved and sometimes a little earlier than publication.

• 255 entries were added between 1 January and 8 October 2026.
• 19 of those 255 have a CVE number from 2019 or earlier, and 15 have one from 2016 or earlier. That is one addition in thirteen.
• 169 of the 255 carry a 2026 CVE number, so about two thirds of the year's additions are fresh and one third are not.
• Across the whole catalog, 558 of 1,739 entries (32 per cent) have a CVE number from before 2020.
• The catalog marks 361 entries (21 per cent) as used in known ransomware campaigns. Among the 558 older ones, 126 (23 per cent) carry that mark, so age does not make a flaw less attractive to ransomware operators.
• Of the 255 additions in 2026, 27 are marked as known ransomware use, and none of the 19 older ones is. The flag is often added later, so this tells you that ransomware use is recorded with a delay, not that old flaws are safe.
• In 2026 the remediation due date was three days after the date added for 130 of the 255 entries, 14 days for 78 and 21 days for 44.

Treat these as a snapshot with limits. The catalog lists only flaws for which CISA holds evidence of exploitation, so it undercounts. A flaw missing from the catalog is not therefore safe. But a flaw present in it is a different class of problem from one that merely has a high score, and the long tail of older entries is the reason to check the catalog against your inventory instead of reading only new additions.

To automate it, download the JSON, filter by vendorProject and product for each item in your inventory, and compare the dateAdded field with your last check. CISA also offers an email subscription for catalog updates. A script of twenty lines run daily does more than a quarterly spreadsheet review.

Matching your versions to the advisories

The KEV catalog tells you what is being exploited. The National Vulnerability Database tells you which versions are affected, and it does so in a field called the configuration, where each product entry has a start version and an end version. Use that field, and not the prose description, to decide whether you are in scope. For the Strapi flaw above, the prose said "through 4.5.5" while the configuration said "before 4.8.0", and the two are not the same set. Where they differ, the wider one is the safer one to act on until you have read the vendor's advisory.

A repeatable check looks like this.

1. Write down the exact version of every self-hosted component, including the operating system, the runtime, the web server and any bundled library. "Latest" and "the 4.x line" are not versions.
2. For each component, open the vendor's lifecycle or support policy and record three dates: when your branch was released, when it leaves feature support, and when it leaves security support.
3. Search the vendor's security advisory page for your branch and note the highest fixed version for each advisory. Then compare that to the version you run.
4. Search NVD by product and read the configuration data for entries in your version range.
5. Filter the CISA feed by vendor and product. A match is a priority regardless of the score attached to it.
6. Record the result with the date and the pages read, so the next person repeating the check starts from yours.

Two traps are worth knowing. First, vendors backport fixes. Linux distributions often keep an old upstream version number and patch it, so a version string alone can make a patched system look vulnerable or the reverse. Read the distribution's own security tracker for the package, and do not conclude anything from the upstream number. Second, bundled software hides inside products: a library version listed by your vendor may be older than the one the library project currently maintains. Ask your vendor for a software bill of materials, or at least a statement of which components and versions ship in each release.

Inventory, contracts and who is paid to tell you

The check above only works on software you know you have. Old self-hosted software tends to survive in places nobody reviews: a daemon enabled for one project, a component installed by a contractor, a server that moved teams. The person who owns the risk is often not the person who knows the software exists.

A useful inventory has a few columns and few rows of prose: product, exact version, host, whether it faces the internet, who owns it, the vendor's end-of-support date, the date you last checked, and the support contract that covers it, if any. Internet exposure matters most because exposure is how the catalog's own timelines are set: CISA's directive says that taking a system off the internet changes its exposure and can lengthen the time allowed to fix it. Start with whatever listens on a public address.

Contracts decide who is obliged to tell you. Paid vendors often give customers early notice of flaws under confidentiality; Strapi's policy says so about its paying customers and partners. Open-source users usually do not get that, and the most they can rely on is a public advisory feed. Read your support terms for four things: which versions are covered, whether security fixes for an older branch are included or sold separately, how fast the vendor must tell you about a flaw, and what happens to the contract if you fall behind on upgrades. Microsoft's policy, for instance, says that to receive support a customer may be required to deploy the latest service pack, and that self-help support remains for at least twelve months after the end of support. A contract that says "supported" may mean less than it appears to.

Subscribe to each vendor's advisory channel with a shared mailbox rather than one person's address, and keep the list of subscriptions next to the inventory. Review both whenever someone leaves.

When a version is past its date

If the check shows that something you run is outside its support dates, you have roughly four choices, and the order in which to try them matters.

First, upgrade within the same product to a supported branch. This is usually the least work for the lowest risk, and it is the right answer where an in-place upgrade path exists. For Struts, the project's own table shows what that means: moving off 2.3 or 2.5 to a supported branch. Check the vendor's migration guide first, and test on a copy with real data, since Strapi's 3 to 4 move changed enough to need codemods and data migration scripts.

Second, move to a different product. This is a project, not a patch, and it needs a plan with an owner, a budget and a date. Start it early. Teams that begin planning after the catalog entry appears have only the due date to work with.

Third, buy extended support. Several vendors sell it: Microsoft's Extended Security Update program, Ubuntu Pro, Red Hat's extended add-ons, and third-party firms for end-of-life Struts. This buys time, not a solution. Read what it covers, because it often covers the operating system or core package and not every component of your deployment. Agree an end date for the arrangement when you sign.

Fourth, contain what you cannot change. Remove the system from the internet or place it behind a gateway that requires authentication, restrict which networks can reach it, run it with the least privilege its function needs, and monitor it. For the five flaws in this week's catalog, those steps reduce the most direct paths, but they are a stopgap. Record the decision and review it on a date.

Whatever you choose, check for signs that someone has already used the flaw. CISA's directive pairs the shortest deadline with a forensic triage step because patching removes the way in and says nothing about whether someone came through first. Review logs for the period since the flaw was published, not since you noticed it, and keep copies before you rebuild anything.

Habits that keep the answer current

Support status changes on a calendar the vendor controls, so put the dates in yours. Enter the end-of-support date of every product in the inventory as a calendar event twelve months ahead and again at six months, and assign a person. Review the CISA feed against the inventory on a fixed day each week. Treat any vendor that publishes no end-of-life dates as one to ask in writing, and keep the reply.

None of this needs a tool you do not already have. It needs a list, a few URLs and a person whose job includes opening them. The five entries added on 8 October 2026 were not hard to defend against. They were unwatched.

Related on TrustList:

• Edge devices are attacked first, application servers after the patch
• Microsoft 365 and Azure: 40 dated changes admins must act on by spring 2027

Sources

Pages read on 9 October 2026 for this guide, with the date each page carries where it shows one.

• CISA, Known Exploited Vulnerabilities Catalog, JSON feed, catalog version 2026.10.08, released 8 October 2026, downloaded 9 October 2026. https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
• CISA, Known Exploited Vulnerabilities Catalog page, read 9 October 2026. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• CISA, BOD 26-04 Prioritizing Security Updates Based on Risk, issued 10 June 2026, read 9 October 2026. https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
• NIST National Vulnerability Database records for CVE-2023-22894 (published 19 April 2023), CVE-2021-3199 (26 January 2021), CVE-2016-3081 (26 April 2016), CVE-2015-5477 (29 July 2015) and CVE-2015-3306 (18 May 2015), read through the NVD API on 9 October 2026. https://nvd.nist.gov
• Strapi, End of The Road for Strapi v3, published 30 November 2022, last updated 22 May 2026. https://strapi.io/blog/end-of-the-road-for-strapi-v3
• Strapi, security policy and supported versions (SECURITY.md), read 9 October 2026. https://github.com/strapi/strapi/blob/main/SECURITY.md
• Strapi documentation, Upgrading to Strapi 5, introduction and FAQ (v4 end of life 30 April 2026, release 4.26.2 of 9 June 2026), read 9 October 2026. https://docs.strapi.io/cms/migration/v4-to-v5/introduction-and-faq
• Strapi support, v3 to v4 migration resources, read 9 October 2026. https://support.strapi.io/support/solutions/articles/67000709822-strapi-v3-to-v4-migration-resources
• Apache Struts, End-of-Life Versions, read 9 October 2026. https://struts.apache.org/eol-versions.html
• Apache Struts, Security guide, read 9 October 2026. https://struts.apache.org/security/
• Apache Struts, announcement of 19 April 2016, Struts 2.3.28.1 with security fixes. https://struts.apache.org/announce-2016.html
• ISC, BIND software support policy and version matrix, updated 11 May 2026, read 9 October 2026. https://kb.isc.org/docs/aa-00896
• ONLYOFFICE Document Server, change log (latest entry 9.4.0, entries 5.6.2 and 5.6.3), read 9 October 2026. https://github.com/ONLYOFFICE/DocumentServer/blob/master/CHANGELOG.md
• Ubuntu, release cycle, read 9 October 2026. https://ubuntu.com/about/release-cycle
• Red Hat, Enterprise Linux life cycle, read 9 October 2026. https://access.redhat.com/support/policy/updates/errata
• Microsoft, Fixed Lifecycle Policy (page metadata dated 8 April 2022, updated 21 February 2023), read 9 October 2026. https://learn.microsoft.com/en-us/lifecycle/policies/fixed