Securing Systems in the AI Era: The Threat Landscape Has Changed, and Our Defences Must Evolve | Daniel Ishola

Over the past decade, I've spent a significant part of my career designing, developing, deploying, and maintaining software systems. From financial technology platforms handling sensitive customer information and billions of naira in transactions to cloud-native applications, real-time communication systems, and legacy infrastructure, one lesson has become increasingly clear to me:

Building a system that works is one thing. Building a system that remains secure when someone is actively trying to break it is an entirely different responsibility.

For years, we've approached cybersecurity with a relatively familiar playbook: patch vulnerabilities, configure firewalls, secure authentication, restrict access, monitor logs, and conduct periodic penetration tests.

These practices are still essential. However, the environment in which we apply them has fundamentally changed.

Artificial intelligence has introduced a new dimension to cybersecurity. The same technology helping engineers write code faster, automate infrastructure, identify bugs, and improve productivity is also helping malicious actors discover vulnerabilities, develop exploits, conduct reconnaissance, and automate parts of cyberattacks.

And the evidence is no longer hypothetical.

In October 2026, Reuters reported on an attacker who allegedly used autonomous AI agents to compromise websites belonging to more than 100 companies. The operation reportedly targeted over 1,200 e-commerce websites, using AI tools to identify weaknesses and execute intrusions with limited human supervision.

According to the investigation, the estimated AI usage cost was approximately $5,000, averaging roughly$ 50 per successful compromise.

Think about what that means.

Activities that previously required considerable human effort can increasingly be coordinated by automated systems operating continuously.

For engineering teams, the question is no longer simply whether their applications contain vulnerabilities.

It's whether they can discover, prioritise, and remediate those vulnerabilities before automated attackers exploit them.

1. AI Has Lowered the Barrier to Cybercrime

Historically, sophisticated cyberattacks required a combination of technical expertise, patience, infrastructure, and specialised knowledge.

An attacker needed to understand network protocols, operating systems, application vulnerabilities, exploit development, and techniques for maintaining access after compromising a system.

Those skills still matter, but AI is reducing the amount of expertise and manual effort required for certain stages of an attack.

In June 2026, Anthropic published research examining 832 accounts associated with malicious cyber activity between March 2025 and March 2026.

The researchers mapped 13,873 observations across 482 MITRE ATT&CK sub-techniques.

Among the findings:

560 accounts used AI assistance for malware development.
Approximately 65% used AI for file or information obfuscation.
Nearly 55% used AI in attempts to impair defensive mechanisms.
The proportion of actors classified as medium risk or higher increased from 33% to 56% between the two halves of the study.

These figures describe the accounts investigated, not all cybercriminals worldwide. Nevertheless, they demonstrate how extensively AI is already being incorporated into malicious workflows.

The implications are significant.

An attacker can use AI to analyse exposed technologies, interpret error messages, identify outdated software, generate candidate exploit code, and investigate possible paths through an application.

AI does not automatically make every attacker sophisticated, nor does every generated exploit work. But it can reduce the time spent on repetitive tasks and make certain capabilities accessible to a broader group of adversaries.

The cost of attempting an attack is falling, while the potential cost of defending against thousands of attempts remains substantial.

This changes the economics of cybersecurity.

2. We're Already Seeing AI-Assisted Attacks in the Wild

One of the biggest mistakes engineering teams can make is treating AI-powered cybercrime as a future concern.

Several incidents reported in 2026 show that attackers are already experimenting with AI-assisted vulnerability exploitation and operational automation.

The 2026 AI-agent website intrusion campaign

In the October investigation reported by Reuters, researchers described an attacker using AI agents to coordinate intrusions against commercial websites.

The campaign reportedly involved a combination of DeepSeek and Claude Code, with agents investigating application weaknesses and related infrastructure.

Some of the companies named in the reporting included Deere, SharkNinja, and Cummins, although the organisations reported different findings about the impact on their systems.

The important takeaway isn't the specific AI model involved.

It's the operating model.

Instead of relying exclusively on an attacker manually testing every endpoint, an automated workflow can evaluate many potential targets and investigate weaknesses over extended periods.

That creates a serious challenge for organisations that rely on infrequent security assessments.

Google's findings on AI-assisted zero-day exploitation

In May 2026, Google's Threat Intelligence Group reported identifying a threat actor using a zero-day exploit that researchers believed had been developed with AI assistance.

This is an important development.

