For years, certain types of attacks seemed reserved for highly specialized profiles: identifying vulnerabilities, generating malicious code, or finding weak points required advanced knowledge, time, and resources.
Today, that landscape is beginning to change.
Artificial intelligence is not inventing entirely new threats; it is making existing threats faster, more accessible, and easier to execute.
In a context where companies increasingly rely on interconnected tools, platforms, and services, the question is no longer just who can carry out an attack, but how many can do so.
Fewer barriers, greater capability.
Historically, preparing an attack required a combination of technical expertise, time, and resources. Today, AI makes it possible to accelerate tasks that were once manual: analyzing public information, identifying potential vulnerabilities, automating repetitive processes, or generating code.
This doesn’t mean that anyone can carry out highly sophisticated attacks overnight, but it does imply something important: the barrier to entry is starting to lower.
What once required days or weeks of work can now be significantly compressed, allowing known threats to gain speed and scale.
What we are seeing is no longer theory.
A few years ago, many conversations around artificial intelligence and cybersecurity focused on future scenarios: what might happen or how attacks could evolve. Today, the conversation is different.
Recent data and incidents show a clear pattern: attackers are using AI tools to accelerate existing processes, from identifying vulnerabilities to more elaborate social engineering campaigns or attacks on digital supply chains.
In recent weeks, we have seen very clear examples of this changing scenario.
One of the most notable cases is the campaign known as Mini Shai-Hulud, a software supply chain attack that compromised hundreds of packages used by developers and continuous integration environments. The goal was not to target a specific company directly, but to exploit trusted tools used by thousands of organizations to steal credentials, secrets, and access to development environments.
What makes this type of attack particularly concerning is that many organizations can be affected without being the initial target. Simply using a compromised library, dependency, or third-party service is enough.
Moreover, the campaign evolved rapidly and ended up affecting widely used developer ecosystems, including tools related to TanStack, SDKs, and packages used in AI and modern development environments.
What makes these attacks particularly interesting is that they shift the traditional point of entry. It is no longer just about breaching a single company: a piece of the ecosystem is compromised, and the impact multiplies automatically.
Are we entering a new phase?
Since late 2025, discussions have begun to emerge across the industry about a possible new phase—or “fourth wave”—of attacks: more automated threats, with greater propagation capabilities and supported by AI tools. This is putting traditional defense models under increasing pressure.
Some recent attacks are already showing particularly concerning behaviors, with malware capable of spreading across dependencies and leveraging stolen credentials to spread automatically across repositories and development environments.
This does not mean that existing mechanisms have stopped working, but it does mean that the speed at which threats evolve is forcing a rethink of many strategies.
Perhaps the most important shift is this: for a long time, we have operated under a relatively comfortable assumption—that something is secure until proven otherwise.
Today, a logic we already knew is starting to prevail: until proven otherwise, nothing should be considered 100% secure (Zero Trust).
While more mature solutions arrive: what can we do today?
There is no definitive solution or formula capable of completely eliminating risk, especially in a context where attacks are beginning to exploit legitimate distribution channels, compromised dependencies, or seemingly trusted processes. However, there are measures that can significantly reduce exposure:
- Limit privileges and restrict the installation of software, extensions, or dependencies only to authorized environments and users.
- Establish validation and auditing processes before deploying new dependencies, libraries, or tools in corporate environments.
- Avoid automatic or indiscriminate installation of the latest versions without prior review, especially in critical systems.
According to our expert, “keeping dependencies up to date was actually part of the problem, as the attack spread through an infected update that was published before anyone noticed.” This highlights the importance of carefully reviewing any updates before applying them.
- Strengthen DevSecOps practices and software supply chain security.
- Periodically audit repository configurations, forks, pipelines, and integration systems to detect potential compromise vectors.
- Protect and secure channels and profiles with access to critical systems, reducing risks associated with social engineering or impersonation.
- Maintain continuous monitoring for anomalous activity, unexpected changes, or out-of-pattern behavior.
- Review tools, services, and third parties that are part of the organization’s technology ecosystem.
In many cases, the issue no longer lies solely in malicious software, but in the implicit trust with which it is incorporated into our environments.
In statements to Reuters, Verizon’s Chief Information Security Officer, Nasrin Rezai, emphasized the importance of addressing these growing threats:
“We have to fight AI with AI. We have to incorporate it into our practices. Integrate it into our software development lifecycle, into our testing processes, into our cyber defense processes on an unprecedented scale.”
Because the conversation may no longer be about whether a company can be attacked. The real question is becoming something else: are we prepared to detect and respond in time?