From ML --- We would like to report an SSRF issue in Eclipse Theia's request-service RPC that can also disclose localhost or other internal HTTP responses. Reporters: * ziyue0530@gmail.com (Ziyue), [https://zyy0530.github.io/](https://zyy0530.github.io/) * 2459406270@qq.com (Chenchen), [https://7thparkk.github.io/](https://7thparkk.github.io/) * cshe0476@uni.sydney.edu.au (Strick), [https://str1ckl4nd.github.io/](https://str1ckl4nd.github.io/) * liyi.zhou@sydney.edu.au (Liyi), [https://lzhou1110.github.io/](https://lzhou1110.github.io/) * chng0012@uni.sydney.edu.au (Maurice), [http://maurice.busystar.org/](http://maurice.busystar.org/) Please treat this as a joint disclosure and attribute the report to all five reporters. **Summary** A browser client that can reach the standard `/services` messaging endpoint can invoke `/services/request-service` with an arbitrary URL. The backend performs the request server-side and returns the fetched response body to the caller. If this service surface is reachable by untrusted users, that behavior allows SSRF to localhost or other internal HTTP services and exposes the responses to the attacker. **Affected behavior** The attack path is straightforward: 1. connect to the normal browser-facing `/services` channel 2. open the `/services/request-service` RPC 3. provide an attacker-controlled destination URL 4. receive the fetched response body back through the same service connection From our review, this is the core issue: the standard frontend/backend connection exposes a generic backend HTTP primitive without restricting where it can connect, and the response body is returned to the caller. **Relevant code locations** * `packages/core/src/node/backend-application-module.ts:145` * `packages/core/src/node/request/backend-request-facade.ts:20` * `packages/core/src/browser/frontend-application-module.ts:457` * `packages/core/src/browser/request/browser-request-service.ts:57` * `dev-packages/request/src/common-request-service.ts:23` **Reproduction notes** We validated this with a loopback-only proof service. An ordinary browser client was able to reach `/services`, invoke `/services/request-service` with [`http://127.0.0.1:4567/`](http://127.0.0.1:4567/), and receive the proof response body back through Theia's normal response path. That was enough to confirm both the server-side request and the attacker-visible disclosure of a localhost-only resource. **Impact** In a deployment where untrusted users can reach the standard Theia service connection, a remote attacker can query localhost or other backend-reachable HTTP services and read their responses. This can expose internal admin endpoints, metadata services, or other resources that are intentionally outside the browser's network boundary. **Suggested Fix** Possible mitigations include restricting which clients can reach `request-service`, validating or allowlisting destinations before issuing backend requests, and avoiding returning raw internal response bodies to untrusted callers. We can share reduced reproduction material privately if useful.