Apostrophecms
Monthly
Unauthenticated HTTP requests to ApostropheCMS import-export module routes before version 3.7.0 can force the server to initialize uploads, store chunks, and perform temporary processing, consuming disk, memory, and processing resources and degrading availability; ApostropheCMS core prior to 4.33.0 bundles the vulnerable module. The flaw is rated CVSS 7.5 with availability-only impact, requires the import-export module to be installed and its routes network-reachable, and has no public exploit identified at time of analysis.
Authenticated users with view-draft access can permanently break request handling across the entire ApostropheCMS Node.js process by sending a piece-type REST GET request whose `project` query contains an exclusion key such as `constructor.prototype.hasOwnProperty`. The malicious key reaches the SQLite, PostgreSQL, or multipostgres adapter's `unsetNestedField` helper, which walks the dotted path into `Object.prototype` and deletes a shared runtime method - surviving beyond the request and requiring a process restart to recover. Exploitation requires a logged-in account (every editing role has view-draft; guestApiAccess reduces this to any logged-in user) and a SQL-backed adapter with a matching document; installations on the default MongoDB adapter are not affected. No public exploit code or KEV-listed active exploitation was identified at time of analysis.
Unauthenticated denial of service in ApostropheCMS versions prior to 4.33.0, where the Rich Text CSV conversion route stages multipart uploads in the system temporary directory before validating the file extension and fails to delete rejected files, allowing repeated large uploads to exhaust temp-disk capacity. Affected deployments are those with the default route network-reachable; no authentication is needed, only the ordinary public CSRF cookie issued to anonymous clients. Per the assessed vector (CVSS 3.1 AV:N/AC:L/PR:N/UI:N, availability-only impact), this is a genuine but moderate-severity availability issue rather than a top-tier emergency, since disruption requires sustained repeated uploads and depends on temp-partition size and co-tenancy; no public exploit code or CISA KEV active-exploitation status was identified at time of analysis.
Prototype pollution in ApostropheCMS 4.32.0 and earlier enables an authenticated editor to trigger a persistent, process-wide denial of service via a single PATCH REST API request. By sending `{ "toString.call": "x" }` to `PATCH /api/v1/article/:id`, the attacker walks the JavaScript prototype chain through `apos.util.set()` into the shared `Object.prototype.toString` function object and shadows its `call` method, breaking every subsequent `Object.prototype.toString.call()` invocation in Node.js - including those inside the MongoDB driver - until the server process is manually restarted. No separate proof-of-concept repository has been published, but the exact attack payload is fully disclosed in the public GitHub security advisory GHSA-vmg4-6gfg-83qx and the upstream commit diff, and active exploitation has not been confirmed by CISA KEV.
Prototype pollution in ApostropheCMS versions up to and including 4.30.0 allows an authenticated editor to poison Object.prototype via the $pullAll patch operator, ultimately bypassing authorization on all piece-type REST API endpoints for unauthenticated requests until the Node.js process restarts. The flaw stems from apos.util.set() failing to sanitize __proto__ in dot-notation paths, and no public exploit identified at time of analysis but the advisory describes a confirmed exploitation gadget in publicApiCheck(). No vendor-released patch identified at time of analysis, making this an open-window risk for any internet-exposed editor account.
Stored cross-site scripting in the @apostrophecms/seo plugin (versions ≤1.4.2) allows any user holding the default editor role to inject arbitrary JavaScript that executes in every visitor's browser. The seoGoogleTrackingId and seoGoogleTagManager fields are interpolated directly into inline <script> tag bodies via template literals with no sanitization, turning legitimate analytics configuration into a persistent payload delivery channel. No public exploit identified at time of analysis, and no vendor-released patch identified at time of analysis.
Stored cross-site scripting in ApostropheCMS SEO fields permits an authenticated attacker to inject arbitrary JavaScript that executes in the context of any authenticated user viewing the crafted page. This can be leveraged to exfiltrate sensitive user data (usernames, emails, roles) and perform actions as the victim via internal APIs. Public exploit code exists, but no active exploitation has been reported; a patch is available.
Unlimited current-password guessing against ApostropheCMS versions before 4.33.0 lets anyone holding an already-authenticated session - even a disposable low-privilege guest session - grind out a victim's existing password through the self-service endpoint PATCH /api/v1/@apostrophecms/settings/password, because that route verifies the password directly without touching the login module's failed-attempt counter, delay, or lockout. Successful guessing yields full account takeover, so confidentiality and integrity are both rated High while availability is unaffected; the assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N (6.8), stricter on privileges than the vendor's published 5.9/PR:H but agreeing on impact. The attack is not self-starting - no pre-authentication vector exists and success still hinges on victim password entropy - and no public exploit code or active exploitation was identified at time of analysis, though the GHSA advisory itself ships a local PoC curl loop that demonstrates the missing throttle.
An authenticated server-side request forgery (CWE-918) exists in ApostropheCMS's @apostrophecms/ai-helper package versions 1.0.0-beta.10 through 1.0.0-beta.12, fixed in 1.0.0-beta.13. An editor holding image-generation capability can persist a base64 AI image record that has no stored provider URL, then send a PATCH accept request with an attacker-chosen Host header; because the deployment has no configured global base URL, the server derives the fetch origin from that header and issues an outbound GET to an attacker-selected host, port, and HTTP origin. Impact is bounded - the request path is fixed to the uploads directory, and stored-provider or absolute-storage configurations are unaffected - yielding a modest CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) rating; no public exploit code or active exploitation was identified at time of analysis.
ApostropheCMS before 4.33.0 can expose single-use bearer session tokens in cross-host or cross-locale session-migration redirect URLs, letting a low-privileged remote attacker who captures and redeems an unconsumed token before the legitimate client does adopt the associated session. The same token-in-URL pattern affects @apostrophecms/passport-bridge before 1.6.1 in its cross-locale authentication flow. This is a moderate-severity CWE-598 session-handling flaw (assessed CVSS:3.1 5.3, AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L), with no public exploit identified at time of analysis and no CISA KEV confirmation.
Improperly encoded CAPTCHA response tokens let remote attackers disrupt reCAPTCHA and hCaptcha verification in ApostropheCMS deployments that run the Form add-on before 1.5.5, login-recaptcha before 1.2.1, or login-hcaptcha before 1.3.0. Submitting a token containing '&' plus extra key=value pairs injects parameters into the server-side siteverify request, forcing verification failures that break CAPTCHA-gated forms and logins and enabling automated bypass probing; the vendor assessment confirms no secret disclosure and no proven CAPTCHA bypass. No public exploit has been identified at time of analysis, and CISA KEV or EPSS data does not elevate this above a low-priority, denial-of-service-style nuisance for sites that have a vulnerable add-on installed with CAPTCHA actively enabled.
Unauthenticated information disclosure in ApostropheCMS prior to 4.33.0 lets remote attackers probe the REST endpoint GET /api/v1/<piece-type>/:_id/locales (and the equivalent page route) to determine whether an arbitrary document _id exists and which locales it is published in. The route omits the publicApiCheckAsync gate that other read routes enforce, so the read-API's intended gating is bypassed by default with no special configuration, though only existence and locale metadata leak - not document contents - leaving confidentiality impact Low and integrity/availability unaffected. There is no public exploit code or confirmed active exploitation at time of analysis, and the practical risk is reconnaissance value (enumerating valid IDs and site localization footprint) rather than data theft.
Unauthenticated modification and deletion of other users' notifications is possible in ApostropheCMS versions prior to 4.33.0, because the notification module's PATCH and DELETE REST endpoints act directly on the underlying MongoDB collection without verifying that the requester is authenticated or that they own the target document. The practical barrier is knowledge of a valid notification ID: these are MongoDB ObjectIds, so they are not readily enumerable, which is why the vector carries AC:H despite PR:N and UI:N. Impact is limited to integrity of notification records (no confidentiality exposure and no availability impact), and no public exploit code has been identified at time of analysis; the issue is fixed in 4.33.0.
Authenticated importers in ApostropheCMS can crash the Node.js process by submitting a crafted tar archive to the @apostrophecms/import-export module prior to 3.7.0. The archive entry's normalized destination is aimed at a directory while evading a literal parent-path substring check, causing a write-stream filesystem error that is not handled and terminates the process. This is an authenticated denial-of-service issue (CVSS 4.0 base 5.3; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/C:N/I:N/A:L) with no public exploit identified at time of analysis, no KEV listing, and no EPSS score provided; the source establishes a static primitive but not controlled arbitrary file read or write.
The import-export module of ApostropheCMS, in versions prior to 3.7.0, allows an authenticated user who has been granted import access to a document type to supply an object or query operator where a scalar update-key value is expected, so the generated import query matches an existing document the attacker did not deliberately select. Because the normal findForEditing permission filter still applies and the matched document is not attacker-controlled, the overwrite is limited to content the user already has generic edit rights over - there is no bypass into protected or arbitrary content. Both import access and edit permission on the affected type are prerequisites, and only import-export releases below 3.7.0 are affected; no public exploit has been identified at time of analysis.
Stored cross-site scripting can occur in sites using sanitize-html before 2.18.0 when a non-default allow-list permits meta refresh elements and their http-equiv/content attributes, because unsafe script or redirect destinations in the refresh value are retained. ApostropheCMS deployments that bundle the affected library are in scope, but default sanitize-html configurations are not affected; exploitation requires an account able to submit content and a victim who renders it. The issue is fixed in sanitize-html 2.18.0, and no public exploit was identified at time of analysis.
ApostropheCMS versions prior to 4.33.0 expose an exist-in-locale API that answers localized existence checks without applying document-level view or edit authorization, letting an authenticated low-privilege user confirm whether restricted or draft-mode documents exist in a given locale and obtain their localized identifiers. Exploitation requires a valid low-privilege account (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) and works against default configurations, but only discloses existence metadata - not document content - and cannot modify or delete anything, so this is a genuine but low-priority issue. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; the vendor-released patch is version 4.33.0.
Cross-site scripting in ApostropheCMS before 4.33.0 allows an unauthenticated attacker to craft a link that, when opened by an authenticated user in the admin context, abuses apos.http.parseQuery prototype-key handling to mutate browser prototypes and reach a DOM sink for script execution in the victim's session. Exploitation requires user interaction and only affects pages that load the admin bundle, so anonymous front-end visitors are not exposed; no public exploit was identified at time of analysis. Version 4.33.0 fixes the issue, which is scored CVSS 6.1 with a scope change.
sanitize-html 2.17.7 and later before 2.18.0 can bypass SMIL URL protection when an application opts into a non-default allow-list that permits namespace-prefixed SVG animation elements plus URL-targeting attributes. The prefixed animation tags do not match the library's unprefixed animation-element check, so a sanitized SVG can rewrite a link destination to an unsafe URI and execute script if a user activates that link. The default configuration is not unconditionally affected, exploitation requires content-submission access and a victim click, and the issue is fixed in sanitize-html 2.18.0; no public exploit code was identified at time of analysis.
Unauthenticated remote attackers can exhaust server-side temporary storage on ApostropheCMS sites running the @apostrophecms/form add-on prior to 1.5.5, because the form submission route writes unbounded multipart uploads to temporary disk before any form validation or authentication is performed and enforces no upload size, count, or rate limits. Repeated anonymous POSTs to an exposed form route let an attacker fill temp storage and degrade or disrupt form handling and other co-hosted services; the rated vector is AV:N/AC:L/PR:N/UI:N with impact limited to availability (5.3, Medium), and no public exploit code has been identified at time of analysis. It is not recorded as confirmed actively exploited (CISA KEV), but the low skill floor and lack of prerequisites make it a realistic nuisance-to-availability risk for any site exposing a form built with the add-on.
Editors in ApostropheCMS who can import a content type but lack that type's publish role can use the import-export module's write helpers to create, replace, or remove published document variants, bypassing normal publish-permission and lifecycle checks. The flaw is an authenticated, missing-authorization issue (CWE-862, CVSS 6.5, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N) affecting ApostropheCMS core before 4.34.0 when paired with @apostrophecms/import-export before 3.7.1. It is most relevant to deployments that intentionally separate import rights from publication rights; no public exploit code or confirmed active exploitation was identified at time of analysis.
ApostropheCMS before 4.33.0 enables an authenticated editor to alter sibling page ordering under a restricted parent without create authorization on that parent, but only when the nested arrangement already exists. This CWE-639 IDOR-class flaw has a CVSS 3.1 base score of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), reflecting low integrity impact, no confidentiality or availability impact, and the editor credential prerequisite. No public exploit identified at time of analysis, and no CISA KEV active exploitation is indicated in the provided data.
Stored cross-site scripting in sanitize-html before 2.18.0 occurs only when the sanitizer is configured with a non-default nonTextTags option that includes noscript; default configurations and other default nonTextTags elements are not affected. In ApostropheCMS, an authenticated low-privilege content author can submit crafted HTML that survives sanitization and executes when a victim later views it in a scripting-enabled browser, yielding limited client-side impact (assessed CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N; CVSS 4.0 base 5.3, Medium). No public exploit was identified at time of analysis.
ApostropheCMS versions prior to 4.33.0 fail to enforce the viewRole permission for anonymous visitors, allowing user-object fields to be disclosed when a developer has deliberately published user documents through a rendered relationship or an expressly enabled public API. The exposure is unauthenticated and low-complexity where it exists, but it is conditional on developer configuration - relationships do not automatically publish full user objects, and password hashes are stored separately and are never disclosed - so a default installation is not affected. The issue is fixed in 4.33.0; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Account-level Azure SAS tokens are written into every public attachment URL by uploadfs - the storage abstraction used by ApostropheCMS - whenever the Azure backend is configured with sas: true, so anyone who can load a single published attachment can silently harvest credentials for the entire backing storage account. Versions 1.25.0 through 1.27.x are affected; remote attackers need no authentication and no user interaction, but exposure is conditional on that specific Azure configuration, which is why the vendor scores it 5.6 with AC:H while our analysis scores the same vector at 8.8 (S:C/C:H/I:H/A:H) given the account-wide blast radius of the leaked secret. No public exploit code or confirmed active exploitation has been identified at time of analysis, and uploadfs 1.28.0 fixes the issue by no longer embedding the SAS query string in the client construction path.
Path traversal (CWE-22) in uploadfs, the file storage library bundled with ApostropheCMS, allows parent-directory segments in attacker-supplied paths to escape the configured upload directory prior to version 1.28.0, affecting file reads, writes, and deletions on the host filesystem through the local backend. The flaw is not exploitable against the library in isolation: it only triggers when a host application explicitly routes unsanitized, attacker-controlled path strings into uploadfs read, write, or delete operations, which is why the vendor scores it as high-complexity with privileged access requirements (AC:H/PR:H). There is no public exploit identified at time of analysis and no CISA KEV listing; this is a low-priority, high-conditionality issue rather than a broadly dangerous flaw.
Unbounded recursive re-sanitization in sanitize-html 2.18.0 allows remote attackers to exhaust the Node.js call stack and crash the process by submitting HTML containing a disallowed <iframe> with deeply nested raw-text content. The flaw triggers only under the library defaults - <iframe> absent from allowedTags and disallowedTagsMode set to 'discard' - which means most unmodified deployments, including ApostropheCMS installations that route untrusted HTML through the sanitizer, are exposed. Impact is limited to availability (CVSS 5.3, A:L only, PR:N/AC:L/UI:N) with no confidentiality or integrity effect, and no public exploit code or CISA KEV active-exploitation entry was identified at time of analysis.
Unauthenticated tampering with import jobs in ApostropheCMS: the @apostrophecms/import-export module before 3.7.1 exposes POST /api/v1/@apostrophecms/import-export/clean-export without any authentication or authorization check, so any site visitor holding the standard CSRF cookie can invoke cleanExport and discard a pending import's uploaded files and mark that import job completed. Impact is narrow rather than severe - the operation targets a pending import by its random ID, which is only disclosed to the uploading user, so an attacker must already know or observe that identifier, and the site must have the optional import-export module installed with an import in flight. There is no data disclosure and no availability impact; no public exploit identified at time of analysis, and vendor fixes are available in 3.7.1.
Stored cross-site scripting in ApostropheCMS versions before 4.34.0 allows an authenticated content editor to break out of an inline style attribute and add executable HTML attributes when a project-defined free-form widget style field is rendered. Published content viewed by visitors or an affected draft viewed by a higher-privileged user can trigger the injected attributes; the issue requires a non-default inline style field and victim interaction, and no public exploit was identified at time of analysis. The CVSS 5.4 rating reflects changed scope with limited confidentiality and integrity impact.
Broken access control in ApostropheCMS's pages REST API (all versions prior to 4.34.0) allows an authenticated editor-level user who knows a document _id to read the full content of admin-only pages and privileged fields via the getOne endpoint, which skips the viewRole and viewPermission enforcement that the getAll endpoint correctly applies. Exploitation requires an authenticated account with at least editor privileges plus knowledge of the target page's _id, giving a confidentiality-only impact (CVSS 4.3, AV:N/AC:L/PR:L/UI:N/C:L/I:N/A:N). No public exploit code has been identified at time of analysis and the flaw is not confirmed actively exploited (not in CISA KEV); the vendor-released patch is 4.34.0.
An authorization bypass in the @apostrophecms/import-export module of ApostropheCMS (versions prior to 3.7.1) lets a low-privilege contributor with draft editing rights cross the publication boundary during a duplicate-import continuation. Because the module accepts a client-supplied replacement choice without binding it to a server-side analysis owned by that user or re-authorizing the canonical target document, the contributor can select a published document for replacement on an import-enabled localized type and modify content they should not be able to touch. The flaw is rated CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N) with integrity-only impact; no public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor's current assessment derives from remediation review rather than a repeated end-to-end reproduction.
Resource exhaustion in ApostropheCMS's import-export module before 3.7.1 allows an authenticated user with importer permission to submit archives whose decompressed bytes, entry count, or per-entry sizes are not bounded before document-type authorization, potentially consuming server resources and leaving staging or extracted artifacts behind after extraction or parsing failures. The flaw is network-reachable and low-complexity but requires a logged-in importer (PR:L), and the maintainers have not validated the full end-to-end denial-of-service impact, so the assessed availability effect is limited. No public exploit or CISA KEV entry is identified in the provided data; the issue is fixed in @apostrophecms/import-export 3.7.1.
ApostropheCMS releases prior to 4.34.0 can be made to reveal information about fields that a public REST API projection deliberately excludes, because search-membership and sort-ordering responses still behave differently depending on hidden searchable or sortable field values. Unauthenticated remote attackers who can query a publicly exposed piece or page type configured with publicApiProjection can therefore test candidate values one at a time, though the projection continues to filter all returned fields, so this is targeted inference rather than an unrestricted dump. The exposure is conditional on a specific configuration - an excluded field that remains searchable or sortable - and no public exploit code or confirmed active exploitation was identified at time of analysis.
Predictable export archive filenames in the @apostrophecms/import-export module before 3.7.1 let an unauthenticated requester derive and fetch another user's export archive from publicly readable export storage while it still exists. Only deployments with the import-export feature enabled and export/upload storage that is publicly reachable over the network are exposed, and the attacker must time the request inside the window before the archive expires or is cleaned up. Exploitation additionally depends on a user with export permission having already created an archive, so real-world risk is conditional rather than universal; no public exploit code or confirmed active exploitation was identified at time of analysis, though the disclosure yields full read access to exported content (CVSS 4.0 6.0; assessed CVSS 3.1 AV:N/AC:H/PR:N/UI:R/C:H/I:N/A:N).
Information disclosure in ApostropheCMS prior to 4.34.0 lets any authenticated user, including low-privileged editors, query the slugTaken API to learn whether a given slug exists across all document types and visibility levels, including private pages, drafts, and archived content. The endpoint returns only a boolean, so the exposure is limited to slug existence rather than document contents, giving a CVSS 3.1 score of 4.3; no public exploit code has been identified at time of analysis, and the issue is fixed in 4.34.0.
Stored cross-site scripting in ApostropheCMS before 4.34.0 allows an authenticated user with content-edit rights to persist arbitrary HTML inside a color field and have it execute in another user's browser when the value is rendered. The flaw exists because the field's TinyColor validation accepts any value that merely contains a valid rgb()/hsl() color, so an attacker can supply a legitimate color prefix followed by crafted markup; the payload reaches the generated wrapper's style attribute when a widget style color field is rendered inline without a selector. Exploitation requires a valid editor account and a victim who later views the affected page (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N, 5.4), and no public exploit code or active exploitation has been identified at time of analysis. The issue is fixed in version 4.34.0.
Unauthenticated page-content disclosure in ApostropheCMS versions prior to 4.33.0 lets remote attackers read page documents that should have been filtered by the platform's authorization and visibility rules. The bypass is exercised through the content REST API by requesting /api/v1/@apostrophecms/page with the all=1 query parameter, matching the assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N vector (score 5.3): network reachable, requiring no credentials and no user interaction, with low confidentiality impact and no integrity or availability impact. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, so this is a genuine but moderate-priority exposure; the vendor has released 4.33.0 to correct the authorization logic.
Stored XSS in sanitize-html versions 1.9.0 through 2.17.6 allows authenticated low-privileged users to inject executable JavaScript via SVG SMIL animation elements that survive the library's scheme-policy sanitization. The sanitizer validates the `values` attribute as a single flat URL, missing that `attributeName="href"` gives `values` URI-list semantics under SVG SMIL; a payload of `#safe;javascript:alert(1)` passes the scheme check on its leading fragment while the `javascript:` entry survives intact. When a victim clicks the rendered link, the browser resolves the later entry and executes script in the application's origin. A working proof-of-concept is publicly disclosed in the GHSA advisory; no CISA KEV listing at time of analysis.
Path traversal in ApostropheCMS's import-export module (versions prior to 3.6.2) allows an authenticated contributor to exfiltrate host files and expose them publicly via the CMS uploads URL. By importing a crafted `.tar.gz` archive with `../` sequences embedded in the `_id`, `name`, or `extension` fields of `aposAttachments.json`, an attacker causes the module to reconstruct a source path that escapes the extraction directory, reading any host file whose name ends with an allow-listed extension and copying it to a publicly accessible, unauthenticated uploads endpoint. No public exploit is identified at time of analysis; vendor-released patch is available in version 3.6.2.
Stored cross-site scripting in ApostropheCMS prior to 2.17.6 enables execution of arbitrary JavaScript in victim browsers through a parser-differential bypass in the bundled sanitize-html library. When `textarea` or `xmp` is included in a site's `allowedTags` configuration, a payload using a trailing solidus on the closing tag - such as `</textarea/>` - is treated as text by htmlparser2 10.x but as a valid close by spec-compliant browsers, causing injected markup like `<img onerror=...>` to execute as live HTML on page load. No public exploit repository has been identified and the vulnerability is not listed in the CISA KEV catalog, but a functional proof-of-concept payload is fully described in the upstream security advisory GHSA-jxwj-j7wr-gfrw; the fix ships in version 2.17.6.
Integrity bypass in ApostropheCMS page management allows authenticated low-privileged editors to move pages into restricted subtrees they have no create rights over, and indirectly re-rank admin-only sibling pages via an unchecked database updateMany call. All deployments running ApostropheCMS prior to 4.32.0 are affected; the flaw exists in the REST page update endpoint and requires no special configuration to reach. No public exploit code exists and the vulnerability is not listed in CISA KEV, but the attack path through documented REST parameters is straightforward for any CMS insider.
Server-Side Request Forgery in ApostropheCMS through version 4.30.0 allows unauthenticated remote attackers to pivot the Node.js application process into issuing outbound HTTP requests to arbitrary hosts on the internal network when the `prettyUrls` SEO feature is explicitly enabled on the `@apostrophecms/file` module. The attack exploits the raw `Host` HTTP request header, which the pretty-URL handler uses verbatim to construct and `fetch()` an upstream URL, streaming the full HTTP response - status code, headers, and body - back to the requester. Practical impact is constrained to blind SSRF (network-topology probing via response-code and timing oracles, and verbose proxy or WAF error-body disclosure) rather than arbitrary data exfiltration; no patch exists at time of publication and no public exploit has been identified.
Cross-site scripting in sanitize-html prior to 2.17.5 allows low-privileged attackers to inject executable `javascript:` URIs through HTML attributes that the library's scheme-blocking logic never inspects. The `naughtyHref()` function gates dangerous URI schemes only for attributes listed in `allowedSchemesAppliedToAttributes` (defaulting to `href`, `src`, and `cite`), leaving attributes such as `action`, `formaction`, `data`, `poster`, `background`, `ping`, `xlink:href`, `dynsrc`, and `lowsrc` entirely unchecked. Applications that explicitly permit any of these attributes in their sanitize-html configuration are vulnerable; no public exploit code has been identified at time of analysis, and this CVE is not currently listed in CISA KEV.
Stored cross-site scripting in ApostropheCMS up to and including version 4.29.0 allows an attacker who controls a user account to inject malicious script into the draft version tooltip via an unsanitized display name field. Any editor or administrator who subsequently views that tooltip in the CMS backend will execute the attacker's payload in their browser, enabling session hijacking or unauthorized action execution. No public exploit has been identified at time of analysis and no patched version is available per the vendor advisory.
Information disclosure in ApostropheCMS 4.28.0 and earlier allows unauthenticated attackers to extract distinct field values via the choices and counts REST API query parameters, bypassing publicApiProjection restrictions. The vulnerability exposes sensitive schema field values, including those protected by viewPermission, and a proof-of-concept exploit exists, though no active exploitation is confirmed.
Stored cross-site scripting in ApostropheCMS versions 4.28.0 and prior allows authenticated editors to inject arbitrary JavaScript into the color-field widget, executing in the browsers of all site visitors. Exploitation enables mass session hijacking and privilege escalation to administrative control; publicly available proof-of-concept exploit code exists, though no active exploitation has been confirmed. The vulnerability has been patched in version 4.29.0.
Information disclosure in ApostropheCMS 4.28.0 and earlier allows unauthenticated attackers to bypass admin-configured field restrictions on the piece-type REST API, exposing sensitive content such as internal notes or draft metadata. Public exploit code is available, though the EPSS score (0.09%) indicates low current exploitation probability; no active exploitation has been confirmed.
Cross-site scripting (XSS) in ApostropheCMS 4.28.0 and sanitize-html 2.17.1 allows remote attackers to bypass HTML tag filtering and inject arbitrary tags through entity-encoded payloads in textarea and option elements. A regression in the sanitize-html parser incorrectly assumes htmlparser2 does not decode entities within non-text elements, causing encoded HTML to be decoded and written directly to output without sanitization. Exploitation requires non-default configurations where textarea or option tags are in the allowedTags list, commonly found in form builders, and user interaction to submit form content. No active exploitation has been identified at time of analysis, but the vulnerability is trivial to exploit once configuration conditions are met.
User enumeration via a timing side channel in ApostropheCMS versions 4.28.0 and prior allows unauthenticated attackers to identify valid usernames and emails. The password reset endpoint fails to normalize response time when a valid user is found, enabling an attacker to distinguish valid accounts from invalid ones by repeatedly probing the endpoint. This can facilitate credential stuffing and targeted phishing against instances that have explicitly enabled the password reset feature.
'sanitize-html' prior to version 1.0.3 is vulnerable to Cross-site Scripting (XSS). Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
`sanitize-html` prior to version 2.0.0-beta is vulnerable to Cross-site Scripting (XSS). Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Versions of the package sanitize-html before 2.12.1 are vulnerable to Information Exposure when used on the backend and with the style attribute allowed, allowing enumeration of files in the system. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
The package sanitize-html before 2.7.1 are vulnerable to Regular Expression Denial of Service (ReDoS) due to insecure global regular expression replacement logic of HTML comment removal. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Apostrophe CMS versions prior to 3.3.1 did not invalidate existing login sessions when disabling a user account or changing the password, creating a situation in which a device compromised by a third. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Apostrophe CMS versions between 2.63.0 to 3.3.1 are vulnerable to Stored XSS where an editor uploads an SVG file that contains malicious JavaScript onto the Images module, which triggers XSS once. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. This Cross-Site Scripting (XSS) vulnerability could allow attackers to inject malicious scripts into web pages viewed by other users.
Apostrophe Technologies sanitize-html before 2.3.2 does not properly validate the hostnames set by the "allowedIframeHostnames" option when the "allowIframeRelativeUrls" is set to true, which allows. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Apostrophe Technologies sanitize-html before 2.3.1 does not properly handle internationalized domain name (IDN) which could allow an attacker to bypass hostname whitelist validation set by the. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Unauthenticated HTTP requests to ApostropheCMS import-export module routes before version 3.7.0 can force the server to initialize uploads, store chunks, and perform temporary processing, consuming disk, memory, and processing resources and degrading availability; ApostropheCMS core prior to 4.33.0 bundles the vulnerable module. The flaw is rated CVSS 7.5 with availability-only impact, requires the import-export module to be installed and its routes network-reachable, and has no public exploit identified at time of analysis.
Authenticated users with view-draft access can permanently break request handling across the entire ApostropheCMS Node.js process by sending a piece-type REST GET request whose `project` query contains an exclusion key such as `constructor.prototype.hasOwnProperty`. The malicious key reaches the SQLite, PostgreSQL, or multipostgres adapter's `unsetNestedField` helper, which walks the dotted path into `Object.prototype` and deletes a shared runtime method - surviving beyond the request and requiring a process restart to recover. Exploitation requires a logged-in account (every editing role has view-draft; guestApiAccess reduces this to any logged-in user) and a SQL-backed adapter with a matching document; installations on the default MongoDB adapter are not affected. No public exploit code or KEV-listed active exploitation was identified at time of analysis.
Unauthenticated denial of service in ApostropheCMS versions prior to 4.33.0, where the Rich Text CSV conversion route stages multipart uploads in the system temporary directory before validating the file extension and fails to delete rejected files, allowing repeated large uploads to exhaust temp-disk capacity. Affected deployments are those with the default route network-reachable; no authentication is needed, only the ordinary public CSRF cookie issued to anonymous clients. Per the assessed vector (CVSS 3.1 AV:N/AC:L/PR:N/UI:N, availability-only impact), this is a genuine but moderate-severity availability issue rather than a top-tier emergency, since disruption requires sustained repeated uploads and depends on temp-partition size and co-tenancy; no public exploit code or CISA KEV active-exploitation status was identified at time of analysis.
Prototype pollution in ApostropheCMS 4.32.0 and earlier enables an authenticated editor to trigger a persistent, process-wide denial of service via a single PATCH REST API request. By sending `{ "toString.call": "x" }` to `PATCH /api/v1/article/:id`, the attacker walks the JavaScript prototype chain through `apos.util.set()` into the shared `Object.prototype.toString` function object and shadows its `call` method, breaking every subsequent `Object.prototype.toString.call()` invocation in Node.js - including those inside the MongoDB driver - until the server process is manually restarted. No separate proof-of-concept repository has been published, but the exact attack payload is fully disclosed in the public GitHub security advisory GHSA-vmg4-6gfg-83qx and the upstream commit diff, and active exploitation has not been confirmed by CISA KEV.
Prototype pollution in ApostropheCMS versions up to and including 4.30.0 allows an authenticated editor to poison Object.prototype via the $pullAll patch operator, ultimately bypassing authorization on all piece-type REST API endpoints for unauthenticated requests until the Node.js process restarts. The flaw stems from apos.util.set() failing to sanitize __proto__ in dot-notation paths, and no public exploit identified at time of analysis but the advisory describes a confirmed exploitation gadget in publicApiCheck(). No vendor-released patch identified at time of analysis, making this an open-window risk for any internet-exposed editor account.
Stored cross-site scripting in the @apostrophecms/seo plugin (versions ≤1.4.2) allows any user holding the default editor role to inject arbitrary JavaScript that executes in every visitor's browser. The seoGoogleTrackingId and seoGoogleTagManager fields are interpolated directly into inline <script> tag bodies via template literals with no sanitization, turning legitimate analytics configuration into a persistent payload delivery channel. No public exploit identified at time of analysis, and no vendor-released patch identified at time of analysis.
Stored cross-site scripting in ApostropheCMS SEO fields permits an authenticated attacker to inject arbitrary JavaScript that executes in the context of any authenticated user viewing the crafted page. This can be leveraged to exfiltrate sensitive user data (usernames, emails, roles) and perform actions as the victim via internal APIs. Public exploit code exists, but no active exploitation has been reported; a patch is available.
Unlimited current-password guessing against ApostropheCMS versions before 4.33.0 lets anyone holding an already-authenticated session - even a disposable low-privilege guest session - grind out a victim's existing password through the self-service endpoint PATCH /api/v1/@apostrophecms/settings/password, because that route verifies the password directly without touching the login module's failed-attempt counter, delay, or lockout. Successful guessing yields full account takeover, so confidentiality and integrity are both rated High while availability is unaffected; the assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N (6.8), stricter on privileges than the vendor's published 5.9/PR:H but agreeing on impact. The attack is not self-starting - no pre-authentication vector exists and success still hinges on victim password entropy - and no public exploit code or active exploitation was identified at time of analysis, though the GHSA advisory itself ships a local PoC curl loop that demonstrates the missing throttle.
An authenticated server-side request forgery (CWE-918) exists in ApostropheCMS's @apostrophecms/ai-helper package versions 1.0.0-beta.10 through 1.0.0-beta.12, fixed in 1.0.0-beta.13. An editor holding image-generation capability can persist a base64 AI image record that has no stored provider URL, then send a PATCH accept request with an attacker-chosen Host header; because the deployment has no configured global base URL, the server derives the fetch origin from that header and issues an outbound GET to an attacker-selected host, port, and HTTP origin. Impact is bounded - the request path is fixed to the uploads directory, and stored-provider or absolute-storage configurations are unaffected - yielding a modest CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) rating; no public exploit code or active exploitation was identified at time of analysis.
ApostropheCMS before 4.33.0 can expose single-use bearer session tokens in cross-host or cross-locale session-migration redirect URLs, letting a low-privileged remote attacker who captures and redeems an unconsumed token before the legitimate client does adopt the associated session. The same token-in-URL pattern affects @apostrophecms/passport-bridge before 1.6.1 in its cross-locale authentication flow. This is a moderate-severity CWE-598 session-handling flaw (assessed CVSS:3.1 5.3, AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L), with no public exploit identified at time of analysis and no CISA KEV confirmation.
Improperly encoded CAPTCHA response tokens let remote attackers disrupt reCAPTCHA and hCaptcha verification in ApostropheCMS deployments that run the Form add-on before 1.5.5, login-recaptcha before 1.2.1, or login-hcaptcha before 1.3.0. Submitting a token containing '&' plus extra key=value pairs injects parameters into the server-side siteverify request, forcing verification failures that break CAPTCHA-gated forms and logins and enabling automated bypass probing; the vendor assessment confirms no secret disclosure and no proven CAPTCHA bypass. No public exploit has been identified at time of analysis, and CISA KEV or EPSS data does not elevate this above a low-priority, denial-of-service-style nuisance for sites that have a vulnerable add-on installed with CAPTCHA actively enabled.
Unauthenticated information disclosure in ApostropheCMS prior to 4.33.0 lets remote attackers probe the REST endpoint GET /api/v1/<piece-type>/:_id/locales (and the equivalent page route) to determine whether an arbitrary document _id exists and which locales it is published in. The route omits the publicApiCheckAsync gate that other read routes enforce, so the read-API's intended gating is bypassed by default with no special configuration, though only existence and locale metadata leak - not document contents - leaving confidentiality impact Low and integrity/availability unaffected. There is no public exploit code or confirmed active exploitation at time of analysis, and the practical risk is reconnaissance value (enumerating valid IDs and site localization footprint) rather than data theft.
Unauthenticated modification and deletion of other users' notifications is possible in ApostropheCMS versions prior to 4.33.0, because the notification module's PATCH and DELETE REST endpoints act directly on the underlying MongoDB collection without verifying that the requester is authenticated or that they own the target document. The practical barrier is knowledge of a valid notification ID: these are MongoDB ObjectIds, so they are not readily enumerable, which is why the vector carries AC:H despite PR:N and UI:N. Impact is limited to integrity of notification records (no confidentiality exposure and no availability impact), and no public exploit code has been identified at time of analysis; the issue is fixed in 4.33.0.
Authenticated importers in ApostropheCMS can crash the Node.js process by submitting a crafted tar archive to the @apostrophecms/import-export module prior to 3.7.0. The archive entry's normalized destination is aimed at a directory while evading a literal parent-path substring check, causing a write-stream filesystem error that is not handled and terminates the process. This is an authenticated denial-of-service issue (CVSS 4.0 base 5.3; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/C:N/I:N/A:L) with no public exploit identified at time of analysis, no KEV listing, and no EPSS score provided; the source establishes a static primitive but not controlled arbitrary file read or write.
The import-export module of ApostropheCMS, in versions prior to 3.7.0, allows an authenticated user who has been granted import access to a document type to supply an object or query operator where a scalar update-key value is expected, so the generated import query matches an existing document the attacker did not deliberately select. Because the normal findForEditing permission filter still applies and the matched document is not attacker-controlled, the overwrite is limited to content the user already has generic edit rights over - there is no bypass into protected or arbitrary content. Both import access and edit permission on the affected type are prerequisites, and only import-export releases below 3.7.0 are affected; no public exploit has been identified at time of analysis.
Stored cross-site scripting can occur in sites using sanitize-html before 2.18.0 when a non-default allow-list permits meta refresh elements and their http-equiv/content attributes, because unsafe script or redirect destinations in the refresh value are retained. ApostropheCMS deployments that bundle the affected library are in scope, but default sanitize-html configurations are not affected; exploitation requires an account able to submit content and a victim who renders it. The issue is fixed in sanitize-html 2.18.0, and no public exploit was identified at time of analysis.
ApostropheCMS versions prior to 4.33.0 expose an exist-in-locale API that answers localized existence checks without applying document-level view or edit authorization, letting an authenticated low-privilege user confirm whether restricted or draft-mode documents exist in a given locale and obtain their localized identifiers. Exploitation requires a valid low-privilege account (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) and works against default configurations, but only discloses existence metadata - not document content - and cannot modify or delete anything, so this is a genuine but low-priority issue. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; the vendor-released patch is version 4.33.0.
Cross-site scripting in ApostropheCMS before 4.33.0 allows an unauthenticated attacker to craft a link that, when opened by an authenticated user in the admin context, abuses apos.http.parseQuery prototype-key handling to mutate browser prototypes and reach a DOM sink for script execution in the victim's session. Exploitation requires user interaction and only affects pages that load the admin bundle, so anonymous front-end visitors are not exposed; no public exploit was identified at time of analysis. Version 4.33.0 fixes the issue, which is scored CVSS 6.1 with a scope change.
sanitize-html 2.17.7 and later before 2.18.0 can bypass SMIL URL protection when an application opts into a non-default allow-list that permits namespace-prefixed SVG animation elements plus URL-targeting attributes. The prefixed animation tags do not match the library's unprefixed animation-element check, so a sanitized SVG can rewrite a link destination to an unsafe URI and execute script if a user activates that link. The default configuration is not unconditionally affected, exploitation requires content-submission access and a victim click, and the issue is fixed in sanitize-html 2.18.0; no public exploit code was identified at time of analysis.
Unauthenticated remote attackers can exhaust server-side temporary storage on ApostropheCMS sites running the @apostrophecms/form add-on prior to 1.5.5, because the form submission route writes unbounded multipart uploads to temporary disk before any form validation or authentication is performed and enforces no upload size, count, or rate limits. Repeated anonymous POSTs to an exposed form route let an attacker fill temp storage and degrade or disrupt form handling and other co-hosted services; the rated vector is AV:N/AC:L/PR:N/UI:N with impact limited to availability (5.3, Medium), and no public exploit code has been identified at time of analysis. It is not recorded as confirmed actively exploited (CISA KEV), but the low skill floor and lack of prerequisites make it a realistic nuisance-to-availability risk for any site exposing a form built with the add-on.
Editors in ApostropheCMS who can import a content type but lack that type's publish role can use the import-export module's write helpers to create, replace, or remove published document variants, bypassing normal publish-permission and lifecycle checks. The flaw is an authenticated, missing-authorization issue (CWE-862, CVSS 6.5, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N) affecting ApostropheCMS core before 4.34.0 when paired with @apostrophecms/import-export before 3.7.1. It is most relevant to deployments that intentionally separate import rights from publication rights; no public exploit code or confirmed active exploitation was identified at time of analysis.
ApostropheCMS before 4.33.0 enables an authenticated editor to alter sibling page ordering under a restricted parent without create authorization on that parent, but only when the nested arrangement already exists. This CWE-639 IDOR-class flaw has a CVSS 3.1 base score of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), reflecting low integrity impact, no confidentiality or availability impact, and the editor credential prerequisite. No public exploit identified at time of analysis, and no CISA KEV active exploitation is indicated in the provided data.
Stored cross-site scripting in sanitize-html before 2.18.0 occurs only when the sanitizer is configured with a non-default nonTextTags option that includes noscript; default configurations and other default nonTextTags elements are not affected. In ApostropheCMS, an authenticated low-privilege content author can submit crafted HTML that survives sanitization and executes when a victim later views it in a scripting-enabled browser, yielding limited client-side impact (assessed CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N; CVSS 4.0 base 5.3, Medium). No public exploit was identified at time of analysis.
ApostropheCMS versions prior to 4.33.0 fail to enforce the viewRole permission for anonymous visitors, allowing user-object fields to be disclosed when a developer has deliberately published user documents through a rendered relationship or an expressly enabled public API. The exposure is unauthenticated and low-complexity where it exists, but it is conditional on developer configuration - relationships do not automatically publish full user objects, and password hashes are stored separately and are never disclosed - so a default installation is not affected. The issue is fixed in 4.33.0; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Account-level Azure SAS tokens are written into every public attachment URL by uploadfs - the storage abstraction used by ApostropheCMS - whenever the Azure backend is configured with sas: true, so anyone who can load a single published attachment can silently harvest credentials for the entire backing storage account. Versions 1.25.0 through 1.27.x are affected; remote attackers need no authentication and no user interaction, but exposure is conditional on that specific Azure configuration, which is why the vendor scores it 5.6 with AC:H while our analysis scores the same vector at 8.8 (S:C/C:H/I:H/A:H) given the account-wide blast radius of the leaked secret. No public exploit code or confirmed active exploitation has been identified at time of analysis, and uploadfs 1.28.0 fixes the issue by no longer embedding the SAS query string in the client construction path.
Path traversal (CWE-22) in uploadfs, the file storage library bundled with ApostropheCMS, allows parent-directory segments in attacker-supplied paths to escape the configured upload directory prior to version 1.28.0, affecting file reads, writes, and deletions on the host filesystem through the local backend. The flaw is not exploitable against the library in isolation: it only triggers when a host application explicitly routes unsanitized, attacker-controlled path strings into uploadfs read, write, or delete operations, which is why the vendor scores it as high-complexity with privileged access requirements (AC:H/PR:H). There is no public exploit identified at time of analysis and no CISA KEV listing; this is a low-priority, high-conditionality issue rather than a broadly dangerous flaw.
Unbounded recursive re-sanitization in sanitize-html 2.18.0 allows remote attackers to exhaust the Node.js call stack and crash the process by submitting HTML containing a disallowed <iframe> with deeply nested raw-text content. The flaw triggers only under the library defaults - <iframe> absent from allowedTags and disallowedTagsMode set to 'discard' - which means most unmodified deployments, including ApostropheCMS installations that route untrusted HTML through the sanitizer, are exposed. Impact is limited to availability (CVSS 5.3, A:L only, PR:N/AC:L/UI:N) with no confidentiality or integrity effect, and no public exploit code or CISA KEV active-exploitation entry was identified at time of analysis.
Unauthenticated tampering with import jobs in ApostropheCMS: the @apostrophecms/import-export module before 3.7.1 exposes POST /api/v1/@apostrophecms/import-export/clean-export without any authentication or authorization check, so any site visitor holding the standard CSRF cookie can invoke cleanExport and discard a pending import's uploaded files and mark that import job completed. Impact is narrow rather than severe - the operation targets a pending import by its random ID, which is only disclosed to the uploading user, so an attacker must already know or observe that identifier, and the site must have the optional import-export module installed with an import in flight. There is no data disclosure and no availability impact; no public exploit identified at time of analysis, and vendor fixes are available in 3.7.1.
Stored cross-site scripting in ApostropheCMS versions before 4.34.0 allows an authenticated content editor to break out of an inline style attribute and add executable HTML attributes when a project-defined free-form widget style field is rendered. Published content viewed by visitors or an affected draft viewed by a higher-privileged user can trigger the injected attributes; the issue requires a non-default inline style field and victim interaction, and no public exploit was identified at time of analysis. The CVSS 5.4 rating reflects changed scope with limited confidentiality and integrity impact.
Broken access control in ApostropheCMS's pages REST API (all versions prior to 4.34.0) allows an authenticated editor-level user who knows a document _id to read the full content of admin-only pages and privileged fields via the getOne endpoint, which skips the viewRole and viewPermission enforcement that the getAll endpoint correctly applies. Exploitation requires an authenticated account with at least editor privileges plus knowledge of the target page's _id, giving a confidentiality-only impact (CVSS 4.3, AV:N/AC:L/PR:L/UI:N/C:L/I:N/A:N). No public exploit code has been identified at time of analysis and the flaw is not confirmed actively exploited (not in CISA KEV); the vendor-released patch is 4.34.0.
An authorization bypass in the @apostrophecms/import-export module of ApostropheCMS (versions prior to 3.7.1) lets a low-privilege contributor with draft editing rights cross the publication boundary during a duplicate-import continuation. Because the module accepts a client-supplied replacement choice without binding it to a server-side analysis owned by that user or re-authorizing the canonical target document, the contributor can select a published document for replacement on an import-enabled localized type and modify content they should not be able to touch. The flaw is rated CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N) with integrity-only impact; no public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor's current assessment derives from remediation review rather than a repeated end-to-end reproduction.
Resource exhaustion in ApostropheCMS's import-export module before 3.7.1 allows an authenticated user with importer permission to submit archives whose decompressed bytes, entry count, or per-entry sizes are not bounded before document-type authorization, potentially consuming server resources and leaving staging or extracted artifacts behind after extraction or parsing failures. The flaw is network-reachable and low-complexity but requires a logged-in importer (PR:L), and the maintainers have not validated the full end-to-end denial-of-service impact, so the assessed availability effect is limited. No public exploit or CISA KEV entry is identified in the provided data; the issue is fixed in @apostrophecms/import-export 3.7.1.
ApostropheCMS releases prior to 4.34.0 can be made to reveal information about fields that a public REST API projection deliberately excludes, because search-membership and sort-ordering responses still behave differently depending on hidden searchable or sortable field values. Unauthenticated remote attackers who can query a publicly exposed piece or page type configured with publicApiProjection can therefore test candidate values one at a time, though the projection continues to filter all returned fields, so this is targeted inference rather than an unrestricted dump. The exposure is conditional on a specific configuration - an excluded field that remains searchable or sortable - and no public exploit code or confirmed active exploitation was identified at time of analysis.
Predictable export archive filenames in the @apostrophecms/import-export module before 3.7.1 let an unauthenticated requester derive and fetch another user's export archive from publicly readable export storage while it still exists. Only deployments with the import-export feature enabled and export/upload storage that is publicly reachable over the network are exposed, and the attacker must time the request inside the window before the archive expires or is cleaned up. Exploitation additionally depends on a user with export permission having already created an archive, so real-world risk is conditional rather than universal; no public exploit code or confirmed active exploitation was identified at time of analysis, though the disclosure yields full read access to exported content (CVSS 4.0 6.0; assessed CVSS 3.1 AV:N/AC:H/PR:N/UI:R/C:H/I:N/A:N).
Information disclosure in ApostropheCMS prior to 4.34.0 lets any authenticated user, including low-privileged editors, query the slugTaken API to learn whether a given slug exists across all document types and visibility levels, including private pages, drafts, and archived content. The endpoint returns only a boolean, so the exposure is limited to slug existence rather than document contents, giving a CVSS 3.1 score of 4.3; no public exploit code has been identified at time of analysis, and the issue is fixed in 4.34.0.
Stored cross-site scripting in ApostropheCMS before 4.34.0 allows an authenticated user with content-edit rights to persist arbitrary HTML inside a color field and have it execute in another user's browser when the value is rendered. The flaw exists because the field's TinyColor validation accepts any value that merely contains a valid rgb()/hsl() color, so an attacker can supply a legitimate color prefix followed by crafted markup; the payload reaches the generated wrapper's style attribute when a widget style color field is rendered inline without a selector. Exploitation requires a valid editor account and a victim who later views the affected page (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N, 5.4), and no public exploit code or active exploitation has been identified at time of analysis. The issue is fixed in version 4.34.0.
Unauthenticated page-content disclosure in ApostropheCMS versions prior to 4.33.0 lets remote attackers read page documents that should have been filtered by the platform's authorization and visibility rules. The bypass is exercised through the content REST API by requesting /api/v1/@apostrophecms/page with the all=1 query parameter, matching the assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N vector (score 5.3): network reachable, requiring no credentials and no user interaction, with low confidentiality impact and no integrity or availability impact. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, so this is a genuine but moderate-priority exposure; the vendor has released 4.33.0 to correct the authorization logic.
Stored XSS in sanitize-html versions 1.9.0 through 2.17.6 allows authenticated low-privileged users to inject executable JavaScript via SVG SMIL animation elements that survive the library's scheme-policy sanitization. The sanitizer validates the `values` attribute as a single flat URL, missing that `attributeName="href"` gives `values` URI-list semantics under SVG SMIL; a payload of `#safe;javascript:alert(1)` passes the scheme check on its leading fragment while the `javascript:` entry survives intact. When a victim clicks the rendered link, the browser resolves the later entry and executes script in the application's origin. A working proof-of-concept is publicly disclosed in the GHSA advisory; no CISA KEV listing at time of analysis.
Path traversal in ApostropheCMS's import-export module (versions prior to 3.6.2) allows an authenticated contributor to exfiltrate host files and expose them publicly via the CMS uploads URL. By importing a crafted `.tar.gz` archive with `../` sequences embedded in the `_id`, `name`, or `extension` fields of `aposAttachments.json`, an attacker causes the module to reconstruct a source path that escapes the extraction directory, reading any host file whose name ends with an allow-listed extension and copying it to a publicly accessible, unauthenticated uploads endpoint. No public exploit is identified at time of analysis; vendor-released patch is available in version 3.6.2.
Stored cross-site scripting in ApostropheCMS prior to 2.17.6 enables execution of arbitrary JavaScript in victim browsers through a parser-differential bypass in the bundled sanitize-html library. When `textarea` or `xmp` is included in a site's `allowedTags` configuration, a payload using a trailing solidus on the closing tag - such as `</textarea/>` - is treated as text by htmlparser2 10.x but as a valid close by spec-compliant browsers, causing injected markup like `<img onerror=...>` to execute as live HTML on page load. No public exploit repository has been identified and the vulnerability is not listed in the CISA KEV catalog, but a functional proof-of-concept payload is fully described in the upstream security advisory GHSA-jxwj-j7wr-gfrw; the fix ships in version 2.17.6.
Integrity bypass in ApostropheCMS page management allows authenticated low-privileged editors to move pages into restricted subtrees they have no create rights over, and indirectly re-rank admin-only sibling pages via an unchecked database updateMany call. All deployments running ApostropheCMS prior to 4.32.0 are affected; the flaw exists in the REST page update endpoint and requires no special configuration to reach. No public exploit code exists and the vulnerability is not listed in CISA KEV, but the attack path through documented REST parameters is straightforward for any CMS insider.
Server-Side Request Forgery in ApostropheCMS through version 4.30.0 allows unauthenticated remote attackers to pivot the Node.js application process into issuing outbound HTTP requests to arbitrary hosts on the internal network when the `prettyUrls` SEO feature is explicitly enabled on the `@apostrophecms/file` module. The attack exploits the raw `Host` HTTP request header, which the pretty-URL handler uses verbatim to construct and `fetch()` an upstream URL, streaming the full HTTP response - status code, headers, and body - back to the requester. Practical impact is constrained to blind SSRF (network-topology probing via response-code and timing oracles, and verbose proxy or WAF error-body disclosure) rather than arbitrary data exfiltration; no patch exists at time of publication and no public exploit has been identified.
Cross-site scripting in sanitize-html prior to 2.17.5 allows low-privileged attackers to inject executable `javascript:` URIs through HTML attributes that the library's scheme-blocking logic never inspects. The `naughtyHref()` function gates dangerous URI schemes only for attributes listed in `allowedSchemesAppliedToAttributes` (defaulting to `href`, `src`, and `cite`), leaving attributes such as `action`, `formaction`, `data`, `poster`, `background`, `ping`, `xlink:href`, `dynsrc`, and `lowsrc` entirely unchecked. Applications that explicitly permit any of these attributes in their sanitize-html configuration are vulnerable; no public exploit code has been identified at time of analysis, and this CVE is not currently listed in CISA KEV.
Stored cross-site scripting in ApostropheCMS up to and including version 4.29.0 allows an attacker who controls a user account to inject malicious script into the draft version tooltip via an unsanitized display name field. Any editor or administrator who subsequently views that tooltip in the CMS backend will execute the attacker's payload in their browser, enabling session hijacking or unauthorized action execution. No public exploit has been identified at time of analysis and no patched version is available per the vendor advisory.
Information disclosure in ApostropheCMS 4.28.0 and earlier allows unauthenticated attackers to extract distinct field values via the choices and counts REST API query parameters, bypassing publicApiProjection restrictions. The vulnerability exposes sensitive schema field values, including those protected by viewPermission, and a proof-of-concept exploit exists, though no active exploitation is confirmed.
Stored cross-site scripting in ApostropheCMS versions 4.28.0 and prior allows authenticated editors to inject arbitrary JavaScript into the color-field widget, executing in the browsers of all site visitors. Exploitation enables mass session hijacking and privilege escalation to administrative control; publicly available proof-of-concept exploit code exists, though no active exploitation has been confirmed. The vulnerability has been patched in version 4.29.0.
Information disclosure in ApostropheCMS 4.28.0 and earlier allows unauthenticated attackers to bypass admin-configured field restrictions on the piece-type REST API, exposing sensitive content such as internal notes or draft metadata. Public exploit code is available, though the EPSS score (0.09%) indicates low current exploitation probability; no active exploitation has been confirmed.
Cross-site scripting (XSS) in ApostropheCMS 4.28.0 and sanitize-html 2.17.1 allows remote attackers to bypass HTML tag filtering and inject arbitrary tags through entity-encoded payloads in textarea and option elements. A regression in the sanitize-html parser incorrectly assumes htmlparser2 does not decode entities within non-text elements, causing encoded HTML to be decoded and written directly to output without sanitization. Exploitation requires non-default configurations where textarea or option tags are in the allowedTags list, commonly found in form builders, and user interaction to submit form content. No active exploitation has been identified at time of analysis, but the vulnerability is trivial to exploit once configuration conditions are met.
User enumeration via a timing side channel in ApostropheCMS versions 4.28.0 and prior allows unauthenticated attackers to identify valid usernames and emails. The password reset endpoint fails to normalize response time when a valid user is found, enabling an attacker to distinguish valid accounts from invalid ones by repeatedly probing the endpoint. This can facilitate credential stuffing and targeted phishing against instances that have explicitly enabled the password reset feature.
'sanitize-html' prior to version 1.0.3 is vulnerable to Cross-site Scripting (XSS). Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
`sanitize-html` prior to version 2.0.0-beta is vulnerable to Cross-site Scripting (XSS). Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Versions of the package sanitize-html before 2.12.1 are vulnerable to Information Exposure when used on the backend and with the style attribute allowed, allowing enumeration of files in the system. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
The package sanitize-html before 2.7.1 are vulnerable to Regular Expression Denial of Service (ReDoS) due to insecure global regular expression replacement logic of HTML comment removal. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Apostrophe CMS versions prior to 3.3.1 did not invalidate existing login sessions when disabling a user account or changing the password, creating a situation in which a device compromised by a third. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Apostrophe CMS versions between 2.63.0 to 3.3.1 are vulnerable to Stored XSS where an editor uploads an SVG file that contains malicious JavaScript onto the Images module, which triggers XSS once. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. This Cross-Site Scripting (XSS) vulnerability could allow attackers to inject malicious scripts into web pages viewed by other users.
Apostrophe Technologies sanitize-html before 2.3.2 does not properly validate the hostnames set by the "allowedIframeHostnames" option when the "allowIframeRelativeUrls" is set to true, which allows. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Apostrophe Technologies sanitize-html before 2.3.1 does not properly handle internationalized domain name (IDN) which could allow an attacker to bypass hostname whitelist validation set by the. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.