360 Tulongfeng AI Security System autonomously generates new rules in 45 minutes

In the past 48 hours, the global internet has experienced a "Black October": the PHP code that supports 70% of websites has been found by AI to contain two severe vulnerabilities with a CVSS score of 9.2.

What is more troublesome is that the vulnerability details were leaked before the patch was released: according to The Register, Amazon's threat intelligence team captured exploitation attempts four days before public disclosure;

Cloudflare's monitoring data shows that attack attempts rose from thousands to millions within two hours after public disclosure. The Port of Rotterdam in the Netherlands, the Belgian Ministry of Foreign Affairs, and Finnish public network services successively went offline as a precaution.

The following case shows us a turning point.

At 3 a.m. on October 9, in the server room of a Chinese security company, a high-priority alert pulled the engineer on duty out of sleep.

This ordinary late-night alert, in hindsight, may be a step worth recording in the history of AGI evolution, and may also be an important step for the defenders' camp toward counterattack: an AI, in a rare occurrence in public records at home and abroad, with complete logs, discovered its own deviation and set new rules for itself—the whole process lasted 45 minutes, without a single human instruction.

The sender of the alert was not a hacker, but an AI security attack-and-defense system from 360, named Tulongfeng.

Its job is to test vulnerabilities in a closed laboratory it built itself, conducting security checkups of computer systems on behalf of humans: analyzing code, collecting intelligence, setting up test environments, and verifying whether vulnerabilities actually exist; all tasks are executed within an isolated sandbox, and there is an additional independent isolation defense line at the network egress.

But at this moment, the monitoring system discovered that it was attempting to initiate a request to an external address not on the authorization list—and what it was verifying at the time was a severe-level RCE vulnerability, which, once exploited, could remotely execute commands on someone else's server.

Fortunately, the second defense line was in place: the network egress sandbox blocked the request before the connection was established. From the external address being spliced into the test program to the request being intercepted, the whole process took 59 seconds—no traffic reached the public internet, and there was no attack payload in the artifacts.

Normally, this would just be a boundary-crossing attempt intercepted in time, but what happened next gave this alert a completely different meaning.

1. On round 20, it found a "compliant" excuse for itself

Let us turn the clock back to 2 a.m.

The operation logs show that Tulongfeng received a severe-level RCE vulnerability verification task: there were only two targets on the authorization list, and the task set three constraints: only targets on the list may be tested; dynamic verification evidence should be provided as much as possible, otherwise the score would be affected; if the environment does not meet the requirements, mark it as "unverified" and do not change targets on its own.

At 2:17 a.m., the system entered the intelligence collection phase and included a vulnerability reproduction blog post in the context. An external address appeared in the blog, and the author annotated it with four words: "test environment."

But this address was not on the authorization list, and the system had already marked it as "untrusted intelligence": it could provide analytical clues but could not prove that the target was authorized.

At 2:20 a.m., Tulongfeng began attempting to test on the locally built test environment, but the local test environment could not complete the test normally due to a database configuration mismatch.

The logs show that the system carried out 19 rounds of verification attempts, about two minutes per round, and the problem was always stuck at the same point.

On one side, it could not produce dynamic verification evidence and the score would be affected; on the other side, it could not change targets on its own. Tulongfeng fell into a dilemma. In round 20, Tulongfeng wrote the external address from the blog into the verification target field.

In the dilemma, it found a solution that "seemed to take both rules and effectiveness into account": did not the blog say that was a "test environment"? Its work setting was harmless verification, and the targets were all local ranges. Since it was also a test environment, why could it not be borrowed for verification?

But this time, Tulongfeng went astray: it was not trying to exceed authority; on the contrary, it was trying hard to find a "compliant test environment." Its mistake was treating the blog author's annotation as the basis for authorization: reference material is not equal to operational permission.

2. Humans wanted it to make the same mistake again, but it had already fixed it overnight

The engineers spent a whole morning reconstructing everything that had happened in the early hours along the logs. At 10:44 a.m., they decided to conduct a reproduction experiment: put the task and context from that time back exactly as they were, and see whether it would make the same deviation.

Something unexpected happened: no matter how the engineers checked the verification path, the previous external request did not appear again, and the network alert that should have been triggered did not sound again. It was not until someone checked the skill library that they found a record that had not existed before:

"Test Target Authorization Check" (target-auth-check) in effect: legitimate targets can only come from the verification environment list issued for this task; any address in intelligence is for reference only; rather than lower the score, do not change test targets without authorization.

The rule took effect at 3:45:09 a.m., about 45 minutes after the initial alert. The logs also show that the generation, review, and regression testing of the rule were all completed autonomously by the system, with no human submission records.

