On 21 October the NCSC issued an alert about a critical security issue affecting PHP. Two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, could let an attacker corrupt memory in PHP and, under the right conditions, run code on a server without logging in. PHP runs a lot of the web, so a lot of people had a busy day.
The short answer for our customers: we had audited everything that uses PHP before the fix existed, patched it the same afternoon the fix was released, and checked every service afterwards. We believe we're protected, and customer data remains secure. You don't need to do anything about the services we provide.
The longer answer is below. It's also a chance to explain why a day like this is routine for us rather than a crisis.
What we did
We heard about the two vulnerabilities on the morning of 21 October, before a fix had been released. We didn't wait for one.
- We found everything that runs PHP. We audited every Simwood service that uses PHP, not just the ones we thought might be out of date. The NCSC was clear that all versions were affected.
- We applied the interim measures. Where the PHP project recommended temporary mitigations, we put them in place straight away, so affected services were protected while we waited for the fix.
- We patched as soon as the fix landed. The fix was released at 14:00 (UTC). We treated it as urgent and updated every affected service to the fixed version.
- We checked our work. We verified each service was running the fixed version and working normally. A patch you haven't checked is just a hope.
None of that is clever. It's what you should expect from anyone who carries your calls and holds your data. The point is that it was ready to happen, on the day.
Why it's routine
Security isn't a project we pick up when there's a headline. It's how we run the business.
- It's our network. We don't resell anyone else's. We control every element of our infrastructure, so when something needs fixing we know where it lives and we can fix it ourselves, without waiting on a supplier's supplier.
- Updates are business as usual. Every one of our services runs in containers, so it's built and deployed the same way everywhere across the network. There are no forgotten servers or one-off setups. We roll out updates routinely through a CI/CD pipeline we've relied on for years, and nobody notices them. The PHP fix went out the same way.
- We're certified, and audited. We hold ISO 27001 for information security and ISO 9001 for quality management. Both mean independent auditors check that we do what we say.
- We're regulated, and we take it seriously. As a public communications provider we're subject to the Telecommunications Security Act 2021 and the Electronic Communications (Security Measures) Regulations 2022. They set a high bar for how we manage risk, and that's how it should be. Our privacy policy sets out how we handle your data.
- Encryption isn't an upsell. We turned on TLS and SRTP for calls in 2013, and they've been free on every call since.
- Protection is built in. Every account gets more than 200 real-time fraud controls, included as standard.
When something like this PHP issue comes along, all of that means the work is small and fast: we know what we run, we can change it ourselves, and shipping a fix is just another release.
What this means for you
For the services we provide, nothing. There's nothing for you to do.
If you run PHP on your own systems, please follow the NCSC's advice:
- find every PHP installation you have, starting with anything facing the internet;
- update to the latest fixed version;
- if you can't update straight away, apply the PHP project's temporary mitigations, or consider taking affected services offline;
- check for updates to products that bundle PHP, which is easy to forget.
We'll keep watching guidance from the NCSC and the PHP project, and we'll act on it. If you have questions, our support team is happy to help.