Can Your Veeam Backups Prove Compliance?

READ NOW

Black October: AI Found the Vulnerabilities. Human Expertise Made the Difference.

AI is changing cybersecurity and business operations, but the technology is only part of the story. Expertise, response, and customer trust matter just as much.

Desk calendar for October 2026 with the 17th, 20th and 21st circled in red, next to a laptop showing a red security alert over a world map

October 2026 may be remembered as a turning point in cybersecurity. Researchers used AI to uncover PHP2Shell, a set of critical flaws in PHP code that had been in place for more than a decade. Attackers began probing them before patches existed, and successful exploitation followed within days.

PHP powers 69.2% of websites whose server-side language is known, according to W3Techs. Serious weaknesses in software that widespread can expose websites and applications to unauthorized access, sensitive data theft, and remote code execution.

AI now works on both sides of cybersecurity. The same models that find long-hidden weaknesses can also make it cheaper to build working exploits, so organizations have less time to respond. That raises the value of human expertise, transparent response, and a tested path to recovery.

AI has already changed how we protect technology. The more important question is how we use it to become better defenders, make better decisions, and run more resilient businesses.

The Black October discovery: AI found PHP2Shell in decade-old PHP code

On October 21, Wiz Research disclosed PHP2Shell, two critical memory-safety vulnerabilities in the core PHP engine tracked as CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS score of 9.2, and Wiz’s write-up details four exploitable bugs under the two CVEs. Affected versions run from PHP 5.4 through 8.5.11, and the vulnerable code had been in place for more than a decade.

PHP2Shell is dangerous because it doesn’t depend on a weak application. Wiz demonstrated unauthenticated remote code execution against WordPress, Drupal, and Joomla. It also noted that even a simple “Hello World” page on an affected PHP version can be vulnerable. A separate memory disclosure path can expose passwords, authentication tokens, API keys, and certificates.

AI changed how fast that research moved. Wiz paired its own tooling with the Gemini 4 Argon and GPT-5.6 Sol models. By Wiz’s account, a single researcher completed in a week what would previously have taken a world-class team months. That raises an uncomfortable question: how many other vulnerabilities remain undiscovered in the technologies organizations depend on every day?

The timeline shows how quickly the advantage can shift once a flaw like this exists:

PHP2Shell timeline

From AI-assisted discovery to confirmed exploitation in 2026

August 19Wiz Research finds the first vulnerability through AI-assisted research
August 24Wiz privately reports its findings to the PHP security team
October 17Amazon Threat Intelligence records the first exploitation attempt, against one of its honeypots, four days before patches
October 20After the CVE IDs leak online, PHP moves its release up a day and warns administrators to prepare
October 21PHP releases versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35, and Wiz publishes its research
October 24A researcher’s honeypot records confirmed remote code execution against unpatched PHP 8.4.26

Attackers tried to use PHP2Shell as a zero-day, and confirmed exploitation followed three days after the patches shipped. Coordinated disclosure came under strain too: the CVE IDs leaked on October 20, and PHP moved its release up a day in response. AI can help researchers find weaknesses that resisted years of scrutiny, but those discoveries become actionable intelligence for attackers once details spread. And while AI speeds up discovery, safely developing, testing, and deploying fixes across a software ecosystem this large still takes time and technical expertise.

A new reality: patch windows are shrinking

Patch windows are shrinking, and AI is part of the reason. Amazon’s CISO, CJ Moses, says AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit. Wiz adds that language models can help adapt an exploit to different PHP versions, configurations, and memory layouts.

For years, cybersecurity strategies have emphasized prevention: securing networks, managing vulnerabilities, controlling access, and protecting data. Those priorities remain essential. AI adds pressure to identify exposure, evaluate risk, and implement fixes more quickly.

A vulnerability announcement can trigger an immediate series of operational decisions:

  • Which systems and customers are affected?
  • Is there evidence of exploitation?
  • Are patches or mitigations available?
  • What is the risk of keeping a service online?
  • How do we validate changes without introducing new problems?
  • What happens if critical systems become unavailable?

For an MSP managing dozens or hundreds of customer environments, these questions become even more complex. Patch management now has to account for exploitation that can begin before a fix exists. The speed at which threats evolve, and remediation becomes available, is changing how we work and do business.

Black October also shows something encouraging. The same technology contributing to this acceleration can help organizations respond more effectively.

AI can be part of the cybersecurity solution

Much of the conversation around AI in cybersecurity focuses on what could go wrong. That’s understandable. More capable technology can introduce new risks, expand attack surfaces, and give malicious actors powerful tools. Concentrating only on those risks overlooks an equally important opportunity: AI can help us become better defenders.

Infographic titled AI: A Stronger Defense at Every Stage, showing four stages: vulnerability discovery, threat analysis, informed remediation, and stronger recovery readiness

