Blind SSRF in TP-Link Omada Controller Enables Internal Service Enumeration

Blind Server-Side Request Forgery (SSRF) in Omada Controllers through webhook functionality, enabling crafted requests to internal services, which may lead to enumeration of information.

TP-Link Systems Inc. identifies Omada Controller as the affected product.

• Versions less than 6.0 are marked affected.
• TP-Link's advisory lists version >= 6.0 as fixed.
• The record gives an unknown default status for versions or builds outside the stated scope. Parallel branches or product-specific builds should not be assumed covered unless they are separately verified.

TP-Link Systems Inc.'s Omada Controller processes webhook functionality in a way that permits crafted requests to internal services. This is a blind Server-Side Request Forgery (SSRF) issue, where the controller makes a request on behalf of the requester, while the available evidence does not describe the exact response channel or observation method. The CNA and vendor advisory indicate that the issue is reachable over the network, has low complexity, requires high privileges, and does not require user interaction. The available evidence does not identify the specific webhook field or parameter, the types of internal services that can be queried, how results are inferred, or the full scope of information that may be enumerated.

The issue is network-reachable through the webhook functionality. CNA data indicates that exploitation requires high privileges and no user interaction, and the vendor advisory describes the same SSRF mechanism through webhooks. The supplied record does not identify real-world exploitation, a campaign, a victim, or a public exploit. The retrieved authoritative enrichment marks exploitation as none, but that status does not prove that abuse is impossible.

The primary technical outcome is that the controller can send crafted requests to internal services through webhook functionality, potentially allowing information to be inferred or enumerated. CNA data describes limited confidentiality impact, while integrity and availability are not identified as affected by this issue. Exploitation requires high privileges according to the CNA data and does not require user interaction. Organisational consequences may include disclosure of internal network or service information and support for further reconnaissance; the available evidence does not confirm deeper data access, configuration changes, takeover, or service disruption.

The flaw may expose information about services reachable from the Omada Controller, such as whether internal services exist or respond to requests. That information could support later reconnaissance, but the available evidence does not confirm a subsequent attack chain, unauthorized access to specific data, or compromise of another system. The issue is described as having a limited confidentiality impact; there is no evidence that it directly changes data or disrupts service. Actual risk depends on the privileges of the account able to manage webhooks and the sensitivity of services reachable by the controller.

1. Upgrade affected Omada Controller deployments to version >= 6.0, which TP-Link lists as the fixed version boundary.
2. After updating, verify the actual installed version on every controller and review configured webhooks again.
3. If an immediate update is not possible, the reviewed evidence does not document a specific temporary mitigation from the vendor. Disabling or changing webhooks should not be treated as a vendor-confirmed fix without corresponding guidance.
4. Review outbound requests from the controller after the update to identify webhook configurations that still target unnecessary internal services.

1. Inventory all Omada Controllers and identify systems running versions within the affected scope by comparing them with TP-Link's version boundary in the advisory.
2. Review configured webhooks, especially destinations that point to internal network addresses or management services, and verify that each destination is necessary.
3. Review available controller, proxy, and firewall logs or telemetry for outbound requests triggered by webhooks to internal services. This is precautionary monitoring, not a vendor-confirmed indicator.
4. Verify the installed version and update status after remediation. The available evidence does not provide a named log event, request pattern, destination address, or specific IOC; absence of those signs must not be treated as proof that a system is safe.