More Vulnerabilities, Less Time: Why Check Your Internet-Facing Systems Regularly

On 17 October 2026, Amazon's decoy servers recorded an attempt to exploit PHP2Shell, two critical flaws in PHP itself. The fix came out four days later.

Our view: this is not an exception, and speed is only half of it. Far more vulnerabilities are published every year, while the time to act on the ones attackers use stays short. So knowing which of your systems face the internet, and what they run, has to be a routine, not a yearly project.

Twice as many vulnerabilities as a year ago

Vulnerabilities get public numbers, called CVEs, when they are published. According to the cve.tools index, about 25,000 were published in 2022 and about 49,000 in 2025. This year, by 23 October, there were already more than 88,000: 2.2 times as many as in the same months of last year.

Critical ones grew even faster: almost 9,000 so far this year, 2.7 times as many as a year earlier.

Attacks are confirmed within days

Most vulnerabilities are never attacked. CISA, the US cybersecurity agency, keeps a list of the ones with confirmed attacks. This year it has already added 270, more than in the whole of 2025.

What matters for a company is how soon that happens. About half of the new vulnerabilities on CISA's list were confirmed as attacked within a week of being published. It has been the same for three years: 2024, 2025 and 2026.

And a confirmation comes after the attacks, not before: by the time a vulnerability is on the list, someone has already used it. So waiting for that list is waiting too long. And there is more to sort through: to find the few vulnerabilities that affect it, a team now has to look through twice as many as a year ago.

It used to be very different. Mandiant, Google's threat intelligence team, measured how long it took from a fix being released to the first attack: about two months in 2018–2019, a month in 2021–2022, and 5 days in 2023.

Some attacks come before any warning at all. VulnCheck, a company that tracks attacks on vulnerabilities, found that almost a third of the vulnerabilities first attacked in 2025 were attacked on the day they were published, or earlier.

AI is part of the reason. Amazon's security team, writing about PHP2Shell, says AI tools make it cheaper to turn a published fix into a working attack. These tools keep getting better, so we do not expect the time to act to grow again.

What this month looked like

In the week of PHP2Shell, Laravel, Node.js, GitLab and the certificate authority eMudhra all needed fixes too. We covered all five alerts in one note, with how many websites run the affected software.

Earlier posts on our blog show the same pattern from other angles:

• a self-hosted Gitea code server that needed checking from the outside once a vulnerability in it entered CISA's list of exploited flaws;
• VMware vCenter management interfaces reachable from the internet, after a flaw in vCenter entered the same list.

In each case the first useful question was the same: do we run this, and can it be reached from outside?

What a missed update can cost

For a business owner, the consequences come down to a few plain outcomes. Two well-documented cases show them.

• Client data stolen. From 27 May 2023, the CL0P ransomware gang exploited a then-unknown flaw in MOVEit Transfer, a file transfer product that companies expose to the internet. According to the US agencies CISA and FBI, the attackers installed a web shell, a hidden back door, and used it to steal data. No update could stop the first wave. But the agencies expected "widespread exploitation of unpatched software services", and companies that knew they ran an internet-facing MOVEit could act as soon as a fix was out.
• Data locked. In February 2023, the ESXiArgs campaign encrypted files on VMware ESXi servers, the software that runs many companies' virtual machines. CISA and the FBI wrote that the attackers may have been exploiting known vulnerabilities, likely on servers without the available patches, and had compromised over 3,800 servers worldwide.

Behind these outcomes sit costs a company already knows: telling clients their data was exposed, answering a customer's security questionnaire with an incident on record, rebuilding systems instead of serving clients.

Our view on one more point: stolen data does not stay with the thief. In an earlier campaign against another file transfer product, GoAnywhere, CL0P's ransom note told victims "we will sell your information on the black market and publish it on our blog". Once data is published, anyone can read it, a competitor included. And a public vulnerability is public for everyone: the advisory that tells your team what to fix tells anyone else what to look for.

