Leiphone reviews the global 72-hour security storm: Behind the PHP2Shell and GitLab full-score vulnerabilities, AI is rewriting offense and defense

If you happened to step on all of these landmines yesterday, you're probably the unluckiest security engineer of 2026. Imagine: your website runs on a Linux server, the frontend uses Nginx as a reverse proxy, the backend mixes Go, PHP, and Node.js, your code lives in a self-hosted GitLab, updates go out through an automated release pipeline, and for your HTTPS certificate you picked a certificate chain issued by eMudhra. Congratulations—you've won the security vulnerability combo platter. On October 21, PHP officially disclosed two remote code execution vulnerabilities rated 9.2 out of 10 in severity (codenamed PHP2Shell). An attacker needs no account or password—just send one HTTP request and they can take over your server outright. The same day, GitLab, the world's largest self-hosted code repository platform, also blew up, disclosing an even more severe perfect-score vulnerability affecting every version from the past 12 years; attackers could break into your code repository server and execute arbitrary code without logging in. The Node.js team also released a security update that day, fixing more than 10 vulnerabilities in one go, 4 of them high severity. And just a week earlier, the web server nginx had just patched 5 security vulnerabilities, including serious ones like buffer overflows and use-after-free that let hackers manipulate system memory and seize the highest level of control outright. You start patching overnight: upgrade the PHP version, restart the Node services, change the Nginx configuration, then take the system down to upgrade GitLab and run database migrations—and the entire development team behind you is forced to a complete standstill. Just as you finally catch your breath and go check the HTTPS certificate, you discover that eMudhra has a fatal weak-entropy vulnerability. Even though mainstream browsers have already blacklisted it at lightning speed, the curl, Python, and Go on your server still trust it by default—equivalent to leaving a backdoor that can forge the identity of any website, making man-in-the-middle attacks easy. From the operating system to the web server, from programming language engines to the code repository, from runtimes to the certificate trust chain, there are surprises at every layer—all high-severity or even perfect-score vulnerabilities. Then you scroll the news and see a few more bad headlines: according to the attackers' claims, PingCAP's cloud database TiDB Cloud suffered a massive data breach, with 10.6TB of core data exfiltrated by attackers, including a large number of customer API keys and code repository information; the Plex media server commonly used on home NAS devices was also found to have a vulnerability chain, which attackers used for cryptomining and planting backdoors. Meanwhile, India's State Bank of India (SBI) also confirmed a data breach. In the third week of October 2026, the global internet operations and security community collectively entered wartime footing. Decades of accumulated security debt across the world's software infrastructure is coming due all at once. And behind all these incidents, a variable that is breaking the balance between attack and defense has already surfaced: AI. The discoverer of PHP2Shell explicitly stated that AI-assisted codebase analysis was what enabled them to quickly find this vulnerability that had been hidden for over a decade. And against the same regex engine in GitLab, security researchers using AI found four tricky vulnerabilities in a row in just one month, far exceeding the normal pace of purely manual research. AI makes finding vulnerabilities faster, and makes exploiting them easier too. Every hour after a patch is released is a race between attackers and defenders: hackers use AI to dissect patches and mass-generate attack scripts, while operations teams must upgrade overnight before they're breached. Someone said on social media: "The worst is yet to come—a huge amount of stuff is surging toward us." Someone else replied: "This is a good thing; it will ultimately lead to a safer internet." But before that "safer internet" arrives, how many more sleepless nights will we have to endure? 01

Starting with the PHP security incident The internet security ecosystem of 2026 can be glimpsed through the sensational global PHP incident. On October 20, the PHP security team issued an unprecedented advance notice:

English text is being prepared.

