Introduction
Ideally, you want to install updates fixing security issues with top priority, then move on to everything else. But how can you know that when you're managing a fleet of dozens of sites with hundreds of extensions and possibly with several different versions of Joomla, WordPress, and each extension?
What we need is threat intelligence, i.e. a machine-readable list of vulnerabilities and the software versions they affect for Joomla and WordPress, both for the core CMS and its extensions / themes / plugins.
The thing is, there is no such published list – unless you're willing to pay a lot to third party services such as WPScan and PatchStack (still, I couldn't find anything free or commercial for Joomla). This won't do, so we'll have to implement our own.
Concept
There are several sources of security information for core CMS and CMS-specific software. Some sources are machine-readable, some have RSS / Atom feeds to human-readable text, some are just blogs. We can have script which uses generative AI to parse that information and produce machine-readable records which include the following information:
- CMS type (
joomla, wordpress)
- Target type (
core, extension, theme, plugin)
- Selector (nothing for
core, extension slug for extension, theme, plugin)
- Minimum vulnerable version (NULL if unknown; implies all previous versions are vulnerable)
- Fixed version (NULL if the security issue isn't fixed, e.g. when it's on an EOL or discontinued product)
- Date added to the database
- URL with more information (if available)
This list could be served from a central location (our getpanopticon.com CDN), and we could also make it configurable so that someone could self-host this solution.
Data sources
Important notes:
Joomla VEL (rows 3 and 4): The old feeds.joomla.org RSS is dead. The current feed is JSON only (extensions.joomla.org/vulnerable-extensions/json-feed). The AI parser will need to consume JSON, not XML. This is actually better for structured data extraction anyway.
Wordfence Intelligence (row 8): This is the best single source for WordPress. The production API endpoint returns a full JSON dump of all known WordPress vulnerabilities with machine-readable fields including affected version ranges, patched versions, CVSS scores, CVE IDs, and affected software slugs. No RSS needed — it's already structured. Free, no auth required.
WPScan API (row 12): Requires a free account/token but gives 25 req/day on the free tier. Useful for querying specific plugin slugs. The enterprise bulk JSON download requires a paid plan. We cannot add it for now, and even if we do it will only be optional and never enabled on the centralized source to avoid any legal issues.
Patchstack (row 9): No free public feed. They have a paid threat intelligence API. However, their blog (row 10) covers major vulnerabilities with narrative write-ups. Similar to WPScan, we cannot add the paid threat intelligence API. We can, however, add the blog as it's public information.
NVD (row 16): They retired the RSS feeds in 2023 and moved to a JSON API. CVEdetails is a much more practical aggregator for our use case.
Practical recommendation: For WordPress, the Wordfence Intelligence production feed is the gold mine — it's already structured JSON with exactly the kind of data we want to output. For Joomla, the Security Centre RSS + VEL JSON feed together give us good coverage. Everything else (Wordfence blog, Sucuri, Patchstack articles) is unstructured prose that needs the AI parsing layer.
This is actually a good thing as it allows us a lot of flexibility. Our aggregator can have two tiers.
Tier 1 is machine readable sources and it's always enabled. At the bare minimum, it should give us excellent coverage across both CMS for both the core CMS products and the third party software running under them.
Tier 2 is optional, parsing blogs and other prose sources with an AI service. Enabling this requires connecting our aggregator to an AI service using an OpenAI, Anthropic, or Ollama API endpoint. Until I run this for real, I am not sure how useful it is.
The service would need to provide a way to easily get all the information we need. To do this, we need to produce a number of JSON files per CMS.
all.json contains every single vulnerability known for this CMS. This is useful for seeding the vulnerability database in each Panopticon installation.latest.json contains the latest 100 vulnerabilities for each CMS. This is the file which will be regularly retrieved by each (already seeded) Panopticon installation to update its database.- Monthly archive, e.g.
202605.json for May 2026. All vulnerabilities added to the database during that month. This will allow re-seeding the database if we discover that the latest vulnerability known to us is more than a month old. The idea is that we get the monthly archives from the month corresponding to the date of the last vulnerability added to the database, up to the current month.
Integration in Panopticon
Main page (Sites Overview): If a CMS update contains security fixes, mark it with an exclamation triangle.
Main page (Sites Overview): If any extension updates contain security fixes, mark the number of extension updates with an exclamation triangle.
Site information page: If the core CMS or any installed extensions have security issues display a warning alert at the top of the page notifying the user of the fact.
Site information page: If a CMS update contains security fixes, mark it with an exclamation triangle.
Site information page: If an extension update contains security fixes, mark it with an exclamation triangle.
Extension Updates page: If an extension update contains security fixes, mark it with an exclamation triangle.
Extension Updates page: Filter by Security with the options being "Known Vulnerabilities" and "No Security Fixes"
Core Updates page: If an CMS update contains security fixes, mark it with an exclamation triangle.
Core Updates page: Filter by Security with the options being "Known Vulnerabilities" and "No Security Fixes"
Site Reports page: When a discovered CMS or extension update has known security issues explicitly mark it as "Security update" (versus just "update" for everything else) and mark it with an exclamation mark.
Scheduled Update Summary email: if a CMS or extension update has known security issues explicitly mark it as "Security update" (versus just "update" for everything else) and mark it with an exclamation mark.
Introduction
Ideally, you want to install updates fixing security issues with top priority, then move on to everything else. But how can you know that when you're managing a fleet of dozens of sites with hundreds of extensions and possibly with several different versions of Joomla, WordPress, and each extension?
What we need is threat intelligence, i.e. a machine-readable list of vulnerabilities and the software versions they affect for Joomla and WordPress, both for the core CMS and its extensions / themes / plugins.
The thing is, there is no such published list – unless you're willing to pay a lot to third party services such as WPScan and PatchStack (still, I couldn't find anything free or commercial for Joomla). This won't do, so we'll have to implement our own.
Concept
There are several sources of security information for core CMS and CMS-specific software. Some sources are machine-readable, some have RSS / Atom feeds to human-readable text, some are just blogs. We can have script which uses generative AI to parse that information and produce machine-readable records which include the following information:
joomla,wordpress)core,extension,theme,plugin)core, extension slug forextension,theme,plugin)This list could be served from a central location (our getpanopticon.com CDN), and we could also make it configurable so that someone could self-host this solution.
Data sources
Important notes:
Joomla VEL (rows 3 and 4): The old feeds.joomla.org RSS is dead. The current feed is JSON only (extensions.joomla.org/vulnerable-extensions/json-feed). The AI parser will need to consume JSON, not XML. This is actually better for structured data extraction anyway.
Wordfence Intelligence (row 8): This is the best single source for WordPress. The production API endpoint returns a full JSON dump of all known WordPress vulnerabilities with machine-readable fields including affected version ranges, patched versions, CVSS scores, CVE IDs, and affected software slugs. No RSS needed — it's already structured. Free, no auth required.
WPScan API (row 12): Requires a free account/token but gives 25 req/day on the free tier. Useful for querying specific plugin slugs. The enterprise bulk JSON download requires a paid plan. We cannot add it for now, and even if we do it will only be optional and never enabled on the centralized source to avoid any legal issues.
Patchstack (row 9): No free public feed. They have a paid threat intelligence API. However, their blog (row 10) covers major vulnerabilities with narrative write-ups. Similar to WPScan, we cannot add the paid threat intelligence API. We can, however, add the blog as it's public information.
NVD (row 16): They retired the RSS feeds in 2023 and moved to a JSON API. CVEdetails is a much more practical aggregator for our use case.
Practical recommendation: For WordPress, the Wordfence Intelligence production feed is the gold mine — it's already structured JSON with exactly the kind of data we want to output. For Joomla, the Security Centre RSS + VEL JSON feed together give us good coverage. Everything else (Wordfence blog, Sucuri, Patchstack articles) is unstructured prose that needs the AI parsing layer.
This is actually a good thing as it allows us a lot of flexibility. Our aggregator can have two tiers.
Tier 1 is machine readable sources and it's always enabled. At the bare minimum, it should give us excellent coverage across both CMS for both the core CMS products and the third party software running under them.
Tier 2 is optional, parsing blogs and other prose sources with an AI service. Enabling this requires connecting our aggregator to an AI service using an OpenAI, Anthropic, or Ollama API endpoint. Until I run this for real, I am not sure how useful it is.
The service would need to provide a way to easily get all the information we need. To do this, we need to produce a number of JSON files per CMS.
all.jsoncontains every single vulnerability known for this CMS. This is useful for seeding the vulnerability database in each Panopticon installation.latest.jsoncontains the latest 100 vulnerabilities for each CMS. This is the file which will be regularly retrieved by each (already seeded) Panopticon installation to update its database.202605.jsonfor May 2026. All vulnerabilities added to the database during that month. This will allow re-seeding the database if we discover that the latest vulnerability known to us is more than a month old. The idea is that we get the monthly archives from the month corresponding to the date of the last vulnerability added to the database, up to the current month.Integration in Panopticon
Main page (Sites Overview): If a CMS update contains security fixes, mark it with an exclamation triangle.
Main page (Sites Overview): If any extension updates contain security fixes, mark the number of extension updates with an exclamation triangle.
Site information page: If the core CMS or any installed extensions have security issues display a warning alert at the top of the page notifying the user of the fact.
Site information page: If a CMS update contains security fixes, mark it with an exclamation triangle.
Site information page: If an extension update contains security fixes, mark it with an exclamation triangle.
Extension Updates page: If an extension update contains security fixes, mark it with an exclamation triangle.
Extension Updates page: Filter by Security with the options being "Known Vulnerabilities" and "No Security Fixes"
Core Updates page: If an CMS update contains security fixes, mark it with an exclamation triangle.
Core Updates page: Filter by Security with the options being "Known Vulnerabilities" and "No Security Fixes"
Site Reports page: When a discovered CMS or extension update has known security issues explicitly mark it as "Security update" (versus just "update" for everything else) and mark it with an exclamation mark.
Scheduled Update Summary email: if a CMS or extension update has known security issues explicitly mark it as "Security update" (versus just "update" for everything else) and mark it with an exclamation mark.