In October 2026, PHP2Shell made it very clear to us how much AI has increased the vulnerability of existing IT systems. Two critical flaws in PHP, a programming language behind a large share of all web applications – and between the patch and the first attacks there were often only hours.

It’s raining vulnerabilities

Since PHP2Shell, we have seen vulnerabilities disclosed in ever faster succession. AI helps security researchers and attackers alike to find weaknesses in code, libraries and standards. And a published patch can quickly be used to work out how to exploit the flaw it closes.

The consequence: nobody can hide any more. Some systems used to be protected simply because they were too small, too obscure or too specialised to interest attackers. When tools scan the internet automatically for vulnerable versions, that no longer matters. Every reachable system will be found.

The bill for decades of sloppiness

What we are seeing now is not a sudden disaster but the result of decades of sloppiness. Over many years, technical debt has piled up: postponed updates, outdated components, temporary fixes that became permanent, and dependencies that nobody fully understands any more. Two causes work together here.

Complexity and human error. Systems have grown over the years; they have been extended, connected and rebuilt. Many are now so complex that people alone may no longer be able to see through them completely. Where people work, mistakes happen – and in complex systems they stay undetected for longer.

Postponing to save costs. Necessary updates to software and systems were postponed again and again or never carried out, on the principle of “nobody sees it, nobody notices”. This is not a reproach to individual clients: our industry, too, has gone along with this pattern too often when maintenance was cut from the budget to leave money for visible new features.

Those days are over

“Nobody sees it, nobody notices” no longer works. A vulnerable system is seen today – just not by the right people. All companies and organisations therefore need to plan, in their processes and budgets, for their systems to be monitored and kept up to date continuously. Otherwise they risk massive damage: data leaks, extortion, service outages, liability issues and a loss of trust that is hard to repair.

Lawmakers are following suit

Legal requirements are moving in the same direction:

  • GDPR: Anyone processing personal data must protect it with technical and organisational measures that take the state of the art into account (Art. 32). The state of the art changes with every security update.
  • NIS2: Since 6 December 2025, Germany’s NIS2 Implementation Act has been in force. It significantly widens the group of companies with obligations for risk management and incident reporting, and it explicitly holds management accountable.
  • Cyber Resilience Act: Since 11 September 2026, manufacturers of products with digital elements have had to report actively exploited vulnerabilities. From 11 December 2027, the requirements apply in full, including security updates throughout the support period.

Which obligations apply in a specific case depends on the company and the product; this overview is not legal advice.

The race has begun

The race has begun, and it is going to be a rough ride. Technical debt has been stacked up over decades; it cannot be paid off in a single quarter. That makes it all the more important to start now – in an orderly way and prioritised by risk.

Ironically, the technology that has made the situation worse also helps: AI-supported tools and workflows speed up defence too, from building an inventory and assessing vulnerabilities to rolling out and documenting updates. We describe how we have adapted ourselves in our article on PHP2Shell and the new normal in IT security. Decisions remain with experienced people.

What to do now

  1. Build an inventory: Know which systems, versions, components and dependencies are in use – including the forgotten ones.
  2. Assess the risks: What is reachable from the internet, what data does it process, what no longer receives updates?
  3. Budget for maintenance: Plan updates, monitoring and upkeep as a fixed, ongoing item, not an optional extra.
  4. Monitor continuously: Keep an eye on security advisories, versions and systems so that vulnerabilities are closed in hours rather than weeks.
  5. Prepare for emergencies: Clear responsibilities and rehearsed procedures – who assesses, who shuts down, who patches, who informs?
  6. Replace legacy systems: Plan the life cycle of every system, and replace or migrate systems that no longer receive updates before they become a way in.

How we help

We run critical systems ourselves, for our clients and for our own products, and we have aligned our processes with this situation. Together with you, we get an overview of your systems, assess the risks and plan how to pay off technical debt – step by step and with a budget that stays predictable. Find out more under Privacy & security and Operation & further development.