As soon as a critical vulnerability is disclosed, the race begins. Threat actors start mapping exposed attack surfaces, adapting exploits, and automating attacks at scale. With AI accelerating this cycle, companies need to drastically reduce the time between discovery, validation, exposure, and response.

The new speed of exploitation

In recent months, the security ecosystem has witnessed a sequence of critical vulnerabilities and high-impact incidents involving technologies widely used across corporate environments, infrastructure providers, Linux servers, administrative panels, firewalls, edge applications, web servers, and software development supply chains.

Recent cases involving Linux LPEs, cPanel/WHM, NGINX, Apache, Palo Alto PAN-OS, Fortinet, as well as supply chain incidents in development environments, reinforce an important trend: critical vulnerabilities are no longer isolated events. They have become part of an operational race between those who can exploit first and those who can identify, contextualize, and mitigate faster.

This race has become even more complex with advances in artificial intelligence.

AI is already being used by researchers, security vendors, and defensive teams for code analysis, fuzzing, vulnerability triage, exploit reproduction, risk prioritization, and detection development. At the same time, it can also be used by threat actors to accelerate reconnaissance, interpret advisories, adapt proofs of concept, automate attacks, create more convincing phishing campaigns, and process large volumes of data in just a few minutes.

Adversaries are already using AI across different stages of the attack lifecycle, including vulnerability discovery, exploit generation, malware development, reconnaissance, social engineering, and agentic workflows, in which models move beyond passive assistance and begin orchestrating tools and executing tasks with less human supervision.

From disclosure to exposure: the response window is shrinking

For a long time, the vulnerability response cycle followed a relatively predictable logic: advisory publication, internal analysis, prioritization, change request creation, patch deployment, and post-validation.

That model still exists, but it no longer keeps pace with the speed of today’s threat landscape.

Today, as soon as a critical vulnerability is disclosed, different actors begin moving almost simultaneously. Researchers validate the technical impact, vendors publish guidance, security providers create detections, offensive operators test hypotheses, and opportunistic groups initiate large-scale scanning.

The question is no longer just:

“Is this CVE critical?”

It has become:

“Do we have this technology exposed? Is the version affected? Is the scenario exploitable? Is there a PoC? Is there active exploitation? Is the asset critical? How quickly can we detect and act?”

This shift is especially sensitive when discussing global technologies. A flaw in a niche component may have limited impact. However, a vulnerability in Linux, cPanel/WHM, NGINX, Apache, PAN-OS, or Fortinet can affect corporate environments, providers, end customers, hosting chains, exposed applications, and critical infrastructure.

Recent LPEs: when a local flaw becomes a critical stage in the attack chain

An important point in this scenario is that not every critical flaw starts as remote code execution. Local privilege escalation vulnerabilities, known as LPEs, can be just as relevant as remote flaws when they are used as part of a broader attack chain.

In recent days, vulnerabilities such as Copy Fail and DirtyFrag drew attention precisely because they affected the Linux kernel and allowed privilege escalation to root in different scenarios.

Copy Fail, tracked as CVE-2026-31431, was described as a logic flaw in the Linux kernel involving authencesn, AF_ALG, and splice(), allowing controlled writes to the page cache and local privilege escalation. The technical research page states that exploitation affects Linux distributions with kernels built since 2017 until the patch is applied, and highlights the impact on multi-tenant hosts, Kubernetes clusters, CI runners, build farms, and environments that execute untrusted code.

DirtyFrag was disclosed shortly afterward, involving CVE-2026-43284 and CVE-2026-43500, related to Linux kernel paths involving IPsec ESP and rxrpc.

The central point is that an LPE should rarely be analyzed in isolation. An attacker may obtain initial access through leaked credentials, an exposed panel, a vulnerable application, a malicious package, a compromised extension, or a CI/CD pipeline. From that limited access, an LPE can turn an initial foothold into privileged control of the host.

In modern environments, this becomes even more relevant. CI runners, sandboxes, container workloads, development environments, and platforms that execute third-party code become sensitive targets when a local flaw allows boundaries between user, container, host, and tenant to be crossed.

