Simwood Outage History

Started Oct 22, 2026, 09:58 AM UTC· resolved Oct 23, 2026, 10:54 AM UTC

1. monitoring Oct 22, 2026, 09:58 AM UTC

   You may have seen the NCSC alert about a critical security issue affecting PHP. This note explains what we have done. What the issue is: Two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, could allow an attacker to trigger an out-of-memory condition in PHP that corrupts memory. Under certain conditions, this could be exploited to run code remotely without logging in. The issue affects all supported versions of PHP. The PHP project has now released a fix. What we have done: • Audit and interim measures: On the morning of 21 October, as soon as we learned of the vulnerabilities, we audited every Simwood service that uses PHP. Where the PHP project recommended interim mitigations, we applied them, so affected services were protected before a fix existed. • Patching: The fix was released at 15:00 (UK time) on 21 October. We treated it as urgent and updated every affected service to the fixed version. • Verification: We then checked each service to confirm the fixed version was running and the service was working normally. Current position: Based on these actions, we believe our services are protected against these vulnerabilities and customer data remains secure. We will keep watching guidance from the NCSC and the PHP project, including any updates to products that bundle PHP, and act on it promptly. Do you need to do anything? You don't need to do anything about the Simwood services we provide. If you run PHP on your own systems, we recommend following the NCSC's advice: • find every PHP installation, internet-facing ones first; • update to the latest fixed version; • if you can’t update straight away, apply the PHP project’s temporary mitigations or take the application offline. If you have any questions, please contact our support team.

2. resolved Oct 23, 2026, 10:54 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 13, 2026, 02:29 PM UTC· resolved Jul 13, 2026, 06:41 PM UTC

1. identified Jul 13, 2026, 02:29 PM UTC

   We have lost hardware in Slough. Voice services have failed over as expected and are unaffected. Most other services have recovered too although we are currently dealing with some Redis master failures elsewhere on the network. This will manifest in portal logins and writing to selected API end-points. Separately CDR processing is several million delayed so API balances etc. will not be current. We are recovering Redis clusters as P1 and will advise progress.

2. identified Jul 13, 2026, 03:13 PM UTC

   Portal and API (v4) are now fully operational. CDRs remain lagged.

3. identified Jul 13, 2026, 04:04 PM UTC

   CDRs are now being processed at full speed and catching up rapidly.

4. monitoring Jul 13, 2026, 04:39 PM UTC

   We have some out of hours house-keeping to do here but this incident is otherwise resolved. We will be monitoring for a few hours before closing to be certain.

5. resolved Jul 13, 2026, 06:41 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 15, 2026, 10:17 AM UTC· resolved Jun 15, 2026, 03:17 PM UTC

1. identified Jun 15, 2026, 10:17 AM UTC

   Reduced network redundancy in our Slough AZ. An optical link back to central London is currently down, and traffic is being routed via alternative paths while we work with the transport provider to restore the link. AZ considered at risk.

2. identified Jun 15, 2026, 11:34 AM UTC

   Our transport provider has identified the fault location and fibre engineers are due to the location at 13:30 to begin repairs.

3. resolved Jun 15, 2026, 03:17 PM UTC

   The engineers attended an intermediate site along the affected route and found multiple fibre pairs had been damaged at the ODF there. These were replaced, testing has been completed, and the link has been restored with all alarms clear. We will continue to monitor.

Read the full incident report →

Started Dec 24, 2025, 10:40 AM UTC· resolved Dec 24, 2025, 04:01 PM UTC

1. identified Dec 24, 2025, 10:40 AM UTC

   We are currently operating with reduced media capacity in our Manchester availability zone following a suspected hardware failure. There is no impact to services and calls are completing normally. Engineers are working to restore the affected hardware and capacity will be returned to normal in due course. In the meantime, our network is designed so that any single availability zone can carry the entire network load if all others fail. This update is for transparency only and no customer action is required.

2. monitoring Dec 24, 2025, 12:07 PM UTC

   The affected hardware in our Manchester availability zone has been restored and reintroduced to the media pool. We are monitoring performance closely before marking this incident as fully resolved.