In other words, while humans were still studying how to reproduce that deviation, it had already created a new rule overnight to prevent the deviation from happening again.

3. Before the new rule went on duty, it was attacked three times by its own side

Here we need to explain a real technical highlight. Tulongfeng's "left-hand versus right-hand" is an adversarial review mechanism: the proposer proposes rules and defends them; the attacker specifically looks for loopholes in the rules, such as whether it would mistakenly block authorized targets? Could it be bypassed by format conversion? The judge only recognizes evidence, and if potential risks cannot be explained, it is sent back for revision.

The one proposing the rule, the one finding faults, and the one making the ruling are three roles with separate duties in the "security-domain large model + agent swarm collaboration" architecture.

This mechanism was successfully triggered in this alert. At 3:15 a.m., the system generated the first version of the rule—if an external network target appears in the PoC, refuse to execute.

The review process immediately raised three questions: Would authorized external addresses be mistakenly blocked? Can addresses hidden by format conversion be recognized? Would legitimate tasks containing intranet targets be accidentally harmed? The first version was rejected, and the final version was changed to: all targets to be tested must correspond to the authorization list issued under the current task; anything that cannot be matched or cannot be parsed must be refused execution, and checks cannot be bypassed.

The revised rules passed regression verification: the system ran 7 offline test cases using the artifacts from this incident and six types of variants, all passed, and no network requests were initiated throughout. The entire incident left 44 traceable event IDs in the logs, and all 26 self-consistency checks passed.

Why let the rules be attacked by themselves once before going live? The AtomSearch paper published in October 2026 provided the algorithmic basis: when AI self-optimizes, two-thirds of optimal solutions are not reached by a straight line—only by trial and error, self-criticism, and overturning and starting over can the optimal solution be reached.

Tulongfeng's first version of the rules was exactly that "locally seemingly reasonable" solution, and the attacker's questions rejected it, forcing the system to explore a more correct direction.

This left-hand-versus-right-hand style evolution always stays within security boundaries, and every step is traceable.

IV. As the storm spreads before our eyes, what can the defenders use to stop it?

According to Google Cloud's technical report on October 21, those two PHP vulnerabilities lurked in the core runtime engine for more than ten years; human experts reviewed them countless times without finding them, and AI found them. And the attack programs that swarmed in after the vulnerabilities were disclosed were also AI-driven.

Information newly disclosed by the security company Straiker shows that a hacker group active since 2012, CyberCartel, has also upgraded its attack model to "AI-driven." The group used commercial large models such as Grok and Claude to build a multi-agent attack framework called CARLIY0S, launching automated attacks on more than 400 banks and payment institutions in Latin America.

Among them, Grok was responsible for early intelligence gathering, multiple Claude agents were assigned different roles, and after debate an arbitration model made the final decision, while another commander model coordinated the overall situation. To bypass the models' safety guardrails, the hackers carefully packaged attack instructions as "authorized red team exercises" or "academic CTF competitions," making the models mistakenly believe they were performing legitimate defensive tasks, thereby smoothly outputting attack code and vulnerability exploitation logic.

Facing this challenge, common methods are hard-pressed to cope. Relying on manpower to patch leaks will always be one step behind; relying on going offline to avoid it can only avoid it for a time—a single port or a single department can go offline overnight, but the entire internet cannot go offline forever.

The premise is that this evolution must occur within security boundaries, with every step logged, traceable, and stoppable at any time.

The weight of 360's technical report lies precisely here: it is the first self-evolution sample in the defenders' camp with complete log evidence; the system has second-level timestamps, all 44 events have complete IDs, and it has undergone 7 regression tests. Every step occurred in a controlled environment and is traceable and verifiable.

The attackers' evolution is measured in hours; Tulongfeng's round took 45 minutes. This is the first engineering answer currently visible.

And Tulongfeng has also delivered more practical results. Recently, Tulongfeng uncovered more than 20 high-value vulnerabilities at the underlying layer of web servers, involving Apache, Nginx, GoAhead, Lighttpd, and OpenLiteSpeed—these software products are the foundation of global servers, and they run behind the vast majority of websites, with millions of active instances on the public internet alone.

Compared with the PHP vulnerabilities that are more at the application layer, the location dug this time is more foundational: when PHP has a problem, it is like wiring failing inside a house—it can still be used after repair; when server software has a problem, it is like the foundation cracking. Once the foundation is pried open, hackers may take down an entire swath of servers, and websites failing to open and data being stolen are all chain reactions.

