Why does patching a browser do nothing against a fake 'update required' download prompt?

## Two different things share one nickname People say `drive-by` for both of these, and they are not the same attack: | | Exploit-driven | Consent-driven | |---|---|---| | What is abused | A flaw in the rendering engine, a plugin or a font/media parser | The visitor's willingness to run a file | | User action needed | None beyond loading the page | Download, dismiss a warning, run, accept a prompt | | Removed by patching | Yes | No | | Evidence you would look for | A vulnerable version, a crash, a specific weakness | An ordinary download and an ordinary execution | A fake **update required** prompt is the second column. The panel is just content: HTML, CSS and script drawn to imitate a browser, plugin, codec or font update dialog, sometimes with a fake progress bar and the visitor's real browser name substituted in. It has no privilege of any kind. The only thing it does is ask. ## Where the prompt usually comes from Often the site hosting it is entirely legitimate and has been altered - an injected script in a page template, or a poisoned third-party component the page includes. So the domain is real, its certificate is valid, and the padlock is genuine. All of that is true of the transport and says nothing whatever about the content that arrived over it. That mismatch is a large part of why people believe the panel. ## Walking the chain, with the flaw-hunt marked absent 1. **Visit.** The person reaches the page by search, bookmark or a link. No flaw. 2. **Render.** The panel draws itself using ordinary web features. No flaw. 3. **Download.** The person clicks, and a file is fetched. The browser may show a download warning; the person dismisses it. No flaw - a warning dismissed is consent, not a bypass. 4. **Execute.** The person runs the file and accepts whatever the operating system asks. No flaw. At no step is a defect used. This matters because `are we patched?` answers a question nobody asked. An estate can be perfectly current and lose exactly the same way. ## Why the lure is dressed as an update The pretext has to explain three awkward things at once: why a file needs downloading, why it is executable, and why it is urgent. An update explains all three in a form people have been trained by every product they own to accept. It also survives being seen: someone who half-noticed the panel remembers `the browser wanted updating`, which is unremarkable. A variant worth recognising is the prompt that asks the visitor to copy a string and run it themselves, or to paste something into a system dialog. The same principle holds - the mechanism is instruction plus compliance, and no flaw is anywhere in it. ## Naming it correctly In ATT&CK terms the visit itself is filed under **Drive-by Compromise (T1189)** for initial access, and the person running the delivered file is **User Execution: Malicious File (T1204.002)**. Note what those identifiers name: *behaviours*. Neither is a vulnerability identifier, and there is no CVE to cite for this, because a CVE record asserts a defect in a product and no product was defective. ## Why the wrong classification is expensive If the working theory is `a browser exploit`, the follow-on questions are all about versions, plugin inventory and patch coverage - and every one of them comes back clean, which is then read as reassurance. The correct theory - a person was persuaded to run an installer - leads to entirely different questions: what can execute on that machine, what is any of this able to do once it runs, and what else was on that page for everyone else who visited. ## What actually removes it The technique depends on one substitution-proof step: an unapproved executable running with a person's consent. Patch level does not touch that step; controls that govern what may execute on the endpoint do. Reducing the number of destinations from which people are expected to fetch and run software is the other half. Neither of those is a browser update.