European CSIRTs: Who Publishes the Best Advisories? Our Top 3

After the php2shell vulnerabilities were published, we found that ENISA lists, in its GitHub repository, links to the advisories that European CSIRTs publish on major vulnerabilities and incidents.

We quickly saw that these advisories are far from equal. Some give the fixed versions, the workaround commands and detection rules. Others just say "apply the patches".

So we set out to measure that gap at scale, with a practical question in mind: when you gather, for each vulnerability, the information needed for remediation, which advisories are worth aggregating, and how do you decide when they contradict each other? We evaluated every national advisory referenced by the European CSIRTs Network for 51 major vulnerabilities and incidents, from Log4Shell (December 2021) to php2shell (October 2026).

The repository lists 51 events and 604 links to advisories. It is an ideal basis for comparing CSIRTs: same vulnerability, same period, different authors.

Our method

Each page was scored on 7 criteria, from 0 to 3 each, for a total out of 21:

Criterion	What we expect at the top level (3)
Fix	Fixed versions per branch, plus end-of-life branches, backports or products that embed the component
Workarounds	Exact values or commands, where to apply them, and their limits
Detection	Indicators of compromise, rules (Sigma, YARA, Suricata…) or a detection script
Exploitation	A dated timeline: PoC, attempts, confirmed exploitation
Technical	Root cause and the conditions that make a system exploitable
Own contribution	Information missing from the vendor's advisory: national telemetry, tooling, original analysis
Updates	Several dated revisions that follow how the event unfolds

We first built the scoring on php2shell, then extended it to the other vulnerabilities and incidents.

In a second step, we looked for contradictions between advisories, such as different fixed versions, diverging exploitation statuses, or workarounds deemed effective by some and insufficient by others.

A few important rules:

• Only pages still online were evaluated. A dead link or a site that refuses automated access counts as "not assessable", not as a poor advisory.
• When a CSIRT published several pages on the same event (one advisory per CVE, or an alert followed by an article), we kept the best one.
• Alerts, advisories and news articles are scored the same way, because every CSIRT has its own vocabulary.
• When a repository link is dead but the same advisory lives at a new address, we evaluated the new address. This applies to 11 advisories from the Dutch NCSC, which moved to a new site.
• Own contribution is measured against the vendor's advisory. For each event, we retrieved the advisory from the vendor (or from the project concerned, such as PHP or Apache). Whatever it already contains (fixed versions, workarounds, technical explanations) does not count as a CSIRT contribution, even when translated or reworded. Limitation: we read these vendor advisories in their current version. If a vendor completed its page afterwards, the CSIRT that gave the information first no longer gets credit for it.

In total, 464 advisories could be evaluated. AI helped us handle that volume. It extracted the useful information from each page (fixed versions, workarounds, exploitation status and date), then let us sort it and compare the advisories with each other.

The ranking

Each CSIRT is scored on the average of its best advisory per event. To avoid unstable averages, this table only includes the 17 CSIRTs evaluated on at least 10 events (major vulnerabilities or incidents).

#	CSIRT	Country	Events evaluated	Score /21
1	CERT-Bund (BSI)	Germany	33	12.9
2	CERT-FR (ANSSI)	France	37	11.2
3	CIRCL	Luxembourg	18	11.1
4	NCSC-NL	Netherlands	29	10.6
5	CERT-EU	EU institutions	27	10.4
6	CSIRT Italia (ACN)	Italy	19	10.4
7	SK-CERT	Slovakia	14	10.3
8	CERT.be	Belgium	12	10.2
9	CERT-SE	Sweden	31	9.8
10	SI-CERT	Slovenia	14	9.7
11	CERT.at	Austria	30	9.6
12	NCSC-FI	Finland	30	9.6
13	NCSC-IE	Ireland	38	9.0
14	CERT.hr	Croatia	13	8.2
15	INCIBE-CERT	Spain	38	8.1
16	CCN-CERT	Spain	22	7.8
17	NCSC-HU	Hungary	11	6.7

Averages range almost from single to double (6.7 to 12.9). Behind CERT-Bund, the next four sit within one point of each other, and none dominates on every criterion.

