Simwood driftsforstyrrelser

1. 22. oktober 2026 kl. 09.58 UTCmonitoring

   Du kan have set NCSC alarm om et kritisk sikkerhedsspørgsmål påvirker PHP. Denne note forklarer, hvad vi har gjort. Hvad er problemet? To sårbarheder, CVE- 2026- 109618 og CVE- 2026- 109619, kunne tillade en angriber at udløse en out- of- memory tilstand i PHP, der korrumperer hukommelse. Under visse omstændigheder kan dette udnyttes til at køre kode fjernfra uden at logge ind. Problemet påvirker alle understøttede versioner af PHP. PHP-projektet har nu udgivet et fix. Hvad vi har gjort: • Revision og foreløbige forholdsregler: Om morgenen den 21. oktober, så snart vi hørte om sårbarhederne, vi revideret hver Simwood-tjeneste, der bruger PHP. Hvor PHP projektet anbefalede midlertidige lempelser, vi anvendte dem, så berørte tjenester blev beskyttet, før et fix eksisterede. • Patching: fixet blev udgivet kl 15: 00 (UK tid) den 21 oktober. Vi behandlede det som presserende og opdateret hver berørt service til den faste version. • Verifikation: Vi tjekkede derefter hver tjeneste for at bekræfte, at den faste version kørte, og at tjenesten fungerede normalt. Nuværende stilling: Baseret på disse handlinger, mener vi, at vores tjenester er beskyttet mod disse sårbarheder og kundedata forbliver sikre. Vi vil holde øje med vejledning fra NCSC og PHP-projektet, herunder eventuelle opdateringer til produkter, der bunker PHP, og handle på det straks. Skal du gøre noget? Du behøver ikke gøre noget ved de Simwood-tjenester, vi leverer. Hvis du kører PHP på dine egne systemer, anbefaler vi at følge NCSC 's råd: • finde hver PHP-installation, internet-vender dem først; • opdatering til den seneste faste version • hvis du ikke kan opdatere med det samme, anvende PHP-projektets midlertidige lempelser eller tage programmet offline. Hvis du har spørgsmål, bedes du kontakte vores support team.

2. 23. oktober 2026 kl. 10.54 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 13. juli 2026 kl. 14.29 UTCidentified

   Vi har mistet hardware i Slough. Stemmetjenesterne er slået fejl som forventet og er upåvirkede. De fleste andre tjenester er også kommet sig, selv om vi i øjeblikket beskæftiger os med nogle Redis master fejl andre steder på netværket. Dette vil manifestere sig i portal logins og skrive til valgte API end- point. Separately CDR behandling er flere millioner forsinket, så API balancer osv. vil ikke være aktuelle. Vi er ved at inddrive Redis klynger som P1 og vil rådgive fremskridt.

2. 13. juli 2026 kl. 15.13 UTCidentified

   Portal og API (v4) er nu fuldt operationelle. CPR 'erne er stadig forsinkede.

3. 13. juli 2026 kl. 16.04 UTCidentified

   CPR 'er behandles nu med fuld hastighed og indhenter hurtigt.

4. 13. juli 2026 kl. 16.39 UTCmonitoring

   Vi har nogle ud af timer husholdning at gøre her, men denne hændelse er ellers løst. Vi vil overvåge i et par timer før lukning for at være sikker.

5. 13. juli 2026 kl. 18.41 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 15. juni 2026 kl. 10.17 UTCidentified

   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. 15. juni 2026 kl. 11.34 UTCidentified

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

3. 15. juni 2026 kl. 15.17 UTCresolved

   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.

1. 24. december 2025 kl. 10.40 UTCidentified

   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. 24. december 2025 kl. 12.07 UTCmonitoring

   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. 24. december 2025 kl. 16.01 UTCresolved

   This incident has been resolved.

1. 3. oktober 2025 kl. 09.07 UTCinvestigating

   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. 6. oktober 2025 kl. 09.53 UTCmonitoring

   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. 6. oktober 2025 kl. 11.06 UTCresolved

   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.

1. 14. august 2025 kl. 13.55 UTCmonitoring

   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. 14. august 2025 kl. 17.06 UTCmonitoring

   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. 15. august 2025 kl. 16.45 UTCmonitoring

   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. 18. august 2025 kl. 14.23 UTCmonitoring

   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. 19. august 2025 kl. 12.51 UTCmonitoring

   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. 22. august 2025 kl. 11.58 UTCmonitoring

   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. 24. august 2025 kl. 11.42 UTCmonitoring

   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. 26. august 2025 kl. 10.10 UTCmonitoring

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

9. 27. august 2025 kl. 07.54 UTCmonitoring

   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. 28. august 2025 kl. 12.24 UTCmonitoring

    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. 2. september 2025 kl. 09.25 UTCmonitoring

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

