@@ -0,0 +1,7 @@
+---
+"apostrophe": patch
+---
+
+Security: the color field accepted any value that merely contained a valid `rgb()`, `hsl()` or similar color, so extra content before or after the color was stored as-is. When such a color is used by a widget style field rendered inline (no `selector`), that content reached the wrapper's `style` attribute and could inject HTML attributes into the published page. The whole value must now be a valid color, otherwise it is discarded like any other invalid color. Legitimate values (hex, named colors, `transparent`, `rgb()`/`rgba()`/`hsl()`/`hsla()` notations, CSS variable names) are stored unchanged. Exploitation requires permission to edit content using a color field (CWE-20, CWE-79, GHSA-vmgj-9cwm-cf3h).
+
+Thanks to [N.HARSHA VARDHAN](https://github.com/saiharsha0546-dot) for reporting the vulnerability.
@@ -0,0 +1,7 @@
+---
+"@apostrophecms/import-export": patch
+---
+
+Security: the `clean-export` and `override-duplicates` routes did not require a login. Also, `clean-export` would discard the pending files of an import started by someone else and mark any import job as completed, without checking who owned either. Both routes now require a logged-in user. `clean-export` only acts on an import uploaded by the caller, and only ends that caller's own job. Import jobs are now recorded as belonging to the user who started them. Exposure was limited because the pending import's ID is random and only shown to the user who uploaded it, so in practice an attacker could only interfere with an import they could already identify (CWE-306, CWE-862, CWE-639, GHSA-rw26-wwfc-9wvm).
+
+Thanks to [Liuhuo Wan](https://github.com/CoSunshine) for reporting the vulnerability.
@@ -0,0 +1,7 @@
+---
+"apostrophe": patch
+---
+
+Security: widget style values were written into the generated wrapper's `style` and `class` attributes without HTML attribute escaping, so a project-defined free-form `string` style field could be used by an editor to inject additional HTML attributes into the published page. All attribute values rendered by `getWidgetAttributes()` and the `apos.styles.attributes()` helper are now escaped. Only projects that define a free-form style field are affected, and exploitation requires permission to edit the widget (CWE-79, CWE-116, GHSA-7jg5-frgc-c67w).
+
+Thanks to [Fariskhi Vidyan](https://github.com/farisv) for reporting the vulnerability.
@@ -0,0 +1,7 @@
+---
+"@apostrophecms/import-export": patch
+---
+
+Security: extracting an import archive had no limit on the size or number of the files it wrote, so a small, highly compressed archive could fill the server's disk, and a failed import left the uploaded archive, its copy in uploadfs and its partial extraction behind. Extraction now stops as soon as the archive goes over a limit on the number of entries (100,000 by default) or on the total extracted size (100 times the size of the archive, at least 64MB, by default), counted on the bytes actually written. The limits can be changed with the new `importLimits` option of the module. Everything an import uploaded or extracted is removed whenever it fails. Exploiting this required a logged-in user (CWE-400, CWE-409, CWE-459, GHSA-9g7p-m758-rp72).
+
+Thanks to [Mufeed VH](https://github.com/mufeedvh) and [Vivek R](https://github.com/123vivekr) for reporting the vulnerability.
@@ -0,0 +1,7 @@
+---
+"@apostrophecms/import-export": patch
+---
+
+Security: when continuing an import after the user confirmed which duplicates to replace, the server trusted the list of documents and replacement targets sent back by the browser, and checked the importable type against the imported file rather than against the existing document being overwritten. A logged-in user allowed to import could overwrite documents the import never offered to replace, including documents of types they may not import, and continue the import of another user. The duplicates found by the import are now remembered on the server for the user who started it, the browser can only narrow that list down, and the type of every replaced document must be importable (CWE-639, CWE-863, GHSA-jf5h-36mg-rp6x).
+
+Thanks to [Mufeed VH](https://github.com/mufeedvh) and [Vivek R](https://github.com/123vivekr) for reporting the vulnerability.
@@ -0,0 +1,10 @@
+---
+"@apostrophecms/import-export": patch
+"apostrophe": patch
+---
+
+Security: importing could write the published version of documents the importing user was not allowed to publish. A contributor could create or replace published content with a crafted archive, and an editor could import or update published documents of a type whose `publishRole` is `admin`. Import now refuses documents whose mode, locale and `_id` disagree. Exploiting this required a logged-in user allowed to import the type.
+
+The rest was a gap in the core permission check, fixed there, which also covers import. A type's `publishRole` was always meant to govern its published content, but editing or creating the published version of a document did not honor it: an editor could change published documents of a type whose `publishRole` is `admin`, including through the REST API, without publishing them through the normal workflow. That was a bug and should not have been relied upon. Editing or creating a published document now requires the `publishRole`. Types with `autopublish: true`, types without a draft/published distinction, and permission checks made with a type name rather than a document are unchanged (CWE-285, CWE-863, GHSA-5m22-7pfq-vp65).
+
+Thanks to [Mufeed VH](https://github.com/mufeedvh) and [Vivek R](https://github.com/123vivekr) for reporting the vulnerability.
@@ -0,0 +1,7 @@
+---
+"apostrophe": patch
+---
+
+Security: fields restricted by `viewPermission` are now removed from every document in every REST API response (`apiRoutes` and `restApiRoutes` of all modules) for a user who lacks that permission, not just from the documents requested from the page and piece REST APIs. This includes documents loaded through relationships (also nested and reverse relationships, and relationships inside widgets, array fields and object fields), the related pages embedded in page responses (`_ancestors` and `_children`), the home page response, page `autocomplete` results, areas rendered with `render-areas`, and the documents returned after a write: `POST`, `PUT` and `PATCH` (including archiving, restoring and moving pages), publish, unpublish, revert, localize and share, as well as `GET /api/v1/@apostrophecms/doc/:_id` and a single document version. The document version history also no longer reveals changes to those fields: the change list of a version (`GET /api/v1/@apostrophecms/document-versions/:versionId/changes`) leaves them out, the change counts of the version list and of a single version no longer count them, and a version's document with `annotate=1` no longer highlights them as changed. Saving a document without those fields in the request body still leaves their stored values untouched, as before. Each document is filtered according to its own type's schema. A `project` query parameter can also no longer exclude `type` or `metaType`, which could previously be used to keep a page's restricted fields in the response. The reported problems with `GET /api/v1/@apostrophecms/page/:_id`, which in 4.32.2 and earlier ignored type-level `viewRole` and did not remove `viewPermission` fields, were already corrected in 4.33.0 and are now covered by additional tests. Enforcing `viewRole` on that route was always the intended behavior, and the earlier behavior was a bug that should not have been relied upon. This only affects sites that use `viewPermission`. Anonymous visitors were affected only where a `publicApiProjection` includes a relationship to documents of a type with such fields (CWE-200, CWE-863, GHSA-vh56-5m88-39rq).
+
+Thanks to [harshavardhan98899-lab](https://github.com/harshavardhan98899-lab) for reporting the vulnerability.
@@ -0,0 +1,7 @@
+---
+"apostrophe": patch
+---
+
+Security: for anonymous REST API requests restricted by `publicApiProjection`, the `sort` query parameter and the per-field filter query parameters could operate on fields excluded by the projection, revealing the relative order of hidden values or which documents had a given hidden value. Sort keys and field filters not permitted by the projection are now ignored for these requests. In addition, the related pages embedded in anonymous page REST API responses (`_ancestors` and `_children`) were not limited to `publicApiProjection` when the projection included `path`; they now are. Authenticated requests and API key requests are not affected. Only sites that set `publicApiProjection` were affected. Full text search (`search`, `autocomplete`) is unchanged: it covers every field not marked `searchable: false`, exactly as the public site search does, so sensitive text fields should be marked `searchable: false` (CWE-200, CWE-639, GHSA-rqgm-cfrp-4hx8).
+
+Thanks to [N.HARSHA VARDHAN](https://github.com/saiharsha0546-dot) for reporting the vulnerability.
@@ -0,0 +1,7 @@
+---
+"sanitize-html": patch
+---
+
+Security: since 2.18.0, the fallback markup of a discarded `<iframe>` was re-sanitized by a recursive call with no limit, one level per nested unclosed `<iframe>`. A few kilobytes of crafted input could throw `RangeError: Maximum call stack size exceeded` with the default options, and the `nestingLimit` option was not enforced across the fallback because each nested call started counting from zero. The fallback of a discarded `<iframe>` is still sanitized and kept, but only up to eight nested `<iframe>` elements (deeper fallback is escaped as text, as before 2.18.0), and the current nesting depth now carries into the nested call so `nestingLimit` applies to the whole output. Only 2.18.0 was affected, and the exception is thrown synchronously, so applications that catch errors from `sanitizeHtml` only lost the affected request (CWE-674, GHSA-c9rx-x947-fp3h).
+
+Thanks to [hkmj19](https://github.com/hkmj19), [JohnBeckley](https://github.com/JohnBeckley), and [amikhailovstiltsoft](https://github.com/amikhailovstiltsoft) for reporting the vulnerability.
@@ -0,0 +1,7 @@
+---
+"apostrophe": patch
+---
+
+Security: the `slug-taken` route of `@apostrophecms/doc` told any logged-in user, including guests who cannot edit anything, whether a slug was in use, even by documents they could not view. It now requires the ability to edit content (the `view-draft` permission held by contributors, editors and admins). Because slugs are unique across all documents, users who can choose a slug still learn that it is already taken; this is inherent in globally unique slugs, and the route reveals nothing about the document beyond that (CWE-200, CWE-203, GHSA-f66c-mpj2-3r8h).
+
+Thanks to [T.Jaswanth](https://github.com/Jaswanth080901) for reporting the vulnerability.