Consider an MSP responsible for multiple customer environments when a critical vulnerability is disclosed. Determining which systems are affected may require reviewing asset inventories, software versions, configurations, network exposure, and customer-specific dependencies.

AI-assisted tools can help analyze that information, correlate it with vulnerability intelligence, and identify systems that need attention. They can also support:

  • Faster vulnerability assessment: interpreting security advisories, identifying potentially affected technologies, and prioritizing investigation.
  • Better visibility into dependencies: analyzing the applications, infrastructure, and services a vulnerability or outage could affect.
  • More informed remediation: supporting investigation, change planning, documentation, and validation while reducing repetitive manual work.
  • Improved incident response: helping analysts correlate security events, organize evidence, and identify issues that need further investigation.
  • Stronger recovery preparation: reviewing recovery plans, finding missing dependencies, and analyzing test results to show where improvements are needed.

These capabilities don’t replace reliable source data, tested tools, or experienced professionals. AI-generated conclusions can be incomplete or incorrect, and production changes still need human-in-the-loop oversight.

Used responsibly, AI gives IT teams better information earlier and the ability to act more decisively. That creates an opportunity to strengthen customer confidence through timely, transparent responses. Google Cloud says its Gemini 4 Argon model contributed to finding the PHP2Shell vulnerability, developing the exploit, detecting attacks, and validating the patch. That’s a significant opportunity for our industry.

Intelligence creates opportunity. Expertise turns it into action.

The PHP2Shell disclosure also highlights something AI can’t replace: the experience and judgment required to respond appropriately. When the vulnerability became public, technology providers had to evaluate their exposure, decide how to protect their systems, and communicate with customers.

At Cloud IBR, our development team promptly assessed the risk, escalated the issue, and implemented precautionary measures. Once the official patch became available, the team integrated the updated software, validated it through development and testing, and deployed it to production. A forensic review found no evidence of unauthorized access or exploitation.

Just as importantly, we communicated directly with our customers about the vulnerability, the steps we had taken, and the outcome of our investigation. That transparency matters. Customer trust is the ultimate test of any response. Customers depend on technology providers to deliver reliable services, recognize emerging risks, respond competently, and communicate clearly when something needs attention.

AI-assisted research helped uncover the vulnerabilities. Security researchers and software maintainers turned those discoveries into actionable information. At Cloud IBR, our engineers applied their expertise and judgment to respond decisively and protect our environment.

AI can improve the information available to us. Human expertise determines how effectively we use it. And how we respond helps determine the trust we earn.

What happens when prevention and remediation aren’t enough?

Even sophisticated security programs can’t guarantee that every vulnerability will be found before it’s exploited, or that every incident can be prevented. When prevention fails, the deciding factor is whether you can restore operations while the systems you rely on are unavailable. Secure backups are only the starting point.

Consider an organization with immutable offsite backups. The backup data may be protected against deletion or modification. Recovery can still stall if the original backup management server is unavailable, production is compromised, or there’s no working environment to restore into. That’s why immutable backups don’t always mean recoverable.

Protected backups are essential, but they’re only one component of a complete recovery strategy. The ability to recover also depends on infrastructure, networking, credentials, access to backup data, operational procedures, and testing.

This is the recovery gap: the difference between having protected backup data and having a practical, proven way to restore operations.

AI may help teams identify these dependencies and improve recovery planning. But the infrastructure and processes required to restore services still have to work when they’re needed.

Five questions that reveal gaps in disaster recovery readiness

As organizations reassess their recovery capabilities, five questions show whether a plan will hold up in a real incident:

  1. Can we recover without our original backup management server? If it’s compromised or unavailable, can we still access and restore protected backup data?
  2. Where will our workloads run? Do we have a recovery environment available, or a reliable way to provision one when needed?
  3. Are our recovery systems truly independent? Could the same incident that affects production also prevent recovery?
  4. Have we tested the complete process? Do we know that our recovery infrastructure, access methods, and application restores actually work?
  5. Can we demonstrate recovery readiness? Do we have documented results, such as recovery KPIs we can share with clients, rather than assumptions?

For MSPs, these questions extend across every customer environment, each with its own infrastructure, dependencies, recovery requirements, and operational risks.

Modern backup and disaster recovery architectures can address these challenges without requiring every organization to run a permanent secondary site. For example, Cloud IBR enables automated recovery of Veeam workloads from supported offsite backups into independently provisioned recovery infrastructure. It doesn’t depend on the original Veeam backup server. Automated disaster recovery testing helps organizations validate their ability to restore workloads before an actual incident.

This approach complements cybersecurity prevention and remediation rather than replacing them. The objective is straightforward: when recovery becomes necessary, organizations have a tested path back to operations.

