ghsa

Silverstripe silverstripe/framework through 4.11 allows XSS (issue 2 of 3).

### Impact A specially crafted HTTP request can trigger an uncaught exception on the Engine.IO server, thus killing the Node.js process. ``` events.js:292 throw er; // Unhandled 'error' event ^ Error: read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:209:20) Emitted 'error' event on Socket instance at: at emitErrorNT (internal/streams/destroy.js:106:8) at emitErrorCloseNT (internal/streams/destroy.js:74:3) at processTicksAndRejections (internal/process/task_queues.js:80:21) { errno: -104, code: 'ECONNRESET', syscall: 'read' } ``` This impacts all the users of the [`engine.io`](https://www.npmjs.com/package/engine.io) package, including those who uses depending packages like [`socket.io`](https://www.npmjs.com/package/socket.io). ### Patches A fix has been released today (2022/11/20): | Version range | Fixed version | |-------------------|---------------| | `engine.io@3.x.y` | `3.6.1` | | `engine.io@6.x.y` | `6.2.1` ...

Flarum's page title system allowed for page titles to be converted into HTML DOM nodes when pages were rendered. The change was made after `v1.5` and was not noticed. This allowed an attacker to inject malicious HTML markup using a discussion title input, either by creating a new discussion or renaming one. The XSS attack occurs after a visitor opens the relevant discussion page. ### Impact All communities running Flarum from `v1.5.0` to `v1.6.1` are impacted. ### Patches The vulnerability has been fixed and published as flarum/core `v1.6.2`. All communities running Flarum from `v1.5.0` to `v1.6.1` have to upgrade as soon as possible to v1.6.2 using: ``` composer update --prefer-dist --no-dev -a -W ``` You can then confirm you run the latest version using: ``` composer show flarum/core ``` ### Workarounds **None.** ### For more information For any questions or comments on this vulnerability please visit https://discuss.flarum.org/d/27558. For support questions create a discuss...

### Impact Another instance of CVE-2022-35935, where `SobolSample` is vulnerable to a denial of service via assumed scalar inputs, was found and fixed. ```python import tensorflow as tf tf.raw_ops.SobolSample(dim=tf.constant([1,0]), num_results=tf.constant([1]), skip=tf.constant([1])) ``` ### Patches We have patched the issue in GitHub commits [c65c67f88ad770662e8f191269a907bf2b94b1bf](https://github.com/tensorflow/tensorflow/commit/c65c67f88ad770662e8f191269a907bf2b94b1bf) and [02400ea266bd811fc016a848445de1bbff3a23a0](https://github.com/tensorflow/tensorflow/commit/02400ea266bd811fc016a848445de1bbff3a23a0) The fix will be included in TensorFlow 2.11. We will also cherrypick both commits on TensorFlow 2.10.1, 2.9.3, and TensorFlow 2.8.4, as these are also affected and still in supported range. TensorFlow 2.7.4 will have the first commit cherrypicked. ### For more information Please consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for m...

### Impact Another instance of CVE-2022-35991, where `TensorListScatter` and `TensorListScatterV2` crash via non scalar inputs in`element_shape`, was found in eager mode and fixed. ```python import tensorflow as tf arg_0=tf.random.uniform(shape=(2, 2, 2), dtype=tf.float16, maxval=None) arg_1=tf.random.uniform(shape=(2, 2, 2), dtype=tf.int32, maxval=65536) arg_2=tf.random.uniform(shape=(2, 2, 2), dtype=tf.int32, maxval=65536) arg_3='' tf.raw_ops.TensorListScatter(tensor=arg_0, indices=arg_1, element_shape=arg_2, name=arg_3) ``` ### Patches We have patched the issue in GitHub commit [bf9932fc907aff0e9e8cccf769e8b00d30fd81a1](https://github.com/tensorflow/tensorflow/commit/bf9932fc907aff0e9e8cccf769e8b00d30fd81a1). The fix will be included in TensorFlow 2.11. We will also cherrypick this commit on TensorFlow 2.10.1, 2.9.3, and TensorFlow 2.8.4, as these are also affected and still in supported range. ### For more information Please consult [our security guide](https://github.com/tens...

