Emergency response and recovery for an iKuai security incident

This runbook is for the incident pattern where many nodes fail diagnostics together, the problem returns after reboot, or the router restarts unexpectedly. It is based on the current emergency firmware and may change as the incident is closed.

Check whether this matches the incident

Collect the time of the first failure, router model, iKuai version, SoloIP version, and whether the router rebooted by itself. A single bad node is not enough to identify this incident.

What the response changes

• Update the router to the current emergency custom firmware.
• Install the SoloIP development build specified by support, currently V7.2.10 for the affected event.
• Disable unnecessary cloud remote-control access while recovery is in progress.
• Re-check management access, node diagnostics, routing, and reboot stability in a fixed order.

Before changing anything

1. Export an iKuai configuration backup and store it offline.
2. Record the current WAN, LAN, VLAN, and management addresses.
3. Prepare a local console or local LAN management path.
4. Save screenshots of service status, node diagnostics, and recent system logs.
5. Tell users that the firmware upgrade may interrupt traffic.

Do not publish backups or logs containing node credentials, API tokens, or private addresses.

1. Temporarily disable cloud remote control

Use the iKuai administration console to disable the cloud remote-control feature involved in the incident. Keep local administration available and record the time of the change.

2. Install the supported SoloIP build

Use the official plugin market or the package path supplied by support. Confirm the build before installation and wait for the service to become stable. Do not combine this step with unrelated proxy-mode changes.

3. Upload the latest custom firmware

Download the firmware for the exact router model and edition. Upload it in the iKuai upgrade page, verify the checksum or file name provided by support, and wait through the reboot. Do not power off the router during cleanup and hardening.

4. Verify recovery in order

1. Open the local management page.
2. Confirm that the router has the expected firmware and system time.
3. Confirm that SoloIP is running.
4. Run one node diagnostic.
5. Verify one test-device egress IP.
6. Check that the router remains reachable after a controlled reboot.
7. Only then restore broader rules and additional devices.

5. Understand temporary feature limits

Emergency firmware may temporarily restrict cloud management, remote access, or automatic updates. Keep the recovery build installed until support publishes the replacement path. Do not downgrade from the emergency build just to restore a familiar menu.

6. Optional management hardening

After local recovery is confirmed, restrict management access to the management LAN or a dedicated VLAN. Keep a documented break-glass path and test it before closing the incident.

Do not do these things during response

• Do not repeatedly reboot a router whose storage or system state is already unstable.
• Do not reuse a backup from an unknown or affected device without reviewing it.
• Do not expose the management port to the public Internet for convenience.
• Do not send credentials in a screenshot or support chat.
• Do not roll out the same change to every router before one device passes the full verification sequence.

If recovery still fails

Send the router model, firmware and SoloIP builds, incident timeline, service status, node diagnostic output, reboot behavior, and sanitized logs. Include which verification step failed. Keep the original backup and do not overwrite the only copy.

Follow-up

Return to DNS, leak prevention, and kill-switch protection after the incident is closed, and review the management access policy with the team.