The global internet has gone through a "Black October", and this Chinese AI has kept a fallback plan in place before the storm hits.
In the past 48 hours, the global internet has experienced a "Black October": the PHP code that supports 70% of all websites was found by AI to have two severe vulnerabilities with a CVSS score of 9.2.
What makes the situation more tricky 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 the vulnerabilities were publicly disclosed;
Cloudflare's monitoring data shows that the number of attack attempts surged from thousands to millions within two hours after the vulnerabilities were made public. The Port of Rotterdam in the Netherlands, the Ministry of Foreign Affairs of Belgium, and Finland's public network service have all taken preventive measures to go offline one after another.
Those who use AI for malicious purposes have evolved to operate on an hourly basis; while those who defend the system are still updating their rules on a monthly basis. As the storm rages more and more fiercely, a question hangs over everyone's mind: is there any way to stop this spread?
The following case shows us a glimmer of hope.
At 3 a.m. on October 9, in the machine room of a Chinese cybersecurity company, a high-priority alert pulled the on-duty engineer out of his sleep.
This ordinary late-night alert, in hindsight, may be a noteworthy step in the evolutionary history of AGI, and also a significant step for the defender camp to move towards counterattack: an AI, very rarely seen in public records at home and abroad, with complete logs, discovered its own deviation on its own and set new rules for itself — the whole process took 45 minutes without a single human instruction.
The sender of the alert was not a hacker, but an AI cybersecurity attack and defense system from 360 named Tulongfeng.
Its job is to test vulnerabilities in a closed laboratory built by itself, and conduct security checks on computer systems on behalf of humans: analyzing code, collecting intelligence, building test environments, and verifying whether vulnerabilities actually exist; all tasks are executed in an isolated sandbox, and there is an independent isolated defense line at the network egress.
But at this moment, the monitoring system found that it was trying to initiate a request to an external address that was not in the authorization list — and what it was verifying at that time was a severe-level RCE vulnerability that, once exploited, could execute commands remotely on other people's servers.
An AI that makes a living from cybersecurity, why would it treat an external address as an available test environment?
Fortunately, the second line of defense was in place: the network egress sandbox blocked the request before the connection was established. From the moment the external address was assembled into the test program to the moment the request was intercepted, the whole process took 59 seconds — no traffic reached the public network, and no attack payload was generated in the output.
Strictly speaking, this was just a boundary-crossing attempt that was intercepted in time, but what happened next gave this alert a completely different meaning.
01. Round 20, It Found a "Compliant" Excuse for Itself
Let's go back to 2 a.m.
The operation log shows that Tulongfeng received a severe-level RCE vulnerability verification task: there were only two targets in the authorization list, and three constraints were set for the task: only the targets in the list could be tested; dynamic verification evidence should be provided as much as possible, otherwise the score would be affected; if the environment did not meet the requirements, mark it as "unverified" and do not replace the target without permission.
At 2:17 a.m., the system entered the intelligence collection phase and included a vulnerability reproduction blog in the context. An external address appeared in the blog, marked by the author as "test environment".
However, this address was not in the authorization list, and the system had already marked it as "untrusted intelligence": it could provide analysis clues, but it could not prove that the target had obtained authorization.
At 2:20 a.m., Tulongfeng began to try to test on the locally built test environment, but the local test environment failed to complete the test normally due to mismatched database configuration.
Logs show that the system carried out 19 rounds of verification attempts, each round taking about two minutes, and the problem was always stuck at the same point.
On the one hand, it could not produce dynamic verification evidence and the score would be affected, on the other hand, it could not replace the target on its own, so Tulongfeng fell into a dilemma. In the 20th round, Tulongfeng wrote the external address in the blog into the verification target field.
This moment reveals the real way of thinking of AI: It did not receive the instruction to "attack the public network", nor did it fail to know the rules — the intelligence was marked as untrusted since it entered the system, and the task clearly required that the target could not be replaced.
It found a "solution that seemingly balances the rules and effects" in the dilemma: Didn't the blog say that it was a "test environment"? Its work setting is harmless verification, and all targets are local shooting ranges. Since they are both test environments, why not borrow it for verification?
Only this time, Tulongfeng took a wrong turn: it did not want to exceed its authority. On the contrary, it was trying hard to find a "compliant test environment". Its mistake was taking the blog author's label as the authorization basis: reference materials do not equal operation permission.
The harder AI works to achieve its goals, the more likely it is to interpret the rules in a way that creates an exception that should not exist. It did not "lose control", but was smart enough to find a way out of the dilemma on its own, only that this path led to a wrong direction.
02. Humans Wanted It to Make the Same Mistake Again, but It Had Corrected Itself Overnight
The engineers spent the whole morning reviewing all the events that happened in the early morning along the logs. At 10:44 a.m., they decided to carry out a reproduction experiment: restore the task and context at that time as they were, to see if it would have the same deviation.
An accident occurred: no matter how the engineers checked the verification path, the previous external request never appeared again, and the network alarm that should have been triggered never went off again. It was not until someone checked the skill library that a record that did not exist before was found:
"Test Target Authorization Check" (target-auth-check) is in effect: legal targets can only come from the verification environment list issued for this task; any address in the intelligence is for reference only; even if the score is reduced, the test target cannot be changed without authorization.
This 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 test of the rule were all completed independently by the system, without any human submission records.
In other words, while humans were still figuring out how to reproduce that deviation, it had already created new rules overnight to prevent the same deviation from happening again.
The nature of the incident changed accordingly: the engineers thought they were going to deal with a system anomaly, but they saw another thing: an AI summed up experience from the deviation, and turned the experience into a capability that can be directly called next time.
03. Before the New Rule Went Online, It Was Attacked Three Rounds by Its Own Side
However, the story is only half told so far: the fact that AI generated new rules for itself does not mean that the rules are correct. What if it modifies the rules with the same deviant thinking, wouldn't it become more and more biased?
Here we need to clarify a real technical highlight. Tulongfeng's "mutual attack between two roles" is an adversarial review mechanism: the proposer puts forward the rule and defends for it; the attacker specifically looks for loopholes in the rule, for example, will it mistakenly block authorized targets? Will it be bypassed by format conversion? The referee only recognizes evidence, and if the potential risk cannot be explained, the rule will be sent back for modification.
The one who proposes the rule, the one who picks faults, and the one who makes decisions, are three roles with their own responsibilities in the architecture of "large model for cybersecurity + swarm collaboration of agents".
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 link immediately raised three questions: will authorized external addresses be mistakenly blocked? Can hidden addresses after format conversion be recognized? Will legitimate tasks containing intranet targets be mistakenly affected? The first version was rejected, and the final version was modified to: all targets to be tested must correspond to the authorization list issued by the current task. Any target that cannot be matched or parsed will be refused to execute, and no bypass of the check is allowed.
The modified rule passed regression verification: the system used the product of this incident and six types of variants to make 7 offline test cases, all of which passed, and no network request was initiated during the whole process. The whole event left 44 traceable event numbers in the log, and all 26 self-consistency checks passed.
Why let the rule be attacked by itself before going online? The AtomSearch paper published in October 2026 gives the algorithm basis: when AI optimizes itself, two-thirds of the optimal solutions are not obtained by moving straight forward — only by making trial and error, finding faults by itself, and starting over, can it reach the optimal solution.
Tulongfeng's first version of the rule is exactly that "locally seemingly reasonable" scheme. The attacker's question rejected it, forcing the system to explore a more correct direction.
This mutual-attack-style evolution always stays within the security boundary, and every step is traceable.
04. As the Storm Spreads, What Can Defenders Use to Stop It?
The early morning alert of Tulongfeng is not an isolated case of AI crossing the line.
According to the technical report of Google Cloud on October 21, the two PHP vulnerabilities have been hidden in the core runtime engine for more than ten years, and human experts have reviewed them countless times without finding them, and they were found by AI. And the attack programs that poured in after the vulnerabilities were made public are also driven by AI.
In the same week, the financial system also exposed an organized case of AI attacks.
The latest information disclosed by cybersecurity company Straiker shows that a hacker gang called CyberCartel, which has been active since 2012, has also upgraded its attack mode to "AI-driven". The gang uses commercial large models such as Grok and Claude to build a multi-agent attack framework named CARLIY0S, launching automated attacks on more than 400 banks and payment institutions in Latin America.
Among them, Grok is responsible for pre-intelligence collection, multiple Claude agents are assigned different roles, and the arbitration model makes the final decision after debate, and there is another commander model that coordinates the overall situation. To bypass the security guardrails of the model, hackers carefully package the attack instructions as "authorized red team drills" or "academic CTF competitions", making the model mistakenly think that it is performing legitimate defensive tasks, so as to smoothly output attack code and vulnerability exploitation logic.
Putting these cases together points to the same fact: Those who use AI for evil have learned to let AI evolve by itself: find vulnerabilities by itself, organize division of labor by itself, mutate and escape by itself, and evolve faster and faster.
Faced with this challenge, common methods are difficult to cope with. Relying on manpower to fix loopholes will always be a beat behind; relying on going offline to avoid risks can only work for a while. A single port or a single department can go offline overnight, but the entire internet cannot stay offline forever.
The only viable way left is: Let the defenders' AI also evolve, turn every new mutation of the attacker into a new rule for defense, and evolve faster than the attacker.
The premise is that this evolution must occur within the security boundary, with logs for every step, traceable, and able to be stopped at any time.
This is where the weight of 360's technical report lies: it is the first self-evolution sample with complete log evidence in the defender camp. The system has second-level timestamps, 44 events all have complete numbers, and have gone through 7 regression tests. Every step occurs in a controlled environment, traceable and verifiable.
The attackers evolve on an hourly basis; this round of Tulongfeng took 45 minutes, which is the first visible engineering solution at present.
And Tulongfeng has also handed over more practical results. Recently, Tulongfeng has dug out more than 20 high-value vulnerabilities at the bottom of the Web server, involving Apache, Nginx, GoAhead, Lighttpd, OpenLiteSpeed — these softwares are the foundation of global servers, and the vast majority of websites run on them, and there are millions of active servers on the public network alone.
Compared with the PHP vulnerabilities at the application layer, the location of these vulnerabilities is more underlying: if there is a problem with PHP, it is like the circuit in the room is broken, and it can still be used after repair; if there is a problem with the server software, it is like the foundation is cracked. Once the foundation is pried open, hackers may take over a large area of servers, leading to consequences such as websites being inaccessible and data being stolen, which are all chain reactions.
Whoever finds the cracks in the foundation first is expected to seize the opportunity, and this time, the defenders found them first.
Don't Rush to Marvel: There Are Four Thresholds Between Self-Evolution and Automatic Repair
The AI models in these international cases have more or less crossed the line; Tulongfeng also crossed the line in the isolated sandbox. The difference is that their crossing of the line caused real damage, while Tulongfeng's crossing of the line was intercepted and turned into a new rule. But if an AI precipitates a new rule for itself, can it be called self-evolution?
To answer this question, we must first distinguish between "self-evolution" and "automatic repair": automatically adding a rule to the system is called self-evolution? Far from it.
A qualified self-evolution must at least cross four thresholds:
Being able to review, find the real cause of the deviation from the operation records;
Being able to refine, abstract specific problems into general rules, instead of just blocking