Product updates

When an alert has more new flags than fit in one email, it now shows the most severe ones first instead of the oldest. The rest are summarised with a link to your dashboard, rather than carried over into the next email.

When the advisory for an older vulnerability was republished or updated, it could be flagged to you as if it were new, sometimes many at once. An older vulnerability now only reaches you as new if it has just been added to StackFlag, in which case the alert says so, or if it has just been found to be exploited. The old flags this produced over the past two days have been removed.

If more than one of your alerts covers the same stack, each one now reliably receives every flag. Previously an alert could miss flags another alert had already sent.

Vulnerability pages now load in a fraction of a second, where some took several seconds.

The facts panel is simpler to read. Each section leads with one figure, and the detail - which scores make up the severity, and what the chance-of-attack figure means - sits behind an information icon. Each part of the fix-by deadline is marked, so you can see at a glance what is driving it.

Every vulnerability page now gives a fix-by deadline: one for software reachable from the internet and one for internal systems. Deadlines follow the risk model CISA introduced for US federal agencies in 2026, which weighs whether a flaw is known to be exploited, whether attacks on it can be automated, and how much control an attacker gains, instead of relying on a severity score alone. We also now carry CISA's assessments for far more vulnerabilities, including older ones known to be exploited.

Tell us whether each stack is internet-facing or internal - one at a time, or several at once from your stack list - and your flags show the one deadline that applies.

Alerts can now list the most urgent flags first across all your stacks, or send only flags due within 3, 14 or 60 days. Stacks set to alert you on updates also tell you when a deadline gets shorter. Our new fix-by deadlines page explains how it all works.

Many older vulnerabilities were missing from StackFlag because of a problem storing some records from one of our sources. They have now been added, so searching for an older CVE, or checking what has affected your software over the years, is far more complete - going back to 1999.

If an older vulnerability reaches StackFlag for the first time and matches one of your stacks, the alert now says it is not a new disclosure and shows when it was first published, rather than presenting it as news. Filling in the missing history did not send you any alerts.

Alert emails now group your flags under the stack that found them, and under a single severity heading rather than repeating the same score against every line. A run of equally severe findings reads as one block, so you can take in a long alert at a glance and skip a whole group at a time.

Each finding sits on one line with its name, identifiers and dates, and the descriptions have gone - the detail is a click away on the vulnerability page. Both dates are now labelled and written the same way round everywhere, so it is clear which is the publication date and which is the day it reached you.

The most urgent stack leads the email, and where two are equally severe the one with more findings comes first.

Filter your flags by severity, known-exploited status and period, and choose how many to show per page. Filters now apply across all your flags rather than just the page you are looking at, so the counts and paging match what you filtered, and you can bookmark or share a filtered view.

Triage has moved to its own page. Vulnerability search and daily pages also let you choose a page size.

Feed alerts can be given a new URL if you lose the old one, and now show when a reader last fetched them.

Sorting search results by severity or date now works as expected.

Alert emails now show when each issue was flagged to you, so you can tell at a glance whether you have seen it before. Identifiers no longer repeat, and each issue shows its CVE first.

We rewrote a large number of vulnerability titles and summaries that described the wrong software. Withdrawn and duplicate advisories no longer carry a summary at all, so they read as what they are.

We also fixed a problem that had stopped one of our sources updating, so advisories from it are flowing again.

As well as email, an alert can now give you a private feed URL - add it to any feed reader that supports RSS, Atom or JSON Feed. Each alert has its own URL and covers whichever stacks or tags you choose, so you can share one client's feed without sharing anything else.

The URL is shown once when you create the alert. Delete the alert to revoke it.

Our privacy policy now sets out exactly what is sent for AI processing and what is not. Vulnerability summaries are generated from the advisory text that is already public. The stack wizard sends the description you type, so the policy now says so plainly and reminds you not to include hostnames or credentials - and you can always skip the wizard and add what you monitor by hand.

It also documents that our AI requests use Zero Data Retention, which limits processing to providers contractually barred from storing prompts or using them for training.

A new Improve page on your stack list points out stacks worth a second look: ones that used to flag and no longer match anything, ones where advisories publish the software under a different name, and ones set to a severity that is no longer offered. You can apply a suggested fix, edit the stack, or dismiss the suggestion for good.

Stack conflicts are now aware of tags: two stacks tracking the same software for different clients are no longer reported as a mistake, and the tags are shown so you can see why both exist.

The wizard now creates a working alert for the stacks it sets up. Previously it was possible to finish the wizard, choose how often to be emailed, and never receive anything.

It no longer creates two stacks that do exactly the same thing: describing both zabbix-agent and zabbix-proxy used to produce two identical stacks and an immediate conflict. Where one stack would match everything another does, the wizard says so and lets you keep both if that is what you want.

Where the name you use differs from the name advisories publish under - postgres for PostgreSQL, k8s for Kubernetes, or a component like elastic-agent belonging to Elastic - the wizard offers the alternative and shows how many more vulnerabilities it would match.

Tag your stacks by client, site, department, or anything else that fits, then filter your stacks and flags by tag. Alerts can cover a tag rather than a list of stacks, so a new stack with that tag is picked up automatically. The wizard can tag everything it creates in one go.

Triage - marking flags read, acknowledged or dismissed - is now something you turn on for the stacks that need it, rather than every stack. Tags appear on your flags and in your alert emails, so you can tell at a glance which client a flag belongs to.

