ghsa

### Impact All users of Nautobot versions earlier than 1.6.10 or 2.1.2 are potentially impacted. Due to inadequate input sanitization, any user-editable fields that support Markdown rendering, including: - `Circuit.comments` - `Cluster.comments` - `CustomField.description` - `Device.comments` - `DeviceRedundancyGroup.comments` - `DeviceType.comments` - `Job.description` - `JobLogEntry.message` - `Location.comments` - `Note.note` - `PowerFeed.comments` - `Provider.noc_contact` - `Provider.admin_contact` - `Provider.comments` - `ProviderNetwork.comments` - `Rack.comments` - `Tenant.comments` - `VirtualMachine.comments` - Contents of any custom fields of type `markdown` - Job class `description` attributes - The `SUPPORT_MESSAGE` system configuration setting are potentially susceptible to cross-site scripting (XSS) attacks via maliciously crafted data. ### Patches Fixed in Nautobot versions 1.6.10 and 2.1.2. ### References https://github.com/nautobot/nautobot/pull/5133 https://git...

An incomplete fix was found in Keycloak Core patch. An attacker can steal authorization codes or tokens from clients using a wildcard in the JARM response mode "form_post.jwt". It is observed that changing the response_mode parameter in the original proof of concept from "form_post" to "form_post.jwt" can bypass the security patch implemented to address CVE-2023-6134.

Affected versions can run the `Drop` impl of a non-Send type on a different thread than it was created on. The flaw occurs when a stderr write performed by the `threadalone` crate fails, for example because stderr is redirected to a location on a filesystem that is full, or because stderr is a pipe that has been closed by the reader. Dropping a non-Send type on the wrong thread is unsound. If used with a type such as a pthread-based `MutexGuard`, [the consequence is undefined behavior][mutexguard]. If used with `Rc`, there would be a data race on the reference count, which is likewise undefined behavior. [mutexguard]: https://github.com/rust-lang/rust/issues/23465#issuecomment-82730326

### Impact Utility functions related to object paths (`get`, `set` and `update`) did not block attempts to access or alter object prototypes. ### Patches The `get`, `set` and `update` functions will throw a `TypeError` when a user attempts to access or alter inherited properties in versions >=2.2.1.

### Impact Since v1.3.0, we use our own Request object. This is great, but the `url` behavior is unexpected. In the standard API, if the URL contains `..`, here called "double dots", the URL string returned by Request will be in the resolved path. ```ts const req = new Request('http://localhost/static/../foo.txt') // Web-standards console.log(req.url) // http://localhost/foo.txt ``` However, the `url` in our Request does not resolve double dots, so `http://localhost/static/.. /foo.txt` is returned. ```ts const req = new Request('http://localhost/static/../foo.txt') console.log(req.url) // http://localhost/static/../foo.txt ``` It will pass unresolved paths to the web application. This causes vulnerabilities like #123 when using `serveStatic`. Note: Modern web browsers and a latest `curl` command resolve double dots on the client side, so it does not affect you if the user uses them. However, problems may occur if accessed by a client that does not resolve them. ### Patches "v1...

### Summary API endpoint `/api/v1/watch/<uuid>/history` can be accessed by any unauthorized user. ### Details WatchHistory resource does not have `@auth.check_token` annotation, which means it can be accessed without providing `x-api-key` header. https://github.com/dgtlmoon/changedetection.io/blob/9510345e01ea8e308c339163d8e8b030ce5ac7f1/changedetectionio/api/api_v1.py#L129-L156 ### PoC 1. Get list of watch with `x-api-key`: ```sh $ curl -H "x-api-key: apikeyhere" http://localhost:5000/api/v1/watch {"uuid": ...} ``` 2. Call for history of snapshots without `x-api-key`. Expected - 401/403 error. Actual - list of snapshots is listed. ```sh $ curl http://localhost:5000/api/v1/watch/uuid/history {"timestamp": "/path/to/snapshot.txt"} ``` ### Impact Anybody can check one's watch history. However, because unauthorized party first needs to know watch UUID, and the watch history endpoint itself returns only paths to the snapshot on the server, an impact on users' data privacy is minima...

### Impact If a user should not be able to see a record, but that record can be added to a `GridField` using the `GridFieldAddExistingAutocompleter` component, the record's title can be accessed by that user. ### References - https://www.silverstripe.org/download/security-releases/CVE-2023-48714

### Impact `canView` permission checks are bypassed for ORM data in paginated GraphQL query results where the total number of records is greater than the number of records per page. Note that this also affects GraphQL queries which have a limit applied, even if the query isn’t paginated per se. This has been fixed by ensuring no new records are pulled in from the database after performing `canView` permission checks for each page of results. This may result in some pages in your query results having less than the maximum number of records per page even when there are more pages of results. This behaviour is consistent with how pagination works in other areas of Silverstripe CMS, such as in `GridField`, and is a result of having to perform permission checks in PHP rather than in the database directly. You can choose to disable these permission checks by disabling the `CanViewPermission` plugin following the instructions in [overriding default plugins](https://docs.silverstripe.org/e...

python-ecdsa has been found to be subject to a Minerva timing attack on the P-256 curve. Using the `ecdsa.SigningKey.sign_digest()` API function and timing signatures an attacker can leak the internal nonce which may allow for private key discovery. Both ECDSA signatures, key generation, and ECDH operations are affected. ECDSA signature verification is unaffected. The python-ecdsa project considers side channel attacks out of scope for the project and there is no planned fix.

### Impact When using `tuitse_html` without quoting the input, there is a html injection vulnerability. It should use the django version `django.utils.html.format_html`, instead of `string.format()` ### Patches Upgrade to version 1.3.2. ### Workarounds Sanitizing Taigi input with HTML quotation. ### References https://github.com/i3thuan5/TuiTse-TsuSin/pull/22