A zero-day vulnerability is a security weakness for which an effective fix may not yet be available when exploitation begins.

Traditionally, developing a reliable zero-day exploit could require substantial expertise and experimentation.

AI-assisted vulnerability research has the potential to accelerate parts of that process, although human expertise and validation remain critical.

The lesson for defenders is that patch management alone cannot address every threat. Organisations also need controls capable of detecting and containing suspicious behaviour when an attacker exploits an unknown weakness.

AI is being used after the initial compromise

Anthropic's September 2026 threat intelligence report documented malicious actors using AI across reconnaissance, initial access, credential collection, lateral movement, and data extraction.

One particularly concerning case involved prompt injection against an AI vendor's automated evaluation environment.

The attacker manipulated the environment into exposing credentials, including production API keys.

Those credentials were subsequently abused in additional intrusion attempts.

This introduces another category of security risk: the AI tools we integrate into our engineering workflows can themselves become attack surfaces.

An AI agent that can read repositories, execute commands, access production credentials, or interact with external services should never be treated as inherently trustworthy.

Its permissions and execution boundaries matter just as much as those of a human operator.

3. Recent CVEs Show Why Basic Security Hygiene Still Matters

While AI is changing the speed and sophistication of attacks, many successful compromises continue to begin with familiar weaknesses: outdated dependencies, exposed services, insecure configurations, and inadequate access controls.

Some recent vulnerabilities illustrate how quickly a seemingly ordinary engineering decision can become a serious security issue.

PHP2Shell: When AI-discovered vulnerabilities forced governments to shut down websites

In October 2026, the cybersecurity industry witnessed one of the clearest examples of how artificial intelligence is changing the vulnerability landscape.

Two critical vulnerabilities in PHP, tracked as CVE-2026-109618 and CVE-2026-109619, triggered emergency security warnings from agencies including the FBI, NSA, CISA, the UK's National Cyber Security Centre, and European cybersecurity authorities.

The vulnerabilities, collectively known as PHP2Shell, could allow unauthenticated attackers to execute malicious code on affected servers.

What made this incident particularly significant was that AI-assisted security research helped uncover the vulnerabilities, demonstrating how artificial intelligence can accelerate vulnerability discovery.

The same capabilities that help security researchers identify weaknesses can also help malicious actors analyse patches and investigate exploitation techniques.

When governments started taking websites offline

Following the disclosure on October 21, several countries and major organisations temporarily suspended public-facing services while investigating their exposure and applying emergency patches.

The reported disruption extended across multiple countries:

Germany: Federal government websites were temporarily taken offline.
France: The Interior Ministry suspended prefecture websites as a precaution.
Netherlands: Government portals, hospital websites, and the Port of Rotterdam were among affected services.
Finland: Government public web services were temporarily suspended.
Japan: Government ministries, financial institutions, and major companies suspended some online services.
United Kingdom: The BBC and some local authorities temporarily took web services offline.

The FBI went further, advising organisations unable to apply security updates immediately to consider taking affected systems offline until the vulnerabilities could be mitigated.

By October 26, both vulnerabilities had reportedly been added to CISA's Known Exploited Vulnerabilities catalogue, reflecting evidence of exploitation in the wild.

This was no longer simply a theoretical security risk.

Why these vulnerabilities were particularly dangerous

Unlike vulnerabilities caused by insecure application code, PHP2Shell affected the underlying PHP runtime.

CVE-2026-109618 involved memory corruption during out-of-memory handling, while CVE-2026-109619 involved stale internal state referencing memory that had already been freed.

Both received CVSS scores of 9.2.

This distinction matters because even a well-written application could remain vulnerable if it ran on an affected PHP installation.

A Laravel application with strong authentication, properly validated inputs, and secure database queries could still be exposed through the runtime executing its code.

A separate vulnerability, CVE-2026-115560, was also disclosed on October 23. It involved a less common application configuration and required additional mitigation.

What engineering teams needed to do immediately

The PHP security team reportedly released patched versions on October 21, 2026.

PHP branch	Reported minimum fixed version
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Older PHP versions, including 7.4, 8.0, and 8.1, required particular attention because they were no longer receiving normal upstream security updates. Some vendors provided backported fixes, but organisations needed to verify those fixes explicitly.

For engineering teams operating Plesk servers, Apache, PHP-FPM, Docker containers, and legacy PHP applications, the response needed to go beyond simply updating the framework.

