The report
A workflow can display an approval dialog, authenticate a user and still perform an operation under the wrong security identity. Five n8n advisories provide concrete examples across browser automation, OAuth callbacks, hosted chat, SQL metadata and older code-execution nodes. These are independent defects, not five descriptions of one incident.
The actual boundary of each feature
| Feature | Reported defect | Necessary condition |
|---|---|---|
| Browser Use upload | The upload source path pointed to a file on the n8n server, but approval emphasized the remote destination | The AI Browser Use feature was enabled and could reach browser_upload |
| Legacy Code nodes | Previously saved Function or LangChain Code nodes could still execute in the main process despite newer task-runner isolation | The workflow contained an affected deprecated node |
| Enterprise OAuth | A consenting user's provider token could be attached to the wrong n8n workflow principal | A dynamic credential link was opened and approved without the original n8n session |
| Embedded Chat Trigger | A setup request inherited an authentication exception inappropriate for embedded chat | An affected chat mode used n8n User Auth |
| Oracle vector metadata | A caller-influenced metadata field name became SQL syntax | A dynamic field could reach an Oracle-backed vector query |
The vendor's upload advisory demonstrates why a human approving an outbound host does not necessarily approve the source bytes. Its OAuth advisory instead concerns whose permission is attached after an external sign-in. The legacy-node advisory says blocking new edits is insufficient if already saved nodes remain executable.
What is fixed and what still needs inspection
The advisories list fixes across different 2.x and 3.x branches. Those version matrices must be checked against the relevant deployment and node type; not every installation exposes every feature. None of these findings establishes a mass compromise of n8n customers, and enabling task runners does not automatically repair a wrong OAuth callback or an SQL identifier.
A useful regression test binds each action to an explicit principal, resource and effect at the final execution boundary. For uploads, show the actual server-side file; for callbacks, validate the current user; for SQL, constrain identifiers; and for saved workflows, inspect what executes after an upgrade. The same approval label should never be assumed to authorize all four kinds of action.