Table of contents of the article:
It's not just a sequence of bugs: it's a paradigm shift
The real point isn't that vulnerabilities exist. Vulnerabilities have always existed. They always will. Complex software is imperfect by definition, especially when it lives for years, accumulating features, compatibilities, modules, layers, backward compatibility, and edge cases.
The difference today is speed.
Until a few years ago, turning a patch into an exploit required very specific skills. You needed to be able to read C and C++ carefully, understand assembler, understand the stack, the heap, memory corruption techniques, GDB, return-to-libc, ROP chains, ASLR bypass, shellcode, NOP sleds, read and write primitives, race conditions, use-after-free, double-free, integer overflows, path traversal, deserialization, and all that gray matter that for decades separated the simple "advisory reader" from the true exploit developer.
Today this border has not disappeared, but it has thinned dangerously.
LLMs don't automatically make anyone a top-tier security researcher. That would be a superficial and false narrative. But they greatly reduce the cost of preliminary analysis, understanding the diff, classifying the bug, generating hypotheses, and building proof-of-concepts. According to the Tom's Hardware article we're drawing inspiration from, language models can drastically reduce the time it takes to turn a patch into a working exploit, even calling into question the traditional 90-day disclosure window. Tom's Hardware Italia: Patches, exploits and AI.
That's the point: It is no longer necessary to analyze an entire codebase of millions of linesThe most effective and pragmatic method is often much more trivial: take the previous version, take the next version, do a diff, observe the changes, isolate the correct code, and from there try to understand which vulnerability has been closed.
In a pre-AI world, this process required time, expertise, and intuition. In a post-AI world, that work can be accelerated, parallelized, automated, refined, and repeated across hundreds of projects, releases, and patches.
There's no need to imagine secret, mythical models hidden in the laboratories of large companies or government agencies. All that's needed are commonly available models, assisted coding tools, automated agents, analysis pipelines, and adequate budgets. The distinction between attacker and defender thus becomes even more brutal: the defender must inventory, assess, test, patch, reboot, communicate, mitigate, and verify; the attacker must find a way in before this entire process is complete.
The chronology of a high-tension May
To understand the degree of concentration of the problem, it is useful to put the events in order.
Il April 28, 2026 The CVE-2026-41940 vulnerability has been revealed in cPanel/WHM. This flaw in the session management layer is particularly serious because it affects a widely used control panel in the hosting industry. cPanel stated that it released updates on April 28th and made fixes available within approximately 28 hours of the report being confirmed, covering supported versions and some select legacy versions. cPanel Security Update: CVE-2026-41940.
Il 29th April Enter Copy Fail, CVE-2026-31431, a vulnerability in the Linux kernel that allows local privilege escalation. The issue resides in the algif_aead cryptographic subsystem and involves interaction with splice(), page cache, and privileged binaries. The most worrying aspect isn't just the technical impact, but the exploit's portability: Tom's Hardware reported that the exploit code was public and worked on multiple major distributions, lowering the barrier to entry for potential attackers. https://xint.io/blog/copy-fail-linux-distributions
Il 5st May Apache HTTP Server 2.4.67 fix is released, which includes CVE-2026-23918: double-free and possible RCE in HTTP/2 handling. Apache explicitly states that this affects Apache HTTP Server 2.4.66 and recommends upgrading to 2.4.67. Apache HTTP Server 2.4 vulnerabilities.
Il 7st May Dirty Frag, CVE-2026-43284 and CVE-2026-43500, two LPE vulnerabilities in the Linux kernel, are disclosed. Ubuntu describes CVE-2026-43284 as an issue related to the handling of shared fragments in skbs and in-place decryption in ESP/IPsec, impacting local privilege escalation. Ubuntu Security: CVE-2026-43284.
Il 12st May The NGINX URL Rewrite Validation Bypass case is also being addressed, a logical vulnerability that impacts rewrite, normalization, and misalignment scenarios between access control and the actual resource accessed. For those managing reverse proxies, application gateways, and stacks with multiple backends, this is a class of problem that shouldn't be underestimated: often, updating a package isn't enough; architectural assumptions, location rules, proxy passes, rewrites, and validation also need to be reviewed. This article discusses the issue in detail. https://www.redhotcyber.com/post/un-bug-critico-per-18-anni-e-rimasto-nascosto-nelle-codice-di-nginx/
This is not a random sequence of small accidents. It's a barrage. And it's a barrage on essential components used by at least 90% of the machines exposed to the network with a web server service. At least 90%!
Apache, Linux, NGINX, cPanel: Why These Names Matter
When a vulnerability affects niche software, the problem can be limited. When it affects Apache HTTP Server, NGINX, the Linux kernel, or cPanel/WHM, the scale changes entirely.
Apache is still a mainstay of the web today. Even when not directly exposed as a frontend, it can be present behind reverse proxies, in legacy environments, enterprise applications, shared hosting, CMS, and LAMP stacks. A possible RCE in HTTP/2 is not a trivial matter. HTTP/2 is widely used, and handling frames, streams, and early resets is a complex area where a memory error can have significant consequences.
The Linux kernel is the common ground. It's under containers, under physical servers, under VPS, under cloud instances, under hypervisors in many scenarios, under appliances and distributions. A local privilege escalation isn't "less serious" just because it requires local access. In the real world, local access can come from a compromised account, a web shell, a compromised container, a hosting user, a CI/CD job, a vulnerable plugin, or a compromised CMS. Once inside, getting root means completely changing the perimeter of the incident.
NGINX is the web server and reverse proxy par excellence in many modern infrastructuresThe golden standard, often the first line of defense against PHP, Node.js, Python, Java applications, microservices, APIs, and admin panels. An access control bypass or logical path traversal using rewrites and normalization can transform a seemingly secure configuration into an alternative route to internal resources.
cPanel/WHM, finally, is one of the most popular panels in the hosting sector. An authentication bypass vulnerability in this context is particularly sensitive because it does not affect a single site, but potentially the administration of entire servers, accounts, DNS, mail, databases, and related services.
The combination of these four worlds tells a very simple story: The month of May 2026 touched almost everything a Linux system administrator and hosting provider needs to manage, and a combination of events of this magnitude had never been seen since 1994.
The systems engineer between a rock and a hard place
In the simplified narrative of cybersecurity, there are hackers on one side and developers on the other. Hackers find bugs, developers fix them. But in the middle, often forgotten, is the systems administrator.
The systems administrator is the one who receives the patch once the vulnerability is already public. He's the one who must determine whether the machine fleet is impacted. He's the one who must distinguish between vulnerable systems, non-vulnerable systems, mitigatable systems, systems requiring immediate reboot, systems requiring a predetermined reboot window, legacy systems, systems with application dependencies, servers with critical uptime, production environments, staging environments, and environments that have been forgotten for years but "can't be shut down."
The systems administrator is the one who has to explain to the customer why the reboot is necessary. They're the ones who have to choose between the risk of downtime and the risk of compromise. They're the ones who have to read advisories, changelogs, CVEs, mailing lists, issue trackers, distribution packages, backports, vendor-specific patches, compatibility notes, scanner false positives, and incomplete reports.
And today it must do so while on the other side attackers, or even simply the most aggressive researchers, can use AI to greatly compress analysis times.
This is the part that is often misunderstood by those who observe security from the outside. The problem is not "updating." The problem is update well, quickly, without breaking production, without losing data, without causing regressions, without leaving secondary systems out, without generating panic and without turning a patch day into an operational disaster.
Why we declined quotes and onboarding
Recently, at Managed Server Srl, we made a decision that wasn't pleasant, but we believe was the right one: we diligently declined sending urgent quotes and onboarding new customers, giving top priority to problem resolution, patching, testing, and developing internal tools to speed up future activities.
Some potential clients have taken this decision very, very, VERY BADLY. We understand. We understand, and we apologize. Those who request an urgent quote often have an urgent need of their own. They may have a stalled project, a slow website, unstable infrastructure, an e-commerce site to migrate, a sales deadline, or a technical issue to resolve.
Other times, it's just a whim, simply wanting a quote within 24-48 hours, because ultimately it's the customer, and the customer, as we know, is "always right." In the systems industry, however, we're not an appliance store, or a delicatessen that sells its products at a high price per kilo, but rather an emergency room, with a triage system, where customers with serious problems have absolute priority over those who are simply having a whim and want to skip serious cases simply because they're "paying customers." Unfortunately, there are some behind-the-scenes details, which we'll explain in this post, which is intended not so much as an excuse but rather an account of what happened, and what will likely happen again.
We're certainly sorry. We're sorry for the new potential client, because not receiving a sales response within the desired timeframe can be frustrating. We're also sorry for the loss of revenue, because every unprocessed quote can mean a missed opportunity.
Ma the safety and business continuity of existing customers come first.
A hosting and systems engineering company doesn't simply sell disk space, CPU, RAM, or traffic. It sells technical support, responsibility, attention, expertise, and responsiveness. When the global landscape presents serious vulnerabilities in critical components, the priority cannot be opening new business deals while existing customers wait for patches, analysis, mitigations, and verification.
We believe we have acted diligently to protect our business and, above all, the business of our existing customers. A new customer can wait for a quote. A vulnerable server exposed in production cannot.
Internal tools, automation and fast patching
One of the side effects of this wave has been the acceleration of the development of internal tools for rapid patching, inventory, and verification.
This is a crucial point. In a world where exploits can emerge within hours of a patch, the response cannot be relied upon solely by the memory of a single system administrator or by manual procedures repeated server by server.
We need tools that let us quickly know where a given version of Apache is installed, where HTTP/2 is enabled, which servers are using NGINX with complex rewrite rules, which kernels are running, which machines require a hard reboot after an upgrade, which cPanel versions are still vulnerable, which nodes are covered by vendor patches, and which require temporary mitigations.
We need a map. We need automation. We need the ability to perform mass checks without losing quality. We also need the ability to produce reports, because security isn't just "we've updated," but “We have updated, verified, documented and we know what remains to be done”.
For example, we have extended our Firewall Management, Monitoring and Inventory Tool with a multiple SSH execution system to be able to immediately fingerprint systems and proceed with mass patch application.
The basic concept was to make a greater initial effort to have what we wanted tailored to then save time every time similar situations might arise in which patching needs to be done not in days but in a couple of hours across the entire machine fleet, whether hundreds, thousands, or tens of thousands of systems and nodes.
In short, AI can be used by attackers, but it must also be used by defenders. Not to replace technical judgment, but to accelerate analysis, correlation, changelog reading, advisory summary, checklist generation, configuration control, and support for repetitive tasks. The key is not to blindly delegate, but to use automation as an operational exoskeleton.
The problem with open source release cycles
This brings us to the most uncomfortable topic: is the traditional open source release model still adequate in a world where AI can quickly turn a patch into an exploit?
The question is provocative, but it can no longer be ignored.
Open source is based on transparency. The code is public, the patches are public, the diffs are public. This has enormous advantages: auditability, trust, collaboration, independent verification, the possibility of backporting, community control, and the absence of black boxes. But the moment a security patch is released, even the attacker sees exactly what has changed.
Previously, this transparency still required a high level of expertise to be turned into a weapon. Today, AI lowers the threshold. A small diff is a perfect context for an LLM: a few lines changed, related functions, commit messages, tests added, fixes introduced. It's much easier to analyze a hundred-line delta than a codebase of millions of lines.
This raises the dilemma: does it still make sense to simultaneously release binary patches, source code, and enough details to quickly reconstruct the vulnerability? Or, for certain classes of critical bugs, would different windows be needed, coordinated distribution to vendors, a binary release first, and a deferred source release?
The answer is not simple.
Delaying the source may temporarily protect end users, but it creates tension with open source principles, complicates independent verification, penalizes distributions and maintainers, introduces trust issues, and risks creating asymmetries between those who have early access and those who do not.
Releasing everything at once, however, in some cases means giving attackers a map almost immediately.
There is no perfect solution. But denying the problem would be irresponsible.
Does the 90-day disclosure still make sense?
For years, the 90-day disclosure window was considered a reasonable compromise: long enough to allow vendors to fix, short enough to prevent vulnerabilities from remaining secret indefinitely.
But if AI allows patches and advisories to be transformed into working exploits in a very short time, the problem shifts. It's no longer enough to ask "how much time did the vendor have to fix?" You need to ask "how much time does the defender have to deploy the fix before the exploit becomes widely operational?"
This second window is much narrower.
In real-world environments, especially hosting and managed infrastructure, applying patches isn't just a matter of pushing a button. You need to consider compatibility, load, maintenance windows, reboots, clusters, HA, rollbacks, backups, application testing, customer communication, and post-patch monitoring.
If the window between a public patch and a working exploit shrinks to just a few hours, the operating model must change. It's no longer enough to be "fast enough." You have to be prepared first.
Security is no longer a department: it's a permanent posture
The lesson of this May is clear: security can't be treated like an event. It can't be a ticket opened when the CVE comes out. It can't be the panic of a Friday night or a holiday. It must be a permanent posture.
This means up-to-date inventory, tested patching procedures, automation, monitoring, verified backups, rollback capabilities, segmentation, attack surface reduction, hardening, least privilege, access control, centralized logging, EDR where appropriate, live kernel patching when sustainable, realistic staging environments, internal documentation, and trained personnel.
It also means having the courage to say no. No to new onboardings when the team needs to manage a crisis. No to urgent quotes if the technical priority is protecting those who have already entrusted us with their infrastructure. No to commercial growth when it risks compromising operational quality.
In a mature industry, this should not be seen as a lack of commercial attention, but as a sign of seriousness.
Obviously, this additional commitment, and the increased risks associated with the new NIS2 directives, will necessarily translate into much more work and inevitably lead to management costs that are at least 10–15% higher than current costs, which are already being increased by the hardware race dictated by the AI revolution.
AI vs. Developers, Hackers vs. Defenders: The New Balance
The symbolic image of this moment is a tug of war: on one side the attackers, on the other the developers and maintainers, with artificial intelligence in the middle as an ambiguous referee, a neutral accelerator that does not distinguish between those who defend and those who attack.
But perhaps the picture is still incomplete. Because next to the table, under pressure, is the systems administrator. He's the one who must translate the results of that tug-of-war into concrete action on the servers. He's the one who must absorb the final blow.
AI isn't "good" or "bad." It's a tool. But like any powerful tool, it changes the balance. And in cybersecurity, balance matters more than intentions.
If an attacker can analyze one hundred patches a day and a defender can successfully patch ten critical systems a day, the problem is not moral: it's mathematical.
The advantage goes to those who automate better, take better inventory, make faster decisions, reduce complexity, and are not caught unprepared.
Conclusion: May 2026 as a wake-up call
May 2026 risks being remembered as a wake-up call. Apache, NGINX, Linux kernel, cPanel/WHM: huge names, widespread software, vulnerabilities in close proximity, major impacts, urgent patches, exploits, and increasingly faster analysis.
This isn't the end of open source. It's not proof that Linux is insecure. This isn't the time for pointless alarmism.
But it's time to admit that the security operating model is changingArtificial intelligence has reduced the time between patching and understanding a vulnerability. It has lowered the technical barrier to analyzing vulnerabilities. It has made it easier to automate the dirty work that previously required hours or days of manual reverse engineering.
As a result, infrastructure managers can no longer afford slowness, improvisation, or artisanal processes.
At Managed Server Srl, we spent May 1st working hard, and seventeen days later, we're continuing to address the challenges this month has imposed on us: patches, checks, mitigations, automation, internal tools, faster procedures, and increased responsiveness.
We would have preferred a picnic, a snack, a day trip. We would also have preferred to send more quotes, acquire new clients, pursue new business opportunities.
But when safety calls, duty comes before turnover.
And this, ultimately, is perhaps the most serious way to truly honor Labor Day: working when necessary, protecting those who have entrusted themselves to us, and preparing for the next attack before it comes.
And we're only halfway through the month... give or take a day.
UPDATE as of May 21, 2026, or just 4 days later.
As already anticipated in the piece written above on Sunday, new surprises were to be expected, and in fact they were not long in arriving.
For the series Local Exploit, Monday 18th May, just to start the day and the week off right, we found ourselves faced with a new bug called DirtyDecryptThis is a vulnerability of Local Privilege Escalation in the Linux kernel, identified as CVE-2026-31635, which can allow an unprivileged local user to gain root permissions on vulnerable systems. The issue affects the kernel's handling of network buffer decryption and falls within the family of vulnerabilities related to DirtyFrag / CopyFail, with public PoCs already available and therefore with a decidedly high level of attention for those who manage Linux servers in production.
Instead today, May 21, 2026, the day thought it a good idea to delight us with something even more serious: an alleged new vulnerability RCE on NGINX, baptised NGINX PoolslipLet's talk about a possible Remote Code Execution, therefore no longer a simple local exploit or a vulnerability exploitable only by a user already present on the machine, but a potentially much more dangerous class of bug, because it can theoretically be activated remotely against a service exposed on the Internet. NGINX, along with Apache, is one of the most popular web servers in the world and is often chosen for its performance, its efficiency in managing concurrent connections and its widespread use as a reverse proxy, load balancer and HTTP frontend for PHP, Node.js, Python applications, containers and Kubernetes environments. The problem, according to initial public reports, also affects NGINX 1.31.0, which is the latest mainline release published with fixes for the previous wave of NGINX Rift / CVE-2026-42945 vulnerabilities.
ngx_http_rewrite_module, classified as potentially exploitable for DoS or, under certain conditions, code execution. Now, very shortly after, comes the news of Poolslip, which according to initial reconstructions would hit version 1.31.0, thus reopening the front on systems that many administrators considered already updated and secured. 23:04 PM Italian Time on May 21, 2026, according to available sources, there is still no official patch published on the NGINX advisory page for “nginx-poolslip”; for this reason, the situation should be treated with the utmost caution, constantly monitoring the official F5/NGINX advisories and in the meantime evaluating conservative hardening measures, reducing the exposed surface area, and checking logs on public frontends.
ptrace, linked to the management of the so-called dumpability Linux processes. The problem, which has been present in the kernel for years, can allow a local, non-privileged user to exploit a race condition window during the termination of privileged processes, allowing them to read sensitive information normally reserved for root, such as host SSH private keys or content linked to /etc/shadowWhile this is not a remote vulnerability that can be exploited directly over a network, the impact is still significant in multi-user scenarios, shared hosting, containerized environments, or servers where an attacker already has even minimal local access. The vulnerability has been publicly associated with the name ssh-keysign-pwn and is particularly concerned with the behavior of SUID binaries such as ssh-keysign e chage, which during their normal execution can open sensitive files with elevated privileges.
Major Linux distributions have begun releasing corrective kernel updates; AlmaLinux, for example, reports the impact on AlmaLinux 9 and 10, with patches also planned for AlmaLinux 8 despite the public PoCs not appearing to be immediately effective on that line.
