Seleniumgrid exposedui templated

[robert-doyensec]

I removed the reflective detector logic because I had issues reproducing that part the way it was implemented previously. No changes to testbed.

{
  "scanStatus": "SUCCEEDED",
  "scanFindings": [{
    "targetInfo": {
      "networkEndpoints": [{
        "type": "IP_HOSTNAME_PORT",
        "ipAddress": {
          "addressFamily": "IPV4",
          "address": "192.168.65.254"
        },
        "port": {
          "portNumber": 4444
        },
        "hostname": {
          "name": "host.docker.internal"
        }
      }]
    },
    "networkService": {
      "networkEndpoint": {
        "type": "IP_HOSTNAME_PORT",
        "ipAddress": {
          "addressFamily": "IPV4",
          "address": "192.168.65.254"
        },
        "port": {
          "portNumber": 4444
        },
        "hostname": {
          "name": "host.docker.internal"
        }
      },
      "transportProtocol": "TCP",
      "serviceName": "http",
      "serviceContext": {
        "webServiceContext": {
        }
      }
    },
    "vulnerability": {
      "mainId": {
        "publisher": "TSUNAMI_COMMUNITY",
        "value": "SeleniumGrid_ExposedUI"
      },
      "severity": "CRITICAL",
      "title": "Selenium Grid Exposed API",
      "description": "The scanner detected an exposed Selenium Grid service that allows annonymous access. It is possible to connect to Selenium Grid to create a remote Chrome webdriver with a set of configurations such as --renderer-cmd-prefix which can allow attackers to inject an arbitrary command that will get executed when a browser is started.",
      "recommendation": "Restrict access to the exposed Selenium Grid by adding --username and --password parameters to selenium-server.jar command line, or within the [router] section in the Selenium Grid config file (/opt/selenium/config.toml).\nSee: https://www.selenium.dev/documentation/grid/configuration/cli_options/#router"
    }
  }],
  "scanStartTimestamp": "2026-07-02T09:17:35.446Z",
  "scanDuration": "15.842s",
  "fullDetectionReports": {
    "detectionReports": [{
      "targetInfo": {
        "networkEndpoints": [{
          "type": "IP_HOSTNAME_PORT",
          "ipAddress": {
            "addressFamily": "IPV4",
            "address": "192.168.65.254"
          },
          "port": {
            "portNumber": 4444
          },
          "hostname": {
            "name": "host.docker.internal"
          }
        }]
      },
      "networkService": {
        "networkEndpoint": {
          "type": "IP_HOSTNAME_PORT",
          "ipAddress": {
            "addressFamily": "IPV4",
            "address": "192.168.65.254"
          },
          "port": {
            "portNumber": 4444
          },
          "hostname": {
            "name": "host.docker.internal"
          }
        },
        "transportProtocol": "TCP",
        "serviceName": "http",
        "serviceContext": {
          "webServiceContext": {
          }
        }
      },
      "detectionTimestamp": "2026-07-02T09:17:51.254Z",
      "detectionStatus": "VULNERABILITY_VERIFIED",
      "vulnerability": {
        "mainId": {
          "publisher": "TSUNAMI_COMMUNITY",
          "value": "SeleniumGrid_ExposedUI"
        },
        "severity": "CRITICAL",
        "title": "Selenium Grid Exposed API",
        "description": "The scanner detected an exposed Selenium Grid service that allows annonymous access. It is possible to connect to Selenium Grid to create a remote Chrome webdriver with a set of configurations such as --renderer-cmd-prefix which can allow attackers to inject an arbitrary command that will get executed when a browser is started.",
        "recommendation": "Restrict access to the exposed Selenium Grid by adding --username and --password parameters to selenium-server.jar command line, or within the [router] section in the Selenium Grid config file (/opt/selenium/config.toml).\nSee: https://www.selenium.dev/documentation/grid/configuration/cli_options/#router"
      }
    }]
  },
  "reconnaissanceReport": {
    "targetInfo": {
      "networkEndpoints": [{
        "type": "IP_HOSTNAME_PORT",
        "ipAddress": {
          "addressFamily": "IPV4",
          "address": "192.168.65.254"
        },
        "port": {
          "portNumber": 4444
        },
        "hostname": {
          "name": "host.docker.internal"
        }
      }]
    },
    "networkServices": [{
      "networkEndpoint": {
        "type": "IP_HOSTNAME_PORT",
        "ipAddress": {
          "addressFamily": "IPV4",
          "address": "192.168.65.254"
        },
        "port": {
          "portNumber": 4444
        },
        "hostname": {
          "name": "host.docker.internal"
        }
      },
      "transportProtocol": "TCP",
      "serviceName": "http",
      "serviceContext": {
        "webServiceContext": {
        }
      }
    }]
  },
  "targetAlive": true
}

[giacomo-doyensec]

LGTM - in general I would keep out of the code all comments related to migration since they are relative to components being removed

[giacomo-doyensec]

Suggested change

# finding ID changed from Java version to be more consistent with the rest of them.

I would write this in the upstream PR and keep the code clean

[giacomo-doyensec]

Suggested change

	# in the original java detector, it loops until the API is ready.
	# We shouldn't do that in our plugins, and instead set up the testbed properly to account for it.
	# Changed it to a fingerprint step and added multiple capitalizations just in case it varies.

[giacomo-doyensec]

I would just mention that reflective was dropped in the migration on the PR

Suggested change

	# This is only out of band detection, had errors implementing the reflective version correctly
	# that were taking a while to debug.

[giacomo-doyensec]

Old detector was using different EP for fingerprint (prepending wd/hub). Just pointing that out, if it worked during your tests it's fine to me