A critical flaw in PHP, a hijacked AI software package and a certificate authority quitting the business, all in the space of a week. Black October has prompted warnings about a new age of AI-powered cyberattacks. But it also reveals some uncomfortable things about how we build, maintain and secure the software on which much of the internet depends.
Most months don’t get their own Wikipedia page. October 2026 has one.
In information security circles, this month has become known as Black October. The name seems to have started on social media before being picked up by The Guardian, CNBC and The Washington Post. The Wikipedia page is still very much a work in progress, but even the incomplete version makes uncomfortable reading:
- 17 October: A researcher reported that the private keys behind eight intermediate certificates operated by eMudhra, an Indian certificate authority, were weak enough to be recovered. Certificate authorities are the organisations your web browser trusts to confirm that a website is genuine, so anyone holding those keys could potentially have created convincing fake certificates. Chrome and Firefox blocked them, and eMudhra has since announced that it is leaving the global website certificate business.
- 21 October: PHP, the programming language behind WordPress and a large share of the web, released emergency fixes for two critical vulnerabilities now known as PHP2Shell.
- Also 21 October: Attackers hijacked the release process for LiteLLM, a popular open-source tool for connecting software to AI services, and published a version containing malware designed to steal passwords and keys.
- Also 21 October: GitLab, which many software teams use to store and manage their code, fixed a critical flaw that could allow attackers to run code on some self-hosted installations.
- Also 21 October, and not yet on Wikipedia: Railway, a hosting platform popular with developers, disclosed suspicious activity involving systems that store the secret keys and passwords its customers’ applications rely on.
That is a lot for one Wednesday.
PHP2Shell got most of the attention, and it is also what took up most of my week. I have spent a fair amount of time looking at PHP versions.
Some of that was straightforward. Identify the version running on a web server, check whether the security update had been applied, and update it where necessary.
Other parts were less straightforward. What about applications running inside Docker containers, which package software together with its own copy of everything it needs to run? What about third-party services connected to a website? What about software where PHP might be running somewhere behind the scenes, but there is no obvious way to find out which version, or even whether PHP is being used at all?
And who is responsible for updating something when the person paying for it doesn’t know how it works, the person who built it doesn’t maintain its infrastructure, and the company hosting it hasn’t said anything?
These are not particularly new questions. Black October has made them a lot more urgent.
What actually happened with PHP?
On 21 October 2026, the PHP project released emergency updates addressing two critical security vulnerabilities, CVE-2026-109618 and CVE-2026-109619. CVE numbers are simply reference codes used to track publicly known security flaws. Together, these two have become known as PHP2Shell.
PHP is a programming language used to power an enormous number of websites and applications. WordPress, for example, relies on it. But PHP also appears in administrative systems, business applications and products whose users may never encounter the language directly.
The vulnerabilities concerned how PHP manages memory, the working space a program uses while it handles each request from a visitor. Under the right conditions, an attacker could exploit them to make a vulnerable server run instructions of their choosing, from anywhere on the internet, without needing to log in. In security terms, this is known as remote code execution, and it is about as serious as vulnerabilities get.
Both were given a severity score of 9.2 out of 10 on CVSS, the standard scale used to rate vulnerabilities.
A successful attack could potentially give someone unauthorised access to systems and data. Security companies also reported attempts to exploit the vulnerabilities, including some before the fixes were publicly released.
The response was understandably urgent. Government agencies including CISA and the NSA in the United States and the NCSC in the UK urged organisations to update immediately. Hosting providers deployed updates, and some organisations temporarily took services offline while they assessed their exposure.
But Black October has also become part of a much larger discussion about artificial intelligence.
Some security experts have warned of a new era of AI-enabled hacking. There are predictions that software maintainers will struggle to fix problems as quickly as AI systems can find them, while attackers could use the same technology to find opportunities that previously required a great deal of expertise.
There is a serious issue here, although I think some of the discussion risks overlooking what actually happened.
AI didn’t create the vulnerabilities
One of the more revealing things about PHP2Shell is how long parts of the underlying problem had existed.
According to the PHP Foundation’s account of the incident, early signs of one of the vulnerabilities were identified during work following a security audit in 2024.
At that stage, developers understood that there might be a problem with memory handling, but had not found a practical way for an attacker to use it to take control of a server.
Several possible solutions were considered. Unfortunately, each introduced difficult trade-offs: breaking compatibility with existing software, slowing PHP down, opening up other ways to knock servers offline, or requiring changes to third-party add-ons.
Work stalled while the team considered how to fix the underlying issue without breaking other things.
Then, in August 2026, security researcher Ryan A at Calif demonstrated a serious exploit involving the same underlying problem. OpenAI independently identified the same root cause, with further research from OpenAI and Wiz helping establish its impact.
The PHP Foundation had also been using AI tools, including Anthropic’s Claude Mythos and OpenAI’s Daybreak Red, as part of its security research and validation work.
So this was not simply a case of somebody asking an AI to find a vulnerability and the AI discovering something nobody had previously noticed.
Human researchers and developers had already identified part of the problem. AI-assisted research was among the work that helped demonstrate how serious the consequences could be.
I think that is the more important story.
A vulnerability can exist for years without anybody successfully demonstrating how to exploit it. That does not necessarily mean it was harmless during that period. It means our knowledge of it was incomplete.
AI is changing how quickly that knowledge can develop.
And it raises an uncomfortable question. The PHP2Shell flaws affect versions of PHP going back to 5.4, which was released in 2012. If a weakness has been sitting in widely used software for well over a decade, is the problem that AI has finally helped us find it, or that we have been relying on vulnerable software all that time without knowing?
Obviously, the answer is not entirely one or the other.
Making vulnerability research faster also gives attackers more opportunities. A flaw that previously required months of specialist research might become much easier to investigate. Defenders may find themselves dealing with more serious reports than they have the capacity to assess.
But the underlying weaknesses were not introduced by the technology that revealed them.
In that sense, AI may be making the internet appear less secure by exposing how insecure some of it already was.
The numbers are alarming, but what do they mean?
One of the figures repeated throughout the reporting was that approximately 70% of websites use PHP.
That sounds alarming when paired with a vulnerability that could allow somebody to take control of a server.
But it is worth understanding what the figure represents.
According to W3Techs, PHP is used by roughly 69% of websites whose server-side programming language can be identified.
That last part matters. Many websites don’t advertise what they are built with, so the figure only covers the sites where it could be worked out.
It is not the same as saying that 69% of every website on the internet has been confirmed to use PHP, nor that every website using PHP is equally exposed to an attack.
Different configurations, hosting environments and applications can influence whether a particular exploit is practical.
The PHP project’s advice was nevertheless to update every affected installation that handles web requests, covering all the common ways of connecting PHP to a web server: PHP-FPM, Apache’s mod_php, php-cgi, FrankenPHP and LiteSpeed.
The urgency was justified. It just does not follow that every website using PHP was compromised, or even that every website was vulnerable in exactly the same way.
Another widely circulated figure concerned the number of attempts to exploit the vulnerabilities.
Cloudflare’s chief executive, Matthew Prince, said its network saw attempts climb from thousands before the public announcement to millions within hours of it.
But an attempted exploit is not a successful compromise. Several of the security companies monitoring that activity said the attempts they observed had been unsuccessful.
Automated scanners can send thousands or millions of requests looking for vulnerable systems. Some requests may target systems that are already patched, systems using configurations the exploit does not work against, or systems that do not even run PHP.
One attacker can also generate an enormous number of requests.
None of this makes the threat insignificant. It does mean that a figure describing malicious traffic should not be confused with the number of victims.
Cybersecurity reporting sometimes struggles with this, particularly when large numbers make for more dramatic headlines.
A potential vulnerability, an exploitable vulnerability, an attempted exploit and a confirmed compromise are four different things. Pointing that out is not pedantic.
And if businesses are going to make sensible decisions about security, they need to understand which of those things is actually being reported.
You can’t patch software you don’t know you’re running
This brings me back to what I was doing this week.
For websites I manage directly, checking PHP versions was relatively straightforward. I could examine the hosting environment, identify the installed versions, check the available updates and investigate whether applications were compatible with them.
Containerised applications added a complication. A container is built from an image, essentially a template that is used to recreate the application each time it is deployed. Updating the software inside a running container is not the same as updating that image.
You can make a running container secure today and accidentally return it to a vulnerable state tomorrow if the template it is rebuilt from has not been fixed.
But things become much more complicated when you start looking at third-party services.
I was investigating the implications for some Shopify-related services, for example.
Shopify itself is not a PHP application in the same sense as WordPress. However, a business using Shopify might also depend on several third-party apps, each developed and hosted by a different company.
Those apps might use PHP, JavaScript, Python, Ruby, or a combination of technologies.
Some have separate administrative dashboards hosted on their developers’ own infrastructure. Some have websites that reveal information about the technology they use. Others reveal very little.
I could inspect publicly accessible parts of these services, look for information about their underlying technologies and check whether their developers had published security updates.
But that is not the same as knowing every component of their infrastructure.
A third-party service might use PHP to process data behind an API (the behind-the-scenes connection that lets one system talk to another), run scheduled tasks, manage administrative functions or provide an internal application, even if its public website is built entirely with JavaScript.
The reverse can also be true. A website might show evidence of PHP somewhere in its infrastructure without that establishing whether the vulnerable part is actually exposed to the internet.
I think this point has received relatively little attention.
Not all PHP is visible from the front end of a website, and not all PHP is used in the same way.
A PHP application can generate a page that is then stored and served by a content delivery network, a service that keeps copies of pages on servers around the world so that they load quickly. Looking at the public page may tell you very little about the software that produced it.
Other installations might only run scripts behind the scenes, such as a scheduled job that sends out invoices overnight.
Those installations still need maintaining, but a vulnerability triggered through handling web requests does not present the same immediate risk to a PHP installation that never receives any.
Then there are the applications and devices that come with their own copy of PHP built in.
Updating the operating system’s PHP may do nothing to secure those if they use separate versions supplied by their vendors.
Even version numbers need some interpretation. A Linux distribution or hosting provider might copy a security fix into an older version rather than moving to the newest release, a practice known as backporting. The version number can then look out of date even though the fix has been applied.
A publicly reported version number can therefore be a useful clue, but it is not always conclusive evidence of whether a system has been patched.
Tools such as Wappalyzer, which guess what a website is built with from clues in its code, can help identify possible dependencies, as can the technical information a server sends along with each page. None of them can provide a complete inventory of everything running behind a domain.
That is not a criticism of those tools. It is a limitation of what can reasonably be observed from outside a system.
For a small business, the practical difficulty is obvious.
You may own your website, but you probably do not know the programming languages used by your booking service, email marketing platform, payment integration, customer management system or every plugin connected to it.
And even if you did, you might have no ability to update them yourself.
You are depending on other organisations to recognise the vulnerability, determine whether their services are affected and apply the necessary fixes.
Sometimes that is a perfectly reasonable arrangement. Indeed, having a competent provider manage your infrastructure can be much safer than attempting to maintain everything yourself.
But it requires somebody to actually accept responsibility for the maintenance.
What happens when AI builds the website?
This is where another development in the software industry becomes relevant.
Tools such as Lovable are making it possible for people with little or no programming experience to create functioning websites and web applications.
Somebody can describe what they want, ask the AI to build it, make changes through further instructions and publish the result.
I think this is a genuinely useful development.
Software development has traditionally required a lot of technical knowledge before somebody can begin testing an idea. Reducing that barrier means more people can build useful things without having to become professional developers.
But it raises a question that becomes especially pointed during something like Black October.
What happens when a critical security vulnerability is discovered in technology used by an application whose creator does not even know that programming languages exist?
Take Lovable as an example.
Lovable commonly builds applications using a modern JavaScript-based setup, with things like the database and user logins provided as managed services. PHP is not normally part of that arrangement, so the PHP2Shell vulnerabilities would not automatically apply to a typical Lovable project.
That is already an important point.
But those applications still depend on programming languages, libraries of pre-written code, databases, login systems, connections to other services and hosting infrastructure.
Some of those components are maintained by Lovable or its infrastructure providers. Others form part of the application being generated, or are third-party services the creator has chosen to connect.
And the responsibility for keeping them secure is not necessarily the same.
The good news is that Lovable does provide security tooling.
According to its security documentation, a Quick security scan runs as part of the publishing process. It looks for issues involving database access rules, dependencies and other common configuration problems.
There is also a more thorough Deep security scan that examines application code for security issues specific to the project.
Lovable has an Auto-fix security issues setting, which users can enable in their project settings.
When enabled, Lovable can include eligible security findings in the context of subsequent development requests and attempt to resolve them as part of its normal work.
That is quite useful, particularly for somebody who might otherwise have no idea how to interpret or resolve a security warning.
But there are two things worth being clear about.
Firstly, automatic detection is not the same as automatic remediation.
Lovable’s Auto-fix feature is opt-in, and it does not simply mean that every vulnerability discovered anywhere in the application is silently repaired the moment it becomes known.
It operates on eligible findings during subsequent build requests. More complicated issues can still require attention, and a Deep scan finding is not necessarily something the automatic process will resolve.
Secondly, correcting a problem in generated application code is different from patching the underlying infrastructure.
If the provider manages the server, the server’s operating system and the software it runs on, those are generally matters for the provider to maintain.
If the user exports the application and deploys it somewhere else, responsibility may change.
Similarly, a third-party integration might have vulnerabilities that neither Lovable nor the application’s owner can repair directly.
It is therefore not especially useful to assume that AI-built websites are inherently less secure than traditionally developed ones.
A professionally managed AI-built application could be better maintained than a hand-coded website abandoned five years ago.
Equally, somebody producing an application without understanding logins, data permissions or software dependencies could introduce problems that a security scanner does not fully recognise.
A recent study by Ascertify gives a sense of what that looks like in practice. It examined the code of 70 public Lovable apps on GitHub and found that 28 of them had at least one critical or high-severity problem in code their own creators were responsible for. Most came down to two things: database rules that let any signed-in user, or anyone at all, change data in some tables, and behind-the-scenes functions that anyone on the internet could run without any check. The other 42 had no serious problems at all.
The finding most relevant to Black October was less dramatic. Almost every app, 69 of the 70, included a software component with a known vulnerability, mostly the build tools that came with the original Lovable template. Many of those vulnerabilities were only published after the apps had been built. Nothing was necessarily wrong when the code was generated. It simply had not been updated since.
Ascertify sells code audits, which it openly acknowledges, and 70 apps is a small sample. But it publishes its raw figures, and the pattern is a familiar one: software that was secure enough on the day it was published does not stay that way by itself.
The important question is how security is handled throughout the application’s life, not simply whether a human or an AI wrote the original code.
Some practical advice if you’re using Lovable
If you have built something using Lovable, there are a few useful things you can do without needing to understand all the underlying code.
- Enable Auto-fix security issues. Look under Project settings, or the Security automation options in workspace settings. This allows Lovable to attempt suitable fixes during future development requests.
- Run a Deep security scan. The automatic Quick scan is useful, but it is not intended to detect every possible problem in your application’s code or business logic. Run a Deep scan before a public launch, after significant changes and periodically thereafter.
- Check the security findings rather than assuming publishing means everything is safe. Lovable can also be configured to prevent publishing when critical findings remain unresolved.
- Keep the building blocks up to date. Lovable projects include third-party components that will need updating as new vulnerabilities are found, even if you never change your own code. Ask Lovable, or whoever maintains your app, to check them periodically.
- Review your third-party services. Know which providers are responsible for your database, payments, logins, hosting and any other important integrations. Check their security notices when major vulnerabilities are reported.
- Ask who maintains the infrastructure. If your application has been exported or deployed outside Lovable, establish who handles security updates for the environment in which it runs.
You do not necessarily need to become a software developer to manage a small application.
You do, however, need to know where responsibility for its security lies.
That applies just as much to WordPress, Shopify, custom development and traditional web agencies as it does to AI development platforms.
The people keeping the internet running
One of the aspects of Black October I find most striking is what it has revealed about the people maintaining the software on which everybody else depends.
PHP has been developed over decades by a mixture of volunteers, contributors and funded developers.
It powers websites, business applications, public services and products used by organisations of almost every size.
Yet the number of people with the specialist knowledge required to make substantial changes to its inner workings is relatively small.
The PHP Foundation has been unusually candid about this.
In its explanation of the October vulnerabilities, the Foundation acknowledged that the delays in addressing the underlying memory-handling problem reflected structural issues in how security decisions were made, alongside a shortage of resources.
That admission matters.
It would be easy to interpret the delay as developers simply ignoring a security problem for two years.
But the situation was more complicated.
The team had identified something potentially dangerous without initially knowing how it could be exploited. Fixing it involved changes to code that supports an enormous software ecosystem, and several possible solutions introduced serious compatibility or security trade-offs of their own.
The developers had to balance a potential vulnerability against the possibility of disrupting applications relied upon by millions of people.
Once the full impact became clear, multiple people worked intensively to prepare and distribute the fixes.
The story also brought attention to people such as Ondřej Surý, who for more than twenty years has turned PHP into ready-to-install packages for Debian and Ubuntu, two of the most widely used operating systems for web servers. As an unpaid volunteer, he had patched builds for every version from PHP 5.6 to 8.5 on the afternoon the fixes were released, including old versions the PHP project no longer supports.
Package maintainers are an easily overlooked part of this process.
Writing a security patch is not the end of the job. It must also reach the different operating systems, hosting platforms, containers and software distributions used in the real world.
Older environments make this even more complicated, particularly when businesses depend on PHP versions that have reached their official end of life and no longer receive updates from the PHP project.
Some distributions and third-party maintainers provide backported security fixes for those older versions, but those arrangements vary, and they are not a substitute for having a plan to move onto supported software.
There is a wider economic problem here.
We have built a substantial part of the modern digital economy using open-source software. That is one of the reasons the internet developed as it did, and I think it has been enormously beneficial.
A small developer can build on the same foundations as a multinational company, without paying licensing fees for every library, programming language or development tool.
But freely available software is not free to maintain.
Somebody still needs to investigate vulnerabilities, review changes, test compatibility, prepare releases and respond when something goes wrong.
The PHP Foundation noted that it had handled more than 100 reports that were invalid, duplicated or could not be reproduced, alongside publishing 15 CVEs since the beginning of July.
AI-assisted vulnerability research is increasing the volume of reports reaching maintainers. Some uncover serious weaknesses. Others consume time despite ultimately revealing no genuine vulnerability.
That creates additional work for projects which may already be struggling to find enough people with the expertise to review and fix problems.
We have spent years making software easier to create and distribute. We have been less successful at making the maintenance of that software economically sustainable.
And now we are introducing technology that could make vulnerability discovery a great deal faster.
I suspect simply expecting a relatively small number of open-source maintainers to work harder is not a particularly sustainable solution.
The organisations that depend on these projects, particularly large commercial users, have an interest in ensuring that the people maintaining them have the resources they need.
Something the NCSC deserves credit for
Amid the warnings and dramatic headlines, there has also been some genuinely impressive work in responding to PHP2Shell.
The UK’s National Cyber Security Centre (NCSC), working with Netcraft, has been proactively contacting organisations about potentially vulnerable systems.
According to Netcraft’s announcement on 22 October, more than 50,000 proactive notifications had been issued as part of the UK response.
That is a substantial effort, and one which I think deserves more attention.
Rather than relying entirely on website owners to notice the news and investigate for themselves, the organisations involved used information visible from outside systems to identify potential exposure and contact the people responsible.
Some website owners may have received these warnings directly, while others may have heard through their hosting providers.
There is something encouraging about that approach.
Many smaller organisations do not employ technical staff. A business owner might never read a security advisory, have no idea what PHP is, and reasonably assume that somebody else is responsible for keeping their website secure.
A targeted notification can give them a reason to ask the right questions.
It is also worth understanding the limitations.
The NCSC’s Proactive Notifications Service uses information that can be seen from outside, including software versions that servers advertise publicly.
It does not provide a comprehensive security audit of every system behind a domain.
As I found during my own investigations, there can be PHP installations that are not identifiable from publicly accessible pages. Equally, a version number seen from outside may not reveal whether a provider has applied a backported fix.
So receiving a notification should prompt an investigation, rather than automatically being treated as proof that a system is exploitable.
And not receiving a notification certainly does not prove that everything is secure.
There is also a sensible precaution here. Because cybercriminals routinely exploit security scares to send fraudulent messages, recipients should check that any warning is genuine.
The NCSC explains that its Proactive Notifications Service emails come from Netcraft addresses, contain no attachments and do not request payment or personal information.
The wider approach is nevertheless encouraging.
It suggests a model in which cybersecurity organisations do more than publish warnings and hope that the people who need them happen to read them.
As vulnerability discovery becomes faster, getting useful information to the people responsible for fixing things will become increasingly important.
There is no particular reason why a small business should have to monitor dozens of specialist cybersecurity publications to discover that its website might need an urgent security update.
Where a potential problem can be identified and the responsible party contacted, doing so makes a lot more sense.
Black October wasn’t just about PHP
Which brings me back to the rest of that list from the start.
It would be a mistake to treat every security incident reported during October as evidence of one new AI-driven phenomenon, because several of them were quite different problems.
On 21 October, LiteLLM reported that its software release process had been compromised, resulting in a malicious version being distributed through PyPI, Python’s main public library of software packages, and through container registries.
This is what is known as a software supply chain attack. Rather than breaking into each victim directly, the attacker compromised a tool that lots of other software depends on, so the malicious code arrived through what looked like a normal update. In this case, it was designed to steal credentials.
LiteLLM’s subsequent investigation traced the incident to an exposed credential that had not been revoked, which eventually allowed an attacker to gain powerful access to the project’s GitHub account and interfere with how new versions were published.
That is a very different problem from PHP2Shell.
There was no need to discover an obscure memory-management vulnerability in a programming language. Instead, an attacker exploited weaknesses in how passwords, access and software releases were managed.
Around the same time, Railway disclosed suspicious activity involving the systems that store its customers’ environment variables, the settings where applications typically keep the passwords and keys for other services they connect to. Railway warned that an unauthorised third party might have obtained some of those secrets.
Again, the underlying concern was different. A platform holding credentials for numerous applications is an attractive target, because those credentials can unlock access to other systems.
The eMudhra incident was different again. According to the Wikipedia page, the weak keys traced back to a key-generation ceremony in April 2025 that did not use enough randomness. That is a failure of process, not a clever new AI attack.
These incidents are useful reminders that software security is not just about finding bugs in code.
It also involves the security of development tools, access permissions, the systems that build and publish software, package libraries, passwords and keys, and the way updates are deployed.
An application can contain perfectly reasonable code and still be compromised because a malicious component was installed during deployment.
A secure server can still be exposed if an attacker obtains a valid administrator password or key.
And a package can be technically free of known vulnerabilities while the process used to distribute it has been compromised.
AI may help identify and prevent some of these problems. It could also help attackers discover or exploit them.
But I would be cautious about treating every incident that happens to involve software or AI as part of one inevitable technological catastrophe.
There are longstanding security problems here, many of which existed well before the current generation of AI tools.
The real challenge is what happens after discovery
I do think there is a fundamental change taking place in cybersecurity.
AI systems are increasingly capable of examining large amounts of code, identifying suspicious patterns, proposing ways to exploit them and helping security researchers confirm whether those weaknesses represent genuine risks.
That could lead to the discovery of vulnerabilities which would otherwise have remained unnoticed for years.
It also means that attackers may have access to capabilities that previously required a great deal of specialised knowledge.
I would not dismiss that risk.
But I think the response needs to involve more than warnings that we are about to discover too many vulnerabilities to fix.
We need better ways to identify what software organisations depend on, make updates available, test them and deploy them safely.
Hosting companies, application platforms and software suppliers need to be clear about the parts of the security process they manage, and the parts they expect their customers to handle.
AI development platforms need to treat security as an ongoing responsibility rather than something that ends when an application is first published.
Businesses need to understand that paying for a website or application does not necessarily mean they are paying for its maintenance.
And the developers and maintainers responsible for the open-source software underpinning much of the internet need resources proportionate to how heavily that software is used.
There is also an opportunity here.
The same technology helping researchers identify vulnerabilities could increasingly help organisations understand their dependencies, assess whether they are affected, prepare fixes and test those fixes before deployment.
In some cases, it already does.
But there will remain situations where a patch could break an important business application, where a provider has not released an update, or where somebody needs to make a judgement about whether a system should be temporarily taken offline.
Those decisions involve trade-offs which cannot always be resolved by generating more code.
Black October has been presented in some quarters as the beginning of an era in which AI makes the internet dramatically less secure.
Perhaps the next few years will be difficult. A rapid increase in the discovery of serious vulnerabilities would certainly create problems for developers and organisations already struggling to maintain their systems.
But there is another possible interpretation.
We may finally be developing tools capable of finding weaknesses that have been hidden in widely used software for decades.
That could ultimately make the internet much more secure.
The difficulty is what happens between discovering those weaknesses and fixing them. A sticking plaster over the crack buys some time. It is not the same as fixing the road.
We are getting much better at finding vulnerabilities. We now need to become much better at maintaining the software in which they are found.
And perhaps Black October will be remembered less for the vulnerabilities themselves than for forcing us to confront how much of the internet depends on somebody, somewhere, being available to fix things when they go wrong.
