[FEATURE]: Alternative fix about GHSA-c83v-7274-4vgp and improve ?url logic #7627

Open
opened 2026-02-16 18:07:46 -05:00 by yindo · 1 comment
Owner

Originally created by @xqe2011 on GitHub (Jan 26, 2026).

Originally assigned to: @thdxr on GitHub.

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Recently, we added a feature for a custom server URL, which cause GHSA-c83v-7274-4vgp. @adamdotdevin fixed this security issues by removing the entire feature.
We should consider alternative ways to retain this feature and address the security issue. I have some ideas about it.

Before talking about how to fix it, we must know why the CSP of opencode web doesn't help us to prevent this attack. When a user hosts the webui using opencode web, the server will listen on 4096 by default, then open the URL http://localhost:4096, the frontend can communicate with the server without being prohibited by Cross-Origin Policy.

Without the custom server URL feature, attackers cannot access http://localhost:4096 directly via an XSS attack, because the server does not allow CORS. But when this feature is enabled, attackers can load a malicious XSS script using a link like http://localhost:4096?url=http://attacker-server. Since this URL is hosted under 'localhost:4096,' attackers do not need to bypass CORS restrictions. They can simply use a code like 'fetch("/api/xxx")' to access the API and perform any action they want.

The key point of this bug is: The server hosting the opencode-webui must be the same server hosting the API. We can use this as a guideline for solutions.

  1. If we host opencode web, the website and api server are definitely hosted together. We will suffer from this security issue.
  2. If we host opencode-webui by an external service(e.g., nginx on https://custom-site), attackers will have no way to utilize it. Because the external service is under control, and only one ?url= can be set, this must be the real api-server, not the attacker server. So attackers cannot control the script running on it.

According to the above analysis, we can use several strategies to fix this problem.

  1. When the server is hosted by opencode web, disable this feature by default. We can add a flag in window.__OPENCODE__.featureFlags.customServerUrl which is injected by the server, if the flag is false, the feature will be disabled.
  2. When the webui is hosted by an external service, which is not the same as the api, the api-server will whitelist the webui's URL by setting the header Access-Control-Allow-Origin: http://webui-site in response. It means only the trusted webui domain can access the api.

The two strategies will prevent attackers from loading external scripts by using http://localhost:4096?url=http://attacker-server, and also protect the api-server from being attacked by CORS directly(If we don't whitelist the webui's url, allow CORS from all domains, attackers can still access the api-server by using an XSS attack).

Related:
https://x.com/thdxr/status/2010827351416803502
https://github.com/anomalyco/opencode/security/advisories/GHSA-c83v-7274-4vgp
https://github.com/anomalyco/opencode/commit/cbb3141130105287302de927af6d016ecce68219

How about your idea? @bluebeel

Originally created by @xqe2011 on GitHub (Jan 26, 2026). Originally assigned to: @thdxr on GitHub. ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request Recently, we added a feature for a custom server URL, which cause GHSA-c83v-7274-4vgp. @adamdotdevin fixed this security issues by removing the entire feature. We should consider alternative ways to retain this feature and address the security issue. I have some ideas about it. Before talking about how to fix it, we must know why the CSP of `opencode web` doesn't help us to prevent this attack. When a user hosts the webui using `opencode web`, the server will listen on 4096 by default, then open the URL `http://localhost:4096`, the frontend can communicate with the server without being prohibited by Cross-Origin Policy. Without the custom server URL feature, attackers cannot access `http://localhost:4096` directly via an XSS attack, because the server does not allow CORS. But when this feature is enabled, attackers can load a malicious XSS script using a link like `http://localhost:4096?url=http://attacker-server`. Since this URL is hosted under 'localhost:4096,' attackers do not need to bypass CORS restrictions. They can simply use a code like 'fetch("/api/xxx")' to access the API and perform any action they want. The key point of this bug is: The server hosting the opencode-webui must be the same server hosting the API. We can use this as a guideline for solutions. 1) If we host `opencode web`, the website and api server are definitely hosted together. We will suffer from this security issue. 2) If we host opencode-webui by an external service(e.g., nginx on https://custom-site), attackers will have no way to utilize it. Because the external service is under control, and only one `?url=` can be set, this must be the real api-server, not the attacker server. So attackers cannot control the script running on it. According to the above analysis, we can use several strategies to fix this problem. 1) When the server is hosted by `opencode web`, disable this feature by default. We can add a flag in `window.__OPENCODE__.featureFlags.customServerUrl` which is injected by the server, if the flag is `false`, the feature will be disabled. 2) When the webui is hosted by an external service, which is not the same as the api, the api-server will whitelist the webui's URL by setting the header `Access-Control-Allow-Origin: http://webui-site` in response. It means only the trusted webui domain can access the api. The two strategies will prevent attackers from loading external scripts by using `http://localhost:4096?url=http://attacker-server`, and also protect the api-server from being attacked by CORS directly(If we don't whitelist the webui's url, allow CORS from all domains, attackers can still access the api-server by using an XSS attack). Related: https://x.com/thdxr/status/2010827351416803502 https://github.com/anomalyco/opencode/security/advisories/GHSA-c83v-7274-4vgp https://github.com/anomalyco/opencode/commit/cbb3141130105287302de927af6d016ecce68219 How about your idea? @bluebeel
yindo added the discussion label 2026-02-16 18:07:46 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Jan 26, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #6355: RCE and file read vulnerability - addresses CORS and authentication security concerns
  • #10047: Basic Auth breaks the CORS support - discusses CORS configuration and middleware ordering issues

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Jan 26, 2026): This issue might be a duplicate of existing issues. Please check: - #6355: RCE and file read vulnerability - addresses CORS and authentication security concerns - #10047: Basic Auth breaks the CORS support - discusses CORS configuration and middleware ordering issues Feel free to ignore if none of these address your specific case.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#7627