Simwood 中断历史

1. 2026年10月22日 UTC 09:58monitoring

   您可能已经看到NCSC的警示 关于一个影响 PHP 的关键安全问题。 这份说明解释了我们所做的工作。 问题是: CVE-2026-109618和CVE-2026-109619这两个弱点,可以让攻击者在PHP中触发破坏内存的外出状态. 在某些条件下,可以利用这个方法在不登录的情况下远程运行代码. 这个问题影响到所有支持的PHP版本. PHP项目现在已经发布了一个固定. 我们所做的一切: • 审计和临时措施: 10月21日上午,我们一得知这些弱点,就对使用PHP的Simwood服务进行了审计。 在PHP项目建议采取临时缓解措施的地方,我们采用了这些措施,因此,受影响的服务在没有固定措施之前就受到保护。 • 补丁:10月21日(英国时间)下午3:00公布。 我们把它看作是紧急的, 更新每一个受影响的服务 到固定版本。 • 核查:我们检查了每个服务,以确认固定版本在运行,服务正常运行。 现任职务: 基于这些行动,我们认为我们的服务受到保护,不受这些弱点的影响,客户数据仍然安全。 我们将继续关注NCSC和PHP项目的指导,包括对捆绑PHP的产品的任何更新,并迅速采取行动。 你需要做什么吗? 你不需要对我们提供的辛伍德服务做任何事 如果你在自己的系统中运行 PHP,我们建议遵循NCSC的建议: · 首先发现每个PHP安装,即因特网安装; • 更新最新固定版本; 如果您无法立即更新, 请应用 PHP 项目的临时缓解措施, 或将应用程序下线 。 有问题请联系支援组.

2. 2026年10月23日 UTC 10:54resolved

   这一事件已经得到解决.

自动翻译自官方事件更新。

1. 2026年7月13日 UTC 14:29identified

   我们在斯劳失去了硬件 语音服务已按预期失败,未受影响。 大多数其他服务也恢复了,尽管我们目前正在处理网络上其他地方的一些Redis主故障。 这将表现在门户网站登录和写入选定的API端点上. 单独的CDR处理被延迟了几百万,因此API余额等将不为时. 我们正在恢复Redis集群为P1,并将建议取得进展.

2. 2026年7月13日 UTC 15:13identified

   门户网站和API(v4)现已全面投入使用. CDR仍然落后.

3. 2026年7月13日 UTC 16:04identified

   CDR现在正在被全速处理并快速赶超.

4. 2026年7月13日 UTC 16:39monitoring

   我们有些时间需要在这里做家务,但这个事件已经解决了。 在关闭前,我们将监测几个小时.

5. 2026年7月13日 UTC 18:41resolved

   这一事件已经得到解决.

自动翻译自官方事件更新。

1. 2026年6月15日 UTC 10:17identified

   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日 UTC 11:34identified

   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日 UTC 15:17resolved

   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日 UTC 10:40identified

   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日 UTC 12:07monitoring

   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日 UTC 16:01resolved

   This incident has been resolved.

1. 2025年10月3日 UTC 09:07investigating

   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日 UTC 09:53monitoring

   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日 UTC 11:06resolved

   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日 UTC 13:55monitoring

   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日 UTC 17:06monitoring

   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日 UTC 16:45monitoring

   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日 UTC 14:23monitoring

   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日 UTC 12:51monitoring

   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日 UTC 11:58monitoring

   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日 UTC 11:42monitoring

   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日 UTC 10:10monitoring

   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日 UTC 07:54monitoring

   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日 UTC 12:24monitoring

    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日 UTC 09:25monitoring

    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日 UTC 08:22monitoring

    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日 UTC 11:11monitoring

    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日 UTC 09:30monitoring

    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日 UTC 10:51monitoring

    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日 UTC 09:05resolved

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

1. 2025年8月1日 UTC 11:23identified

   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日 UTC 11:46monitoring

   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日 UTC 12:28resolved

   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日 UTC 15:16investigating

   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日 UTC 21:23resolved

   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日 UTC 12:41investigating

   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日 UTC 13:22monitoring

   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日 UTC 09:43resolved

   This incident has been resolved.

1. 2025年5月29日 UTC 10:10investigating

   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日 UTC 12:15resolved

   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日 UTC 08:00identified

   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日 UTC 06:44resolved

   This incident has been resolved.

1. 2024年9月25日 UTC 16:56investigating

   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日 UTC 22:17monitoring

   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日 UTC 22:42resolved

   All alarms have been cleared. Resolving this incident.

1. 2024年4月30日 UTC 14:53identified

   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日 UTC 15:55identified

   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日 UTC 16:24resolved

   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日 UTC 18:12resolved

   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日 UTC 12:58postmortem

   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日 UTC 17:12resolved

   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日 UTC 12:47resolved

   We have identified delays in received SMS delivery.

1. 2022年6月7日 UTC 15:48investigating

   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日 UTC 16:50monitoring

   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日 UTC 17:38resolved

   This incident has been resolved.

1. 2022年5月24日 UTC 10:28resolved

   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日 UTC 20:57resolved

   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日 UTC 09:29identified

   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日 UTC 10:43monitoring

   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日 UTC 11:51identified

   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日 UTC 11:53monitoring

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

5. 2022年2月26日 UTC 14:44resolved

   All services have been fully restored in Volta.