Repository navigation
Default-enabled local upload server has no authentication and unrestricted CORS, allowing cross-site file exfiltration #1454
Description
Affected versions: confirmed on commit 78283f4 (main), with picgo-core 3.1.0 as pinned in package.json.
Summary
PicGo's bundled local upload server (127.0.0.1:36677 by default) starts automatically on launch with authentication disabled and an unrestricted CORS policy on POST /upload. Any web page the user's browser loads while PicGo is running can use this to make PicGo read an arbitrary local file and upload it to the user's configured image/file host, then read the resulting hosted URL back cross-origin, with no interaction beyond visiting that page.
Details
ensureConfig() in src/main/server/index.ts creates the server's first-run configuration as { port: 36677, host: '127.0.0.1', enable: true } with no secret. picgo-core's ServerManager.handleAuth() skips authentication entirely whenever no secret is configured, and logs "Authentication disabled. Anyone can upload images." on startup in that state. Separately, picgo-core's server applies CORS with no origin restriction, so Access-Control-Allow-Origin: * is returned on every response including /upload, letting cross-origin script read the JSON response body as well as send the request.
POST /upload accepts {"list": ["<path>"]} and uploads each named local path to whichever image host the user has configured, returning the resulting URL in the response.
Steps To Reproduce
(available upon request)
Impact
Any website a PicGo user visits while the app is running can exfiltrate the contents of arbitrary local files (bounded only by whatever content validation the user's configured upload destination applies to the bytes it receives) with zero privileges and zero interaction beyond the page load, against PicGo's shipped default configuration.
Activity
Molunerfinn commentedon Oct 20, 2026
Thanks for reporting this. The GUI starts the local server automatically, so users may not realize that it is running without authentication. This deserves an explicit warning in the GUI.
However, silently generating a secret for existing installations would be a breaking change: integrations that currently call the server without authentication would start receiving 401 responses after an upgrade. We should let users make that change explicitly.
The preferred approach is to handle this in PicGo GUI:
Authorization: Bearer <secret>orX-PicGo-Secret: <secret>.For this change, the scope should stay in the GUI. The standalone Core CLI server is started explicitly and already warns when authentication is disabled; Core also already supports secret-based authentication. This does not mean an unauthenticated Core server is safe, but the automatic startup and lack of a visible warning are the GUI-specific concerns we want to address here.
A warning is not equivalent to removing the vulnerability: users who keep authentication disabled will remain exposed to the reported risk. The dialog needs to make that consequence clear so this is an informed choice rather than a silent default.