It required identifying every affected runtime, deploying verified patches, rebuilding affected container images, restarting services, and examining logs for possible exploitation.

Temporary mitigations could reduce exposure, but they were not equivalent to applying the security fixes.

Importantly, putting a Laravel application into maintenance mode was not sufficient protection against a vulnerability in the underlying PHP runtime.

The lesson for engineering leaders

What stands out to me about PHP2Shell isn't simply that critical vulnerabilities were discovered in a programming language used across a significant portion of the web.

It's the speed at which a software vulnerability became an international operational emergency.

Governments, financial institutions, healthcare providers, and technology companies were forced to make immediate decisions about whether to keep services running or temporarily suspend them.

For engineering leaders responsible for production infrastructure, this highlights a difficult reality.

Availability is important, but maintaining an available system that attackers can remotely compromise may be far more damaging than a controlled period of downtime.

It also reinforces why vulnerability management cannot depend on developers occasionally checking for updates.

Organisations need automated asset inventories, vulnerability intelligence, emergency deployment procedures, tested recovery processes, and clear authority to isolate affected systems.

In the AI era, attackers may be able to investigate newly disclosed vulnerabilities faster than traditional patching processes can respond.

The organisations that stay ahead will be those capable of turning vulnerability intelligence into verified remediation within hours rather than weeks.

CVE-2025-55182: React2Shell

Severity: Critical — CVSS 10.0 (v3.x)

In December 2025, a critical vulnerability was disclosed in React Server Components.

Known as React2Shell, CVE-2025-55182 allowed unauthenticated remote code execution in affected implementations.

Google's Threat Intelligence Group subsequently observed multiple threat actors exploiting the vulnerability to deploy backdoors, downloaders, tunnelling tools, and cryptocurrency miners.

This was particularly concerning because React and Next.js are widely used in modern web applications.

A team could have a well-designed frontend, strong authentication, and properly secured APIs, yet still expose its server infrastructure through a vulnerable framework dependency.

For teams using Next.js, the lesson is straightforward:

A framework dependency is part of your production attack surface, not merely a development convenience.

Dependency monitoring, version inventories, emergency patching procedures, and production isolation should be standard engineering practices.

CVE-2025-29927: Next.js middleware authorization bypass

Another important vulnerability involved Next.js middleware.

CVE-2025-29927 allowed attackers, under affected configurations, to bypass authorization checks implemented through middleware.

This illustrates a different type of failure.

An application may appear secure because its middleware checks authentication before allowing users to access protected routes.

However, if the security boundary depends entirely on middleware behaviour, a framework-level vulnerability can undermine that assumption.

Authorization must be enforced at the appropriate backend and data-access boundaries, not exclusively at the presentation or routing layer.

CVE-2025-53770 and CVE-2025-53771: Microsoft SharePoint ToolShell

The ToolShell exploit chain targeted on-premises Microsoft SharePoint deployments and was associated with remote code execution and related authentication or security-control bypass weaknesses.

Attackers exploited vulnerable servers to gain access, extract sensitive information, and establish additional footholds.

MITRE documented exploitation involving both ransomware and espionage actors.

The broader lesson extends beyond Microsoft SharePoint.

Enterprise systems often remain operational for years, accumulating integrations, privileged service accounts, and access to sensitive information.

An unpatched enterprise application can become an entry point into a much larger environment.

This is particularly relevant to organisations maintaining older PHP applications, internal administrative platforms, and legacy systems alongside modern cloud services.

Your security posture is not determined by your newest application. It is often constrained by the oldest vulnerable component that remains reachable.

4. The Hidden Risk of Legacy Infrastructure

One area I've become increasingly concerned about is legacy infrastructure.

Across the industry, many organisations continue to operate applications built years ago using older versions of PHP, outdated frameworks, and infrastructure configurations that have evolved through multiple generations of developers.

These systems may still serve important business functions.

Replacing them immediately is not always commercially or operationally realistic.

However, continuing to operate them without a clear security strategy introduces significant risk.

Consider a legacy PHP application hosted on a publicly accessible server.

Even when the application itself appears to be functioning correctly, its security depends on several layers:

The PHP runtime and installed extensions.
The framework and third-party dependencies.
The operating system and web server.
File permissions and deployment configurations.
Database access controls.
Administrative interfaces and exposed services.
Monitoring, backups, and incident-response capabilities.

Updating application code without addressing the runtime or server configuration may leave exploitable weaknesses in place.

