CVE-2026-120224: Oray X5 Pro Authorization Bypass

Detection Guidance

Detection should focus on:

• Access to management or API services from untrusted networks
• Calls involving run_apis_by_json or run_async_task
• Factory-reset or reset-related events
• Restricted accounts invoking administrative functions
• Unexpected reboots, configuration loss, or device re-enrollment
• Management access followed by sudden connectivity loss

Review router logs, centralized syslog, reverse-proxy logs, firewall telemetry, and network-flow records. Correlate the source address, account identity, authentication result, request method, and timestamp with subsequent reset or configuration events.

Log Triage

Search normalized HTTP or proxy logs for relevant function names and reset-related terms:

grep -Ei \\
'run_apis_by_json|run_async_task|factory.?reset|factory_reset|reset' \\
/var/log/router/*.log /var/log/proxy/*.log 2>/dev/null

For an Elasticsearch-compatible environment, adapt field names to the local schema:

(
  url.path: "*run_apis_by_json*" OR
  url.path: "*run_async_task*" OR
  http.request.body.content: "*factory_reset*" OR
  message: "factory reset"
)
AND NOT source.ip: <approved-management-subnet>

A Sigma-style analytic can provide an initial detection rule:

title: Potential Oray X5 Pro Unauthorized Reset API Activity
logsource:
  category: webserver
detection:
  api_function:
    url|contains:
      - "run_apis_by_json"
      - "run_async_task"
  reset_indicator:
    message|contains:
      - "factory_reset"
      - "factory reset"
      - "reset"
  condition: api_function and reset_indicator
level: high

This rule may generate false positives because reset terminology can appear during legitimate administration. Increase confidence by correlating events with restricted accounts, external source addresses, new networks, unusual user agents, failed authorization attempts, or a reboot immediately after the API request.

If the router does not provide adequate logs, monitor upstream firewall connections to its administration ports and alert on management access outside approved networks.

Remediation and Mitigation

No confirmed fixed version was identified in the reviewed sources. The affected range is through and including 7.6.1, but no authoritative remediation version can be named. Contact Oray or Pugongying support and request written confirmation of the firmware version that addresses CVE-2026-120224.

Until a fix is confirmed:

1. Remove internet access to management and API interfaces.
2. Disable remote administration unless it is operationally required.
3. Restrict management access to a dedicated trusted subnet or VPN.
4. Review accounts and disable unnecessary restricted users.
5. Remove unnecessary port forwarding.
6. Review cloud-mediated management paths.
7. Monitor for reset, reboot, and configuration-change events.
8. Back up configuration securely and test recovery procedures.
9. Rotate credentials if unauthorized account use is suspected.
10. Replace or retire the device if it cannot be patched or isolated safely.

Network segmentation can reduce exposure and may also support compliance objectives; for related context, see how network segmentation reduces PCI scope.

Management Network Example

The following generic nftables example illustrates how a management VLAN might allow access only from an approved administrator subnet:

sudo nft add rule inet filter input iifname "mgmt0" ip saddr 192.0.2.0/24 tcp dport <management-port> accept
sudo nft add rule inet filter input tcp dport <management-port> drop

Replace the interface, source subnet, and management port with values appropriate to the deployment. Do not copy the example blindly into a production firewall.

The following illustrative command is not a confirmed Oray utility:

oray-device-cli --host <router-management-ip> firmware-version

Use Oray’s documented management interface or approved inventory method to record the current firmware version. Do not execute an unknown command on production equipment.

After upgrading or isolating the device, confirm that:

• Remote administration remains disabled or restricted
• Only approved networks can reach management services
• Configuration backups are current
• Reset and recovery procedures work as expected
• Unexpected account and configuration changes are investigated

Incident Response Considerations

If unauthorized reset activity is suspected:

1. Isolate the management interface without disrupting evidence collection.
2. Preserve router, firewall, proxy, and authentication logs.
3. Record the device firmware version and current configuration state.
4. Identify all accounts that accessed the management plane.
5. Review source addresses, timestamps, and associated network flows.
6. Determine whether the device rebooted or lost configuration.
7. Reset credentials through a trusted management path.
8. Restore only from a known-good configuration backup.
9. Validate firmware provenance and remediation status with Oray.
10. Monitor for repeated access attempts and configuration changes.

If the device supports centralized logging, forward logs to an independent system so that a reset cannot erase the only copy of relevant evidence.