PHP2Shell Vulnerabilities: What Banks and Credit Unions Need From Their Vendors

Two critical PHP vulnerabilities have raised questions about the security of banking websites, lending platforms, digital banking services, and the third parties responsible for operating them.

On October 21, 2026, MSU Federal Credit Union temporarily took its website and digital banking services offline while it addressed vulnerable PHP systems. Members went approximately 24 hours without online and mobile banking, although branches, ATMs, payment cards, and the call center remained operational. The credit union patched the affected systems, which it developed and maintained internally, and restored its primary digital banking services the following day.

April Clobes, Chief Executive Officer of MSU Federal Credit Union, said the precautions “were necessary to ensure we could safely restore services.” Some secondary functions were still being restored when American Banker reported on the incident October 23. The interruption was precautionary, with no confirmed intrusion or reported impact to member information at the time.

The shutdown followed the disclosure of PHP2Shell, two critical vulnerabilities identified as CVE-2026-109618 and CVE-2026-109619. For community banks, regional banks, and credit unions, the concern extends beyond systems they operate directly. Many customer-facing services depend on outside technology providers, making it important to establish where vulnerable software may be running and whether those providers have completed remediation.

What Are the PHP2Shell Vulnerabilities?

PHP2Shell refers to two critical vulnerabilities in PHP, the server-side programming language used by many websites and web applications. Both received a CVSS v4.0 severity score of 9.2 and can permit unauthenticated remote code execution under certain conditions. The flaws exist in the PHP runtime itself rather than in a particular banking application or content management system.

CVE-2026-109618 involves PHP's handling of certain out-of-memory conditions. A specially crafted request can cause memory allocation to fail while internal request data remains partially initialized, allowing subsequent cleanup operations to process invalid information. For Apache deployments using mod_php, researchers demonstrated an attack path that can occur before application code executes. Consequently, an application's login requirement does not necessarily prevent a malicious request from reaching the vulnerable PHP processing code.

CVE-2026-109619 involves unsafe internal state persisting between requests. A PHP worker—the server process handling incoming web requests—may retain a reference to memory that has already been freed. A later request handled by the same worker may encounter that reference. Exploitation depends on configuration, request timing, memory layout, and other conditions.

The PHP project advises organizations to assess deployments using Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed. These configurations do not have identical exploitation paths, and the presence of an affected PHP version does not establish that every application can be exploited in the same manner.

The original PHP security advisories provide further detail on CVE-2026-109618 and CVE-2026-109619.

Fixed PHP Versions for CVE-2026-109618 and CVE-2026-109619

The PHP development team released emergency security updates on October 21, 2026.

‍

PHP 8.1 and older branches no longer receive regular upstream security releases. Some Linux distributions and commercial extended-support providers maintain security backports, so an older version number does not necessarily indicate that a particular deployment remains vulnerable. Institutions should verify the installed package against the applicable vendor bulletin. PHP 8.2 also reaches upstream end of life on December 31, 2026, making an upgrade plan necessary even after the current fixes have been applied.

Updating WordPress, its themes, or plugins does not resolve a vulnerability in the underlying PHP engine. Likewise, installing a corrected PHP package may not complete remediation if older worker processes remain active in memory or corrected container images have not been deployed. Web application firewalls can help block certain malicious requests, but they do not replace runtime remediation. The PHP security announcement provides official release information and mitigation guidance.

Which Banking Vendors Could Be Exposed to PHP2Shell?

Many financial institutions depend on outside providers for customer-facing applications, hosting, and document processing. They may have limited visibility into the software supporting those services, particularly when a vendor relies on additional technology providers for infrastructure or administration.

The following categories deserve attention because of the information they handle, their accessibility, or their importance to banking operations.

‍

These are priorities for investigation, not assertions that every provider uses PHP or operates vulnerable software. The potential consequences also depend on the permissions and integrations available to an affected application. Compromising a PHP worker does not automatically provide access to a financial institution's core processing system.

When evaluating a vendor's exposure, banks should consider the application's access to stored credentials, service accounts, databases, network resources, and transaction-related functions. Shared hosting arrangements and subcontracted infrastructure may introduce dependencies that are not apparent from the primary vendor relationship.

What Should Banks Ask Their Vendors About PHP2Shell?

A financial institution may not have administrative access to the servers supporting a critical lending or digital banking platform. It can nevertheless require the provider to assess its exposure, document the results, and explain how any identified vulnerabilities have been addressed.

The inquiry should begin with a question that identifies both CVEs and requests a remediation status:

Are any of your production systems or supporting infrastructure affected by the recently disclosed PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 (PHP2Shell)? If so, please provide remediation status and expected completion date.

This question can be incorporated into the institution's existing vendor due diligence and ongoing monitoring program. For critical providers, the response should establish which environments were assessed, what remediation was performed, and whether supporting infrastructure operated by subcontractors was included.