AI is reshaping infrastructure. Resilience must evolve with it.

The implications of AI extend far beyond cybersecurity research. Organizations are introducing AI-powered applications, automated workflows, intelligent agents, new data pipelines, and increasingly interconnected systems.

These technologies can improve productivity and create new opportunities. They also introduce dependencies that IT teams must understand, secure, and prepare to recover. As AI becomes more deeply embedded in business operations, cyber resilience planning has to evolve alongside it. We covered that shift in how AI is changing disaster recovery for MSPs.

That means asking how AI changes the risks organizations face, and how it can help manage them. AI can help teams identify weaknesses earlier, understand infrastructure dependencies, prioritize remediation, strengthen incident response, and make recovery planning more effective. The open question is whether the right people, processes, and technologies are in place to act on that intelligence.

Black October shows both sides of AI’s growing influence. AI helped uncover serious vulnerabilities that stayed hidden for years, and security leaders warn that the same tools lower the barrier for attackers.

Most organizations are asking how to incorporate AI into their operations. The more important question is whether we’re using it to its full potential. And how would we know?

There isn’t an established benchmark yet for AI’s highest and best use, especially while the technology is evolving so quickly. Time saved, threats discovered, faster remediation, and fewer disruptions all matter. How organizations protect their customers, respond to threats, and maintain trust is a meaningful place to start.

Measure AI not simply by how much we use it, but by how much better we perform because of it.

Continue the conversation: How AI Is Reshaping the Modern Technology Stack

The conversation is much bigger than cybersecurity. AI is changing how we build infrastructure, operate businesses, manage risk, and make decisions.

On November 18, 2026, at 2:00 PM ET (11:00 AM PT), Cloud IBR joins NetApp, Upscale AI, and TeraOps for a live discussion.

How AI Is Reshaping the Modern Technology Stack: Building, Scaling & Protecting AI Infrastructure While Optimizing Costs, Efficiency & Business Impact

We’ll explore how AI is changing the infrastructure businesses depend on and the opportunities and risks it creates. We’ll also look at what it takes to build and protect modern technology environments.

Live webinar graphic for How AI Is Reshaping the Modern Technology Stack on Nov. 18, 2026 at 11 am PT / 2 pm ET, with NetApp, Cloud IBR, Upscale AI and TeraOps logos

Frequently Asked Questions

What is PHP2Shell?

PHP2Shell is the name Wiz Research gave to two critical memory-safety vulnerabilities in the core PHP engine: CVE-2026-109618 and CVE-2026-109619. Together they cover four exploitable bugs. Disclosed on October 21, 2026, they allow unauthenticated remote code execution and memory disclosure, and both are rated CVSS 9.2. Affected versions run from PHP 5.4 through 8.5.11.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 fix both CVEs. PHP 8.1 and older no longer get official releases. Some Linux distributions and LTS vendors ship backported fixes, and PHP published minimal source backports for 7.4, 8.0, and 8.1. Upgrading is still the lasting fix, especially since PHP 8.2 reaches end of life on December 31, 2026. After updating, restart PHP-FPM or the web server, because running workers keep the old code in memory. PHP also suggests setting session.upload_progress.enabled to 0 until its next regular release fixes CVE-2026-115560, a related flaw that only affects an unusual configuration.

Was PHP2Shell exploited before the patch?

Attackers tried. Amazon Threat Intelligence recorded an exploitation attempt against one of its honeypots on October 17, four days before patches. Amazon said it’s unclear whether such attempts would work on real systems. Confirmed remote code execution came on October 24, against a researcher’s honeypot running unpatched PHP 8.4.26 in a deliberately exploit-friendly setup.

How is AI used in cybersecurity?

AI helps security teams analyze large volumes of data, interpret advisories, find vulnerabilities in code, detect attacks, and validate patches. In the PHP2Shell case, Google says its Gemini 4 Argon model contributed to finding the vulnerability, developing the exploit, detecting attacks, and validating the patch. Attackers can use the same capabilities, which is why human oversight still matters.

What are the risks of AI in cybersecurity?

The biggest risk is speed on the attacker side. AI can help attackers find weaknesses and adapt exploits faster, which shrinks the time defenders have to patch. AI tools can also produce incomplete or incorrect conclusions, so production changes still need experienced people to review them.

Will AI replace cybersecurity professionals?

AI is changing cybersecurity work more than replacing it. During Black October, AI helped find the flaws. People decided what to patch, validated the changes, checked for signs of compromise, and explained the outcome to customers.

Are immutable backups enough to recover from a cyberattack?

No. Immutable backups protect data from deletion or modification. Recovery also needs access to that data without the original backup server, a working recovery environment, credentials, networking, and a tested process. Having backups doesn’t mean having recovery.

Related Posts

SHARE

Table of Contents