Finextra · সাধারণ

When Cybersecurity Takes a Website Offline: How AI Can Detect PHP Vulnerabilities

২৩/১০/২০২৬

Artificial intelligence is changing how organisations identify software vulnerabilities and respond to cyber threats. But without effective governance, AI can introduce new security risks even as it attempts to prevent them.

Introduction: Website availability is now a cybersecurity priority

When a website goes offline, the immediate assumption is often an infrastructure failure, a cloud outage or a deployment problem. Yet the underlying cause may be a cybersecurity incident.

Distributed denial-of-service (DDoS) attacks, exploited software vulnerabilities, compromised credentials, malicious code injection and security misconfigurations can prevent legitimate users from accessing digital services. In other circumstances, organisations deliberately take systems offline to contain an attack, protect sensitive information or prevent further damage.

For banks, payment providers, retailers and other digital businesses, the consequences extend beyond temporary inconvenience. Customers may be unable to access accounts, complete payments or use essential services. Operational costs increase, customer confidence declines, and regulatory or contractual obligations may be affected.

The challenge for technology leaders is therefore twofold: how can organisations identify vulnerabilities before attackers exploit them, and how can they use artificial intelligence (AI) to strengthen cybersecurity without introducing new risks?

PHP-based applications provide a useful case study. They power websites, content management systems, APIs and business applications, making the security of their source code, dependencies and configurations an important part of organisational cyber resilience.

AI can assist with analysing PHP code, identifying suspicious patterns, correlating security events and prioritising remediation. However, AI is not a substitute for secure software engineering, independent testing or accountable decision-making.

This article introduces a proposed AI-Driven Cybersecurity and Resilience (AICR) Framework, designed to connect AI-assisted vulnerability detection with risk management, incident response, service recovery and AI governance.

The central argument is straightforward: organisations should not measure cybersecurity success solely by how quickly they detect an attack. They should also measure how effectively they prevent exploitation, maintain critical services and recover safely when security controls fail.

1. How cybersecurity incidents take websites offline

Understanding the relationship between cyber threats and service availability is essential before considering where AI can add value.

Distributed denial-of-service attacks

A distributed denial-of-service attack overwhelms a website, application or supporting network with traffic from multiple sources. When the volume of requests exceeds available capacity, legitimate users may experience slow responses or complete service failure.

AI-assisted monitoring can establish normal traffic patterns and identify anomalies such as sudden request spikes, unusual endpoint access or abnormal connection behaviour.

Security systems can use these signals to support rate limiting, traffic filtering, automated challenges and escalation to DDoS mitigation services.

However, AI alone cannot absorb excessive traffic or guarantee accurate attack classification. Resilient architecture, appropriate network capacity, content delivery networks and tested DDoS protection remain essential.

Exploitation of application vulnerabilities

A website may also become unavailable when an attacker exploits weaknesses in its application code.

Common examples include SQL injection, broken access control, insecure file handling, authentication weaknesses and vulnerable third-party components. Depending on the vulnerability and the attacker's access, exploitation can expose data, corrupt records, consume server resources or compromise the application environment.

The OWASP Top 10:2025 identifies major web application risks, including broken access control, security misconfiguration, software supply-chain failures, cryptographic failures and injection. These categories provide a useful foundation for application security assessments. Source: OWASP Top 10:2025.

Compromised credentials and misconfiguration

Not every attack requires an advanced exploit. Weak credentials, stolen session tokens, excessive permissions and incorrectly configured services can provide access to sensitive systems.

An attacker with administrative privileges may alter application code, disable security controls, install malicious components or interfere with normal operations.

These risks demonstrate why application security must be integrated with identity management, access control, configuration management and operational monitoring.

Deliberate shutdown as a containment measure

Taking a website offline is not always a failure of cybersecurity. In some circumstances, it is a deliberate containment decision.

If an application is actively exposing sensitive information or executing malicious code, temporarily disabling an affected component may be safer than keeping it available.

The decision should be proportionate to the threat, the sensitivity of the affected service and the availability of alternative controls. Technology leaders must balance security, customer impact and business continuity rather than treat uninterrupted availability as the only objective.

2. How AI can detect vulnerabilities in PHP applications

