Several recent events made me realize just how decisively the security field has entered the AI era. They prompted this essay and some reflection on what the future may hold.
The first event was the shutdown of PSRC.
On July 23, PSRC announced that, because of business changes, the platform would cease operations and close on July 30.
The news left me reflective: over the past year, the pace of vulnerability discovery has accelerated dramatically.
In the past, finding a vulnerability or auditing a large project could take one person weeks or even months. Now, much of that work can be completed in days simply by giving the code or target to AI. For well-bounded problems, results may appear within hours. AI has multiplied the efficiency of vulnerability research enormously.
The second event was the disclosure of a Fastjson RCE.
On July 19, Kirill Firsov publicly stated on X that Fastjson 1.2.83 contained a remote code execution vulnerability that did not depend on a classpath gadget.
Simply put, the exploit chain can run without the target environment already containing a class that would traditionally be considered exploitable.
Very little information was public at first: essentially the vulnerability claim, a demonstration video, and the crucial hint that it did not depend on a classpath gadget. The complete request, trigger conditions, call flow, and exploit code were not initially available.
Within a few hours, however, an exploit had already appeared. A little over ten hours later, someone had published a reproducible PoC and test environment on GitHub. In the past, even a researcher familiar with Java, Fastjson, and historical deserialization vulnerabilities would have needed several days for a problem like this.
I have lived through two similar cases. The first was the Cobalt Strike RCE. After Beichen discovered it, researchers in our group discussed it all night. I was among the first to reproduce the vulnerability, but it still took the entire night. The other was Spring4Shell, which also took several hours to reproduce from very limited information.
Things are completely different now. In both of these cases, AI could solve the problem within a few hours.
What struck me was not that Fastjson had another RCE, nor that the exploitation technique was unusual. It was that the entire process—from a very limited hint, through finding the key path in the source, to completing the trigger conditions, building the environment, and writing a PoC—had been compressed to a matter of hours.
Once someone provides a reasonably accurate direction, AI can automate environment setup, analyze the code, and trace specific call relationships and data flows.
The greatest difference between AI and people is that AI can tirelessly try different ideas, adapting each one to the code currently under analysis. The breadth of its underlying knowledge means that once it identifies the core issue, it can build the essential exploit chain.
More importantly, these lines of research can proceed in parallel. A person can usually follow only one or two paths at a time, while AI can explore a dozen possibilities simultaneously and organize the results for human judgment.
Traditional code auditing, in that sense, is already dead.
We used to say that a good code auditor needed experience: seeing a function and immediately recalling its history of vulnerabilities, recognizing where an argument might be controlled, and being willing to follow an odd piece of compatibility code further. The auditor also needed patience and precision—not missing a branch, overlooking a type conversion, or skipping a function simply because its name looked ordinary.
These abilities genuinely mattered before because the human mind can process only a limited amount of information. The more experience someone had, the faster they could filter code; the more patient they were, the more likely they were to continue after others had given up and eventually find the problem.
But experience and attention to detail are now precisely the things AI does best.
AI knows more common vulnerability patterns than most security professionals. Repeatedly tracing dozens of layers of calls is effortless for it. Once it has checked one project, it can immediately apply the same method to dozens of similar projects.
If a security professional's main advantage is knowing which functions are dangerous, or being willing to trace variables for days on end, that advantage has almost disappeared.
At least when you already have the code and roughly know what you are looking for, AI can now outperform the vast majority of people. You may only need to tell it that a project contains an RCE vulnerability, and it may uncover one for you.
We used to spend a great deal of time reading code before a direction finally emerged from it. In the future, we are more likely to start with a direction and then ask AI to uncover all the relevant code for us to study.
The first thing that truly creates a gap is the choice of attack surface.
In the Fastjson case, for example, AI could quickly compare versions, trace the deserialization flow, determine which checks were bypassed, repeatedly adjust the test code based on errors, and ultimately produce a working PoC.
What is truly worth investigating, however, is not whether another gadget-based exploitation technique can be found, but whether an entirely new path to RCE exists.
Risk assessments for Fastjson used to depend heavily on whether an exploitable class existed in the target environment. If that premise no longer holds, do our assumptions about exploitation requirements, impact, and defenses all have to be rebuilt from scratch?
Starting from scratch means the possibilities are almost unlimited. Once told the premise, AI can reason about paths that reach code execution without a traditional classpath gadget. Like a security researcher, it can read the source, build an environment, and test PoCs.
Yet the phrase 'does not depend on a classpath gadget' was the central insight—and the most valuable input a security professional could provide.
AI can follow a path very quickly, but choosing which path to follow is where security professionals distinguish themselves. The more valuable the input, the better the output AI can potentially produce.
Another point of differentiation is how a security professional uses the information produced by AI.
In day-to-day work, many individual clues look ordinary: an error returned by a web page, a configuration switch, or a feature of some component. AI can help analyze and connect them. But the value those clues ultimately create still depends on how a person uses them and how far they are willing to push the conclusion.
Humans became Homo sapiens because we learned to use tools, and AI is the defining tool of this new era. The future is not about security professionals competing with AI to prove who is better; it is about how far security professionals can go by using AI.
AI will produce ever more information and independently complete increasingly complex work. There is no need to be anxious about that. Adapting to the direction of the times is far more useful than worrying about it.
From my perspective, the truly scarce ability for a security professional is not discovering a particular vulnerability or obtaining a piece of information through AI. It is knowing where a vulnerability may exist and understanding what can be done with the information once it has been obtained.
In the AI era, security professionals' ability to discover vulnerabilities is gradually leveling out. The remaining gap may be only the few hours AI spends reasoning deeply. The real difference will be what you ask AI to do, and why you thought to ask it in the first place.
In one sentence:
Engineering ability will no longer be the main dividing line. What will truly separate people is how deeply they understand a problem, how well they choose a direction, and how effectively they use the information AI produces.