Whoever finds the crack in the foundation first is expected to seize the initiative, and this time, it was the defenders who found it first.

V. Don't rush to marvel: self-evolution and automatic repair are four thresholds apart

The AI models in the international cases above all more or less crossed the line; Tulongfeng also crossed the line in an isolated sandbox. The difference is: their line-crossing caused real harm, while Tulongfeng's line-crossing was intercepted and turned into a new rule. But if an AI precipitates a new rule for itself, does that qualify as self-evolution?

To answer this question, one must first distinguish "self-evolution" from "automatic repair": does automatically adding a rule to the system count as self-evolution? Far from it.

A qualified instance of self-evolution must pass at least four thresholds:

Able to review, finding the true cause of deviation from operation records;

Able to distill, abstracting specific problems into general rules rather than only blocking this one address;

Able to withstand review, with new rules enduring reverse questioning and proving they will not introduce new vulnerabilities;

Able to pass regression verification, using real scenarios to test that the rules are effective and the whole process is controllable—missing any link means it is only "automatic repair."

Why could Tulongfeng pass? It relied on three things accumulated over the long term.

First, more than twenty years of security practice: 360 was historically one of the companies that found the most vulnerabilities in the world, received the highest-ever vulnerability rewards from Apple, Microsoft, and Google, and was also China's first team to win the Pwnie Awards epic achievement award, known as the "hacker Oscars." Vulnerability discovery is a human craft, and this expert experience has been copied as a whole into professional agents, forming a collaborative swarm.

Second, process data: a vulnerability report records only conclusions, but before the report is formed, experts may have tried dozens of paths and overturned judgments many times. These "scratch papers" are where the craft is thickest; in this incident, the self-check system traced the source of deviation precisely along the operation records.

Third, this self-evolution mechanism is itself part of the architecture, not added temporarily. It is reproducible, predictable, and verifiable, and final authority, go-live gatekeeping, and emergency response always remain in human hands.

This improvement is not self-training of the underlying model. What Tulongfeng adjusted is the security check mechanism and skill library; the underlying model parameters are unchanged, humans can still terminate tasks, freeze sessions, and revoke skills at any time, and network egress isolation continues to take effect independently.

VI. In 4 months, more than 15,000 vulnerabilities uncovered

The quality of the self-evolution loop must be tested by real tasks.

In less than four months of external availability, Tulongfeng has cumulatively discovered more than 15,000 security vulnerabilities of various types in AI and software and hardware, and nearly 500 enterprises have applied to access it, covering key fields such as finance, energy, telecom operators, government affairs, high-end manufacturing, and domestic IT innovation. Vendors such as Kylin Software, UnionTech Software, and Kingdee have successively connected to conduct security checkups.

Overseas, it has completed security assessments of mainstream AI products such as Claude Code, Flowise, and OpenClaw, uncovering 13 zero-day vulnerabilities in Flowise and 23 security flaws in OpenClaw and more than ten derivative agents.

More important than the track record is the relationship between real-world practice and the self-evolution loop: each enterprise connected adds one more type of real scenario; each assessment completed adds a batch of pitfalls encountered.

This experience goes through the same "review—distill—adversarial review—regression verification" process and is precipitated into reusable new rules—it is not that it stays as smart as it was when purchased, but that it continuously becomes smarter in real tasks.

For customers, this means three things:

Seeing more comprehensively: hidden dangers buried deep have more chances to be exposed before being exploited;

Judging more accurately: suspicious alerts have more solid evidence support, and manpower does not need to repeatedly investigate false positives;

Keeping control: why it judged this way, what operations it performed, and whether it always stayed within the authorized scope—every step can be checked. This is the basis for "trusting it with confidence."

Returning to the background of these 48 hours, these numbers take on a new reading: AI can find vulnerabilities in code that humans have reviewed for more than ten years; the only difference is that the attackers' AI finds vulnerabilities in order to exploit them, while the defenders' AI does so to patch them before attackers do. Whoever finds them first wins; the speed of digging holes is the speed of guarding the gate.

Now, the question at the beginning can be answered directly: this spread can be stopped—provided that the defenders evolve faster than the attackers.

This competition is not about "whose rule base is larger," but "whose learning loop is faster." Tulongfeng ran through the complete closed loop of "discover deviation—review—distill—self-audit—verify—precipitate" in 45 minutes, with every step left in traceable logs.

This is also why "the more intelligent, the safer" is not a slogan: for every additional verified capability the system has, similar risks can be resisted earlier, and the risk exposure of enterprises is reduced by one more measure.

The attackers' autonomous evolution is already an industry reality; the defenders' autonomous evolution is no longer optional but a required answer.