CVE-2026-105679 in Ghost
Summary
by MITRE • 10/06/2026
Ghost is a Node.js content management system. From 6.22.1 until 6.64.0, Ghost restricted the content type used to serve uploaded files to prevent browsers from executing them. On sites using the default local storage adapter, this restriction was not applied, so files uploaded by any staff user were served with a content type derived from their file extension. This could be used to host scripts on the site's domain, possibly resulting in compromise of other staff users' admin sessions. This issue is fixed in version 6.64.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified as CVE-2023-5871 represents a critical security flaw within Ghost versions ranging from 6.22.1 to 6.64.0, specifically affecting installations that utilize the default local storage adapter for file management. This issue stems from an inconsistency in how content types are assigned and served when users upload files through the platform's administrative interface. In a properly secured configuration, Ghost is designed to restrict the Content-Type header of uploaded assets to prevent browsers from interpreting them as executable scripts, thereby mitigating cross-site scripting risks. However, this protective mechanism was inadvertently bypassed for sites relying on local storage, where file serving logic derived the content type directly from the original file extension rather than enforcing a strict whitelist or sanitization process.
From a technical perspective, this flaw constitutes an improper restriction of dynamic web content execution, which aligns with CWE-79: Improper Neutralization of Input During Web Page Generation known as Cross-site Scripting (XSS). When a staff member uploads a file such as a JavaScript script disguised with a benign extension or simply named to trigger browser interpretation, the server serves it back with an application/javascript content type. This allows any user who views the uploaded asset within their web browser to execute arbitrary code in the context of the Ghost site's domain. The severity is heightened by the fact that authentication is not required for some file viewing endpoints depending on configuration, but even if restricted, authenticated staff users can exploit this vector against other privileged accounts.
The operational impact of this vulnerability centers on session hijacking and unauthorized access to administrative functions. An attacker with any level of staff access could upload a malicious script containing code designed to exfiltrate authentication cookies or tokens from the browser sessions of other administrators who view the file. By leveraging standard DOM-based XSS techniques, such as accessing document.cookie via an injected event handler like onerror in an image tag that references the uploaded script, the attacker can steal sensitive session data. This leads directly to CWE-287: Improper Authentication and CWE-384: Session Fixation, ultimately allowing the compromise of other staff users' admin sessions and granting full control over the content management system.
This attack vector maps closely to MITRE ATT&CK technique T1059.007: JavaScript under Command and Control or more accurately in this context, T1189: Drive-by Client Execution if viewed as a delivery mechanism for further compromise, but primarily it falls under T1053.005: Scheduled Task/Job: Local Job or simply the broader category of Web Application Attack vectors leading to Account Manipulation (T1078). The exploitation requires no special privileges beyond basic staff access, making it particularly dangerous in environments where multiple users have upload capabilities but varying levels of trust and administrative rights.
To mitigate this vulnerability, organizations running Ghost versions prior to 6.64.0 must upgrade immediately to the patched release which corrects the content type handling logic for local storage adapters. For those unable to patch instantly, a temporary workaround involves configuring Ghost to use an external cloud storage provider such as Amazon S3 or Azure Blob Storage instead of the default local adapter, provided that these providers enforce strict Content-Type headers and do not allow execution of stored objects directly via URL access without additional security policies like bucket restrictions. Additionally, implementing a Web Application Firewall with rules specifically targeting script injection in file upload parameters can provide an extra layer of defense against exploitation attempts while permanent fixes are deployed.