Histórico de interrupções do Simwood

1. 22 Here 2026 da 09:58 UTCmonitoring

   Você pode ter visto o alerta NCSC sobre um problema de segurança crítico que afeta PHP. Esta nota explica o que fizemos. Qual é a questão: Duas vulnerabilidades, CVE-2026-109618 e CVE-2026-109619, podem permitir que um atacante ative uma condição fora de memória no PHP que corrompe a memória. Sob certas condições, isso poderia ser explorado para executar o código remotamente sem fazer login. O problema afeta todas as versões suportadas do PHP. O projeto PHP agora lançou uma correção. O que fizemos: • Auditoria e medidas provisórias: Na manhã de 21 de outubro, assim que soubemos das vulnerabilidades, auditámos todos os serviços da Simwood que usam PHP. Onde o projeto PHP recomendou mitigação provisória, nós os aplicamos, então os serviços afetados foram protegidos antes de uma correção existir. • Patching: A correção foi lançada às 15:00 (hora do Reino Unido) em 21 de outubro. Tratamos como urgente e atualizamos todos os serviços afetados para a versão fixa. • Verificação: Verificamos cada serviço para confirmar que a versão fixa estava em execução e que o serviço estava funcionando normalmente. Posição atual: Com base nessas ações, acreditamos que nossos serviços estão protegidos contra essas vulnerabilidades e os dados do cliente permanecem seguros. Vamos continuar assistindo orientação do NCSC e do projeto PHP, incluindo quaisquer atualizações de produtos que bundle PHP, e agir sobre ele prontamente. Precisas de fazer alguma coisa? Não precisas de fazer nada em relação aos serviços de Simwood que fornecemos. Se você executar PHP em seus próprios sistemas, recomendamos seguir o conselho do NCSC: • encontrar cada instalação PHP, face à internet primeiro; • actualização para a última versão fixa; • se você não pode atualizar imediatamente, aplique as mitigação temporárias do projeto PHP ou tire o aplicativo off-line. Se tiver alguma dúvida, contacte a nossa equipa de apoio.

2. 23 Here 2026 da 10:54 UTCresolved

   Este incidente foi resolvido.

Traduzido automaticamente da atualização oficial do incidente.

1. 13 Gouere 2026 da 14:29 UTCidentified

   Perdemos hardware em Slough. Os serviços de voz falharam como esperado e não são afectados. A maioria dos outros serviços também se recuperaram, embora estejamos atualmente lidando com algumas falhas mestre Redis em outro lugar na rede. Isso se manifestará nos logins do portal e escrevendo para os pontos finais da API selecionados. Separadamente, o processamento de CDR é de vários milhões de atrasos para que os saldos da API, etc., não sejam atuais. Estamos recuperando clusters Redis como P1 e vamos aconselhar o progresso.

2. 13 Gouere 2026 da 15:13 UTCidentified

   Portal e API (v4) estão agora totalmente operacionais. Os CDRs permanecem defasados.

3. 13 Gouere 2026 da 16:04 UTCidentified

   Os CDR estão agora a ser processados a toda a velocidade e a recuperar rapidamente.

4. 13 Gouere 2026 da 16:39 UTCmonitoring

   Temos algumas horas de limpeza para fazer aqui, mas este incidente está resolvido. Estaremos monitorando por algumas horas antes de fechar para ter certeza.

5. 13 Gouere 2026 da 18:41 UTCresolved

   Este incidente foi resolvido.

Traduzido automaticamente da atualização oficial do incidente.

1. 15 Mezheven 2026 da 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 Mezheven 2026 da 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 Mezheven 2026 da 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 Kerzu 2025 da 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 Kerzu 2025 da 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 Kerzu 2025 da 16:01 UTCresolved

   This incident has been resolved.

1. 3 Here 2025 da 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 Here 2025 da 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 Here 2025 da 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 Eost 2025 da 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 Eost 2025 da 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 Eost 2025 da 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 Eost 2025 da 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 Eost 2025 da 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 Eost 2025 da 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 Eost 2025 da 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 Eost 2025 da 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 Eost 2025 da 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 Eost 2025 da 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 Gwengolo 2025 da 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 Gwengolo 2025 da 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 Gwengolo 2025 da 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 Here 2025 da 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 Here 2025 da 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 Here 2025 da 09:05 UTCresolved

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

1. 1 Eost 2025 da 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 Eost 2025 da 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 Eost 2025 da 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 Gouere 2025 da 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 Gouere 2025 da 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 Mezheven 2025 da 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 Mezheven 2025 da 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 Mezheven 2025 da 09:43 UTCresolved

   This incident has been resolved.

1. 29 Mae 2025 da 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 Mae 2025 da 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 Mae 2025 da 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 Mae 2025 da 06:44 UTCresolved

   This incident has been resolved.

1. 25 Gwengolo 2024 da 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 Gwengolo 2024 da 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 Gwengolo 2024 da 22:42 UTCresolved

   All alarms have been cleared. Resolving this incident.

1. 30 Ebrel 2024 da 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 Ebrel 2024 da 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 Ebrel 2024 da 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 Du 2023 da 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 Du 2023 da 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 Cʼhwevrer 2023 da 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 Kerzu 2022 da 12:47 UTCresolved

   We have identified delays in received SMS delivery.

1. 7 Mezheven 2022 da 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 Mezheven 2022 da 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 Mezheven 2022 da 17:38 UTCresolved

   This incident has been resolved.

1. 24 Mae 2022 da 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 Ebrel 2022 da 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 Cʼhwevrer 2022 da 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 Cʼhwevrer 2022 da 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 Cʼhwevrer 2022 da 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 Cʼhwevrer 2022 da 11:53 UTCmonitoring

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

5. 26 Cʼhwevrer 2022 da 14:44 UTCresolved

   All services have been fully restored in Volta.