The severity levels you can alert on are now Extreme (9.5+), Critical (9+), High (7+), Medium (4+) and All. Extreme is the top of the critical range, where vulnerabilities known to be exploited in the wild are concentrated - they appear there about three times as often as in the rest of the critical band.

Low has been retired as an alerting level. It sat between Medium and All while adding almost nothing, and reading as a real choice when it was not. It is still shown as a severity on vulnerability pages.

The severity options are now identical wherever you set them - adding a stack, editing one, running the wizard, or changing several at once. They used to differ slightly, so the same choice could save a different setting depending on where you made it.

Your stacks now show what they match, and the severity they filter on, in one consistent line - on your stack list, on your flags, and in the emails we send. The rule values are picked out so you can scan a list quickly.

Stacks are named automatically from what they match, so there is one less thing to fill in when you add one. Existing names you set yourself are kept.

Each tracking option in the stack wizard already showed how many vulnerabilities it would match. Every option now has a preview link too, so you can open those results in a new tab and see exactly what you would be monitoring before you commit.

Where the vendor recorded against a product differs from the name you used, the other options are offered too. Monitoring MySQL used to suggest the narrow "vendor:mysql AND product:mysql", which matches almost nothing; "vendor:oracle" is now offered alongside it, because that is the vendor most MySQL advisories are published under. Items we cannot find at all are flagged rather than quietly creating a monitor that can never alert, and where a broader term would work better we say so.

If the analysis fails or takes a while, the wizard now says so instead of reporting that nothing was found.

Vulnerability records now name the vendor behind 99.9% of affected packages, up from 94.4%. Packages from Linux distributions, and from the .NET, Elixir and Julia ecosystems, were often left without one. That matters if you monitor by vendor: a package with no vendor recorded could not match, so those alerts were being missed.

More vulnerabilities now show the vendor behind an affected package. Python packages and packages rebuilt by another distributor were often left without one, which meant monitors matching on a vendor could miss them.

A monitor that filters by severity now shows that filter everywhere it appears, not just on your stack page. Previously a monitor could be listed by its keyword alone, so a vulnerability it had correctly filtered out looked like one we had missed.

Vulnerability pages covering hundreds of products or versions now show the most relevant entries first, with the full list one click away. Those pages load faster and are much easier to scan.

A vulnerability that appears in more than one of our sources could be stored as several separate records, so monitoring it could alert you about the same vulnerability more than once. Sources are now matched together properly, so each vulnerability is recorded once and alerts once.

The vulnerabilities already split this way have now been merged, so the duplicates are gone.

Vulnerability pages show a plain-English name alongside every CWE weakness classification. Previously most of them appeared as a bare code with no explanation.

The "What to do" box no longer suggests a version number when a vulnerability affects many vendors and the underlying record does not actually name a fix. In those cases it now points you to the vendor advisories instead of guessing.

Alert emails also stop re-sending for older vulnerabilities when only background scoring data changed, and any alert that is an update to something you have already seen is now labelled as an update rather than as new.

Some advisories from feeds that publish little detail had summaries that described the wrong software. Every affected record has been rebuilt from the underlying advisory data, and the summaries now stay blank rather than guess when there is genuinely nothing to describe.

The "What to do" section now reads fix versions directly from the advisory record, so pages no longer say a fix is unavailable when the advisory names one. Where no fix version is published, the page says so plainly instead of implying none exists.

The vulnerability index and detail pages have a new fact-sheet layout: severity, exploitation status, affected software, and what to do are easier to scan at a glance.

Fixed slow page loads on your stack and alert pages, which could stall when several pages were open at once. The vulnerability index no longer shows outdated titles for very recently published CVEs, and logged-in visitors are always served their own view of a page.

Vulnerabilities listed in the CISA Known Exploited catalogue no longer show the date they were added to that catalogue as their publication date. Affected records now show their real publication date.

StackFlag now posts critical vulnerabilities to Bluesky as they are published, with a plain-English summary and a link to the full detail page. Follow along at the account linked in the footer.

Homepage and vulnerability index load faster. URLs with a trailing slash now redirect to the correct page instead of returning a not-found error.

Added a new feed covering advisories from all CVE numbering authorities, so vendor-assigned CVEs now appear the same day rather than waiting for them to reach other sources. Also fixed two feeds that had been quietly collecting less than they should, which means noticeably more complete coverage.

Added the groundwork for a weekly summary of vulnerability activity: headline counts, week-on-week trend, newly exploited entries, and the most significant items of the week.

Simplified the site's colour scheme so that colour consistently signals severity and nothing else. The wordmark has a new two-tone treatment.

Improved page titles, descriptions, and structured data across the site, so vulnerability pages surface more accurately in search results.

Backfilled vulnerability records going back to 1999, so searches and monitors now cover the full published history rather than recent years only.

Feedback submissions now have threading and acknowledgement. This public changelog now appears on the FAQ page.

Updated copy and legals.

Significantly reduced database queries during digest notifications. Poll cycle optimised for large numbers of trackers.

Flag detail and vulnerability detail are now a single page, so everything about a vulnerability you are monitoring is in one place.

Your stack list now supports sorting, filtering, pagination, and bulk assignment, with vulnerability and severity counts per entry. Navigation labels are clearer throughout.

CSRF, CSP and other security improvements.