未知漏洞：為何開發者應超越安全程式碼思維

Recent security incidents, zero-days, and AI are reminders that writing secure code is only part of building secure systems.

Over the past few days, several security incidents caught my attention. Critical vulnerabilities in PHP, security issues in Node.js, and a particularly interesting incident involving HTTPS Certificate Authorities.

What interested me wasn't just how serious these vulnerabilities were. It was how different they were, and how each one affected something developers normally rely on.

We spend a lot of time making sure our applications work correctly, validating inputs, handling authentication, and following best practices. But even if we do all of that, our applications still depend on components we don't fully control.

And that got me thinking about something bigger:

What about the vulnerabilities that already exist in the systems we use, but nobody has discovered yet?

When the Problem Isn't in Your Code

Let's look at three recent incidents.

PHP — PHP2Shell

On October 21, 2026, two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619) were disclosed in PHP's request handling. Under vulnerable conditions, memory corruption could allow an unauthenticated attacker to execute arbitrary code.

The interesting part is that the vulnerability exists in PHP itself.

You could have properly validated inputs, implemented authentication, and avoided common application-level vulnerabilities, yet your application might still be exposed through its runtime.

Red Hat Security Advisory

Node.js — TLS and Runtime Security

The October 21 Node.js security release addressed multiple issues, including CVE-2026-106072, a certificate-validation flaw involving non-canonical IPv4 addresses, and CVE-2026-111497, a memory corruption vulnerability in the Brotli decoder.

These vulnerabilities have different exploitation requirements, but they illustrate how problems inside underlying components can affect the applications depending on them.

In the TLS case, the issue was particularly interesting because the representation of an address could influence how the server's certificate was validated.

Node.js Security Release

eMudhra — When the Trust System Itself Fails

This one deserves a closer look.

In October 2026, eight intermediate Certificate Authority (CA) certificates operated by eMudhra were found to have extremely weak private keys.

These were P-384 cryptographic keys, but their private values were smaller than 256.

Normally, P-384 private keys are generated from an enormous range of possible values. With such a tiny set of candidates, recovering the affected keys became practically trivial.

Why does this matter?

When your browser connects to an HTTPS website, it relies on a chain of trust:

Trusted Root CA → Intermediate CA → Website Certificate

If an attacker obtains the private key of a trusted intermediate CA, they may be able to issue fraudulent certificates for websites they don't control.

Combined with the ability to intercept a connection, this could allow website impersonation against clients that still trust the affected certificates.

Mozilla responded by blocking the intermediates, and the affected CA certificates were revoked.

There is no public evidence establishing that attackers exploited these keys maliciously before the discovery. The incident is important because of the risk it created, not because we know that every possible attack occurred.

Mozilla's Incident Report | eMudhra's Statement

Think about that for a moment.

We use HTTPS because we trust its security model, and that model depends partly on the organizations responsible for issuing and managing certificates.

In this case, the weakness wasn't in our applications or the TLS cryptography itself. It was in the generation of keys used by a trusted authority.

Of course, this doesn't mean HTTPS is insecure or that we should stop trusting Certificate Authorities.

It means that even established security mechanisms depend on assumptions, processes, and people that can sometimes fail.

What About the Vulnerabilities We Haven't Discovered?

The incidents above became public because someone discovered and reported them.

But a vulnerability doesn't begin to exist when we assign it a CVE.

It may have been there for months or years.

And the fact that a vulnerability hasn't been publicly disclosed doesn't necessarily mean nobody knows about it.

A zero-day vulnerability is generally a weakness unknown to the responsible vendor or one for which defenders have no patch available when it can be exploited.

Some vulnerabilities may remain completely undiscovered. Others may be known privately to security researchers, criminals, or government-backed threat actors.

This isn't just a hypothetical concern.

In 2021, Microsoft reported that the HAFNIUM threat group was exploiting previously unknown vulnerabilities in Exchange Server.