GitLab, another even more serious security incident. On the same day PHP released its patches, GitLab also pushed out an emergency security update. This time it fixed a remote code execution vulnerability with a perfect CVSS score of 10.0, tracked as CVE-2026-110264. The problem lies in Ruby's built-in Onigmo regular expression engine—a classic integer overflow flaw. An attacker only needs to craft a regular expression containing an extremely large repetition count to trigger it. When the engine calculates the memory space required, a numeric overflow occurs, and the allocated buffer is far smaller than what is actually needed; subsequent writes then overrun and overwrite adjacent memory, allowing the attacker to seize direct control of the server. This vulnerability has existed since GitLab 7.0 in 2014—it lay dormant for a full 12 years. Public analysis so far indicates the attack path most likely triggers through Org-mode file rendering: an attacker only needs to submit an Org file containing a malicious regular expression to a public repository, and GitLab will trigger the Onigmo flaw when rendering the preview—no login privileges are required at any point. To fix this vulnerability, GitLab unprecedentedly backported the patch to seven versions, including 19.5.1, 19.4.3, 19.3.6, as well as the long-unsupported 19.2.9, 19.1.9, 19.0.10 and 18.11.13. By comparison, GitLab normally maintains only the latest three version branches. What alarms the security community even more is the frequency with which these vulnerabilities are erupting. This is already the fourth GitLab regex engine code execution vulnerability reported by researcher joaxcar within a single month. The first three were fixed on September 23 and October 12 respectively, with scores also between 9.9 and 10.0. This is clearly not a single bug but an entire class of systemic defects. What is even more exhausting is that countless operations engineers around the world had just stayed up a few days earlier to upgrade their systems to the "latest version," yet after the new vulnerability appeared, the systems they had upgraded still could not defend against it—making all that effort futile. And upgrading itself has costs. The new version includes database schema changes, so upgrading a single-node server requires downtime; for small and medium-sized teams, this means several hours of development standstill. Many can only choose to wait and see, finding a weekend maintenance window to act. And those few days of waiting are the attacker's window of opportunity. Compared with PHP2Shell, GitLab's vulnerability has a narrower impact surface, but its destructive power runs deeper. PHP attacks the website itself, whereas GitLab attacks the repository where source code is stored. Once an enterprise's GitLab instance is compromised, attackers can not only steal all the code and keys but also plant backdoors in the code that spread to all downstream systems through the normal release process. This is a classic supply chain attack, and the consequences may only surface months or even years later. That is not all. In the 72 hours surrounding the PHP and GitLab bombshells, two other storms also struck at the internet's foundational trust. First, eMudhra. This certificate authority from India is a "notary" trusted by default by major browsers worldwide. On October 17, security researchers were shocked to discover that when this authority generated eight core encryption certificates, its key generation script malfunctioned. The ultra-strong private keys that should have had countless possibilities—uncrackable even by supercomputers—had their actual value range shrunk to between 0 and 255 due to a lack of random numbers, and the private key value of one critical certificate was simply the number 4. This means anyone could use these weak private keys to forge HTTPS certificates for any website, and browsers would still dutifully display the green security lock. After the incident came to light, Mozilla blocked the relevant certificates through a certificate revocation list within 3 hours, and the browsers of Google, Apple and Microsoft followed suit by blacklisting them. But a large number of non-browser clients—such as curl, programs compiled with Go, and Docker base images—still trusted the problematic certificates. The Go language team subsequently issued an emergency fix, CVE-2026-111943, excluding this problematic certificate chain from the standard library, but all programs compiled against older versions must be rebuilt for the fix to take effect. Then there was PingCAP's TiDB Cloud. The hacker group FulcrumSec disclosed and claimed that they exploited cloud service credentials left behind in PingCAP's internal code repository (including GCP and Azure credentials) to establish a data replication channel, fully exporting all data from the production control plane once every 6 hours during the attack—88 times in total without triggering any alerts—stealing as much as 10.6 TB of data cumulatively. According to the list they published, the leaked contents include 413 private code repositories, over 20 million customer SQL query records, tens of thousands of customer keys (including Pinterest's AWS root key, a GitHub token managing thousands of repositories, and a large number of OpenAI and Anthropic API keys), and even the internal network architecture information and contract pricing of major customers are prominently listed. What's more, the leaked developer data table also covered the personal email addresses and social media profiles of more than 20,000 developers at a large number of leading domestic tech companies. At present, some of the leaked data is already circulating on the dark web. Although PingCAP officially and urgently confirmed that it had suffered unauthorized access and stressed that its customer databases themselves were not directly affected, this major leak—serious enough to undermine supply chain security—has still dealt a heavy blow to trust in the cloud security field. 03

