Great question. First up, as long as you don't put --remote-debugging-address=0.0.0.0 you are only exposed locally, so the debugging endpoint can only be accessed from your local machine.
That leaves open the possibility that a web page can access that.
There's two possibilities:
- fetch('http://localhost:9222/json') which errors or is opaque because it is non CORS, or
- connecting directly to the websockets for targets, which have addresses like, http://localhost:9222/devtools/page/<128_bit_hex_string>
Interestingly, you can connect to the websocket, you just need to know the random identifier.
There are probably some DevTools zero days, but apart from those it looks like it's OK unless:
0) the identifier is not random,
1) you can get past CORS on the localhost which might be possible with an exploited extension, 3rd party software or plugin or
2) you can guess the websocket 128-bit identifier. (Guessing should only take 500 billion years. Even so 128 bits seems quite short relative to some encryption keys but there's probably a reason for that.)
Regarding 0) checking the Chromium source it appears that these ids are passed in to the constructor of "DevToolsAgentHostImpl":
https://cs.chromium.org/chromium/src/content/browser/devtool...
and are either "GUID"s or "tokens" and in the former case they are created here:
https://cs.chromium.org/chromium/src/base/guid.cc?sq=package...
and in the latter case by a class revealingly named "unguessabletoken.h":
https://cs.chromium.org/chromium/src/base/unguessable_token....
which in each case appears to rely on getting random bytes from a file descriptor to "urandom" which I think is an operating system level randomness primitive.