Simwood の障害履歴

1. 2026年10月22日 9:58 UTCmonitoring

   重要なセキュリティ問題については、NCSC の警告を PHP に表示している可能性があります。 このメモは、私たちが行っていることを説明します。 問題は: 2つの脆弱性、CVE-2026-109618およびCVE-2026-109619は、攻撃者がメモリを破損したPHPのメモリ状態をトリガーすることを可能にします。 特定の条件下では、これはログインせずにリモートでコードを実行するために悪用される可能性があります。 問題は、サポートされているすべてのバージョンの PHP に影響します。 PHP プロジェクトが修正されました。 私たちが行っていること: •監査および暫定措置: 10月21日(日)の朝、脆弱性を学んだ直後には、PHPを使用するSimwoodサービスをすべて監査しました。 PHP プロジェクトが暫定の緩和を推薦したところ、それらを適用しました。そのため、修正前に影響を受けたサービスは保護されていました。 • パッチ: 修正は10月21日に15時(イギリス時間)にリリースされました。 被災した全てのサービスを、修正版に速やかに更新しました。 • 検証: 固定バージョンが実行されていることを確認し、サービスが正常に機能していた各サービスをチェックしました。 現在の位置: これらの行動に基づいて、当社はサービスがこれらの脆弱性と顧客データから保護されていると確信しています。 NCSCとPHPプロジェクトから、PHPをバンドルする製品へのアップデートや、速やかに対応するなど、ガイダンスを見守ります。 何かする必要はありますか? 私たちが提供するSimwoodサービスについて何もする必要はありません。 独自のシステムで PHP を実行している場合は、NCSC のアドバイスに従ってください。 •すべての PHP のインストール、インターネット インターフェイスの 1 つを見つける。 •最新の固定バージョンに更新します。 • すぐに更新できない場合は、PHP プロジェクトの一時的な緩和を適用するか、アプリケーションをオフラインで取得してください。 ご不明な点がございましたら、サポートチームにお問い合わせください.

2. 2026年10月23日 10:54 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年7月13日 14:29 UTCidentified

   Sloughでハードウェアを紛失しました。 音声サービスは期待通りに失敗し、期待通りに失敗しました。 現在、ネットワーク上の他の一部のRedisのマスターの故障に対処するにもかかわらず、他のほとんどのサービスはあまりにも回復しています。 これは、ポータルログインで明示し、選択したAPIエンドポイントに書き込みます。 個別にCDR処理は数百万遅延しているため、API残高などは現在処理されません。 RedisクラスターをP1として回復し、進捗をアドバイスします.

2. 2026年7月13日 15:13 UTCidentified

   ポータルと API (v4) は、現在運用中です。 CDRs は堅牢です.

3. 2026年7月13日 16:04 UTCidentified

   CDRは現在、フルスピードで処理され、急速にキャッチアップされています.

4. 2026年7月13日 16:39 UTCmonitoring

   ここまでは、何時間も家を守っていますが、この事件は解決しています。 閉館までに数時間監視いたします.

5. 2026年7月13日 18: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日 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. 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日 16: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日 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. 2025年8月14日 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. 2025年8月15日 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. 2025年8月18日 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. 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日 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. 2025年7月24日 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. 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日 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. 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日 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. 2024年9月25日 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. 2024年9月25日 22:42 UTCresolved

   All alarms have been cleared. Resolving this incident.

1. 2024年4月30日 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. 2024年4月30日 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. 2024年4月30日 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. 2023年11月14日 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. 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日 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. 2022年12月28日 12:47 UTCresolved

   We have identified delays in received SMS delivery.

1. 2022年6月7日 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. 2022年6月7日 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. 2022年6月7日 17: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日 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. 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日 14:44 UTCresolved

   All services have been fully restored in Volta.