The Night We Chose to take Crysp Offline
How a small technology company navigated a global cybersecurity emergency, a coordinated response to critical security vulnerabilities, and a long night of testing and recovery.
23 October 2026
On Wednesday evening, two critical security vulnerabilities were disclosed in widely used software infrastructure supporting websites and applications around the world.
The vulnerabilities presented a significant security risk to affected systems, prompting organisations across the globe to take immediate action to assess their exposure and implement the necessary precautions.
At Crysp, protecting our customers and their information remained our priority. Following the disclosure, our digital team quickly assessed the potential impact on our infrastructure and identified the appropriate steps to safeguard the platform.
Within minutes of confirming our exposure, we made the precautionary decision to take our production API offline and put a maintenance page in front of our customers.
We recognised that temporarily interrupting access to our platform would cause disruption, and this was not a decision we took lightly.
However, taking this precautionary measure allowed us to prioritise customer security while our digital team implemented and thoroughly tested the necessary updates before safely restoring the platform.
A global incident, not an isolated problem
The vulnerabilities affected widely used software infrastructure, prompting cybersecurity authorities and organisations around the world to assess the risks and take appropriate action.
The UK's National Cyber Security Centre advised organisations unable to apply suitable mitigations quickly to consider taking affected services offline.
Reports have since emerged of attempts to exploit the vulnerabilities even before their public disclosure.
The vulnerabilities were serious enough to potentially allow attackers to compromise affected systems without authentication. This wasn't simply an advisory about something that might become a problem in the future.
The threat was significant, and the response window was short. With the availability of security updates dependent on wider global software release processes, it was essential that we acted quickly and took the necessary precautions to protect our customers.
Once production was safely offline, we pursued two approaches at the same time. The first was to build our own patched infrastructure. We began rebuilding the necessary container images using the newly released security fixes, carefully checking compatibility with our existing application and supporting services.
The second was to wait for the official upstream container images to be updated. That sounds straightforward, but it proved to be one of the most frustrating parts of the night.
Modern applications depend on layers of software, libraries, container images and automated build systems. Just because a security patch has been published doesn't mean every dependent image is immediately available.
We found ourselves repeatedly checking GitHub Actions workflows, waiting for nightly builds to execute, watching release pipelines complete, and verifying whether the resulting images actually contained the necessary fixes.
All while organisations around the world were responding to the same emergency.
While our digital team was prepared to manage the technical response, the availability and timing of external security updates presented an additional challenge.
Throughout the process, our digital team continued to assess the availability and compatibility of security updates, while progressing with our own patched infrastructure. This allowed us to evaluate the available options and carefully consider the most appropriate approach to restoring the platform safely.
Every hour was critical, particularly with customers unable to access the platform. At approximately 2am, the appropriate upstream patched image became available to us. It was a huge relief, but we still weren't ready to restore production.
Patching is not the same as being ready to deploy
Throughout the night, we were also running regression tests in our staging environment. There is a temptation during an emergency to apply a fix, see the application start successfully, and declare victory. That isn't sufficient.
We needed confidence that the updated runtime behaved correctly with our application, that critical services remained operational, and that the security fix hadn't introduced another problem.
Our containerised architecture and established deployment processes meant we could build, deploy and test the updated environment independently of production. We checked core application functionality, integrations, background processing and the behaviour of the updated infrastructure.
Only when we were satisfied did we begin restoring production.
At 6:23am on Thursday 22 October, Crysp was back online.
It had been a long night, and the disruption was real. But we had taken a controlled, precautionary approach rather than accepting an unknown level of security exposure.
Our precautionary response and findings
One distinction is particularly important.
Following our investigation and checks to date, we have found no evidence that these vulnerabilities were exploited against Crysp.
This was a precautionary shutdown in response to a known critical security risk, not a response to a detected breach.
Nevertheless, we recognise that restoring service is only part of responding to a critical security risk. Ongoing monitoring, log reviews and retrospective assessments remain important as we continue to maintain a secure and resilient platform for our customers.
We also recognise the inconvenience this outage caused to our customers, and we sincerely apologise for this disruption. We understand how important access to our platform is for daily operations, and the decision was not made lightly. However, protecting our customers and their information remained our priority throughout.
Disaster recovery is about much more than backups
Perhaps the biggest operational lesson from the night was the value of having infrastructure that can be reliably rebuilt and redeployed. When people think about disaster recovery, they often think about data backups and restoring failed servers. But resilience is also about being able to deliberately stop services, isolate environments, rebuild infrastructure, validate changes, and restore operations in a controlled and repeatable way.
For us, containerisation and consistent deployment processes made an enormous difference. We weren't trying to manually recreate infrastructure from memory in the early hours of the morning. We had a structured approach to building and deploying our application.
Just as importantly, having an independent staging environment meant we could test without prematurely exposing production. Firewalls, access controls, monitoring and layered security protections are also essential parts of that picture.
No individual security control eliminates every risk. Firewalls cannot substitute for security patches, and monitoring cannot guarantee an attack will be detected. But effective defence in depth gives an organisation options when something unexpected happens.
Good disaster recovery planning isn't just about how quickly you can bring something back online. It's about knowing when you should, and having confidence that doing so is safe.
AI is changing both sides of cybersecurity
One of the most significant aspects of this global incident is the role artificial intelligence has played in discovering critical vulnerabilities.
AI-assisted security research is increasingly capable of identifying weaknesses that have remained hidden in software for years. That's a positive development for defenders, but the same advances can also accelerate the development of attacks. It changes the time available for organisations to respond.
At Crysp, part of our evolving approach involves AI-assisted security agents that monitor emerging vulnerabilities and advisories at regular intervals, assessing their relevance to the technologies and services we operate.
The intention is to extend the reach of a small engineering team, identify relevant threats earlier, and reduce the manual effort involved in monitoring an increasingly complex technology landscape.
But we are careful not to overstate what this achieves.
AI does not replace security engineering, human judgement, defence in depth or tested recovery procedures.
It helps us identify what deserves attention. People still need to understand the risk, make difficult decisions and take responsibility for the consequences. This week's events have only reinforced the importance of combining those capabilities.
The reality of responding as a small company
There's a temptation to turn experiences like this into polished success stories. However, the reality of responding to a global cybersecurity emergency involves difficult decisions, careful coordination and the ability to act quickly under pressure.
For our digital team, this involved interrupted plans, hours of checking logs and build pipelines, repeated testing and the responsibility of prioritising the protection of our customers' information throughout.
The incident also highlighted the interconnected nature of modern technology, with organisations of all sizes relying on global open-source infrastructure and software release processes.
We are enormously grateful to the maintainers, researchers and security teams around the world who worked to identify, remediate and distribute the necessary fixes. Their efforts played an important role in helping organisations respond to the vulnerabilities.
For Crysp, our established infrastructure, deployment processes and independent testing environments enabled our digital team to respond quickly, implement the necessary updates and safely restore the platform.
We also want to thank our digital team for their dedication and hard work throughout the night. Their quick response, careful testing and commitment to restoring the platform safely played an essential role in our recovery.
At Crysp, maintaining a secure and resilient platform is an ongoing priority. This experience has reinforced the importance of having the right people, infrastructure and procedures in place to respond quickly, make informed decisions and prioritise customer security.
Sometimes the right decision is to switch something off
As a technology company, we recognise the responsibility that comes with protecting the people and businesses who trust us with their information. Maintaining that trust and prioritising customer security remains fundamental to everything we do.
On Wednesday evening, we faced a difficult decision, but our priority was clear: customer security had to come before service availability.
While this caused temporary disruption, our digital team's quick response, established engineering processes and careful testing enabled us to restore the platform safely and with confidence.
We believe the precautionary decision to take the platform offline was the responsible approach, and one that reflected our commitment to protecting our customers.
Resilience isn't about never encountering a problem. It's about recognising potential risks, responding appropriately, and having the right people, processes and infrastructure in place to recover safely.
And sometimes, the most responsible thing a technology company can do is switch something off.
Even when switching it back on takes all night.
Dr David McKee — Chief Technology Officer
Sian Purver — Chief Operating Officer
Crysp Ltd