3. resolved Dec 24, 2025, 04:01 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Oct 03, 2025, 09:07 AM UTC· resolved Oct 06, 2025, 11:06 AM UTC

1. investigating Oct 03, 2025, 09:07 AM UTC

   AirWallex, who we use for global automated payment processing, have "temporarily" suspended our account for incoming payments. They haven't said why or for how long and gave us the courtesy of zero notice. Any payments sent this route will therefore be returned to senders and not applied to Simwood accounts. Please use our back-up Lloyds Bank account which is shown in the document linked from https://si.mw/jp2qgym or one of the alternative payment methods (card or stablecoin) described at: https://si.mw/ro4n9hd . We apologise for any inconvenience and will update this as soon as we know more about this as yet unjustified (and in our opinion totally undeserved and heavy-handed) action.

2. monitoring Oct 06, 2025, 09:53 AM UTC

   New payment processing is now in place in all currencies and account details are being updated now. Customers may continue to send to the Lloyds account but payments will be manually processed; sending to the new bank details (with only the account number as reference) will resume automated top-ups on receipt. AirWallex have refused to provide any information and continue to reject incoming payments. We will therefore be terminating all AirWallex accounts across all businesses, regardless of what this transpires to be, and updating details in due course.

3. resolved Oct 06, 2025, 11:06 AM UTC

   Bank details are updated on the document linked from https://si.mw/jp2qgym (our support portal). Please note this is on the simwood.com domain - we will never email you bank details. Alternative payment methods (card or stablecoin) are described at: https://si.mw/ro4n9hd We're sorry for any inconvenience caused by AirWallex's grossly unreasonable and still unjustified actions.

Read the full incident report →

Started Aug 14, 2025, 01:55 PM UTC· resolved Oct 14, 2025, 09:05 AM UTC

