On 21 October, two critical flaws were found in software that runs around 70% of the web. Here’s what Kamma’s engineering team did between the announcement and the last service coming back online.
At 3pm UK time on Wednesday 21 October, the team behind PHP released details of two critical security flaws. PHP is a programming language that sits underneath a large share of the internet. Security researchers at Wiz estimated the flaws affected around 70% of websites. Parts of Kamma run on PHP too, including Kamma Suite, our Reapit integration and some of the services that match addresses behind our property data.
Flaws like these let an attacker run their own instructions on a server they should have no access to. You don’t wait to find out whether someone will try.
The decision: switch off first
The release had been flagged in advance, and that morning the plan was to patch each service in turn with little or no interruption. By early afternoon it was clear the flaws were more serious than first expected. Our engineering team made the call: every Kamma service that used PHP, directly or indirectly, would go offline until it could be rebuilt with the fix.
That is a hard call for a product people use all day. It meant letting agents would lose access to Kamma Suite for the rest of the afternoon. It also meant none of those services could be reached while the fix was prepared, which mattered more.
The team had a branded maintenance page ready on our test environment within minutes, explaining what was happening in plain language. By about 3.30pm every external service was showing it, including the screens our Reapit customers see, and the systems behind them were shut down. Our shared data services were taken offline in the same way.
The wait: a fix arrives in stages
This is the part most people never see. When PHP releases a fix, it doesn’t arrive ready to install on a platform like ours. It travels down a chain:
- The PHP team publishes the corrected version.
- The open-source teams who package PHP for servers rebuild their own versions and run their tests.
- Only then can we rebuild each of our own services on top of those packages, test them and release them.
Each link has to finish before the next can start. Our team watched the second stage happen in public, test by test, and was ready to move the moment each package landed. The fix itself was out shortly after 4pm. The server packages for our data services followed soon after, and the team began rebuilding those straight away. The last package we needed, the one Kamma Suite is built on, didn’t arrive until 5pm.
The engineering team rebuilt and re-released every affected service in the four hours after the last piece arrived.
The rebuild
- 3.00pm Flaws announced worldwide
- 3.30pm Every affected Kamma service offline, maintenance page live
- 4.00pm Official fix released; data services rebuild begins
- 4.45pm Address-matching service rebuilt and released
- 5.00pm Final package arrives; Kamma Suite rebuild begins
- 5.55pm Reference data services released, fully patched
- 9.18pm Every service back online and fully patched
While services came back, both of our Reapit apps moved onto the patched version, and our integration partners got answers on exactly what had been affected and what had been done. Each upstream release was tracked as it landed, so no time was lost between one stage and the next.
At 9.18pm the last service came back online, fully patched.
What customers saw
A maintenance page for Wednesday afternoon and evening, and then Kamma working as normal. The overnight refresh that keeps property records up to date ran on schedule that night with no failed jobs. There was nothing for customers to update, reset or reinstall.
The team
Five of our engineers worked from the first warning that morning until the last service came back that night. They split the work between them: the maintenance page, the shutdown, the data services, Kamma Suite, the Reapit apps and the questions from our partners. Every one of them was in-house.
This won’t be the last one
The 21 October flaws were serious, but they were not unusual. Security researchers publish newly found weaknesses in widely used software all the time, and the number is climbing fast. In January 2026, around 2,500 were published. In September alone, it was around 15,000.
Our engineers monitor every one of them. Where a weakness affects any of our APIs or products, they patch it, test the fix and roll it out. That includes the tools only our own team uses, whether or not customers ever see them.
This work never finishes, and our team does it every day. Most of the time, customers never notice it happening. 21 October was one of the rare days when a fix needed Kamma offline for a few hours.
Why this is what Every Let. Protected. means
Every Let. Protected. is about making sure every property in your portfolio has the right licence. That promise depends on the platform underneath it being looked after by people whose job it is.
Kamma is built and run by its own in-house engineers. On 21 October that meant the people who decided to switch off were the same people who rebuilt it that evening, with no outside supplier to chase. It sits alongside the rest of how we protect your data: independent security experts brought in to test Kamma and identify potential weaknesses, encryption, daily off-site backups and £5 million of cyber and data-risk cover backed by Markel (UK) Limited.
If you have questions about how Kamma protects your data, contact support@kammadata.com.
Official records: CVE-2026-109618, CVE-2026-109619 and the PHP security release of 21 October 2026. All times are UK time (BST).