When global technologies become surfaces for mass exploitation

Another group of recent flaws reinforces the risk posed by widely adopted technologies exposed to the internet.

CVE-2026-41940 in cPanel/WHM is a clear example. It is a remote, unauthenticated authentication bypass with a CVSS score of 9.8, allowing unauthorized administrative access to affected systems. The analysis also highlighted that a simple Shodan query returned approximately 1.5 million cPanel instances exposed to the internet, reinforcing the potential scale of the issue.

cPanel’s own advisory stated that the issue affected all versions after 11.40 and recommended immediate updates using the /scripts/upcp --force script, in addition to restarting the cpsrvd service and applying temporary mitigations such as port blocking and service disabling when updating was not immediately possible.

This type of vulnerability is especially critical because cPanel/WHM acts as a hosting control plane. The compromise of a single panel can expose domains, files, databases, email accounts, configurations, and multiple customers hosted on the same server.

In the case of Palo Alto PAN-OS, vulnerabilities in firewalls and authentication portals are particularly sensitive because they are positioned at the network perimeter. Recent reports pointed to CVE-2026-0300 as a critical flaw in the PAN-OS User-ID Authentication Portal, with the potential for code execution by unauthenticated attackers against firewalls exposed to untrusted networks or the internet.

In Fortinet, recent flaws have also demonstrated how security applications can become initial access vectors. CVE-2025-64446, affecting FortiWeb, was described as a critical path traversal vulnerability allowing unauthenticated execution of administrative commands, with active exploitation reported. CVE-2025-59718 and CVE-2025-59719 were associated with SAML authentication bypasses in Fortinet products, enabling administrative access and exfiltration of configuration files in observed attacks.

In technologies such as NGINX and Apache, impact must also be analyzed contextually.

Not every web server flaw is automatically exploitable in every environment, but when a vulnerability combines public exposure, an affected version, a vulnerable configuration, and a working PoC, the response window shrinks drastically.

This is the main point: real criticality does not depend only on the CVE name or CVSS score. It depends on the combination of exposure, exploitability, asset function, PoC maturity, active exploitation, and business impact.

Opportunistic attacks: when a new flaw becomes a mass scanner

When a critical flaw is disclosed, opportunistic actors quickly seek to exploit it at scale.

This type of threat actor does not need to know the victim in advance. The objective is simple: identify vulnerable instances on the internet, test exploitation at scale, and monetize the access obtained. This can happen through the sale of initial access, deployment of webshells, cryptominers, botnets, ransomware, or data theft.

The logic is operational: the larger the affected technology base and the slower organizations respond, the greater the chance of compromise.

This behavior has already been observed across several historical exploitation cycles, such as Log4Shell, vulnerabilities in VPNs, edge applications, administrative panels, application servers, and widely used libraries. The pattern repeats itself: as soon as enough technical detail is available, scanners emerge, PoCs are adapted, scripts are shared, and exploitation begins to occur in waves.

With AI, this cycle tends to accelerate. A less experienced operator can use models to interpret advisories, understand prerequisites, write basic scanners, adapt payloads, handle errors, organize target lists, and automate repetitive steps.

AI does not need to turn a beginner attacker into an advanced researcher. It only needs to reduce operational friction.

APTs and targeted attacks: when a CVE becomes part of a larger operation

In parallel with opportunistic actors, more sophisticated groups may use critical vulnerabilities within targeted operations.

In this case, the question is not “who is vulnerable on the internet?”, but rather:

“Does my target use this technology? Where is it exposed? Which business unit, supplier, subsidiary, or third party uses this component? Can this flaw open a path into the environment I want to reach?”

This behavior is particularly relevant in vulnerabilities involving firewalls, VPNs, edge applications, identity servers, CI/CD platforms, administrative panels, remote management tools, and infrastructure components.

The difference lies in intent. The opportunistic actor seeks volume. The targeted actor seeks context.

With AI, more mature groups can scale data analysis at much greater speed. An APT can use agents to process public inventories, map technologies by ASN, correlate domains, analyze certificates, identify suppliers, enrich employee data, cross-reference exposures with news, detect technology stacks, and prioritize targets based on exploitation probability.