PHP applications can develop vulnerabilities through insecure coding practices, inadequate input validation, weak authorisation checks, outdated dependencies and incorrect server configurations.

Traditional security tools remain effective at identifying many of these weaknesses. AI adds another analytical capability: it can help interpret complex code, follow data flows, explain potential impacts and suggest remediation.

The strongest approach combines AI with established application security testing rather than treating AI as an independent security authority.

Detecting SQL injection

SQL injection occurs when untrusted input changes the intended structure of a database query.

Consider this deliberately vulnerable PHP example:

<?php
$id = $_GET['id'];
$sql = "SELECT * FROM customers WHERE id = '$id'";
$result = $pdo->query($sql);
?>

The query directly incorporates user-controlled input. Depending on the surrounding application and database configuration, this can create an SQL injection vulnerability.

An AI-assisted code review could identify the path from $_GET['id'] to the database query, explain the potential risk and recommend parameterised queries.

A safer approach is:

<?php
$id = $_GET['id'];
$stmt = $pdo->prepare(
"SELECT * FROM customers WHERE id = :id"
);
$stmt->execute(['id' => $id]);
?>

Parameterised queries separate the SQL statement from the supplied value, preventing that value from changing the query's structure. Appropriate input validation and error handling are also important.

AI can help developers understand why the first implementation is unsafe and how to correct it. However, automated static analysis and security testing should verify the result.

Identifying insecure file uploads

File-upload functionality can create opportunities for attackers when applications trust supplied filenames, fail to validate file content or store uploaded files in executable locations.

AI-assisted code analysis can identify potentially missing validation, unsafe path construction and inadequate restrictions on accepted file types.

Developers should validate file content, enforce file-size limits, generate safe server-side filenames and store uploads outside executable web directories where practical. Additional malware scanning and access controls may be appropriate depending on the application's purpose.

AI can recommend these safeguards, but the implementation must be assessed against the actual application architecture.

Detecting broken access control

Authentication confirms a user's identity; authorisation determines what that user is allowed to do.

A PHP application may correctly authenticate a customer but still expose another customer's records if it fails to enforce ownership checks.

AI-assisted analysis can review controllers, API endpoints and database queries for missing permission checks or inconsistent enforcement of business rules.

For example, a banking application should verify that a customer is authorised to access a particular account rather than relying solely on a valid session or a supplied account identifier.

The finding must be validated against the application's access-control design and tested in an authorised environment.

Identifying vulnerable dependencies

PHP applications frequently use third-party packages managed through Composer. A vulnerability in one of these components can introduce risk even when the organisation's own code is secure.

Software composition analysis tools can identify vulnerable dependencies and compare them with established vulnerability intelligence. AI can then help explain the affected functionality, assess potential consequences and suggest appropriate upgrades or mitigations.

This distinction is important: a model-generated explanation is not sufficient evidence that a package is vulnerable. Reliable dependency data and technical verification are required.

Combining AI with established security testing

AI is most effective when it complements a broader application security programme.

Technique	Primary purpose
Static application security testing (SAST)	Analyses source code for potentially insecure patterns.
Dynamic application security testing (DAST)	Tests a running application for observable security weaknesses.
Software composition analysis (SCA)	Identifies vulnerable or outdated dependencies.
AI-assisted code review	Helps interpret findings, investigate code paths and propose fixes.
Penetration testing	Validates exploitable weaknesses and realistic attack scenarios.
Runtime monitoring	Identifies suspicious behaviour and operational anomalies.

These techniques provide different forms of evidence. AI can help correlate findings across them, but security professionals must validate significant conclusions before taking high-impact action.

3. The proposed AICR Framework: connecting AI detection with cyber resilience

Detecting a vulnerability is only one stage of cybersecurity management. Organisations must also assess its business significance, determine who is responsible for remediation, authorise corrective action and verify that the resulting system is secure.

The proposed AI-Driven Cybersecurity and Resilience (AICR) Framework addresses this challenge by connecting application security with governance and operational recovery.

AICR is an original proposed operating model for this article, not an established or independently validated industry standard. It is intended to complement recognised cybersecurity standards and AI risk-management guidance.

The five layers of AICR

Layer 1: Discover and establish context

Organisations identify their critical applications, PHP versions, dependencies, APIs, data flows, privileged accounts and service dependencies.