Likewise, upgrading PHP does not automatically fix insecure application logic, compromised credentials, or malicious files already present on the server.

I've learned to think about legacy security as a continuous risk-reduction process rather than a single upgrade exercise.

When a vulnerability is disclosed, the first step should be determining whether the affected component exists anywhere in your environment.

The next question is whether that component is exposed, exploitable, and capable of affecting other systems.

That requires an accurate inventory.

If an engineering team cannot quickly identify which servers are running a vulnerable runtime or dependency, its incident response is already operating at a disadvantage.

5. Containerisation Is Not a Security Boundary by Itself

Docker has made application deployment more consistent and infrastructure management significantly easier.

But containerisation does not automatically make an application secure.

A common example is using a floating image tag such as:

php:8.3-fpm-alpine

That tag can resolve to newer patched images when pulled again, but an already-running container does not automatically update itself.

Rebuilding an image also does not guarantee that every installed dependency is secure.

A responsible container security process should include image vulnerability scanning, deliberate base-image updates, dependency review, minimal runtime privileges, and controlled deployments.

For production systems, I would also recommend pinning tested image digests and using automation to detect when newer patched versions become available.

This provides a balance between reproducible deployments and timely security updates.

More importantly, containers should operate with the minimum permissions required to perform their functions.

A compromised application process should not automatically gain access to the host operating system, other containers, or production secrets.

The objective is not merely to prevent the initial compromise.

It is to limit what an attacker can do after gaining access.

6. Security Must Be Designed Into the Architecture

As engineering teams adopt microservices, asynchronous processing, real-time communication, and cloud-native infrastructure, the number of potential attack paths increases.

A modern application may include a mobile frontend, web dashboard, API gateway, authentication service, databases, Redis, message queues, third-party payment providers, cloud storage, and background workers.

Every connection introduces a trust boundary.

Every credential introduces potential exposure.

Every publicly accessible endpoint expands the attack surface.

This is particularly important in financial technology.

When a platform handles customer identities, payment instructions, bank integrations, loan disbursements, or repayment workflows, a security incident can have consequences beyond application downtime.

It can affect customers financially, expose regulated information, or undermine confidence in the business.

My approach to secure architecture increasingly centres on three principles.

First, never assume that a request is trustworthy simply because it originates from an authenticated user.

Authentication establishes identity. Authorization determines what that identity is allowed to do.

Every sensitive operation should enforce the appropriate permissions and business rules.

Second, separate critical systems according to their risk.

A public-facing application should not have unrestricted access to databases, cloud administration interfaces, or internal financial operations.

Use network segmentation, least-privilege service identities, private infrastructure, and carefully scoped credentials.

Third, design for the possibility of compromise.

No security control is perfect.

Systems should be built so that a compromised component cannot automatically compromise the entire platform.

This is the practical foundation of zero-trust architecture and defence in depth.

7. AI-Generated Code Introduces Another Responsibility

AI-assisted development has become part of modern software engineering.

Tools such as Codex, Claude Code, and other coding agents can accelerate implementation, testing, documentation, and debugging.

I've seen how much development time can be saved when these tools are used effectively.

But faster code generation does not necessarily mean safer code.

An AI assistant may produce an implementation that passes functional tests while overlooking security considerations.

For example, generated code may introduce overly permissive authorization rules, unsafe database operations, insecure file uploads, insufficient input validation, or excessive cloud permissions.

These issues are not exclusive to AI-generated code. Human developers introduce them too.

The difference is that AI can significantly increase the volume of code being produced.

Without corresponding improvements in review and testing, engineering teams risk accumulating vulnerabilities faster than they can identify them.

AI should accelerate engineering execution, not replace engineering judgment.

For security-sensitive code, I believe teams should require explicit review of authentication, authorization, financial operations, cryptographic handling, secrets management, and externally accessible endpoints.

Coding agents should also operate with restricted permissions, particularly when interacting with production infrastructure.

An agent should not need unrestricted access to an organisation's cloud account simply to implement an application feature.

8. Monitoring Is No Longer Optional

One of the most dangerous assumptions in software operations is that a system is secure because it appears to be working normally.

A compromised server may continue serving requests.

An attacker may quietly extract data while legitimate users experience no visible disruption.

A malicious process may run in the background without causing immediate performance problems.

This is why security monitoring must extend beyond application availability.