AI "Enters the Game": The Tearing Down and Rebuilding of Global Cyber Offense and Defense When we review this chain of storms, we find that AI is the most easily overlooked yet also the most critical variable. It is simultaneously rewriting the rules of the game on both the offensive and defensive sides, pushing the entire cybersecurity industry into a race era of "machine speed." In the PHP2Shell incident, AI had already played a core role: OpenAI led cross-border collaboration through its "Patch the Planet" program, and the security company Calif used the GPT-5.6 Sol model to discover the key memory flaw involved; Google's Wiz team also independently found the same set of vulnerabilities using its Atlas multi-agent vulnerability discovery system. In the end, more than a dozen cloud vendors and CDN service providers were brought into a secret remediation list, completing cross-institutional protective preparations before the vulnerabilities were disclosed. Similar AI security arrangements are rapidly rolling out across the industry. Google Wiz's Atlas system, through a multi-agent division of labor involving code understanding, hypothesis generation, and cross-validation, has already discovered and verified more than 200 previously unknown security vulnerabilities in mainstream open-source projects; in October, Microsoft just added "Guardian Agents" to its enterprise security system, specifically using AI to supervise the behavior and permissions of other business AI agents and prevent internal risks caused by agents exceeding their authority; Anthropic is promoting Project Glasswing, working with industrial giants such as Hitachi to apply the Claude model to routine security protection in public utility sectors such as energy and transportation. But AI has never been a weapon exclusive to defenders. Just in October, Microsoft disclosed that the hacker group Storm-0940 had used the ARTEX AI penetration testing framework to launch a supply chain attack by compromising the ConnectWise cloud backup tool, infiltrating thousands of enterprise tenants worldwide at "machine speed," covering more than ten industries including aerospace, finance, and manufacturing. Amid the race between offense and defense, the cost barrier is rapidly widening. AWS relies on a global honeypot system codenamed MadPot to continuously monitor threats, capturing hundreds of millions of potential attack probes every day; Microsoft concentrates on fixing thousands of vulnerabilities on its monthly Patch Tuesday, building a defensive barrier with massive computing power. These are all "money defenses" that only big companies can afford to play. But the vast majority of the 1.5 million unpatched PHP servers worldwide belong to small and medium-sized enterprises, open-source projects, and individual developers. If the cost of defensive tools remains prohibitively high, the security level of the entire internet will only become more sharply polarized. There is only one way out: drive down the cost of AI security auditing. Interestingly, in the same week that the global security storm was fermenting, details of the next-generation foundation model GLM-5.5 from the domestic large-model vendor Zhipu began to leak. In a Zhipu expert exchange summary circulating across the internet, it was revealed that GLM-5.5 had validated two technical routes in parallel: one strengthening code capabilities, and the other deepening general logical reasoning. In the end, the code direction won out and received more budget and resource allocation. Core security tasks such as code auditing, vulnerability discovery, and patch generation are essentially extensions of code understanding capabilities. A large model deeply optimized specifically for code understanding is naturally an efficient security auditing engine. It can push the capabilities of top security teams down to every code commit and every round of routine inspection. Several technical directions mentioned in the summary all have clear value in a security context:

Recursive self-improvement can enable security auditing to automatically loop and iterate, no longer relying on accidental discoveries by human researchers;

An autonomous data production flywheel means security capabilities will not be strangled by the technology policies of overseas vendors—in scenarios involving the protection of critical infrastructure, this is an irreplaceable advantage. Of course, GLM-5.5 has not yet been released. It is said that the problem of loss not decreasing has just been solved, and whether a foundation model with 3 trillion parameters can be trained stably to completion, whether its code capabilities can reach a flagship position, and whether inference costs can be low enough to support large-scale security auditing all remain unknown. But the direction is already clear. What AI is changing is not only the way we write code, but also the speed at which we discover errors in code. Once this speed changes by orders of magnitude, the balance between offense and defense will be recalibrated. ▼ Leiphone.com Recommended Reading ▼

After Jev went viral across the internet, we answered a few questions

2026-09-21

When the traffic tax is taken by APIs, what moat do ByteDance and Google have left?

2026-08-12