12. 8. september 2025 kl. 08.22 UTCmonitoring

    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. 16. september 2025 kl. 11.11 UTCmonitoring

    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. 2. oktober 2025 kl. 09.30 UTCmonitoring

    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. 7. oktober 2025 kl. 10.51 UTCmonitoring

    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. 14. oktober 2025 kl. 09.05 UTCresolved

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

1. 1. august 2025 kl. 11.23 UTCidentified

   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. 1. august 2025 kl. 11.46 UTCmonitoring

   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. 1. august 2025 kl. 12.28 UTCresolved

   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.

1. 24. juli 2025 kl. 15.16 UTCinvestigating

   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. 24. juli 2025 kl. 21.23 UTCresolved

   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.

1. 20. juni 2025 kl. 12.41 UTCinvestigating

   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. 20. juni 2025 kl. 13.22 UTCmonitoring

   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. 21. juni 2025 kl. 09.43 UTCresolved

   This incident has been resolved.

1. 29. maj 2025 kl. 10.10 UTCinvestigating

   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. 29. maj 2025 kl. 12.15 UTCresolved

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

1. 10. maj 2025 kl. 08.00 UTCidentified

   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. 11. maj 2025 kl. 06.44 UTCresolved

   This incident has been resolved.

1. 25. september 2024 kl. 16.56 UTCinvestigating

   There is currently reduced network redundancy in our Manchester availability zone due to an identified issue with an optical transport link. Vendor has identified an issue with a line card in Leeds and an engineer is being sent to perform a replacement, expected on-site at 22:15. No service or traffic impacted, but site is considered at-risk.

2. 25. september 2024 kl. 22.17 UTCmonitoring

   The optical card has been replaced and the link has been restored. Status will remain in “monitoring” until we have confirmation from the engineers, vendor, and when we have satisfied our internal checks.

3. 25. september 2024 kl. 22.42 UTCresolved

   All alarms have been cleared. Resolving this incident.

1. 30. april 2024 kl. 14.53 UTCidentified

   We noticed some instability on the network around London this afternoon which resulted from two of our fibre pairs out of Volta (both East and West loops) having been disconnected/cut within the building within 5 seconds of each other. This is being investigated but the result is that Volta is reduced to N+1 from N+3 redundancy, and Telehouse East (which has no voice services whatsoever) has been temporarily isolated. The network continues to operate at 100% otherwise with no interruption to voice or related services but further events are always possible. We do not expect a rapid resolution to the cut fibre but will update when there is one.

2. 30. april 2024 kl. 15.55 UTCidentified

   The datacentre have confirmed that these two fibre pairs were indeed seperately cut within the building and are reviewing repair options.

3. 30. april 2024 kl. 16.24 UTCresolved

   Volta has been returned to N+3 connectivity and Telehouse East reconnected at N+1. Voice service was unaffected by this incident but full redundancy in the affected of our 3 UK Availability Zones has been restored.

1. 14. november 2023 kl. 18.12 UTCresolved

   At around 15.45 this afternoon we were made aware of inbound calls to some number ranges hosted on our network, in some circumstances, being delivered to customers with the destination number in the RURI and To header truncated, resulting in those calls failing to connect due to the target number not being recognised. Within 5 minutes we had identified the issue was related to an update we were in the process of rolling out, which was intended to work around an increasing number of calls being sent to us by BT with invalid destination numbers. This was necessary because they were unwilling/incapable of fixing in their own call routing, with the numbers matching their routing plan despite being invalid. By 15.55 we had rolled back the update across all availability zones, and affected customers had confirmed calls were once again being delivered as expected. We are currently working through examples provided to understand why each specific routing case was impacted and will update here with our findings in due course.

2. 16. november 2023 kl. 12.58 UTCpostmortem

   Recently we discovered that calls being sent to us by BT, particularly to ported numbers, were increasingly including the destination number in a non-standard \(i.e. invalid\) format. These calls were as a result matching unexpected routing and causing our customers issues. However upon reporting this non-conformity to BT they confirmed they were unable/unwilling to fix since the format matched their own routing plan and they did not have the flexibility in their routing engine to accommodate a fix. We therefore subsequently prepared a config change in order to accommodate the invalid numbers. Automated testing by replaying historical live call scenarios, and continuous deployment are standard practice for us and, following completion of that, we initiated the rollout to production during the afternoon of 14th November. The rollout was to each call routing instance, of which there are many in each of our 5 availability zones, watching channel/call levels closely for any signs of issues.  Part-way through the rollout, at 15.45, we were alerted to a number of inbound calls being rejected by some customers due to the RURI and To header in the outgoing INVITEs for those calls being truncated. We halted the rollout and rolled everything back to the previous state which remedied the situation, with normal state confirmed by 15.55. Following further investigation it was discovered that in the config change and suite of tests we had failed to consider a particular routing scenario involving hosted ranges, applying to a very small number of customers. In all, around 2% of _inbound_ calls across the entire network were affected, which made it extremely difficult to identify from the channel metrics, particularly as we were now intentionally rejecting the improper calls BT couldn’t/wouldn’t. Whilst the overall impact was very small and our Community Slack was uncharacteristically silent on the issue, the 15 customers affected by this issue on their hosted ranges, in some cases saw a much higher percentage of calls affected, depending on their individual traffic and configuration mix.  In terms of lessons learned by this incident, we do not believe that not making changes at all, as some would advocate, is a competent approach. Equally, we do not believe that deploying out of hours when some scenarios are absent, only to see issues the following day when they return, the deployment is complete, and attention has turned elsewhere is an acceptable approach - that assures bigger impact, later, and a slower response. Further, with a large distributed network our approach of progressive automated roll-out is one we defend over manual updates to monolithic instances. Thus, as is our standard practice when our test suite fails to accommodate a scenario, it is updated to do so, and this has been done. This enables us to continue to rapidly iterate with automated testing providing the assurance it has so far through thousands of deployments and absolute consistency around the network. We’re sorry to those customers affected who, for the avoidance of doubt, had nothing “wrong” in their configuration at all. It was simply an edge case we’d missed, but which will now be tested automatically with every committed change in future.

