Is this the new cyber normal?
A recent wave of high‑impact software vulnerabilities, including AI‑assisted exploits in core infrastructure like PHP, has many engineers asking whether constant 0‑days are now the “new cyber normal.” Commenters are split: some see a temporary spike as large language models rapidly mine decades of legacy code for long‑latent bugs, while others think AI‑generated “slop” and faster exploit chains will keep pressure high indefinitely. Across viewpoints, there’s broad agreement that security must shift left—toward memory‑safe languages, simpler architectures, automated LLM‑based auditing, and faster patching—because attackers and defenders now have access to the same powerful tools.
Overall question: “New normal” or temporary spike?
- Some argue this is a transitional “gold rush”: LLMs are clearing a long-standing backlog of bugs, so the rate of new high‑impact vulns should eventually drop once code is more systematically scanned and rewritten.
- Others see a genuine “new normal” (or worse to come): near‑zero‑day exploitation across multiple fronts, with windows between disclosure and mass exploitation shrinking dramatically.
- A third view: this is just the old normal turned up to 11; worms, bad CAs, and sloppy software have always existed, but LLMs accelerate both discovery and exploitation.
AI’s dual role: attacker and defender
- Attackers can now cheaply perform code review, fuzzing, exploit development and OSINT with LLMs. This makes obscure, “theoretical” bugs practically exploitable.
- Defenders can also use LLMs: continuous pentesting, automated code reviews, dependency upgrades, and scanning legacy code. Some report fewer customer‑reported issues and better pen‑test outcomes after adopting LLM tooling.
- Debate on coordinated disclosure: hints about a bug may be enough for attackers to have LLMs reconstruct the exploit quickly, weakening traditional embargo models.
Security of AI‑generated code
- One camp: AI‑generated code is “notoriously terrible” at security, easily shipping SQLi, XSS, missing auth, bad configs, and unsafe deployment patterns—especially when devs blindly trust bots and skip review.
- Another camp: modern frontier models can produce very defensive code and catch many high‑priority issues, particularly when used in multi‑step “generate → review → audit” pipelines with explicit security prompts.
- Concerns:
- “Vibe coding” and code flooding without human oversight.
- AI choosing outdated or unmaintained libraries, or re‑implementing instead of reusing hardened ones.
- Overreliance on outdated studies of older models.
Finite vs endless vulnerabilities
- Some assert there’s a finite pool of serious bugs per codebase; once LLMs exhaust what they can find, things calm down.
- Others counter that ongoing changes, complex specs, and Turing‑complete systems keep generating new vulns; only formally verified or radically simplified stacks could meaningfully cap this.
Shifts in software practice and architecture
- Calls for:
- Memory‑safe languages (e.g., moving away from C/C++), simpler architectures, fewer dependencies, and smaller attack surfaces.
- Treating LLM security scanning like tests/CI: a standard pre‑release step.
- Possibly more LTS/security‑only releases and more static/simple systems; some even talk about taking critical systems offline.
- Skepticism that current incentives (speed, cost‑cutting, “ship it”) will support the needed discipline.
Other recurring themes
- Closing source (e.g., NHS‑style) is seen as weak protection: decompilation and AI‑assisted fuzzing still work.
- Worries that small teams and non‑“big players” are disproportionately hurt by rapid, opaque disclosure cycles.
- Broad agreement that human security awareness is low, underinvestment is chronic, and without cultural/regulatory change, LLMs will amplify both strengths and weaknesses.