Repository navigation
v3.15.2
Security
SSRF through the Playwright sidecar (GHSA-26wr-prg5-vr77, reported by @yassertioursi).
The SSRF guard checked the submitted URL in Node and then handed it to the sidecar, where Chromium navigated on its own: a public page answering with a 302, a <meta http-equiv="refresh">, a location assignment, an <iframe> or a fetch() could reach an internal host on the sidecar's network, and for top-level navigations the response body came back as the rendered Markdown. Reachable unauthenticated on the default compose file via render=force, extractor=playwright, the automatic render fallback and the MCP read_url tool.
The sidecar now enforces the same address policy as lib/ssrf.js on every request Chromium makes: a page.route() handler for first hops, a CDP Fetch session for redirect hops (Playwright continues those itself without consulting routes), a WebSocket route, and service workers are blocked. A blocked main-frame navigation fails the render with 403 {"code":"ssrf_blocked"}; /api and read_url answer 403 URL not allowed for render=force / extractor=playwright and cache nothing.
Both images change: update pullmd-playwright together with pullmd. A new pullmd alone does not close this.
Full details in CHANGELOG.md.