1. monitoring Aug 14, 2025, 01:55 PM UTC

   Colt have advised that they are unable to complete any import or export porting orders until further notice. Their Status page (https://www.colt.net/status/) suggests an IT issue while online speculation (https://cyberplace.social/@GossiTheDog/115022343170487477) is of an undisclosed cyber attack. We will advise when we have further news.

2. monitoring Aug 14, 2025, 05:06 PM UTC

   Colt have now confirmed an ongoing cyber-incident (https://www.colt.net/status/). At the moment voice traffic on existing ported numbers seems unaffected.

3. monitoring Aug 15, 2025, 04:45 PM UTC

   There is no news to report here although the now admitted attack is being actively reported on, e.g. https://www.bleepingcomputer.com/news/security/colt-telecom-attack-claimed-by-warlock-ransomware-data-up-for-sale/

4. monitoring Aug 18, 2025, 02:23 PM UTC

   Colt are still unable to process number ports, we assume as a consequence of their well publicised cyber-attack. A list of compromised files, which is asserted to be the files compromised by the attacks is at (https://www.klos.com/~john/colt_filename_tree.txt) This list contains a number of interoperability documents between Simwood and Colt. The list also contains documents that appear to be Number Portability Order Forms, although it is unclear as to whether these relate to Simwood customers. NPORs will contain some information about the Subscriber changing providers, e.g. name, address, and telephone numbers. Additionally, there is other information clearly of a sensitive nature on the list, but that does not, as far as we can tell, relate to Simwood and its customer’s relationships. At this time, we understand that Colt are working to prevent further disclosure, however, this is all the detail we have at this time. Our customers should engage their Data Protection Officers regarding the consequences of the attack on Colt as a matter of urgency.

5. monitoring Aug 19, 2025, 12:51 PM UTC

   There is no update here other than Colt's porting team have advised there will be no imports or exports "until further notice". We continue to queue POV and porting orders for them.

6. monitoring Aug 22, 2025, 11:58 AM UTC

   Other than restating their status page to say this was a cybersecurity incident from day one (formerly an "IT issue"), and their compromised documents being mid-auction, there is no update here. Their porting desk appear to have stopped the daily updates and are still not processing orders.

7. monitoring Aug 24, 2025, 11:42 AM UTC

   An excellent blog has been published documenting the events so far at https://doublepulsar.com/colt-technical-services-gets-ransomwared-via-sharepoint-initial-access-some-learning-points-617da7e27ebc Colt are still not processing number ports.

8. monitoring Aug 26, 2025, 10:10 AM UTC

   Colt are still not processing number ports. Please continue to submit porting orders normally, we have a queue and are chasing them daily.

9. monitoring Aug 27, 2025, 07:54 AM UTC

   Colt have contacted us to say that "all port-in and port-out activities are currently on hold until next week, as we’re still working internally to stabilize the situation"

10. monitoring Aug 28, 2025, 12:24 PM UTC

    Colt are keen to emphasise on their status page (https://www.colt.net/status/) how this didn't affect customer systems. They have also marked their cyber-incident page at https://www.colt.net/go/cyber-incident/ to "noindex" to hide it from search engines, and it isn't linked anywhere on their website. None of them mention number portability either, which they continue to not do, despite us now being in day 16.

11. monitoring Sep 02, 2025, 09:25 AM UTC

    Colt continue to not process number ports despite down-playing the cyber-security incident which they initially responded to 21 days ago.

12. monitoring Sep 08, 2025, 08:22 AM UTC

    27 days since Colt responded to their cyber-security incident which, after eventually admitting they have consistently down-played, they continue to be unable to process number ports. Please continue submitting them as we are queuing this side.

13. monitoring Sep 16, 2025, 11:11 AM UTC

    Colt are still not porting and have not updated us as to the status. They have updated their "cyber-incident" page (which isn't linked on their website and is set to prevent indexing by search engines) to say they are committed to transparency. We also hear they have advised some Enterprise customers they will be unable to deliver new connectivity orders until 2026. We cannot confirm this, but if true it would be reasonable to assume that porting numbers out is not of a higher priority to them than new business. We know Ofcom are aware and hope they will be asserting appropriate priorities and full disclosure.

14. monitoring Oct 02, 2025, 09:30 AM UTC

    In a recent update to their customers Colt claim to be nearly able to deliver on some sales orders but their regulatory obligations in porting are apparently a lower priority - no porting still.

15. monitoring Oct 07, 2025, 10:51 AM UTC

    Colt claim to be doing excellently with processing sales orders and say "voice services will start to come back online from this week". We're not sure if this means honouring their regulatory obligations after 50 days, or just sales activity. We will advise if/when they resume porting or give a further update.

16. resolved Oct 14, 2025, 09:05 AM UTC

    Colt have accepted our outstanding ports so this incident will be resolved after nearly 2 months.

Read the full incident report →

Started Aug 01, 2025, 11:23 AM UTC· resolved Aug 01, 2025, 12:28 PM UTC

1. identified Aug 01, 2025, 11:23 AM UTC

   We were seeing reduced volume to certain UK mobile networks which we believe we have mitigated. We are investigating why this might be with the last report being at 12.06 BST.

2. monitoring Aug 01, 2025, 11:46 AM UTC

   We believe this was mitigated at 12.13 - any examples after that please let us know. We believe we understand what the issue was but continue to investigate and will report fully shortly. To correct the previous report, this would have affected calls to UK destinations applying an origin surcharge - mobile networks are the most egregious but some landlines would have been affected too.

3. resolved Aug 01, 2025, 12:28 PM UTC

   This incident is now fully resolved and appears to have been a fault on the Simwood network. A minor change relating to the validation of caller ID against Ofcom data was rolled around the network from 11am. It had passed all unit tests and presented no errors in production. However, it had the consequence of us assuming at the time of calls being routed that our costs included maximum origin surcharges on destinations that apply them, i.e. UK mobile networks except O2 and certain fixed line operators. While we routinely route calls at a loss and do not pass on origin surcharges, the consequence of this was that customer profiles became progressively loss-making for these destinations and overall. Our fraud and anti-arbitrage protections then began blocking such ostensibly loss-making traffic for customers who had tripped their account or destination specific loss-limits. Surcharges vary between 34ppm and 200ppm depending on network meaning account traffic profile would have affected if and when limits were reached. Some did not trip at all, others would have progressively tripped after 11.08, resulting in some calls to affected destinations being blocked. Calls to destinations without surcharges were unaffected as were those for customers who had not tripped particular limits; nevertheless it resulted in a progressive reduction in our traffic to certain networks over the ensuing hour. Our first support ticket was at 11:42, with a greater volume of reports from 12:00 and mitigation(s) fully deployed by 12:13. There were two mitigations: 1) customer loss-limits were raised at 12:11 and 2) the deployed image was fully rolled back around the network from 12:10 to 12:13. The last call exhibiting this behaviour, albeit not blocked, was 12:13. We identified and corrected the bug introduced in logic and are adding further unit tests to ensure such an occurrence cannot repeat. Once the new build fully passes the new tests, this updated image will be carefully deployed later today. We have also added specific global margin monitoring to alert very quickly on unnaturally changes in apparent profitability. Apologies for this issue which, as usual, we own and will learn from.

Read the full incident report →

Started Jul 24, 2025, 03:16 PM UTC· resolved Jul 24, 2025, 09:23 PM UTC

1. investigating Jul 24, 2025, 03:16 PM UTC

   We’ve received several reports of calls failing to certain mobile numbers. Our systems are operating normally, and we’ve found no issues within the Simwood network. There are indications the issue may lie with another network, and we’re actively monitoring the situation while we investigate further.

2. resolved Jul 24, 2025, 09:23 PM UTC

   Following the initial reports of issues calling certain mobile numbers, we’ve been monitoring closely and can confirm once again that there have been no faults or abnormalities on the Simwood network throughout the period. While some customers may still experience issues, these appear to relate to factors outside of our network. We encourage those affected to consult general media sources for the latest updates on wider network conditions. Thank you for your understanding.

Read the full incident report →

Started Jun 20, 2025, 12:41 PM UTC· resolved Jun 21, 2025, 09:43 AM UTC

1. investigating Jun 20, 2025, 12:41 PM UTC

   Customers connecting to our services in Slough over Cogent transit may have seen instability over the last 15 minutes or so. We have temporarily shutdown sessions with Cogent to alleviate any issues. Those on-net or reaching us over peering sessions (which is the majority) and other ultimate transit providers, or reaching other availability zones over Cogent have been unaffected. We strongly encourage all customers to connect into us directly wherever possible.

2. monitoring Jun 20, 2025, 01:22 PM UTC

   Cogent have confirmed issues on their network. Our sessions with them remain shut down to prevent impact. We will continue monitoring and will only reintroduce routes for Cogent in Slough once we are confident their network is stable.

3. resolved Jun 21, 2025, 09:43 AM UTC

   This incident has been resolved.

Read the full incident report →

Started May 29, 2025, 10:10 AM UTC· resolved May 29, 2025, 12:15 PM UTC

1. investigating May 29, 2025, 10:10 AM UTC

   We are seeing one of our physical fibre spans between Telehouse North and IXN hard down currently, suggesting physical disturbance. We have preemptively shut down links using this whilst it is investigated and repaired. This reduces redundancy around our London ring but as we have multiple other paths, no service impact is expected.

2. resolved May 29, 2025, 12:15 PM UTC

   The span has been restored and the links have been brought back into service, restoring full redundancy around our London ring.

Read the full incident report →

Started May 10, 2025, 08:00 AM UTC· resolved May 11, 2025, 06:44 AM UTC

1. identified May 10, 2025, 08:00 AM UTC

   The Slough Availability Zone is currently operating on a single power feed due to planned power infrastructure maintenance by our datacenter provider. While all services remain fully operational, the zone should be considered at risk until full power redundancy is restored. The maintenance window is scheduled to conclude by 22:59 UTC on Saturday, 10 May. We are closely monitoring the situation and will provide updates as needed.

2. resolved May 11, 2025, 06:44 AM UTC

   This incident has been resolved.

Read the full incident report →