ghsa

### Impact Sentry's Slack integration incorrectly records the incoming request body in logs. This request data can contain sensitive information, including the [deprecated Slack verification token](https://api.slack.com/authentication/verifying-requests-from-slack#deprecation). With this verification token, it is possible under specific configurations, an attacker can forge requests and act as the Slack integration. The request body is leaked in log entries matching `event == "slack.*" && name == "sentry.integrations.slack" && request_data == *`. The deprecated slack verification token, will be found in the `request_data.token` key. Example event: ```json { "name": "sentry.integrations.slack", "level": "info", "event": "slack.event.message", # This could be any of the `slack.*` events "request_data": { # Other keys are omitted for brevity "token": "<MyDeprecatedSlackVerificationToken>", } } ``` ### Patches - **SaaS users** do not need to take any a...

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

During the internal penetration testing of our product based on Yii2, we discovered an XSS vulnerability within the framework itself. This issue is relevant for the latest version of Yii2 (2.0.49.3). ### Conditions for vulnerability reproduction * The framework is in debug mode (YII_DEBUG set to true). * The php.ini setting zend.exception_ignore_args is set to Off (default value). * An attacker induces an exception in the application, leading to a stack trace page being displayed. ### Vulnerability description The issue lies in the mechanism for displaying function argument values in the stack trace. The vulnerability manifests when an argument's value exceeds 32 characters. For convenience, argument values exceeding this limit are truncated and displayed with an added "...". The full argument value becomes visible when hovering over it with the mouse, as it is displayed in the title attribute of a span tag. However, the use of a double quote (") allows an attacker to break out of ...

In a shared hosting environment that has been misconfigured to allow access to other users' content, a Moodle user with both access to restore workshop modules and direct access to the web server outside of the Moodle webroot could execute a local file include.

In a shared hosting environment that has been misconfigured to allow access to other users' content, a Moodle user with both access to restore wiki modules and direct access to the web server outside of the Moodle webroot could execute a local file include.

In a shared hosting environment that has been misconfigured to allow access to other users' content, a Moodle user with both access to restore feedback modules and direct access to the web server outside of the Moodle webroot could execute a local file include.

In a shared hosting environment that has been misconfigured to allow access to other users' content, a Moodle user with both access to restore database activity modules and direct access to the web server outside of the Moodle webroot could execute a local file include.

Actions in the admin management of analytics models did not include the necessary token to prevent a CSRF risk.

Actions in the admin preset tool did not include the necessary token to prevent a CSRF risk.

Unsafe direct use of $_SERVER['HTTP_REFERER'] in admin/tool/mfa/index.php. The referrer URL used by MFA required additional sanitizing, rather than being used directly.