Each asset is classified according to its business importance, exposure and potential customer impact. A public-facing authentication service, for example, may require a different level of protection from an internal reporting tool.

This stage establishes the context needed to prioritise security work according to risk rather than technical severity alone.

Layer 2: Detect and analyse

Security teams combine SAST, DAST, dependency scanning, runtime monitoring and AI-assisted code review.

AI can help trace potentially unsafe data flows, correlate related alerts and explain how a weakness might affect the application. Deterministic tools and authorised security tests provide independent evidence.

The objective is to identify meaningful security weaknesses early and reduce the time required to understand them.

Layer 3: Assess and govern risk

Technical findings are translated into business risks.

Assessment should consider exploitability, exposure, data sensitivity, service criticality, potential operational disruption and existing controls.

AI-generated recommendations are subject to governance requirements appropriate to their risk. These may include human approval, documented evidence, audit logging and restrictions on automated actions.

A critical vulnerability in an exposed customer authentication service may require immediate escalation. A lower-risk issue may be addressed through a scheduled and tested change.

Layer 4: Remediate and respond

Accountable teams implement corrective action, such as securing a database query, patching a dependency, correcting access controls or restricting access to an affected endpoint.

AI may assist with generating proposed code changes or test cases, but changes must undergo appropriate review and testing before production deployment.

If an attack is underway, authorised incident responders may also apply containment measures, including blocking malicious traffic, disabling an affected feature or rolling back a release.

Layer 5: Validate, recover and improve

The organisation confirms that the vulnerability has been addressed, security tests pass and the application behaves as intended.

Where a service has been disrupted, recovery follows documented objectives and considers data integrity, customer impact and security assurance.

Lessons from incidents and near misses are incorporated into coding standards, regression tests, detection rules and AI governance controls.

The process then returns to discovery, creating a continuous improvement cycle.

AICR operational model

<title size="md">1. Discover</title>

<text textAlign="center" size="sm">Assets, dependencies, exposure and business criticality</text> </box>

</row>

<title size="md">2. Detect and Analyse</title>

<text textAlign="center" size="sm">Security scanners, AI-assisted code analysis and runtime monitoring</text>

</box>

</row>

<title size="md">3. Assess and Govern</title>

<text textAlign="center" size="sm">Business risk, evidence, accountability and approval</text> </box>

</row>

<title size="md">4. Remediate and Respond</title>

<text textAlign="center" size="sm">Secure fixes, containment, change control and incident management</text>

</box>

</row>

<title size="md">5. Validate, Recover and Improve</title>

<text textAlign="center" size="sm">Retesting, service restoration and continuous improvement</text>

</box>

**Cross-cutting AI governance**

<text textAlign="center" size="sm">Human oversight, privacy, least privilege, auditability, monitoring and accountability across all five layers.</text>

</box>

<text color="secondary" size="xs">Figure 1. Proposed AICR framework. Governance applies throughout the lifecycle, not just at the point of deployment.</text>

</box>

The framework's key principle is that AI-generated findings should not move directly from detection to production action without an appropriate risk assessment.

For low-risk, well-tested activities, automation may be suitable. For actions that could affect customer access, sensitive data or critical services, stronger validation and explicit authorisation are warranted.

4. Use case: preventing a PHP banking portal outage

Consider a hypothetical retail bank operating a PHP-based customer portal connected to account information, payment services and internal APIs.

An application security scanner identifies a potentially unsafe database query in a newly updated endpoint. At the same time, monitoring detects unusual request volumes and repeated attempts to access account information.

These signals do not automatically prove that the application has been compromised. However, together they justify a focused investigation.

Under the AICR framework, the response would proceed as follows.

Step 1 — Establish the baseline. The bank uses application and infrastructure monitoring to understand normal request rates, authentication failures, endpoint usage and response times.

Step 2 — Correlate security evidence. Detection systems assess the unusual traffic alongside application errors, authentication events and the code-scanning finding. AI helps analysts interpret the evidence and identify relevant code paths.

Step 3 — Validate the vulnerability. Security engineers examine the database query and perform authorised tests in a controlled environment to establish whether the weakness is exploitable.

Step 4 — Assess business impact. The team considers the endpoint's exposure, the sensitivity of the affected records, the potential for unauthorised access and the impact of taking the service offline.