1. 22. februar 2023 kl. 17.12 UTCresolved

   At 14h44 we were notified of the failure of a primary database node in London (Volta). This is a planned failure scenario and as designed service failed over cleanly to a candidate replacement in Slough (LD4). At 14h50 our call monitoring reported increased PDD (Post Dial Delay) from some parts of the network. This was owing to several call-routing nodes which were previously slaves to the failed master resyncing, and thus being unavailable for service. In this scenario, call-routing fails over to other back-up instances, which it did. Depending on the precise local state at the time of the call this can increase PDD. The first node had resynced by 14h58 and by 15h03 the last node had fully resynced and PDD had returned to normal levels everywhere. Our monitoring shows that less than 15% of calls network wide were impacted by increased PDD but customer experiences may vary according to their own timers and failover protocols. We are however investigating utilisation of the backup routing instances which, whilst not experience affecting, was not as evenly distributed as designed.

1. 28. december 2022 kl. 12.47 UTCresolved

   We have identified delays in received SMS delivery.

1. 7. juni 2022 kl. 15.48 UTCinvestigating

   We are seeing elevated errors on our London SIP edge. Whilst this will not affect customers properly configured to use FQDN and SRV, we have manually failed DNS over to another Availability Zone for those who are not. We are investigating the underlying issue.

2. 7. juni 2022 kl. 16.50 UTCmonitoring

   This has been stable since the incident was opened but we continue to investigate the root cause and will likely need to continue to do so once the incident is closed. DNS has been returned but we again urge customers to respect SRV or at least DNS for seamless failover in cases like this.

3. 7. juni 2022 kl. 17.38 UTCresolved

   This incident has been resolved.

1. 24. maj 2022 kl. 10.28 UTCresolved

   At 10.01 we lost reachability to equipment in Manchester over certain routes and a loss of power in Equinix Kilburn became apparent. Whilst power and service were restored a few minutes later we understand the site is running on generators and a UPS fault has been identified. We have very little active equipment in Kilburn but it is a major hub for networks and further power issues will affect reachability; it should be considered at risk.

1. 28. april 2022 kl. 20.57 UTCresolved

   It appears that a routine upgrade to our call routing engine disrupted some incoming calls this evening from 20:25 to 20:57. This type of update is quite normal for us and happens very often as part of our continuous development and deployment. It was being progressively rolled around the network such that calls could failover to the previous version in the event of any failure. However it did not fail and whilst passing all unit tests appears to have caused unexpected call rejections for calls hitting it. The deployment was paused as soon as we were aware of issues and has been rolled back. We will investigate the underlying issue and resolve before resuming continuous deployments. Apologies for anyone affected.

1. 26. februar 2022 kl. 09.29 UTCidentified

   We have lost a power feed in Volta which has reduced redundancy across the whole site and taken some servers off-line. Affected services have already automatically migrated to other sites for those following our standard configurations and DNS has been modified for those forcing traffic to this particular site. Customers who haven't followed the interop at all (and are forcing traffic by IP address) will need to manually update their config. We are monitoring the situation and will advise on recovery in due course.

2. 26. februar 2022 kl. 10.43 UTCmonitoring

   We have been checking services and are confident all is working normally. We will be monitoring this until power is fully restored and services migrated back.

3. 26. februar 2022 kl. 11.51 UTCidentified

   Whilst continuing to monitor the earlier problem we are aware that the portal is unavailable for some customers and are addressing that issue

4. 26. februar 2022 kl. 11.53 UTCmonitoring

   Portal access has been fixed for all customers and we continue to monitor all services

5. 26. februar 2022 kl. 14.44 UTCresolved

   All services have been fully restored in Volta.