CVE-2026-76235: Cockpit-ws: cockpit: cockpit-ws: unauthenticated remote memory leak via cockpitlang cookie in send_login_html
A flaw was found in cockpit-ws. The sendloginhtml() function in src/ws/cockpithandlers.c reads the CockpitLang cookie via cockpitwebserverparsecookie(), which returns a heap-allocated string (via guriunescapesegment, transfer-full ownership). On this code path, the function's only cleanup call is gstrfreev(languages), but languages remains NULL when the value came from the cookie rather than the Accept-Language header, so the allocated 'language' string is never freed. Every unauthenticated GET request to the login page carrying a CockpitLang cookie leaks one heap allocation sized by the (attacker-controlled) decoded cookie value, up to Cockpit's ~8192-byte request-size cap. Sustained requests grow the shared cockpit-ws process's memory without bound, eventually causing it to be OOM-killed and disrupting all users of that instance, not just the attacker.
Candidate upstream fix (Martin Vollmer): if (languages) gstrfreev (languages); else gfree (language);
Other sources
A memory leak flaw was found in cockpit-ws. The login page handler leaks a heap allocation on every unauthenticated request that carries a CockpitLang cookie, allowing a remote unauthenticated attacker to exhaust memory on the host and cause a denial of service.
— MITRE
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
Any remote, unauthenticated attacker able to send GET requests to the Cockpit login page can trigger the leak. The attacker does not need credentials or user interaction.
What request conditions are required to cause the leak?
Requests must include a CockpitLang cookie when accessing the unauthenticated login page. Each such request leaks memory based on the decoded cookie value, subject to Cockpit's approximately 8192-byte request-size cap.
What is the operational impact of sustained exploitation?
Repeated requests can grow memory use in the shared cockpit-ws process without bound until it is OOM-killed. This disrupts all users of that Cockpit instance, not only the attacker.
Is there a described source-level remediation?
The candidate upstream fix frees language when languages is not allocated: if languages exists, it calls g_strfreev(languages); otherwise, it calls g_free(language).