Two Fastify Vulnerabilities: Multipart Disk Exhaustion and OAuth Login CSRF

Two flaws at different operational boundaries

Fastify published two plugin advisories on August 14, 2026. CVE-2026-19474 affects temporary-file cleanup in @fastify/multipart: when a multi-part upload is interrupted after an earlier file has completed, that file can remain on disk. Repeating the condition can produce persistent, linear disk growth and eventually deny service. CVE-2026-18165 affects the browser-cookie boundary in @fastify/oauth2. A related host able to set cookies for the application can plant the state value—and the PKCE verifier when PKCE is enabled—then bind a victim's callback to an OAuth flow controlled by the attacker.

The remedies are deliberately different. The multipart issue is fixed by replacing the package and, until that is possible, explicitly cleaning request files on rejection. The OAuth issue requires both an upgrade and a configuration decision: version 8.3.0 introduces host-prefixed cookies as an opt-in feature, so upgrading alone does not activate the protection. Teams should treat package inventory, runtime configuration, and deployment verification as one change set.

CVE-2026-19474｜How an interrupted upload remains on disk

@fastify/multipart provides request.saveRequestFiles(), which writes uploaded files into the operating system's temporary directory. In the vulnerable path, a client completes one file part, starts a later part, and then disconnects. The iterator rejects outside the per-file cleanup scope, allowing the earlier completed temporary file to survive even though the overall request fails. An application may therefore return an error while retaining storage consumed by the abandoned request.

Exposure conditions and repeatability

The affected range is @fastify/multipart 3.0.0 through versions before 10.1.1. The advisory's path matters when an application invokes request.saveRequestFiles() for untrusted requests and accepts more than one part. An unauthenticated upload endpoint lowers the cost of repetition. Routes that never call saveRequestFiles(), or that stream data through an independently managed storage lifecycle, should be evaluated separately rather than assumed vulnerable by package presence alone.

An attacker does not need to submit one exceptionally large file. Many failed requests can leave many smaller files behind. If the temporary directory shares a volume with application logs, a container writable layer, or other services, exhaustion can interrupt file creation, logging, process health, and neighboring workloads. Monitoring should therefore correlate HTTP failures with temporary-directory file count and disk growth. Request counts by themselves cannot distinguish ordinary failed uploads from failures that leave storage behind.

• Check the resolved @fastify/multipart version in the lockfile and in each running container.
• Inventory every route that calls saveRequestFiles() and the number of files and fields accepted per request.
• Record authentication, body-size limits, part-count limits, and concurrency controls for those routes.
• Determine whether temporary files use a dedicated volume or share capacity with other workloads.
• In staging, interrupt a later part and compare temporary-file count and disk use before and after the request.

Fixed release and interim handling

Fastify fixed the flaw in @fastify/multipart 10.1.1. Environments that stopped at the earlier incomplete correction associated with CVE-2025-24033 still need 10.1.1 or later. Verify the resolved dependency in monorepo lockfiles, build artifacts, and deployed images rather than changing only a direct declaration. Shared base images also need to be rebuilt and rolled out to the services that actually accept uploads.

Where an immediate upgrade is not possible, the advisory recommends calling request.cleanRequestFiles() when saveRequestFiles() rejects. The cleanup belongs in the failure branch, and a cleanup failure should be logged and alerted. Lower file-size and part-count limits, authentication, and concurrency controls can reduce the rate of disk growth, but they do not repair the cleanup defect and should not replace the patch.

CVE-2026-18165｜When the OAuth cookie boundary changes

The built-in state validation in @fastify/oauth2 compares the callback query's state value with a browser cookie. With PKCE enabled, the verifier is also stored in a cookie. In affected configurations, those cookies are not host-prefixed. Another host under the same registrable domain may therefore set cookies that will be sent to the application host. An attacker-controlled sibling host, a subdomain takeover opportunity, or a related service with cross-site scripting can supply that capability.

The practical result of login CSRF

The attacker begins an OAuth flow using the attacker's own provider account and prepares the values needed to complete it. The related host aligns the victim browser's state and verifier cookies with that flow. When the victim follows the crafted login URL, the callback can pass validation and the service may sign the victim's browser into the attacker's service account. Searches, uploaded files, addresses, orders, or other actions the victim performs can then be recorded in an account the attacker controls.

This is not theft of the victim's OAuth credentials, existing account, session, or tokens. The advisory's direct impact is a login-context switch: the victim acts inside the attacker's account without intending to do so. Testing should therefore verify the identity displayed immediately after login and whether the browser session that initiated authorization is bound to the callback. Services that collect sensitive content after login face a particularly consequential context-confusion risk.

Configuration required after upgrading

Affected releases are @fastify/oauth2 7.2.0 through versions before 8.3.0. Version 8.3.0 adds the hostPrefixedCookies option, but the option is disabled by default. Deployments must upgrade and explicitly enable it over HTTPS. The resulting __Host- cookie names require Secure and a root path while disallowing a Domain attribute, preventing a sibling subdomain from planting a cookie for the application host. Teams should test the behavior behind their production proxy because local HTTP development and the HTTPS deployment can produce different cookie results.

• Upgrade @fastify/oauth2 to 8.3.0 or later and enable hostPrefixedCookies.
• Behind a proxy, confirm that the application correctly recognizes the original HTTPS request.
• Use browser developer tools to verify __Host- names, Secure, and Path=/ on state and verifier cookies.
• Inventory production, staging, retired, and third-party-connected subdomains under the registrable domain.
• For older releases, consider binding state to a server-side session with generateStateFunction and checkStateFunction.

Why PKCE alone does not stop the flow

PKCE proves that the party redeeming an authorization code holds the verifier associated with the initial request. It cannot provide that assurance when an attacker can replace the cookie that stores the verifier. Planting state and verifier as a matched pair aligns the victim browser with the attacker's authorization flow. Server-side state storage bound to the browser session removes this dependence on a writable cross-host cookie boundary and offers an additional defense for organizations that operate many subdomains.

Deployment order and verification

1. Dependency inventory: inspect lockfiles, build output, and running images for the resolved versions of both Fastify plugins.
2. Multipart rollout: install @fastify/multipart 10.1.1 or later, interrupt a later upload part in staging, and confirm temporary-file count and disk use return to baseline.
3. OAuth rollout: deploy @fastify/oauth2 8.3.0 or later together with hostPrefixedCookies, then inspect the resulting cookie attributes over HTTPS.
4. Domain boundary: list every host under the registrable domain and remove unused CNAME records, expired hosting bindings, and abandoned test services.
5. Operational visibility: monitor temporary-directory growth, upload failures, OAuth state mismatches, and reports of an unexpected account immediately after login.

Evidence to retain after the change

Change records should capture more than package versions. Preserve the multipart failure-cleanup branch, the OAuth cookie option, the HTTPS proxy assumptions, and the subdomain inventory used for validation. An integration test can interrupt a later multipart segment and assert that temporary storage returns to baseline. A separate OAuth test can attempt to set the same cookie name from a related host and verify that the application's __Host- cookie remains authoritative.

Prioritize internet-facing unauthenticated upload routes and OAuth applications that share a registrable domain with many brands, staging systems, or customer hosts. The first weakness threatens storage availability; the second undermines the integrity of the login context. The deployment is complete only after the corrected package, required option, failure-path test, and operating metrics agree with the intended design.