CVE-2026-113652 in ApostropheCMS
Summary
by MITRE • 10/20/2026
ApostropheCMS is an open-source Node.js content management system. From 1.25.0 until 1.28.0, uploadfs Azure backend leaks account-level SAS token into every public attachment URL. When uploadfs is configured with the Azure backend and sas: true, createContainer() builds the BlobServiceClient from a URL that embeds the full SAS query string, and Azure SDK v12 derived clients inherit that query string. This issue is fixed in version 1.28.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/20/2026
ApostropheCMS versions ranging from 1.25.0 to 1.28.0 contain a critical information disclosure vulnerability within its Azure Blob Storage integration, specifically affecting the uploadfs module when configured with the azure backend and sas enabled. This flaw results in the unintended exposure of account-level Shared Access Signature tokens through every public attachment URL generated by the system. The vulnerability stems from an improper handling of authentication credentials during the initialization of cloud storage clients, leading to a significant breach of confidentiality for organizations relying on this content management platform for digital asset management.
The technical root cause lies in how the createContainer function constructs the BlobServiceClient when SAS token authentication is active. Instead of isolating the credential from the resource URL, the implementation embeds the full SAS query string directly into the base URL used to instantiate the client. Because Azure SDK version 12 propagates this configuration down through derived clients, every subsequent operation that generates a public attachment URL inadvertently includes the sensitive account-level SAS token as part of the query parameters. This means that any publicly accessible asset served by ApostropheCMS via Azure storage will contain credentials capable of granting broad access to the underlying storage account resources if intercepted or scraped from logs and caches.
From an operational perspective, this vulnerability poses a severe risk to data integrity and availability in addition to confidentiality. An attacker who discovers these URLs can extract the embedded SAS token and utilize it to perform unauthorized actions against the Azure Storage Account. Depending on the permissions granted by the specific SAS token, such as read, write, delete, or list operations, an adversary could exfiltrate sensitive documents, modify existing content, destroy critical data assets, or enumerate other resources within the storage account that were not intended for public access. This effectively bypasses the isolation mechanisms provided by container-level permissions and exposes the entire storage infrastructure to compromise.
This flaw aligns with CWE-200, which classifies information exposure as a category of vulnerability where sensitive information is disclosed without proper authorization controls. Furthermore, in terms of adversary behavior mapping under MITRE ATT&CK, this scenario relates to techniques involving credential access from local systems or cloud environments, specifically how misconfigured APIs can leak secrets that facilitate further lateral movement and data exfiltration phases within an attack chain. The persistence of these tokens in public URLs also complicates incident response efforts, as the leaked credentials remain valid until rotation occurs, requiring immediate remediation to prevent ongoing exploitation.
To mitigate this vulnerability, organizations running ApostropheCMS versions 1.25.0 through 1.28.0 must upgrade immediately to version 1.28.0 or later, where the issue has been resolved by correcting how SAS tokens are handled during client initialization. If upgrading is not immediately feasible, administrators should consider disabling public access for containers that store sensitive assets and restricting network-level access via firewall rules until the patch can be applied. Additionally, it is imperative to rotate any Azure Storage Account keys or SAS tokens associated with affected instances to invalidate potentially leaked credentials. Regular audits of cloud storage configurations and monitoring for unusual API calls originating from exposed endpoints are recommended practices to detect potential exploitation attempts early in the attack lifecycle.