Engineering teams should be able to investigate authentication anomalies, unusual administrative activity, suspicious process execution, unexpected file modifications, unusual outbound network connections, and abnormal database access patterns.

Tools such as Datadog, cloud-native audit logging, endpoint detection platforms, and security information and event management systems can help provide visibility.

But installing monitoring software is only the beginning.

The real question is whether the organisation can distinguish ordinary behaviour from a meaningful security event and respond quickly enough to contain it.

Logs should be centralised, protected from tampering, retained appropriately, and connected to actionable alerts.

For high-risk systems, detection and response procedures should be tested regularly.

If an attacker gained access to one of your production servers tonight, how long would it take your team to notice?

That is a question every engineering leader should be able to answer with evidence rather than confidence alone.

9. What Engineering Teams Should Do to Stay Ahead

I don't believe organisations can solve the AI cybersecurity problem simply by purchasing more security products.

The response has to begin with engineering discipline, operational visibility, and clear ownership.

Here are the practices I consider most important.

Make vulnerability management continuous

Maintain a current inventory of applications, servers, frameworks, containers, and dependencies.

Use automated scanning in CI/CD pipelines and monitor newly disclosed vulnerabilities through trusted sources such as CISA, NVD, vendor advisories, and national CERT organisations.

Prioritise vulnerabilities based on exploitation evidence, exposure, business impact, and the sensitivity of affected systems rather than CVSS scores alone.

Build security into deployment pipelines

Integrate static application security testing, dependency scanning, secret detection, container scanning, and infrastructure-as-code checks into automated workflows.

Critical security findings should block releases when appropriate.

The objective is to identify problems before deployment rather than discovering them through production incidents.

Enforce least privilege everywhere

Apply least privilege to developers, applications, service accounts, databases, CI/CD runners, and AI agents.

Use short-lived credentials where possible, enforce phishing-resistant multifactor authentication for privileged access, and rotate credentials after suspected exposure.

Assume that attackers will eventually get in

Implement network segmentation, workload isolation, immutable or protected backups, recovery procedures, and incident-response playbooks.

A successful intrusion should not automatically become a company-wide compromise.

Use AI defensively, but verify its findings

AI can help engineering teams analyse logs, summarise threat intelligence, identify suspicious patterns, review code, and prioritise remediation.

However, AI-generated security recommendations should be validated.

A model can misinterpret an alert, overlook environmental context, or confidently recommend an ineffective fix.

Security decisions still require accountable human oversight.

Test the organisation, not just the application

Conduct penetration tests, threat-modelling exercises, incident simulations, and recovery drills.

Test scenarios involving stolen credentials, compromised third-party integrations, exposed secrets, ransomware, and malicious activity originating from a trusted service.

Security is not just about whether an application can resist an attack.

It is also about whether the organisation can detect, contain, investigate, and recover from one.

10. The Future of Cybersecurity Is a Race Between Automation and Resilience

I believe we're entering a period where the speed of cyberattacks will increasingly be determined by automation.

AI will continue improving vulnerability research, code analysis, reconnaissance, and the coordination of complex workflows.

Defenders will have access to many of the same capabilities.

The organisations that succeed will not necessarily be those with the largest security budgets.

They will be the ones that build security into everyday engineering decisions, understand their infrastructure, reduce unnecessary exposure, and respond rapidly when something goes wrong.

This is also why I believe cybersecurity will become even more central to software engineering as AI adoption accelerates.

As more business processes become automated, more applications gain access to sensitive data, and more AI agents are trusted to perform real-world actions, the consequences of weak security boundaries will become increasingly serious.

The separation between software engineering, infrastructure, AI, and cybersecurity will continue to narrow.

Engineers will need to understand not only how to build intelligent systems, but also how to control what those systems can access, what they can execute, and how their actions can be verified.

Final Thoughts

After years of building and managing production systems, I've come to appreciate that security is not a feature you add when development is complete.

It is a responsibility that begins with architecture and continues throughout the lifetime of a system.

AI has made software development faster.

It is also making parts of cybercrime faster, cheaper, and more accessible.

We cannot control how quickly attackers adopt these technologies.

But we can control how we design our systems, manage vulnerabilities, protect credentials, monitor infrastructure, and prepare for incidents.

The goal is not to build a system that can never be attacked. That is unrealistic.

The goal is to build systems that are difficult to compromise, capable of detecting malicious activity, resilient enough to contain an intrusion, and prepared to recover when defences fail.

In the AI era, that is what responsible software engineering must look like.