Impact An unauthenticated attacker who knows a publicly-known Parse Application ID can submit a single HTTP request whose client SDK version field contains adversarial input that triggers polynomial backtracking in a request-header parser. The parsing runs before session authentication and before rate limiting on every "/parse/" request, so the request consumes seconds to minutes of synchronous CPU on a Node.js worker before any access control evaluates it. A small number of concurrent requests can saturate a worker; a single large request via the body-field variant can pin a worker for minutes. Production deployments running the default configuration are affected. Patches The client SDK version capture and parsing have been removed entirely. The Parse JS SDK compatibility table defines a strict version-pinned contract between Parse Server and the Parse JS SDK; server-side adaptation to client SDK version is an obsolete pattern that contradicts that contract. The vulnerable parser, the "clientSDK" parameter that threaded its output through routers, and the legacy code path it gated are all removed. The "X-Parse-Client-Version" header and "_ClientVersion" JSON body field are now silently ignored on every request; supported Parse SDKs are unaffected. Workarounds Deploy a reverse proxy or WAF in front of Parse Server that strips or strictly size-limits the "X-Parse-Client-Version" header AND the "_ClientVersion" field in JSON request bodies on every "/parse/" route before forwarding to the server. A header-size cap alone is insufficient: the body-field variant requires inspection of JSON content. Upgrading to the patched version is the recommended remediation.