What Counts as Adequate Remediation Evidence?

A completed change ticket or a statement that patches were installed may not establish that vulnerable processes have stopped running. Institutions should request supporting information proportionate to the vendor's criticality and the sensitivity of the services involved.

‍

A pending remediation plan remains an open finding even when interim protections have been implemented. Similarly, a statement that no compromise was identified does not establish that the underlying vulnerability has been corrected.

The Importance of Fourth-Party Providers

In a September 2026 discussion of community banking risks, Andrew Pyles, President and Chief Executive Officer of Eclipse Bank in Louisville, Kentucky, raised a question that applies to complex technology relationships:

“You need to ask: Who are your vendors’ vendors?”

His statement, published by ICBA's Independent Banker, addressed fourth-party risk generally rather than PHP2Shell specifically.

A digital lending provider may operate its application while relying on another company for hosting, infrastructure management, or technical support. The institution's assessment should account for the providers responsible for the underlying components used to deliver its services.

Has PHP2Shell Been Exploited in the Wild?

Security researchers have documented attempts to exploit PHP2Shell, including activity that preceded the official October 21 disclosure. Amazon Threat Intelligence identified an attempt dating to October 17, 2026, in its MadPot honeypot telemetry, with additional attempts appearing as information about the vulnerabilities became public.

Attempted exploitation does not establish that an attacker successfully compromised a system. Early public reports claiming or attributing successful PHP2Shell exploitation also required correction. Sophos revised an initial success claim, while Palo Alto Networks Unit 42 withdrew an earlier incident attribution. An October 23 American Banker review had not identified a publicly reported PHP2Shell compromise at a U.S. bank or credit union, although that observation was limited to the information available at the time.

Potentially affected institutions and vendors should consider reviewing available logs and endpoint telemetry beginning at least October 17. Unusual multipart requests, repeated PHP worker failures, unexpected processes launched by PHP services, suspicious outbound connections, and unauthorized file changes may warrant investigation. Individual indicators should be evaluated in context rather than treated as conclusive proof of compromise.

Where compromise is suspected, incident response personnel should consider preserving relevant process-memory and other volatile evidence before restarting affected systems, when feasible and without unnecessarily delaying containment. Restarting processes can destroy evidence that may be useful in determining whether exploitation occurred. Google Cloud's PHP2Shell response guidance discusses this consideration.

PHP2Shell and Banking Regulatory Reporting Requirements

The discovery of vulnerable PHP software does not automatically constitute a reportable cybersecurity incident. Notification obligations depend on the applicable rule and the circumstances of the event.

Under the federal banking agencies' computer-security incident notification rule, a banking organization generally must notify its primary federal regulator as soon as possible and no later than 36 hours after determining that a qualifying notification incident occurred. Certain covered bank service providers have separate requirements involving qualifying incidents that materially disrupt, or are reasonably likely to materially disrupt, covered services for four or more hours. The FDIC's rule summary provides additional information.

Federally insured credit unions generally must notify NCUA within 72 hours after reasonably believing that a reportable cyber incident occurred. The NCUA Cyber Incident Reporting Guide explains the applicable requirements. Institutions should evaluate potential notification obligations with incident response leadership and counsel.

Third-party cybersecurity exposure was a supervisory concern long before PHP2Shell. During an October 2024 NCUA cybersecurity briefing, Todd M. Harper, then Chairman of the National Credit Union Administration, warned that:

“third-party service providers are a weak link in the financial system”

The NCUA briefing addressed broader cybersecurity and outsourcing risks rather than these specific vulnerabilities. For banks, the federal banking agencies' 2023 interagency third-party risk management guidance addresses risk-based due diligence, ongoing monitoring, and management of third-party relationships.

Financial institutions can document their PHP2Shell assessments within those existing oversight processes. Vendor records should distinguish between confirmed non-exposure, verified remediation, outstanding vulnerabilities, and responses that remain insufficient to establish a vendor's status. Unresolved findings should retain accountable owners, remediation deadlines, and appropriate interim controls.

How NETBankAudit Can Support PHP2Shell Risk Assessments

NETBankAudit provides financial institutions with risk-focused auditing, cybersecurity assessments, technical testing, and regulatory consulting services. Its IT General Controls audits, internal and external vulnerability assessments, website security reviews, and vendor-management risk assessments can help institutions evaluate patch-management practices, review vendor assurances, and identify weaknesses in supporting controls.

Business continuity and incident response assessments can also address the procedures used when containment or remediation affects critical banking services. Institutions seeking an independent evaluation of their cybersecurity controls, vendor oversight, or PHP2Shell remediation documentation can contact NETBankAudit to discuss an assessment appropriate to their circumstances.