When a Critical Vulnerability Hits the Runtime: How RemitSo Responds, Step by Step

Most security problems live in an application's own code, so the application's own checks can be part of the answer. A runtime vulnerability is different. When the flaw sits in the language that runs every request, it can be reached before a login screen, before input validation and before any business rule. On 21 October 2026 the PHP project shipped emergency fixes for two flaws of exactly this kind, nicknamed PHP2Shell. RemitSo had the fix on all 23 of its servers within an hour. This guide uses that advisory to show how RemitSo's engineers handle a critical vulnerability, from the moment it is published to the moment every client installation is proven safe, and what that means for the money transfer operators who run on RemitSo.

The principle: the objective is not simply to deploy a security fix. It is to establish four things: what was updated, what was verified, what the investigation found, and whether further action is required. An incident is closed only when all four have a written answer.

RemitSo, a white label remittance platform, gives every client its own deployment in a dedicated AWS account. That shapes everything below: there is no single server to patch, there is a known list of installations, and each one has to be updated and checked on its own. Your team still owns your own decisions, such as telling your customers or your regulator about an incident, but you should never have to find out about a platform vulnerability before we do.

The PHP project published advance notice on 20 October and released fixes on 21 October 2026 for two vulnerabilities, each rated 9.2 out of 10 under CVSS 4.0:

• CVE-2026-109618: when PHP runs out of memory part-way through setting up a request, the clean-up step can treat half-built data as valid.
• CVE-2026-109619: internal state that belongs to one request can survive after its memory is freed, and a later request handled by the same worker can use it.

Under the right conditions, either could let an attacker run code on the server without signing in. Both sit in how PHP processes a request, which is why application-level protections cannot be relied on alone.

The PHP project, the UK's National Cyber Security Centre and AWS all said the same thing: updating is the only complete fix. Temporary settings and firewall rules reduce exposure while you patch. They do not make an installation safe, and AWS notes that the second flaw is largely out of reach of any web application firewall.

When the PHP project released its fixes on 21 October, RemitSo's engineers had the patched runtime on all 23 servers that run client installations within an hour. That speed did not come from heroics on the day. It came from the groundwork described in the rest of this guide: a list of every installation and what it runs, a pipeline that can rebuild and redeploy each one, and a habit of proving a fix rather than assuming it.

The response follows the same path whatever the vulnerability:

Advisory published → find every installation → read what the flaw really reaches → contain → patch the runtime → prove the fix → validate critical operations → look back for compromise → assess customer impact → close with four answers → tell clients → improve.

The first question in any incident is "where are we exposed?" Teams that answer it by logging in to servers one by one lose the first day. RemitSo answers it from records it keeps all the time:

• A known list of installations. Every client runs its own deployment, and every environment, staging and production, shows exactly which release it runs. "Which version are we on?" always has an answer.
• A software bill of materials. Each installation can list every third-party component it is built from, with its version and licence, in the format auditors and security scanners read. When an advisory names a component, the question "do we use it?" takes minutes.
• An infrastructure picture. Each installation can draw its own hosting estate: the domain names requests arrive on, what answers them, and the database, queue and storage behind them. That tells the team which part of the stack a runtime flaw would touch.

A 9.2 score says how bad a flaw can be. It does not say whether it reaches you. RemitSo's engineers assess exposure from what the advisory actually describes: which request path is affected, which settings make it worse, and whether that path exists in how our installations are built and hosted.

The same habit applies to everyday dependency alerts. Automated audits run against the platform's dependencies, and each finding is read for what it actually does before anyone decides how urgent it is. Two rules come out of that:

• An advisory with no fix in the version line we run turns an upgrade into security work. A framework upgrade planned as modernisation stops waiting its turn when it is the only way to close an advisory.
• "Nil exposure" is written down, with the reason. When a flaw cannot reach us, the reasoning is recorded, so the next person does not have to rediscover it. If it can be fixed cheaply anyway, it is fixed.

Where a fix is not yet in place, the published temporary mitigations reduce exposure. They are treated as a stopgap, never as the fix.

The fix itself means replacing the runtime, not just the application. In practice:

