Simwood 장애 기록

1. 2026년 10월 22일 오전 9:58 UTCmonitoring

   PHP에 영향을 미치는 중요한 보안 문제에 대한 NCSC 경고를 볼 수 있습니다. 이 글은 우리가 한 것을 설명합니다. 문제는: 2개의 취약점, CVE-2026-109618 및 CVE-2026-109619는, 손상 기억을 손상하는 PHP에 있는 out-of-memory 상태를 방아쇠하는 공격자를 허용할 수 있었습니다. 특정 조건에서, 이것은 로그인 없이 코드를 원격으로 실행할 수 있습니다. 문제는 PHP의 모든 지원 된 버전에 영향을 미칩니다. PHP 프로젝트는 이제 수정을 발표했다. 우리가 수행 한 일 : • 감사 및 간 조치 : 10 월 21 일 아침에, 우리가 취약의 배운 것처럼, 우리는 PHP를 사용하는 모든 Simwood 서비스를 감사. PHP 프로젝트를 권장하는 간 완화, 우리는 그들을 적용, 그래서 영향을받는 서비스는 문제가 존재하기 전에 보호되었다. • 패치 : 수정은 10 월 21 일에 15:00 (영국 시간)에 릴리스되었습니다. 우리는 긴급하게 취급하고 고정 된 버전에 모든 영향을받는 서비스 업데이트. • Verification: 우리는 그 후에 조정 버전이 달리는 것을 확인하기 위하여 각 서비스를 검사하고 서비스는 일반적으로 작동되었습니다. 현재 위치: 이러한 행동에 따라, 우리는 우리의 서비스를 믿고 이러한 취약점과 고객 데이터에 대한 보호는 안전합니다. 우리는 NCSC와 PHP 프로젝트에서 지도를 관찰하고, PHP를 묶는 제품에 대한 모든 업데이트를 포함하여, 그것을 신속하게 행동합니다. 아무것도 할 필요가 있습니까? Simwood 서비스에 대해 아무것도 할 필요가 없습니다. 자체 시스템에 PHP를 실행하면 NCSC의 조언을 따르는 것이 좋습니다. • 모든 PHP 설치를 찾아, 인터넷 직면 한 것 먼저; • 최신 고정 버전으로 업데이트; • 즉시 업데이트 할 수없는 경우 PHP 프로젝트의 임시 완화를 적용하거나 오프라인으로 응용 프로그램을 취할 수 있습니다. 질문이 있으시면 지원 팀에 문의하십시오.

2. 2026년 10월 23일 오전 10:54 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 7월 13일 오후 2:29 UTCidentified

   우리는 Slough에서 하드웨어를 잃었습니다. 음성 서비스는 예상대로 실패하고 불완전합니다. 대부분의 다른 서비스는 현재 네트워크의 일부 Redis 마스터 실패를 처리하고 있지만 복구했습니다. 이것은 포털 로그인 및 선택한 API 엔드 포인트로 작성합니다. 별도의 CDR 처리는 몇몇 백만 지연된 그래서 API 균형 등은 현재일 것입니다. Redis 클러스터를 P1로 복구하고 진행 상황을 조언합니다.

2. 2026년 7월 13일 오후 3:13 UTCidentified

   Portal 및 API (v4)는 이제 완전히 운영됩니다. CDRs 남아 lagged.

3. 2026년 7월 13일 오후 4:04 UTCidentified

   CDR은 이제 전체 속도로 처리되고 빠르게 잡을 수 있습니다.

4. 2026년 7월 13일 오후 4:39 UTCmonitoring

   우리는 여기에서 할 수있는 몇 시간의 주택 유지가 있지만이 사건은 그렇지 않으면 해결됩니다. 우리는 특정하기 전에 몇 시간 동안 모니터링 할 것입니다.

5. 2026년 7월 13일 오후 6:41 UTCresolved

   이 사건은 해결되었습니다.

공식 인시던트 업데이트를 자동 번역했습니다.

1. 2026년 6월 15일 오전 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. 2026년 6월 15일 오전 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. 2026년 6월 15일 오후 3: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. 2025년 12월 24일 오전 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. 2025년 12월 24일 오후 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. 2025년 12월 24일 오후 4:01 UTCresolved

   This incident has been resolved.

1. 2025년 10월 3일 오전 9: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. 2025년 10월 6일 오전 9: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. 2025년 10월 6일 오전 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. 2025년 8월 14일 오후 1: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. 2025년 8월 14일 오후 5: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. 2025년 8월 15일 오후 4: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. 2025년 8월 18일 오후 2: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. 2025년 8월 19일 오후 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. 2025년 8월 22일 오전 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. 2025년 8월 24일 오전 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. 2025년 8월 26일 오전 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. 2025년 8월 27일 오전 7: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. 2025년 8월 28일 오후 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. 2025년 9월 2일 오전 9: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. 2025년 9월 8일 오전 8: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. 2025년 9월 16일 오전 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. 2025년 10월 2일 오전 9: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. 2025년 10월 7일 오전 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. 2025년 10월 14일 오전 9:05 UTCresolved

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

1. 2025년 8월 1일 오전 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. 2025년 8월 1일 오전 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. 2025년 8월 1일 오후 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. 2025년 7월 24일 오후 3: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. 2025년 7월 24일 오후 9: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. 2025년 6월 20일 오후 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. 2025년 6월 20일 오후 1: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. 2025년 6월 21일 오전 9:43 UTCresolved

   This incident has been resolved.

1. 2025년 5월 29일 오전 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. 2025년 5월 29일 오후 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. 2025년 5월 10일 오전 8: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. 2025년 5월 11일 오전 6:44 UTCresolved

   This incident has been resolved.

1. 2024년 9월 25일 오후 4: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. 2024년 9월 25일 오후 10: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. 2024년 9월 25일 오후 10:42 UTCresolved

   All alarms have been cleared. Resolving this incident.

1. 2024년 4월 30일 오후 2: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. 2024년 4월 30일 오후 3:55 UTCidentified

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

3. 2024년 4월 30일 오후 4: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. 2023년 11월 14일 오후 6: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. 2023년 11월 16일 오후 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. 2023년 2월 22일 오후 5: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. 2022년 12월 28일 오후 12:47 UTCresolved

   We have identified delays in received SMS delivery.

1. 2022년 6월 7일 오후 3: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. 2022년 6월 7일 오후 4: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. 2022년 6월 7일 오후 5:38 UTCresolved

   This incident has been resolved.

1. 2022년 5월 24일 오전 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. 2022년 4월 28일 오후 8: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. 2022년 2월 26일 오전 9: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. 2022년 2월 26일 오전 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. 2022년 2월 26일 오전 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. 2022년 2월 26일 오전 11:53 UTCmonitoring

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

5. 2022년 2월 26일 오후 2:44 UTCresolved

   All services have been fully restored in Volta.