Banks dodge early damage from PHP2Shell flaws

• Key insight: Attackers have fired millions of attempts at the PHP2Shell flaws, but no U.S. bank or credit union has publicly reported a compromise.
• Expert quote: "You own the risk even when a vendor runs the system," wrote Samantha Van den Broek of Crimson Oak Strategies, a compliance consultancy for credit unions.

Overview bullets generated by AI with editorial review.

Processing Content

Attackers have fired millions of attempts to exploit two critical flaws, nicknamed PHP2Shell, in the code behind most of the world's websites this week. Federal agencies have told organizations to patch or pull vulnerable systems offline.

For U.S. banks and credit unions, the damage so far has been limited.

MSU Federal Credit Union, or MSUFCU, an $8.9 billion credit union in East Lansing, Michigan, took its website and digital banking offline Wednesday after the federal warnings.

The systems it took down ran PHP and were vulnerable to the flaws, Allison Horn, the credit union's chief of staff, told American Banker.

MSUFCU patched the systems and restored online and mobile banking Thursday. "There is no impact to member information at this time," Horn said.

No U.S. bank or credit union has yet publicly reported a compromise stemming from the PHP flaws.

Eight percent of financial services organizations that cybersecurity company Check Point tracks had an exploit attempt against them, according to a Thursday blog post from the company. Compare that to 10% across all sectors.

Check Point counts organizations that saw exploit attempts; the company said it has no way of knowing whether the attacks succeeded.

The recently disclosed vulnerabilities matter to banks because they affect PHP, a programming language that runs almost 70% of websites, according to data from web survey firm W3Techs.

At banks and credit unions, PHP can run public websites, online banking and online applications for loans and memberships.

Hosting companies or web developers run most credit unions' websites, according to a Thursday blog post from Crimson Oak Strategies, a compliance consultancy for credit unions.

Sometimes institutions build their own. MSUFCU's affected systems were "developed by and maintained by MSUFCU, not a vendor," Horn said.

What PHP2Shell is

The two flaws, tracked in the public catalog of software vulnerabilities as CVE-2026-109618 and CVE-2026-109619, each carry a severity rating of 9.2 out of 10.

Under the right conditions, they let an attacker run code on a server without logging in, according to the PHP project's Wednesday security advisory.

The flaws are in PHP itself (in how it cleans up memory after an error), so updating WordPress (a popular website platform built on PHP) or a website plugin does not fix them, according to a Wednesday blog post from Cloudflare. Administrators have to update PHP itself.

PHP released fixes in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Versions 8.1 and older get no new release from the PHP project.

Wiz, OpenAI and a security research firm named Calif found the flaws with help from artificial intelligence tools, according to blog posts from the three companies.

Lots of attacks, little proof of damage

Word of the flaws began circulating online Tuesday, a day before PHP released its fixes, according to a Wednesday post from the nonprofit PHP Foundation.

In the 10 hours before the flaws were formally announced, Cloudflare's network saw thousands of attempts to exploit them, "and millions now," Cloudflare CEO Matthew Prince said in a post on X late Wednesday.

Attempts are not break-ins. CISA said in a Wednesday alert that it had "not observed exploitation" of the flaws as of the alert's publication.

"The public exploits do not work against a default PHP installation," e-commerce security firm Sansec said in a Thursday update to its research post. An attack "needs specific knowledge of the target server and specific conditions on it," the update said.

There might be exceptions. VulnCheck, which sells exploit intelligence, said in a blog post that it built a working exploit that defeats a standard memory protection on servers running some versions of PHP 8.4 with PHP's recommended production settings.

While Sansec's claims suggest that the exploits are inert against many unpatched websites and web applications, VulnCheck's claims suggest that some are vulnerable.

Regardless, there are steps a financial institution can take to minimize the risk these PHP flaws pose to data security.

What banks are being told to do

The ultimate fix for the vulnerabilities is to install a patched version of PHP on every server that runs an institution's websites.

For organizations that cannot patch right away, the Cybersecurity and Infrastructure Security Agency, the National Security Agency and the FBI each urged them to take PHP systems offline in the meantime.

Following that advice has a cost. MSUFCU members went about 24 hours without online or mobile banking, though branches, the call center, ATMs and cards kept working, according to a statement from CEO April Clobes that the credit union provided to American Banker.

Statement viewing, web-based check deposit and the credit union's virtual assistant were still coming back Friday, and MSUFCU expected them to be restored by the end of the day, chief of staff Horn said.

The precautions "were necessary to ensure we could safely restore services and maintain the trust our members place in us every day," Clobes said.

In Japan, megabanks and several regional banks suspended some online services as a precaution, Jiji Press reported. The Japanese Bankers Association confirmed that the network that settles payments among nearly all of Japan's banks had not been affected, Jiji reported.

The New York Department of Financial Services, which oversees state-chartered banks, insurers and other financial companies in the state, told the firms it regulates to patch immediately and to take systems they cannot patch offline, according to an industry letter issued Thursday.

Web application firewalls, which filter malicious traffic before it reaches a website, "may provide limited protection" but "should not be used as a substitute for patching or isolation," the letter said.

For institutions that rely on vendors to run their websites, the fix runs through them. The New York regulator told firms to "coordinate with third-party service providers to assess exposure" and to confirm that those providers have fixed the flaws.

"You own the risk even when a vendor runs the system," Samantha Van den Broek wrote in the Crimson Oak post.