1. Rebuild from a corrected base. The runtime an installation runs is rebuilt from the patched release, not edited in place.
2. Deploy to every installation. Each client's deployment is updated through the normal release pipeline. Security and stability fixes are not held for office hours: they can go out any day, including weekends.
3. Replace what was running. A new image does not help if old workers are still serving requests, so running instances are replaced, not assumed to have picked it up.
4. Keep the checks that matter. Critical journeys, such as a quote, a payment and a payout, are checked after the change, without letting ordinary release scheduling delay an urgent fix.

"We deployed it" is not the same as "every installation runs it". RemitSo closes that gap in two ways:

• Coverage, not hope. Each release is tracked against every client installation, staging and production, so the team can see how many production installations run the fixed release and which, if any, do not yet.
• Evidence that does not change. When a fix is proven on a real installation, the proof is recorded as a sealed evidence record: what was claimed, whether it passed, where, on which version and when, with the files that prove it. Sealed records cannot be edited. A newer record can only supersede an old one.

A security fix is verified the way its advisory is described: against the patched versions it names, one by one, rather than by trusting a summary that says "no issues found".

A patched runtime that breaks payouts is a second incident. So after the fix, the operations that move money are checked one by one, on each installation, using the same pages your team uses every day:

Scout measures its figures every five minutes, so after a change the team can watch each one settle back to normal rather than wait for a customer to notice.

Patching stops future exposure. It does not prove nothing happened before the patch. The look-back uses records the platform keeps anyway:

A money transfer platform serves two groups: the operator's team and the operator's own customers. Before an incident is closed, each installation gets an impact statement that answers the questions both groups would ask:

• The window. From when was the installation exposed, and when was it patched?
• Data. Could customer or staff data, such as profiles or identity documents, have been reached, and does any evidence say it was?
• Money in flight. Were any transfers delayed, failed or sent twice during the window or the fix?
• What customers saw. Did anyone meet an error or an outage in the app?
• Secrets. Could any credential, such as a key to a payment or payout partner, have been exposed? If so, it is rotated.

"Potential" matters here. The statement separates what could have been reached from what the evidence shows was reached, so nobody under-reacts or over-reacts. Deciding whether to tell your customers or your regulator stays with you. Our job is to give you facts you can rely on when you make that decision.

The objective is not simply to deploy a fix. Each installation's incident record answers four questions, each backed by evidence:

Security communication has two jobs that pull against each other: clients need to know, and detail published too early helps attackers more than defenders. RemitSo's release notes handle both:

• Every release says whether it contains a security fix, and whether it needs downtime or a maintenance window.
• The detailed security note is shown only once every production installation has the fix. Until then, a client knows a security fix is coming without the release notes describing how to exploit an installation that has not been updated yet.
• Actions a client must take are spelled out, such as a setting to review or an app change to make, rather than buried in technical notes.

For your customers, the benefit is mostly invisible, and that is the point: their money keeps moving, their data stays where it belongs, and nobody has to explain an outage that a patched runtime would have prevented.

If you run your own stack, including on RemitSo source code, this is the checklist we work to:

1. Keep a live list of every environment, the runtime and version it runs, and its owner.
2. Keep a software bill of materials for each one.
3. When an advisory lands, list affected environments within hours, internet-facing first.
4. Read what the flaw reaches; record "not exposed" with the reason.
5. Apply official temporary mitigations only as a stopgap, and restart workers so they take effect.
6. Rebuild from the patched runtime; replace running instances.
7. Verify the running version on every instance, not just the image tag.
8. Check every operation that moves money: sign-in, quotes, payments in, payouts out, screening, the books and background jobs.
9. Preserve logs and look back for compromise before you declare it closed.
10. Write an impact statement per environment: the window, what could have been reached, what the evidence shows, and what customers saw.
11. Close only when you can say what was updated, what was verified, what the investigation found and whether further action is required.
12. Tell the people who depend on you what they need to do, without publishing exploit detail early.
13. Plan upgrades off end-of-life runtime branches before the next advisory forces it.

Security is built into how RemitSo is run, not added when an advisory arrives: ISO 27001:2022 certified processes, a dedicated AWS account per client, rate-limited sign-in and verification codes, secrets masked in every log, and dated releases tested on your staging first. Read how we work with established operators, see the admin features, follow every change in the release notes, or book a demo to ask our engineers how they would handle your next security review.

Sources: PHP security release, 21 October 2026; UK National Cyber Security Centre advisory; AWS Security Blog on PHP2Shell mitigations.