ghsa

Version 3.0.0 introduced an `AtomicStr` type, that is used to store the current locale. It stores the locale as a raw pointer to an `Arc<String>`. The locale can be read with `AtomicStr::as_str()`. `AtomicStr::as_str()` does not increment the usage counter of the `Arc`. If the locale is changed in one thread, another thread can have a stale -- possibly already freed -- reference to the stored string.

Impact SOFARPC defaults to using the SOFA Hessian protocol to deserialize received data, while the SOFA Hessian protocol uses a blacklist mechanism to restrict deserialization of potentially dangerous classes for security protection. But there is a gadget chain that can bypass the SOFA Hessian blacklist protection mechanism, and this gadget chain only relies on JDK and does not rely on any third-party components. Patches Fixed this issue by adding a blacklist, users can upgrade to sofarpc version 5.12.0 to avoid this issue. Workarounds SOFARPC also provides a way to add additional blacklist. Users can add some class like -Drpc_serialize_blacklist_override=org.apache.xpath. to avoid this issue.

### Impact Users who don't have edit or delete permissions for records exposed in a `ModelAdmin` can still edit or delete records using the CSV import form, provided they have create permissions. The likelyhood of a user having create permissions but _not_ having edit or delete permissions is low, but it _is_ possible. Note that this doesn't affect any `ModelAdmin` which has had the import form disabled via the [`showImportForm` public property](https://api.silverstripe.org/4/SilverStripe/Admin/ModelAdmin.html#property_showImportForm), nor does it impact the `SecurityAdmin` section. #### Action may be required If you have a custom implementation of [`BulkLoader`](https://api.silverstripe.org/4/SilverStripe/Dev/BulkLoader.html), you should update your implementation to respect permissions when the return value of [`getCheckPermissions()`](https://api.silverstripe.org/4/SilverStripe/Dev/BulkLoader.html#method_getCheckPermissions) is true. If you are using any `BulkLoader` in your ow...

Cross Site Scripting (XSS) vulnerability in JFinalcms 5.0.0 allows attackers to run arbitrary code via the /admin/login username parameter.

Cross Site Scripting (XSS) vulnerability in beetl-bbs 2.0 allows attackers to run arbitrary code via the /index keyword parameter.

A stored cross-site scripting (XSS) vulnerability exists in Apache Superset before 3.0.3. An authenticated attacker with create/update permissions on charts or dashboards could store a script or add a specific HTML snippet that would act as a stored XSS. For 2.X versions, users should change their config to include: TALISMAN_CONFIG = {     "content_security_policy": {         "base-uri": ["'self'"],         "default-src": ["'self'"],         "img-src": ["'self'", "blob:", "data:"],         "worker-src": ["'self'", "blob:"],         "connect-src": [             "'self'",             " https://api.mapbox.com" https://api.mapbox.com" ;,             " https://events.mapbox.com" https://events.mapbox.com" ;,         ],         "object-src": "'none'",         "style-src": [             "'self'",             "'unsafe-inline'",         ],         "script-src": ["'self'", "'strict-dynamic'"],     },     "content_security_policy_nonce_in": ["script-src"],     "force_https": False,     "session...

### 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.