Why regular checks, not a one-off

An annual assessment answers two questions for one day: which systems face the internet, and what is wrong with them. Both answers age. We wrote before about the first one, the perimeter that keeps changing. This article is about the second: even if nothing on your side changes, new vulnerabilities in software you already run are published every day, now more than ever.

Regular external scanning repeats the check on a schedule. On each pass it can show:

• which of your websites, subdomains and services answer from the internet, including new ones;
• which technologies and versions they give away to anyone: the web server, the website platform, the programming language;
• which known vulnerabilities match those versions, and which of them are confirmed as attacked;
• exposed admin panels, test copies and other systems that should not be public.

See how SeguriScan shows a finding on one of your assets and what to fix first.

If a site hides its versions, that is a small plus: from outside, it is harder for anyone to tell whether it is affected. It is no protection. Attackers' automated tools do not stop at the version number; they try the flaw itself. A hidden version can also stop an outside scan from matching it to a known flaw, so your IT team may need to confirm what is installed.

Scanning has other limits. It sees what is visible from outside, so it cannot see the exact components inside an application. It reports likely problems; whether one can really be used to break in is a question for a penetration test. And it does not fix anything: it tells your team where to start, and the update is still theirs to make.

How often? Agree a regular schedule with your IT team, more often for the systems that matter most and are most exposed. Between scans, check urgent alerts about software you use, and check again after any big change and after each fix.

Five questions to ask your team this week

1. Do we have one list of every website, subdomain and service we expose to the internet, including those run by contractors and subsidiaries?
2. For each one, do we know what software it runs and who updates it?
3. When a critical vulnerability is published, how do we learn whether it affects us, and how long does that take?
4. When was each internet-facing system last checked from the outside?
5. If a system turned out to be compromised, who would we call, and which clients would we have to inform?

Frequently asked questions

We had a penetration test this year. Isn't that enough?

It is valuable, and it goes deeper than any scan. But it describes the day it was done. Vulnerabilities published after that day in software you already run are not in its report.

Does regular scanning prevent attacks?

No. It shortens the time between a problem appearing and your team knowing about it. The fix is still an update, a configuration change or taking a system offline.

We are a small company. Would anyone target us?

Much exploitation starts with automated scans that look for vulnerable software across the internet, not for specific companies. Amazon saw the first PHP2Shell attempts on its own decoy servers, set up only to catch such attacks. Size matters less than what you expose.

Want to see what this looks like for your company? SeguriScan, the IntruForce platform, looks at your company's internet-facing systems from the outside. Request a free SeguriScan pilot with the form below. First we agree with you on the scope and the systems to assess, and confirm you may authorize the check. Nothing is scanned before that. Then you get access to the SeguriScan platform with the discovered assets, findings and reports. No obligation to proceed.

---

Sources

• Vulnerability counts and CISA KEV figures: cve.tools index, queried 23 October 2026. CVEs from all sources, published only, by publication year: 25,490 (2022), 29,231 (2023), 40,912 (2024), 49,399 (2025), 88,271 (1 January–23 October 2026, against 39,594 in the same period of 2025). Critical = severity label: 8,997 against 3,348; 10,465 of the 2026 CVEs had no severity yet. KEV entries by date added: 186 (2024), 245 (2025), 270 (2026 to date). For CVEs under a year old when added, share in KEV within 7 days of publication or before it: 55.3%, 51.3%, 51.8%.
• Mandiant (Google Cloud): How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends (16 October 2024). Averages without a few extreme cases: 63, 44, 32 and 5 days; with them, 47 days for 2023.
• VulnCheck: State of Exploitation 2026. 884 vulnerabilities first exploited in 2025, 28.96% on or before publication day.
• Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure in MadPot (21 October 2026).
• CISA and FBI: advisory AA23-158A on CL0P exploiting MOVEit Transfer CVE-2023-34362; advisory AA23-039A on ESXiArgs ransomware.