In 2023, Citizen Lab documented BLASTPASS, a zero-click exploit chain used to deliver Pegasus spyware to iPhones without requiring user interaction.

These examples don't mean every unknown vulnerability is being exploited. But they show why we can't build our entire security strategy around known vulnerabilities and available patches.

Microsoft — HAFNIUM | Citizen Lab — BLASTPASS

AI Is Making This More Interesting — and More Complicated

AI is changing how vulnerabilities are discovered and how some attacks are carried out.

In September 2026, Google Threat Intelligence reported that monthly vulnerability disclosures had increased from 5,045 in January to 10,740 in August.

The average number of vulnerabilities observed being exploited also increased from 10.5 per month in 2025 to 18 per month during January–August 2026.

But there's an important distinction here: these numbers don't mean AI caused all that growth.

Changes in disclosure practices and other factors also influence the statistics.

What we can say is that AI is becoming increasingly useful for analyzing code, identifying weaknesses, and automating parts of security research.

And these capabilities are available to both defenders and attackers.

In November 2025, Anthropic described a cyberespionage campaign in which attackers used AI agents to automate substantial parts of their operations.

That doesn't mean AI can suddenly compromise any system without human knowledge. But it does suggest that some activities which previously required more manual work can now happen faster and at greater scale.

For developers, this raises another question:

If finding and exploiting certain vulnerabilities becomes faster, are we building systems that can detect and contain attacks quickly enough?

Google Threat Intelligence Report | Anthropic's Investigation

So, What Should We Do as Developers?

I don't think the takeaway is that every developer needs to become a cybersecurity specialist.

But I do think we should consider security as part of our engineering decisions, not just a checklist before deployment.

For example:

1. Understand your dependencies.

Know what your application depends on, including runtimes, libraries, infrastructure, and external services. Follow security advisories and prioritize updates based on actual exposure and impact.

2. Think about what happens after a compromise.

Imagine that an attacker gets remote code execution in one of your backend services.

Can that service access every database? Read every environment secret? Connect to internal administrative services?

If the answer is yes, the impact of one vulnerability could be much greater than necessary.

3. Apply least privilege and isolation.

Services shouldn't automatically receive access to everything simply because they're part of the same application.

Separate responsibilities, restrict permissions, and reduce unnecessary connections between components.

4. Don't assume prevention will always work.

Logging, monitoring, backups, incident-response procedures, and tested recovery plans matter because sometimes the first defensive layer fails.

5. Know when to involve security specialists.

Developers should understand the risks their design decisions create, but specialized security assessment still requires dedicated expertise.

The goal isn't to do everyone's job. It's to build software in a way that makes security part of the development process.

A Thought From Syria

As a Syrian developer, this topic matters to me for reasons beyond my personal interest in technology.

We're building and improving digital services across different sectors, from startups and private companies to public institutions.

Every one of these systems deserves appropriate security attention, especially when it handles people's data or provides services they depend on.

This becomes particularly important for government institutions, where a security incident could affect sensitive information, essential services, or large numbers of citizens.

I don't claim to know the internal security practices of these institutions, and I certainly don't assume that the professionals working within them are unaware of these risks.

We have talented developers and security professionals in our community.

What I hope is that we continue giving security the attention it deserves, supporting local expertise, and making independent technical assessment a normal part of building and operating important systems.

Not because we should distrust every technology we use, but because we should understand what we're trusting, why we're trusting it, and what happens if that trust fails.

Final Thoughts

The recent vulnerabilities in PHP, Node.js, and eMudhra are different in many ways.

But together, they highlight something worth remembering:

Writing secure code doesn't automatically mean we've built a secure system.

There will always be vulnerabilities we haven't discovered, dependencies we don't fully control, and risks we can't completely eliminate.

What we can do is make better engineering decisions, reduce unnecessary trust, and design systems that can limit the damage when something goes wrong.

We don't need to become security experts to start thinking this way.

We just need to recognize that security is part of what we're building, not something separate from it.

References

Research reviewed through October 27, 2026.