The threat of zero-day vulnerabilities in business
Critical vulnerabilities in widely used software regularly remind us of an uncomfortable reality: no system is immune. The Log4Shell vulnerability (CVE-2021-44228), discovered at the end of 2021 in the Java library Log4j, remains the emblematic example. Present in countless applications (often without their operators even knowing, because it was embedded as a dependency), it exposed a huge number of servers within days and triggered a worldwide mobilisation of security teams.
What makes these flaws so dangerous is not only their technical severity but the window of vulnerability: between public disclosure and the patch being applied across the whole estate, attackers have precious time. They scan the internet continuously, and a known unpatched flaw is sometimes exploited within hours.
A widening gap between attackers and defenders
Figures for 2025-2026 show that this gap is getting worse year after year, and not in companies' favour.
Average time between a critical patch and active exploitation (2020): 45 days
Average time between a critical patch and active exploitation (2025): under 15 days
Average time to exploitation after a public proof of concept: 4.5 days
Average time an organisation takes to patch a critical vulnerability: 60 days
Time recommended by NIST and by national agencies such as France's ANSSI for critical vulnerabilities: 30 days
Zero-day vulnerabilities exploited worldwide in 2025: 90 (compared with 78 in 2024)
The most worrying figure is the gap between exploitation and patching: attackers exploit a critical flaw in 4.5 days on average, while the average organisation takes 60 days to fix it, a factor of more than 13. This window of exposure, widely documented, is exactly what allowed Log4Shell to do so much damage in 2021, and the phenomenon has worsened since.
What made Log4Shell so particularly dangerous
Three combined factors explain why Log4Shell became the absolute reference for a critical vulnerability. First, ease of exploitation: a simple character string sent to a vulnerable application was enough to trigger arbitrary code execution, without advanced technical skills. Second, the breadth of distribution: Log4j being an extremely widespread logging library, it was embedded as an indirect dependency in a considerable number of applications, often without IT teams being aware of it. Finally, the difficulty of detection: unlike a flaw located in an identified piece of software, finding every occurrence of Log4j in an information system required an in-depth inventory of dependencies, a task few organisations knew how to carry out quickly in 2021.
The concrete risks
Data exfiltration: an unpatched flaw can open access to sensitive information: customers, finances, intellectual property.
Ransomware: attackers use known vulnerabilities as an entry point to deploy ransomware and encrypt your data.
Business interruption: a compromised system can paralyse the whole of production, with downtime costs often far higher than those of prevention.
Pivoting: a compromised server sometimes serves as a springboard to attack your partners or customers, extending the damage beyond your own perimeter.
Good practice
Set up active security monitoring of the CVEs affecting the components of your estate. You can only fix the flaws you know about.
Know your estate: maintain an up-to-date inventory of software and its dependencies. The main difficulty with Log4Shell was precisely knowing where the library was present.
Establish a regular patching schedule with planned maintenance windows, and an emergency procedure for critical flaws outside the schedule. Aiming to fix critical vulnerabilities within 30 days, in line with NIST and national agency recommendations, already sharply reduces the risk compared with the market average.
Test patches in a pre-production environment before deployment, so that a patch does not break an application in production.
Have a documented and tested incident response plan, to react quickly and in a coordinated way on the day a flaw affects you directly.
Why SMEs take longer to patch
The average of 60 days observed across organisations is generally not a choice but the consequence of a lack of time or inventory: without a precise map of the estate, it is impossible to know quickly whether a vulnerable component is present, and where. That is exactly the trap Log4Shell revealed: the library was often integrated as an indirect dependency, invisible in a superficial inventory.
Where to start without drowning
Faced with the scale of the subject, a small organisation can feel helpless: there is no way to compete with the security teams of a large group. Yet the first step is within everyone's reach, and it is the most decisive. Before even talking about monitoring or patching, you need to know what you have. An up-to-date inventory of servers, applications and their dependencies is the prerequisite for everything else: you can neither fix nor even monitor a component whose presence you are unaware of.
That is exactly the trap Log4Shell revealed. The library was often embedded as an indirect dependency, invisible in a superficial inventory, and many companies spent days looking for where it was hiding while the attacks were starting. Mapping your estate, even roughly, turns disorganised panic on the day of an alert into a quick, targeted check.
Watch what is already being exploited
Not all flaws are equal, and trying to fix everything at once is the best way to prioritise nothing. The modern approach is to focus effort on vulnerabilities that are actually being exploited in the wild, not only on those deemed serious in theory. Public resources such as the Known Exploited Vulnerabilities (KEV) catalogue maintained by the US agency CISA list precisely the flaws attackers are using right now, which makes it possible to deal urgently with the ones that really matter.
For an SME, the point is not to build a sophisticated monitoring centre, but to subscribe to the right alerts and know how to react quickly when a flaw affecting its estate moves into that category. Better to fix without delay the few flaws that are really dangerous than to drown in an endless list of theoretical patches.
Anticipate rather than react in a hurry
The lesson of Log4Shell has lost none of its relevance, and the steady shrinking of the time to exploitation makes it even more urgent than in 2021: the next major flaw is only a matter of time. The organisations that cope best are not the lucky ones but those that have prepared the ground: an up-to-date inventory, active monitoring, a well-rehearsed patching process and a tested response plan. Security is a continuous process, not a state reached once and for all, as our SME security audit checklist explains in detail.
Structure your approach before the incident
Security against critical flaws does not rely on a miracle tool, but on a handful of reflexes maintained over time: knowing your estate, watching the right alerts, quickly fixing the flaws that are really exploited and knowing how to react in a coordinated way when the day comes. None of these building blocks is out of reach for an SME; it is their absence, more than the sophistication of attacks, that turns a known flaw into an incident.
We can help you structure this approach, remotely: inventory of exposed components, prioritisation of patches and lasting good habits. Do not wait for an incident to act. To go further, see our SME security audit checklist and our IT audit, or contact us.
Sources: Ayi Nedjimi Consultants, your CVEs are already exploited before your team has read them (in French) · I-Lead Consulting, patch management (in French)