This type of use is especially concerning because it combines three capabilities: intelligence, automation, and persistence. AI helps process large volumes of data, but operational decision-making may still be guided by strategic objectives defined by humans.

Supply chain: your company may be vulnerable without even knowing it

Supply chain attacks change the perception of risk because an organization can be impacted even without a direct flaw in its own application. The vector may be a malicious dependency, an npm/PyPI package, an IDE extension, a SaaS provider, or any tool the development team uses daily but that rarely receives the same priority as an exposed server.

The GitHub case in May 2026 is a clear example. On May 19, TeamPCP, a group recurrently associated with supply chain campaigns against developers, claimed on underground forums to have leaked around 4,000 internal repositories from the platform. The following day, GitHub confirmed the incident: unauthorized access through a malicious VS Code extension on an employee’s device, resulting in the exfiltration of approximately 3,800 internal repositories, with no evidence at the time of impact on customer repositories.

The central point was not a classic exploitation of exposed infrastructure, but rather an apparently legitimate tool within the development environment. IDE extensions can access local files, terminals, tokens, credentials, repositories, and cloud or CI/CD integrations, the same type of surface that actors such as TeamPCP have been exploiting in campaigns against npm, PyPI, and development ecosystems.

For other companies, the risk is not limited to what happened inside GitHub. Even without direct exposure of customer repositories, the leakage of internal code and logic, including components such as Actions, Dependabot, and Copilot, opens second-order scenarios: discovery of undisclosed flaws, more credible social engineering, and more targeted supply chain attacks against the ecosystem that depends on the platform.

This is one of the most difficult risks to communicate internally: even with a patched application, updated servers, and a reduced external surface, the development chain can still introduce compromise through a transitive dependency, an automatic update, a productivity extension, or a token stored on a developer’s machine.

AI as an offensive multiplier: from beginner attackers to APTs

AI changes offensive dynamics because it lowers barriers.

For less experienced attackers, it can act as a technical assistant. The operator can ask for help understanding a vulnerability, interpreting a stack trace, adapting a script, fixing errors, building a simple scanner, organizing results, and writing a more convincing phishing message.

For an intermediate operator, AI can accelerate automation. It can help create pipelines to collect targets, enrich data, test versions, group results, prioritize assets, and generate operational reports.

For an advanced group, AI can act as a scaling layer. Agents can handle large volumes of data, maintain context across tasks, consult multiple sources, generate hypotheses, compare technologies, assist with reverse engineering, support code triage, and automate reconnaissance.

We have observed that adversaries are moving toward agentic workflows, in which models become active participants in the offensive chain, orchestrating tools and making decisions at machine speed. Examples include the use of tools such as Hexstrike and Strix in autonomous reconnaissance and automated vulnerability validation activities.

This point is essential: AI does not completely replace the operator, but it increases their capability.

It enables smaller teams to process more data, test more hypotheses, and operate at a larger scale.

AI, phishing, and people-centered attacks

The impact of AI is not limited to the exploitation of technical vulnerabilities.

One of its most immediate and dangerous uses is the creation of more sophisticated attacks against people.

Phishing messages, social engineering approaches, corporate pretexts, deepfakes, supplier impersonation, and contact attempts through LinkedIn, WhatsApp, or email can become more personalized, fluent, and convincing.

Adversaries use LLMs for research, reconnaissance, and support across the attack lifecycle, including the collection of organizational information, identification of hierarchies, departments, third-party relationships, and high-value areas such as finance, internal security, and human resources. This information can be used to create more targeted and higher-fidelity phishing lures.

This changes the logic of the attack. Instead of targeting only exposed vulnerabilities, threat actors can target specific people who have access, influence, or the ability to approve sensitive actions.

AI-assisted phishing can take into account job title, language, company context, recent events, suppliers used, communication style, and even operational urgency. In more sophisticated attacks, this can be combined with previous leaks, infostealer credentials, public social media data, and supplier information.

The result is an attack surface that is not only technological but also human and organizational.

The defensive role of AI

