Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| func (c *ConsoleServer) handleExecute(w http.ResponseWriter, r *http.Request) { | ||
| if r.Method != http.MethodPost { | ||
| http.Error(w, "method not allowed", http.StatusMethodNotAllowed) | ||
| return | ||
| } | ||
|
|
||
| var payload struct { | ||
| Command string `json:"command"` | ||
| } | ||
|
|
||
| if err := json.NewDecoder(r.Body).Decode(&payload); err != nil { | ||
| http.Error(w, "invalid payload", http.StatusBadRequest) | ||
| return | ||
| } | ||
|
|
||
| command := strings.TrimSpace(payload.Command) | ||
| if command == "" { | ||
| w.WriteHeader(http.StatusNoContent) | ||
| return | ||
| } | ||
|
|
||
| c.broadcastAppend(">> " + command + "\n") | ||
| go c.executeCommand(command) | ||
| w.WriteHeader(http.StatusAccepted) |
There was a problem hiding this comment.
Expose command execution endpoint without origin checks
The new web console accepts POSTs to /execute and directly forwards the payload to cmd.Execute with no CSRF token, authentication, or Origin/Referer validation. Because the server listens on 127.0.0.1 a malicious website opened in the user’s browser can issue a cross‑site fetch to this endpoint (it does not need to read the response) and execute arbitrary ServerCommander commands, which often map to shell actions. The random port does not prevent this because it can be brute‑forced. This is effectively a remote code execution vector for any user running the app with a browser open.
Useful? React with 👍 / 👎.
| func main() { | ||
| ui.ApplicationBanner() | ||
| reader := bufio.NewReader(os.Stdin) | ||
|
|
||
| for { | ||
| fmt.Print(utils.Yellow, "\n>> ", utils.Reset) | ||
| input, err := reader.ReadString('\n') | ||
| if err != nil { | ||
| fmt.Println(utils.Red, "Failed to read input:", err, utils.Reset) | ||
| continue | ||
| } | ||
|
|
||
| command := strings.TrimSpace(input) | ||
| if command == "" { | ||
| continue | ||
| } | ||
|
|
||
| if err := cmd.Execute(command); err != nil { | ||
| fmt.Println(utils.Red, err, utils.Reset) | ||
| } | ||
| if err := ui.RunStandaloneConsole(cmd.Execute); err != nil { | ||
| log.Fatal(err) |
There was a problem hiding this comment.
Browser console cannot satisfy interactive prompts
Replacing the CLI loop with RunStandaloneConsole executes each command via HTTP but only forwards the initial command string. Commands that call utils.Prompt/PromptPassword still read from the process’s original os.Stdin (initialised at startup), which is no longer connected to the browser input. When users trigger interactive commands such as session add from the web UI, the prompts are rendered in the browser but the process waits for input on the hidden terminal, effectively hanging the command. Consider plumbing user input back to os.Stdin or rewriting prompts to use the web channel so interactive commands remain usable.
Useful? React with 👍 / 👎.
Summary
Testing
https://chatgpt.com/codex/tasks/task_e_68f7b700f248832caaebf128532d6d5c