Germany's CERT-Bund clearly stands out. Its advisories combine fixed versions per product, detailed workarounds, indicators of compromise and a dated exploitation timeline. It is the only CSIRT in the table to average above 2/3 on exploitation.

CERT-FR comes 2nd and stands out for follow-up. It regularly updates its advisories as the event unfolds. It is also one of the most consistent (37 events evaluated out of 39 referenced).

Luxembourg's CIRCL, 3rd by a tenth of a point, is one of the strongest on detection and own contribution.

CERT-EU gets the best technical score of the panel, but says little about exploitation.

These averages hide fine advisories everywhere. The best individual advisories (20/21) are those of SK-CERT and Spain's CCN-CERT on Log4Shell. CCN-CERT published six dated revisions, with scanners, YARA rules and indicator feeds. Yet its average is low: quality depends heavily on the event.

The other 11 CSIRTs had fewer than 10 events evaluated: their averages are too fragile to rank.

Case study: php2shell

php2shell is the most recent event in the repository (21 October 2026): critical vulnerabilities in PHP (CVE-2026-109618 and CVE-2026-109619, then a third one, CVE-2026-115560), fixed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.

The CNW repository lists 26 CSIRTs, 22 of them with an assessable advisory.

CSIRT	Score /21	Advisory
CERT-Bund (BSI)	19	Link
CSIRT Italia (ACN)	18	Link
NCSC-HU	18	Link
NCSC-FI	17	Link
CIRCL	17	Link
CERT-EU	16	Link
INCIBE-CERT	16	Link
CERT-FR	15	Link
NCSC-NL	14	Link
CERT Polska	13	Link
CERT.LV	12	Link
SI-CERT	12	Link
SK-CERT	11	Link
CERT.hr	10	Link
NCSC-IE	10	Link
CERT.at	9	Link
CERT-SE	9	Link
CERT-EE (RIA)	8	Link
CERT.bg	8	Link
CFCS / SAMSIK	6	Link
CERT ZSIS / NCSC.hr	6	Link
CCN-CERT	5	Link

On the same event, scores range from 5/21 to 19/21.

The best advisory, CERT-Bund's, gives the fixed versions, including the backported fixes for end-of-life versions, and detailed workarounds with their limits. It points out that updating the application is not enough: PHP itself must be patched, Docker images included. It lists the network appliances affected or not (F5, QNAP, Synology), refutes rumors of incomplete patches and suggests leads for hunting compromise. It went through three versions in two days.

Close behind, at 18/21, the advisory from Italy's ACN gives fixed versions per branch, explains the root cause and tracks the exploitation status, with several updates up to 28 October.

Detection makes the difference. Hungary's NCSC, last in the overall ranking, also scores 18/21. It is the only advisory to provide ready-to-use detection rules, taken from the security vendor Lorikeet Security:

• an auditd rule that flags shells launched by the web server account and writes to /tmp and /dev/shm;
• a Falco rule for containers and Kubernetes, which raises a critical alert when a PHP-FPM or Apache process spawns a shell;
• a Suricata/Snort signature that spots repeated multipart POST requests with an oversized Content-Length, aimed at the Zend engine's memory limits (CVE-2026-109618).

The advisory adds leads for log hunting: series of empty HTTP 500 responses, PHP-FPM processes killed by SIGSEGV or SIGABRT, outbound connections from the www-data or apache accounts, and the User-Agents of public proof-of-concept tools (php2shell-poc, php2shell-verify/1.0). It also lists suspicious processes to watch on Linux and on Windows/IIS (w3wp.exe spawning cmd.exe or powershell.exe, for example).

Conversely, 10 advisories out of 22 say nothing about detection.

The 3 advisories with the lowest scores give no fixed version, while most of the others list them. Some advisories even still recommend, as of this writing, taking systems offline until an update is available.

The event also concentrates several contradictions, which show how misleading a single advisory can be:

• Exploitation. On 21 October, most advisories reported a public PoC, and three stated the flaw was not exploited. CERT-Bund reported attempts from 22 October, as did the advisories updated on 26 October; those of 28 and 30 October reported active exploitation. At the time of the study, on 1 November 2026, three CSIRTs still said "not exploited": their pages, published on 21 October, had not been updated since.
• The memory_limit workaround. Most recommend memory_limit=-1, enforced at the administrator level. CERT Polska offers 128M or more as a fallback, whereas INCIBE-CERT states that 128M does not disable the vulnerability. PHP's advisory sides with INCIBE-CERT.
• Where to set session.upload_progress.enabled=0. Five advisories, including CERT-Bund's, specify that it must be done in php.ini or the server configuration, not in .user.ini. CERT-EE, on the contrary, says .user.ini is fine. PHP's advisory sides with the first five.
• End-of-life versions. Some CSIRTs report backported fixes (as source code) for PHP 7.4, 8.0 and 8.1. Others state that no fix will ever exist and that these systems must be isolated or retired.

An administrator who read only one of these advisories could therefore believe the flaw was not exploited, apply an ineffective workaround, or decommission a server they could have patched.

225 contradictions between CSIRTs

Comparing the advisories turned up 225 contradictions across 46 events, 36 of them judged high-impact for security teams.

Topic	Contradictions
Fixed versions	70
Exploitation status	63
Workarounds	37
Affected scope	16
Severity, impact	7
Other	32

Log4Shell is the most telling example. Depending on the CSIRT you read, the "fixed" version was 2.15.0, 2.17.0 or 2.17.1. The formatMsgNoLookups=true setting was presented as a valid workaround by some advisories (CCN-CERT, CIRCL, GR-CSIRT, CSIRT-CY, INCIBE-CERT) and as insufficient by others (CERT-FR, CERT.at, CERT.hr, SI-CERT, SK-CERT, CERT ZSIS / NCSC.hr), because it does not protect against CVE-2021-45046.

Often, nobody is wrong at the time of writing. The contradiction comes from an advisory published early and never updated. For example, on the 2022 Exchange ProxyNotShell flaws (CVE-2022-41040 and CVE-2022-41082), some advisories offer only workarounds (CIRCL, NCSC-IE, GovCERT.CZ, INCIBE-CERT), and one even states that no patch exists (CERT.at), although Microsoft has since released the patches.

For a security team, an advisory read on its own can be incomplete. Check the date of the last update and cross-check sources.

Key takeaways

1. No advisory is complete. Even the best-rated CSIRT tops out at 12.9/21 on average. To remediate fast, you need to cross-check several sources.
2. Detection is the weak link. It is the lowest-scoring criterion across all advisories: on php2shell, 10 advisories out of 22 say nothing about it. CSIRTs that regularly provide it, such as CERT-Bund or CIRCL, are worth following even outside your own country.
3. The date matters as much as the content. Many contradictions come from frozen pages. An advisory not updated since the patch should be read with caution.
4. Reading beyond your national CSIRT pays off, because advisories from other countries often bring details your local one lacks.

That is the question behind this analysis, and the problem SYRN sets out to solve: gathering, for each vulnerability, the information scattered across vendors, CSIRTs and intelligence sources, and surfacing the most recent rather than the first published.

Limitations of the study

• Online pages only. Many links from 2021 to 2023 are dead. CSIRTs that redesigned their site are therefore less well covered on older events.
• Automated scoring. The rubric is fixed and was validated on one hand-scored event, but a language model can get a given page wrong.
• Small samples. A CSIRT evaluated on 2 or 3 events has an unreliable average; that is why the ranking only includes CSIRTs evaluated on at least 10 events.
• Usefulness for remediation, not overall quality. A short advisory published very early to raise the alarm may be exactly what was needed at the time, even if it scores low here.
• Different national formats. Some CSIRTs separate emergency alerts, published early with few details, from more technical advisories published later: CERT-FR, for instance, distinguishes its "alertes" from its "avis". We kept each CSIRT's best page, but when a CSIRT only publishes an alert, it is compared with full advisories. This penalizes CSIRTs whose model favors speed.
• The CNW repository is not exhaustive. A CSIRT may have published an advisory that the repository does not reference.