Despite the risks, AI also strengthens defense.

The same technology that can help attackers scale operations can help defensive teams reduce analysis time, correlate events, interpret advisories, review code, create hypotheses, generate detections, prioritize vulnerabilities, and respond faster.

The difference lies in how AI is integrated into the defensive process.

AI without inventory, without Attack Surface Management (ASM), without technical validation, and without context can generate noise. AI combined with CTI, ASM, technical labs, automation, and exposure-based prioritization can generate operational advantage.

In other words, AI does not solve the problem of critical vulnerabilities by itself. But it can significantly accelerate the ability to turn public information into defensive action.

QuimeraX’s response: from CVE to actionable context

At QuimeraX, this scenario is treated as an operational race.

As soon as a relevant critical vulnerability is disclosed, our team begins a technical analysis of the flaw, evaluates exploitation prerequisites, monitors evidence of active exploitation, reproduces scenarios in a lab environment when applicable, and develops detection templates for the ASM engine.

The goal is not only to know that a new CVE exists. The goal is to quickly understand whether it is relevant to our customers’ actual attack surfaces.

This process makes it possible to turn a public advisory into actionable visibility: identifying affected technologies, mapping potential exposures, differentiating truly exploitable assets from assets that are only related to the technology, prioritizing more sensitive environments, and notifying customers with technical context and real impact.

In some cases, this allows customers to be notified within hours of the public disclosure of a critical flaw, before exploitation becomes widespread or the vulnerability is broadly incorporated into offensive tools.

This speed is essential because threat actors are also operating faster. While an organization is still internally assessing whether a given CVE is relevant, opportunistic attackers may already be scanning the internet for vulnerable instances. While a team is still relying on manual inventory checks, targeted actors may be validating whether that technology appears in the attack surface of a specific organization.

From patch management to attack-surface-oriented response

Patch management remains essential. But on its own, it is no longer enough.

The current reality requires an attack surface-oriented response. This means correlating vulnerabilities with real assets, external exposure, criticality, configuration, active exploitation, and business impact.

A critical flaw in a technology not used by the organization does not represent direct risk. A critical flaw in a segmented internal asset may require prioritization, but it may not be the first item in the queue. However, a remotely exploitable flaw in a firewall, administrative panel, web server, edge application, or exposed development environment requires immediate response.

Maturity lies in transforming CVEs into operational context.

To achieve this, some questions need to be answered quickly:

• Do we have this technology?
• Is it exposed to the internet?
• Is the version affected?
• Does the configuration make exploitation possible?
• Is there a public PoC?
• Is there active exploitation?
• Is the asset critical?
• Is there evidence of exploitation attempts?
• Does the exposure affect a customer, supplier, subsidiary, or third-party environment?
• Which action reduces risk the fastest?

Without these answers, the organization gets stuck between two extremes: ignoring a critical flaw due to lack of visibility, or entering a generalized crisis mode without prioritization.

Conclusion

Critical vulnerabilities are no longer isolated technical events. They have become triggers for a race between public disclosure, offensive exploitation, automation, supply chain compromise, and defensive response.

Recent Linux LPEs show how local flaws can become critical stages of post-exploitation. Vulnerabilities in cPanel, NGINX, Apache, Palo Alto, and Fortinet demonstrate the risk of exposed global technologies. Supply chain incidents, such as the case involving a malicious VS Code extension and access to GitHub internal repositories, show that companies can be impacted by components and tools that do not always appear on the traditional risk surface.

AI accelerates this scenario even further.

For attackers, it can reduce the cost of research, reconnaissance, automation, phishing, and exploitation. For advanced groups, it can enable large-scale data analysis and more scalable targeted operations. For defenders, it can accelerate technical validation, detection, prioritization, and response.

In this context, defensive advantage is not only about keeping up with CVE news. It is about reducing the time between disclosure, technical validation, exposure identification, and action.

At QuimeraX, this is the focus: transforming critical vulnerabilities into actionable context, rapid detection, and real prioritization so customers can respond in hours, not days.

Schedule a free demo and see QuimeraX in action: https://quimerax.com/