Step 5 — Contain and remediate. If exploitation is suspected, authorised responders apply proportionate controls. Developers correct the vulnerable query, review related code and prepare regression tests.

Step 6 — Approve and validate recovery. The corrected release is reviewed, tested and deployed under the appropriate change process. Security testing confirms that the weakness has been addressed before the service returns to normal operation.

This approach connects application security, incident response and service management rather than treating each as a separate activity.

The expected benefit is earlier investigation, more focused remediation and better-informed recovery decisions. It does not guarantee that an attack will be detected or that downtime will be eliminated.

5. Why AI governance matters as much as vulnerability detection

AI introduces risks that organisations must manage alongside conventional cybersecurity threats.

A model may incorrectly classify legitimate activity as malicious, overlook an exploitable weakness, recommend an insecure code change or produce an explanation that sounds convincing but is technically incorrect.

AI coding agents can also create vulnerabilities if they introduce unsafe dependencies, mishandle secrets or modify security-sensitive logic without adequate review.

Where AI systems have access to source code, production logs or deployment tools, excessive permissions can turn a model error into an operational incident.

AI governance therefore establishes who is accountable, what an AI system may do, how its outputs are validated and when human approval is required.

A practical AI governance model

Risk classification and accountability

Classify AI-assisted activities according to their potential consequences. An AI tool that summarises a code warning presents a different risk from an agent authorised to modify authentication logic or deploy changes to production.

Assign responsibility to application owners, security teams, AI system owners and change-approval authorities.

Human oversight and approval

AI may recommend temporarily disabling a banking feature, but an authorised incident commander or designated service owner should determine whether that action is proportionate.

The decision should consider the threat, the effect on customers, alternative controls and recovery requirements.

Routine actions can be automated when their boundaries, failure modes and rollback arrangements have been tested and approved.

Privacy and confidentiality

Source code, security logs and vulnerability reports may contain confidential information or personal data.

Organisations should restrict the information sent to AI providers, apply data-minimisation principles, establish appropriate retention arrangements and use approved tools.

Proprietary source code and sensitive production data should not be submitted to unapproved public AI services.

Explainability and auditability

Security decisions should be traceable to evidence.

AI-assisted findings should identify the affected component, relevant code or events, potential impact, limitations and recommended validation steps.

Audit records should capture significant recommendations, approvals and actions, supporting incident investigation and accountability.

Model validation and monitoring

AI security systems should be tested against representative code, realistic attack scenarios and known failure cases.

Organisations should monitor false positives, false negatives, detection delays and remediation quality. Models and detection rules should be reassessed as applications and attack techniques evolve.

Least privilege and secure deployment

AI agents should receive only the access required for their tasks. Development and testing should take place in controlled environments, with protected secrets, reviewed code changes and restricted production permissions.

Organisations must also consider AI-specific threats, including prompt injection, data poisoning and unauthorised disclosure of information.

The UK Government's AI Cyber Security Code of Practice provides guidance on securing AI systems throughout their lifecycle, including design, development, deployment and maintenance. It emphasises risk assessment, human responsibility, security testing, monitoring and appropriate protection of assets.

6. Integrating AICR with established cybersecurity standards

AICR is most useful when mapped to recognised standards rather than implemented as a competing set of controls.

Three references provide a strong foundation.

NIST Cybersecurity Framework 2.0 organises cybersecurity outcomes around six functions: Govern, Identify, Protect, Detect, Respond and Recover. It helps organisations connect security activities with business objectives and risk ownership.

NIST AI Risk Management Framework provides a structure for managing AI risks through four functions: Govern, Map, Measure and Manage.

OWASP Application Security Verification Standard (ASVS) provides verifiable security requirements for web applications, helping organisations define and test the controls that applications should implement.

Sources: NIST Cybersecurity Framework, NIST AI Risk Management Framework, and OWASP Application Security Verification Standard.

The relationship can be summarised as follows:

AICR capability	Established reference	Practical application
Discover assets and establish context	NIST CSF 2.0: Identify	Maintain application and dependency inventories.
Detect and analyse vulnerabilities	OWASP ASVS and application security testing	Define verifiable security requirements and test application code.
Assess and govern AI-related risk	NIST AI RMF: Govern, Map, Measure, Manage	Establish accountability, risk criteria and oversight.
Remediate and respond	NIST CSF 2.0: Protect and Respond	Correct vulnerabilities and manage incidents.
Validate and recover	NIST CSF 2.0: Recover	Test fixes and restore services securely.