### Impact The application allow anyone with view access to modify any page of the wiki by importing a crafted XAR package. ### Patches The problem has been patched in XWiki 14.6RC1, 14.6 and 13.10.8. ### Workarounds The problem can be patched immediately by setting the right of the page Filter.WebHome and making sure only main wiki administrators can VIEW it the application is installed on main wiki or edit the page and apply the changed described on https://github.com/xwiki/xwiki-platform/commit/fb49b4f289ee28e45cfada8e97e320cd3ed27113. ### References * https://github.com/xwiki/xwiki-platform/commit/fb49b4f289ee28e45cfada8e97e320cd3ed27113 * https://jira.xwiki.org/browse/XWIKI-19758 ### For more information If you have any questions or comments about this advisory: * Open an issue in [JIRA](https://jira.xwiki.org) * Email us at [security ML](mailto:security@xwiki.org)

### Impact The `modifications` rest endpoint does not filter out entries according to the user's rights. Therefore, information hidden from unauthorized users are exposed though the `modifications` rest endpoint (e.g., comments, page names...). ### Patches Users should upgrade to XWiki 14.6+, 14.4.3+, or13.10.8+. Older versions have not been patched. ### Workarounds No known workaround. ### References - Patch: https://github.com/xwiki/xwiki-platform/commit/38dc1aa1a4435f24d58f5b8e4566cbcb0971f8ff - Jira issue: https://jira.xwiki.org/browse/XWIKI-19997 ### For more information If you have any questions or comments about this advisory: - Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) - Email us at [Security Mailing List](mailto:security@xwiki.org)

### Impact User without the right to view documents can deduce their existence by repeated Livetable queries. #### Reproduction steps 1. Restrict "view" access to `Sandbox.TestPage3` by setting an explicit view right for admins 1. As a user who is not an admin, open `<server>/bin/get/XWiki/LiveTableResults?outputSyntax=plain&classname=&collist=doc.title%2Cdoc.location%2Cdoc.content&doc.title=Sandbo&doc.location=Sandbox.TestPage3&doc.content=dummy&limit=0` where `<server>` is the URL of your XWiki installation. #### Expect Result: No results are displayed as the user doesn't have view rights on Sandbox.TestPage3. ##### Actual Result: The result ```json { "reqNo": null, "matchingtags": {}, "tags": [], "totalrows": 1, "returnedrows": 0, "offset": 1, "rows": [ { "doc_viewable": false, "doc_fullName": "obfuscated" } ] } ``` is displayed. This reveals that a document `Sandbox.TestPage3` exists (we explicitly searched for this name) which has a ti...

### Impact Any user with view rights on commonly accessible documents including the menu macro can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation due to improper escaping of the macro content and parameters of the menu macro. The issue can be demonstrated by opening `<server>/xwiki/bin/view/Main?sheet=CKEditor.HTMLConverter&language=en&sourceSyntax=xwiki%2F2.1&stripHTMLEnvelope=true&fromHTML=false&toHTML=true&text=%7B%7Bmenu%7D%7D%7B%7Bcache+id%3D%22menuMacro%22%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22Hello+from+Groovy%21%22%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fcache%7D%7D%7B%7B%2Fmenu%7D%7D` where `<server>` is the URL of the XWiki installation. If this displays "Hello from Groovy!", the installation is vulnerable. ### Patches The problem has been patched in XWiki 14.6RC1, 13.10.8 and 14.4.3. ### Workarounds The [patch](https://github.com/xwiki/xwiki-platform/commit/2fc20891e6c6b0ca05ee07e315e7f435e8919f8d) for the document `Menu....

### Impact We discovered that when the reset a forgotten password feature of XWiki was used, the password was then stored in plain text in database. This only concerns XWiki 13.1RC1 and next versions. Note that it only concerns the reset password feature available from the "Forgot your password" link in the login view: the features allowing a user to change their password, or for an admin to change a user password are not impacted. This vulnerability is particularly dangerous in combination with other vulnerabilities allowing to perform data leak of personal data from users, such as https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-599v-w48h-rjrm. Note that this vulnerability only concerns the users of the main wiki: in case of farms, the users registered on subwiki are not impacted thanks to a bug we discovered when investigating this. ### Patches The problem has been patched in version 14.6RC1, 14.4.3 and 13.10.8. The patch involves a migration of the impacted u...