PHP Vulnerabilities: What Banks and Credit Unions Should Do

Two critical PHP flaws just hit. Is your institution exposed?

On October 21, 2026, the PHP project rushed out emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS v4.0 score of 9.2. If your credit union or community bank runs PHP anywhere, from your public website to a vendor-hosted tool, an attacker could take control of that server without ever logging in.

Here’s the good news for FMSI clients: RelationshipOS does not use PHP, so it is not affected. No patches, no downtime, nothing to do.

But PHP is everywhere, and your exposure doesn’t stop at one vendor. Below is what happened, where PHP tends to hide inside a financial institution, a five-step checklist for your IT team, and the questions every vendor should be able to answer within days of a threat like this.

What happened with CVE-2026-109618 and CVE-2026-109619

PHP is a programming language behind a huge share of websites and web applications. The two flaws let an attacker run their own code on an unpatched PHP server, with no username or password required.

That’s why both are rated Critical (CVSS v4.0 9.2). Code execution on a web server can mean defaced websites, stolen form data, or a foothold into other systems.

Where PHP hides at credit unions and community banks

Most institutions don’t write PHP, but they often run it without knowing. The usual places to look:

The last two are the hardest. When a vendor hosts the software, you depend on them to know their own stack, patch fast and tell you about it. That makes this as much a third-party risk question as a technology one.

Your 5-step PHP vulnerability checklist

Share this with your IT and security teams today.

5 questions to ask every technology vendor

A critical vulnerability is a stress test for your vendors. The good ones answer before you ask. If you’re still chasing replies a week later, that tells you something.

Vendors who can’t answer these quickly are adding risk to your institution, even if they turn out not to be affected.

Why FMSI clients didn’t lose a minute on this

While many institutions spent the week chasing vendors for answers, FMSI clients already had theirs.

Not affected by design. RelationshipOS doesn’t use PHP, so the vulnerable component simply isn’t there to exploit. No emergency patch window, no downtime, no change to how your branches run.

Answered within two days. PHP released its fixes on October 21. FMSI clients had a written advisory on October 23, before most had time to ask.

Examiner-ready from day one. Our advisory is written to drop straight into your vendor management and third-party risk file, and it’s shareable with your board, auditors and regulators.

A team that keeps watching. We continue to monitor these vulnerabilities and will contact clients directly if anything changes.That’s the standard your branch technology partner should meet: secure architecture, fast and plain-language answers, and documentation you don’t have to request.

That’s the standard your branch technology partner should meet: secure architecture, fast and plain-language answers, and documentation you don’t have to request.

The takeaway: security is a vendor decision

While many institutions spent the week chasing vendors for answers, FMSI clients already had theirs.