The Internet Now Lives on the Ring of Fire

Wu Yuwei published on
11 min, 2426 words

Categories: Opinion

I used to live in Taiwan, and these days I live in Japan. On a map they look like two very different places, but geologically they share the same address: the Pacific Ring of Fire. Moving from one to the other didn't change one thing: the ground still shakes, and it shakes all year round. After enough years of this, earthquakes stop being events and become background noise. A phone screams with an alert, the lamp starts swinging, and the first thought isn't panic but a quick calculation: is this a small one, or do I need to get under the table? Most of the time it passes in a few seconds and everyone goes back to what they were doing, but you never fully forget that the floor you're standing on is not as solid as it looks.

Lately, the internet feels the same way. Since AI-assisted vulnerability discovery took off, new CVEs land by the hundreds every day, and the high CVSS scores keep coming with them. In June, FIRST forecast around 66,000 CVEs for 2026, and Google's threat intelligence team saw monthly disclosures double from about 5,000 in January to over 10,000 by July. TLS, the thing quietly holding up almost every connection we make, is no exception: OpenSSL shipped 12 CVEs in January, all found by an AI system and some hiding in the code since the late '90s, then another 18 in June, headlined by a high-severity use-after-free found with AI's help. Mozilla fixed 271 vulnerabilities in Firefox 150 surfaced by an AI model. And just this week, PHP shipped security releases for two critical flaws, both scored 9.2 under CVSS v4 and both allowing unauthenticated remote code execution, affecting basically every PHP installation serving the web. Rapid7 recommends patching them on an emergency basis, outside normal patch cycles. None of these bugs are new. Like fault lines, they were sitting in the code all along, some of them for decades; a CVE is just the moment one of them finally slips. Each alert is another tremor. Most of them pass, we patch and move on, but the ground under the internet has never felt less solid.

Lessons from the Ring of Fire

Neither Taiwan nor Japan gets to move away from the fault lines. The earthquakes aren't going to stop, so over the past few decades both countries stopped hoping they would and focused on surviving them instead. I think the internet is in the same position now. AI isn't going to stop finding bugs, and the CVE count isn't going back to what it used to be. So instead of asking how to make the shaking stop, maybe we should look at what people living on the Ring of Fire have already figured out.

The first lesson is early warning and drills, and the good news is that we already have both. Japan and Taiwan both run earthquake early warning systems that detect the first waves and push an alert to phones in the affected areas, giving people anywhere from a few seconds to a few tens of seconds before the strong shaking arrives (though places right next to the epicenter may get it too late). Both countries also measure how bad the shaking is on a seismic intensity scale, Japan's and Taiwan's each with ten levels.

The internet has its own version: a CVE ID tells everyone that something is broken, and a CVSS score tells them how big it is. Coordinated disclosure gives maintainers time to prepare a fix, and the people who ship the software often get a heads-up before the public announcement. With the PHP flaws this week, Linux distributions and LTS vendors received the patches in advance. On the drill side, most companies have some kind of process too: someone watches the advisories, someone decides what's urgent, and there's a playbook for rolling out a patch.

So the problem isn't that these systems don't exist. It's that they were designed for a quieter era, and now they need to get better. An early warning is only useful if people know what to do in those few seconds, which is why both countries keep running disaster drills even when nothing is happening: Japan on Disaster Prevention Day every September 1st, and Taiwan on National Disaster Prevention Day, September 21st, the anniversary of the 921 earthquake.

An early warning is also only useful if people still trust it. Japan's public warnings are only issued when the expected intensity reaches 5-lower or above (or long-period ground motion class 3 or above), which JMA chose because that's where significant damage starts to occur. And the warning only goes to the areas expected to feel strong shaking, plus those expected to reach intensity 4, in case the estimate is off or the shaking grows. It's based on intensity, not magnitude. A phone that screams at every small tremor, or at a big one far away, would soon be ignored.

Our processes face the same two pressures. When the number of new CVEs a day doubles in half a year, triage has to get sharper so the critical ones aren't buried under the noise. The catch is that a CVSS score is closer to an earthquake's magnitude than its intensity. Magnitude describes the earthquake itself, the same number for everyone. Intensity describes how hard the ground shakes where you are standing. A CVSS 9.2 bug in a component you don't run is a big earthquake on the other side of the world. The intensity is what the bug means for your own environment: do you ship that component, is it exposed to the internet, and is anyone actually exploiting it? So triage has to go by intensity, not just magnitude: combine the CVSS score with what you actually run and expose, with FIRST's EPSS, which estimates how likely a CVE is to be exploited in the next 30 days, and with CISA's Known Exploited Vulnerabilities catalog.

And the response has to be practiced enough that it doesn't depend on heroics. If upgrading PHP is a scary, manual, once-a-year event, a critical RCE turns into a long, stressful week. If you have automated builds, tests you trust, and a deployment pipeline you've already exercised many times, an emergency patch is just another Tuesday.

Rewriting the Building Code

