ApostropheCMS versions prior to 4.33.0 and passport-bridge versions prior to 1.6.1 contain a vulnerability where a single-use bearer session token is placed in a redirect URL during cross-host or cross-locale session migration. This allows a client who obtains and redeems a still-valid, unconsumed token before its first use to adopt the associated session. The issue is fixed in ApostropheCMS 4.33.0 and passport-bridge 1.6.1.
ApostropheCMS versions prior to 4.33.0 have a vulnerability where an unauthenticated user can access the GET /api/v1/<piece-type>/:_id/locales REST route without proper authorization checks. This allows the user to determine if a document exists and which locales it is published in, exposing sensitive metadata that should be restricted. The issue is fixed in version 4.33.0.
ApostropheCMS versions prior to 4.33.0 and db-connect versions prior to 1.1.0 contain a vulnerability where accounts with view-draft access can submit a crafted projection exclusion path that manipulates the prototype chain, leading to deletion of shared runtime members. This causes persistent process-wide integrity and availability issues. The vulnerability affects SQLite, PostgreSQL, and multipostgres adapters but not the default MongoDB adapter. The issue is fixed in ApostropheCMS 4.33.0 and db-connect 1.1.0.
ApostropheCMS versions prior to 4.34.0 and import-export module versions prior to 3.7.1 contain a missing authorization vulnerability. An editor with import permissions but lacking stronger publication roles can improperly create, replace, or remove published content variants without the usual publish permission and lifecycle checks. This flaw allows unauthorized modification of published content through import write helpers. The issue is resolved in ApostropheCMS 4.34.0 and import-export 3.7.1.
ApostropheCMS versions prior to 4.33.0 contain an authorization bypass vulnerability allowing authenticated editors with edit rights on a page to reorder sibling pages under a restricted parent without having create authorization on that parent. This bypass is limited to sibling ordering and does not allow arbitrary content modification, confidentiality loss, or creation of restricted nesting. The issue is fixed in version 4.33.0.
ApostropheCMS versions from 1.25.0 up to but not including 1.28.0, when configured with the Azure backend and SAS tokens enabled, leak account-level SAS tokens in public attachment URLs. This exposure occurs because the BlobServiceClient is constructed from a URL embedding the full SAS query string, which is then inherited by Azure SDK clients. The issue is fixed in version 1.28.0 and later.
ApostropheCMS is an open-source Node.js content management system. Prior to 3.7.1 of the import-export module, predictable export archive filenames allow an unauthenticated requester to download another user's export from publicly readable export storage before the archive expires or is removed. A user with export permission must first create the archive, and sites with exports disabled, private upload storage, or authenticated upload delivery are not exposed through this network-download path. This issue is fixed in version 3.7.1.
### Summary
The color field accepts any string that *begins* with a valid `rgb()` / `hsl()` color, because `TinyColor.isValid` does not anchor its match at the end of the string. An authenticated user with edit rights can store arbitrary HTML after a valid color prefix. When the stored value is rendered , the payload executes, resulting in stored XSS.
### Details
Server-side validation of the color field relies on TinyColor:
```js
const { TinyColor } = require('@ctrl/tinycolor');
if (!new TinyColor(value).isValid) throw self.apos.error('invalid');
```
TinyColor's `rgb`/`hsl` matchers are not anchored at the end of the string, while hex matchers are. Tested with @ctrl/tinycolor
| Input | `isValid` |
|---|---|
| `rgb(1,2,3)<img src=x onerror=alert(1)>` | `true` |
| `rgb(1,2,3)</textarea><script>alert(1)</script>` | `true` |
| `hsl(0,100%,50%);--x:1}</style><script>alert(1)</script>` | `true` |
| `#ff0000<img src=x onerror=alert(1)>` | `false` |
The value is saved to MongoDB unchanged (not normalized to hex8).
### Relation to GHSA-97v6-998m-fp4g
GHSA-97v6 addressed CSS custom property injection escaping a `<style>` context. The root cause (validation that accepts trailing content after a valid color) still exists in <= 4.32.2, so [FILL IN: either "the style-tag sink remains exploitable via `</style>`" OR "a separate HTML sink at X is exploitable"]. Fixing the validation (requiring the full string to be a color, or storing only TinyColor's normalized output) would close both.
### Impact
Any user with edit permission can plant persistent JavaScript that runs in the browser of visitors and administrators viewing the affected page, enabling session hijacking and actions as an admin.
### Suggested fix
Reject values unless the entire string is a valid color, e.g. normalize on save:
```js
const c = new TinyColor(value);
if (!c.isValid) throw self.apos.error('invalid');
value = c.toHex8String(); // store only normalized output
```
ApostropheCMS versions 4.28.0 and earlier have an authorization bypass vulnerability in the REST API's choices and counts query parameters. This flaw allows unauthenticated attackers to retrieve distinct values of any schema field, including those protected by view permissions, bypassing intended field exposure restrictions. The vulnerability arises because MongoDB's distinct() operation does not respect the publicApiProjection filtering, resulting in sensitive data exposure. The issue affects both piece-type and page REST APIs and has been fixed in version 4.29.0.