This mapping provides a practical route from the proposed framework to existing organisational security processes.

It also helps avoid a common mistake: assuming that deploying an AI security product automatically establishes a mature security programme.

7. From AI governance to operational resilience

A vulnerability is not merely a technical defect. It is a risk that must be assessed, assigned, prioritised, remediated and verified.

Organisations can integrate AI-assisted findings into established IT service management processes.

For example, an active exploit may trigger incident management. A recurring security weakness may require problem management to establish its root cause. Remediation may require a change record, testing, approval and controlled deployment. Following the incident, the organisation should review the effectiveness of its controls and update its security practices.

This creates a continuous improvement cycle:

Detect → Assess → Prioritise → Remediate → Validate → Learn.

Technology leaders should measure outcomes through indicators such as:

Mean time to detect (MTTD): how quickly security incidents are identified.
Mean time to remediate (MTTR): how quickly confirmed vulnerabilities are resolved, with the metric definition clearly specified.
Critical vulnerability remediation: the proportion of critical findings resolved within agreed timeframes.
Recurring defect rate: how often similar security weaknesses reappear across releases.
Service availability: the availability of critical customer-facing applications.
AI recommendation quality: the proportion of AI-generated security recommendations independently validated and accepted.
Governance compliance: the proportion of high-risk AI-assisted actions with appropriate approval and audit records.

These measures should be compared with an established baseline. Organisations should not attribute improvements to AI unless the evidence supports that conclusion.

The goal is not to maximise the number of vulnerabilities an AI system reports. It is to reduce exploitable weaknesses, improve response quality and maintain reliable digital services.

8. What technology decision-makers should do next

For CIOs, CISOs and application owners, the practical priority is to make AI-assisted cybersecurity part of secure software delivery and business continuity.

First, establish visibility. Maintain an inventory of critical applications, PHP versions, dependencies, APIs, data classifications and business owners.

Second, strengthen the software development lifecycle. Integrate SAST, DAST, dependency scanning and secret detection into development and release processes. Use AI to assist with deeper analysis while retaining deterministic tests and qualified review.

Third, prioritise according to business risk. Consider exploitability, exposure, data sensitivity and service criticality rather than relying solely on technical severity scores.

Fourth, establish AI governance before granting autonomy. Define access permissions, approval thresholds, audit requirements and prohibited actions before AI agents can modify code, access sensitive information or initiate production changes.

Fifth, test recovery. Maintain appropriate backups, rollback procedures, incident response plans and recovery objectives. Verify that restored applications are secure rather than simply available.

Finally, measure results. Compare vulnerability remediation, recurrence, false-positive rates and service availability against documented baselines. Use the evidence to refine both technical controls and governance arrangements.

These measures support a secure-by-design approach in which cybersecurity is incorporated throughout the application lifecycle instead of being treated as a final check before release.

Conclusion: Intelligent detection requires accountable decisions

Cybersecurity incidents can take websites offline through traffic flooding, software exploitation, compromised credentials and misconfiguration. In some cases, temporary shutdown is a necessary containment measure; in others, it is an avoidable consequence of weaknesses that could have been identified earlier.

AI can help security teams analyse PHP code, identify suspicious behaviour, correlate findings and prioritise remediation. Combined with established security testing and effective monitoring, it can improve the speed and consistency of application security operations.

However, AI can also produce incorrect findings, introduce insecure code and trigger harmful actions when its permissions and outputs are poorly controlled.

The proposed AICR Framework connects five operational capabilities: discovery, detection and analysis, risk assessment and governance, remediation and response, and validation and recovery. By applying governance across every layer, organisations can use AI to support security decisions without transferring accountability to the model.

For financial services and other organisations that depend on digital channels, the strategic objective is not simply to keep websites online. It is to maintain secure, reliable and trustworthy services while responding effectively to changing threats.

The organisations best positioned to withstand cyber threats will be those that combine intelligent detection with disciplined engineering, accountable AI governance and measurable operational resilience.

মূল প্রতিবেদনে যান ↗