But warnings and drills only help you react. The second lesson is about what you build in the first place, and here both countries learned the hard way that building codes have to be rewritten after every major disaster. Japan introduced its new seismic standard in June 1981, and when the Great Hanshin-Awaji earthquake hit Kobe in 1995, most of the deaths came from collapsing buildings, with the damage concentrated in buildings built before 1981 that didn't meet the new standard. Taiwan learned a similar lesson from the 921 earthquake in 1999. In the years that followed, it revised its seismic zones, added near-fault effects to its seismic design code, and started retrofitting public buildings, more than 4,600 of which had been damaged in the earthquake. The new rules weren't perfect, but each disaster became data for the next standard.

In software, I like to think of programming languages as building materials. Buildings range from wood to steel frames to reinforced concrete. Languages have a similar range: from memory-unsafe ones like C and C++, to garbage-collected ones like Go, Java, C#, or Python, to languages like Rust that are memory-safe without a garbage collector. Japan's building code doesn't say everything has to be made of reinforced concrete. It has separate structural rules for each material, and a house built properly out of wood, steel, or concrete can all survive a big earthquake. The same goes for software. It doesn't all have to be Rust.

Wood is a good example of a material that keeps getting better rules. Japan revised its requirements for wooden houses again in 2000, clarifying how joints and connections, among other things, have to be built. When the 2016 Kumamoto earthquakes hit, the difference was clear. In the center of Mashiki, one of the hardest-hit towns, 28.2% of wooden houses built before June 1981 collapsed, compared to 8.7% of those built between June 1981 and May 2000, and only 2.2% of those built from June 2000 on. Of the 297 wooden houses that collapsed there, 290 were built before the 2000 revision.

C and C++ go through something similar. Each new language standard, like C17, C23, or C++26, is a revised building code for wood: C23 added checked integer arithmetic and memset_explicit, and C++26 adopted standard library hardening to catch things like out-of-bounds access. Projects that keep up with these standards can be in better shape than ones still written like it's the '90s. And well-maintained wood can last an astonishingly long time. Some of the wooden buildings at Hōryū-ji have been standing since the late 7th or early 8th century. Some old C code bases are like that too: carefully looked after for decades, and still holding up.

But if you're about to build a modern high-rise, you should think hard about which material to use. As of 2019, around 70% of the CVEs Microsoft assigns came from memory safety issues, and the headliners from earlier, OpenSSL's use-after-free and PHP's memory corruption and use-after-free, are the same kind of crack. AI turns out to be very good at finding these cracks in wooden structures. With memory-safe materials, the compiler or the runtime acts as an inspector that refuses to let most of these cracks in. And it works: after Android shifted new code to memory-safe languages, including Rust, memory safety bugs dropped from 76% of its vulnerabilities in 2019 to under 20% in 2025, and Google conservatively estimates that Android's Rust code has a more than 1000x lower memory safety vulnerability density than its C and C++ code.

So the lesson isn't "rewrite everything in Rust." It's the same principle Japan's building code already follows: pick the material that fits what you're building, and follow the latest code for that material. A small house can be made of wood, as long as it's built to today's standard and not the one from 1980. A high-rise that thousands of people walk into every day deserves a harder look at what it's made of. For software, the high-rises are the code that faces the internet directly and that everything else depends on: TLS stacks, parsers, language runtimes, the request handlers that touch untrusted input before any application code runs. For those, it's worth seriously considering a memory-safe language, and in some cases, a rewrite. Language runtimes are worth singling out. The PHP flaws from earlier weren't in anyone's PHP code; they were in the C runtime underneath it. A steel-frame building on a wooden foundation is only as strong as the wood. And if you look closely, most software still rests on wood somewhere, since operating system kernels and system libraries are largely written in C. That's not a reason to give up. It's a reason to know where your foundation is, and to reinforce it first.

That doesn't mean tearing out the foundation. Japan didn't demolish every pre-1981 building after Kobe; it passed a law in 1995 to promote seismic retrofitting, and started with large buildings used by many people, like schools, hospitals, and department stores. CPython, whose interpreter is written in C, is now considering the same approach. The Rust for CPython proposal, motivated in part by crash reports climbing from 82 in 2021 to 222 in 2025, starts small: an optional Rust backend for the zlib module, with the C code kept as a fallback, and more modules like json and the parser later on. Rust wouldn't become a build requirement until 2029 at the earliest, and as the presenter put it, CPython "should not be written in Rust for the sake of Rust." That's what retrofitting looks like in software: start small, with a contained piece, and keep the building standing while you work. For everything else, keep up with the code: move to newer language standards, turn on the hardening your toolchain already offers, adopt the newer guidelines, and fix the weakest parts first.

Here in Japan, my phone will keep screaming with earthquake alerts, and I'll keep doing that quick calculation: is this a small one, or do I need to get under the table? What makes that calculation possible is decades of warnings, drills, and building codes, put in place by people who accepted that the shaking would never stop. The internet needs to get to the same place. The earthquakes won't stop, but the next one doesn't have to bring the same buildings down.