The DownloadPrompter.prototype method that warns before launching an executable download rendered its “Open Executable File?” dialog through this._prompter.confirm(title, message), which presents the OK button as immediately actionable. Because the dialog inherited focus with no activation delay, a keypress (for example a held or scripted Enter/Space) that was already in flight or auto-repeating when the dialog appeared could dismiss it and confirm the launch before the user could read the warning. The security invariant — that a destructive confirmation must reflect a deliberate, informed user decision rather than a stray or attacker-timed keystroke — was therefore violated.

The fix replaces the call with this._prompter.confirmEx(title, message, flags, ...) and sets flags to Ci.nsIPrompt.BUTTON_DELAY_ENABLE | Ci.nsIPrompt.STD_OK_CANCEL_BUTTONS, so the accept button is briefly disabled after the dialog opens and pre-queued keystrokes can no longer auto-confirm it. It works because any keypress arriving during the enforced delay window is ignored by the button, forcing a fresh, post-delay interaction.

An attacker can bypass the executable-launch confirmation and achieve code execution in the context the launched file runs in, effectively the user’s own privileges outside the browser sandbox. Preconditions are that the attacker can stage an executable download and can lure the user into supplying a keystroke coincident with the dialog’s appearance, which limits reliability and accounts for the low severity rating.