#perl

Failing to properly encode incoming data, the bookmark toolbar is susceptible to Cross-Site Scripting.

When a drug kingpin named Microsoft tried to seize control of an encrypted phone company for criminals, he was playing right into its real owners’ hands.

Failing to properly encode editor input, several frontend components are susceptible to Cross-Site Scripting, allowing authenticated editors to inject arbitrary HTML.

Fastly researchers discover unauthenticated stored XSS attacks plaguing WordPress Plugins including WP Meta SEO, and the popular WP…

A flaw in the database escaping API results in a SQL injection vulnerability when extension dbal is enabled and configured for MySQL passthrough mode in its extension configuration. All queries which use the DatabaseConnection::sql_query are vulnerable, even if arguments were properly escaped with DatabaseConnection::quoteStr beforehand.

Failing to properly encode editor input, the search result view of indexed_search is susceptible to Cross-Site Scripting, allowing authenticated editors to inject arbitrary HTML.

Failing to properly encode user input, several backend components are susceptible to Cross-Site Scripting, allowing authenticated editors to inject arbitrary HTML or JavaScript.

The ip package through 2.0.1 for Node.js might allow SSRF because some IP addresses (such as 127.1, 01200034567, 012.1.2.3, 000:0:0000::01, and ::fFFf:127.0.0.1) are improperly categorized as globally routable via isPublic. NOTE: this issue exists because of an incomplete fix for CVE-2023-42282.

### Impact Due to an improperly applied permission check in the `wagtail.contrib.settings` module, a user with access to the Wagtail admin and knowledge of the URL of the edit view for a settings model can access and update that setting, even when they have not been granted permission over the model. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin. ### Patches Patched versions have been released as Wagtail 6.0.5 and 6.1.2. Wagtail releases prior to 6.0 are unaffected. ### Workarounds No workaround is available. ### Acknowledgements Many thanks to Victor Miti for reporting this issue. ### For more information If you have any questions or comments about this advisory: * Visit Wagtail's [support channels](https://docs.wagtail.io/en/stable/support.html) * Email us at [[email protected]](mailto:[email protected]) (view our [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).

The Fides webserver has a number of endpoints that retrieve `ConnectionConfiguration` records and their associated `secrets` which _can_ contain sensitive data (e.g. passwords, private keys, etc.). These `secrets` are stored encrypted at rest (in the application database), and the associated endpoints are not meant to expose that sensitive data in plaintext to API clients, as it could be compromising. Fides's developers have available to them a Pydantic field-attribute (`sensitive`) that they can annotate as `True` to indicate that a given secret field should not be exposed via the API. The application has an internal function that uses `sensitive` annotations to mask the sensitive fields with a `"**********"` placeholder value. This vulnerability is due to a bug in that function, which prevented `sensitive` API model fields that were _nested_ below the root-level of a `secrets` object from being masked appropriately. Only the `BigQuery` connection configuration secrets meets these ...