ghsa

### Impact This vulnerability can be categorized as a security misconfiguration. It impacts users of our project who rely on the [ctx.IsFromLocal()](https://docs.gofiber.io/api/ctx#isfromlocal) method to restrict access to localhost requests. If exploited, it could allow unauthorized access to resources intended only for localhost. In it's implementation it uses c.IPs(): ```go // IPs returns a string slice of IP addresses specified in the X-Forwarded-For request header. // When IP validation is enabled, only valid IPs are returned. func (c *Ctx) IPs() []string { return c.extractIPsFromHeader(HeaderXForwardedFor) } ``` Thereby, setting `X-Forwarded-For: 127.0.0.1` in a request from a foreign host, will result in true for [ctx.IsFromLocal()](https://docs.gofiber.io/api/ctx#isfromlocal) ### Patches This issue has been patched in `v2.49.2` with commit [b8c9ede6efa231116c4bd8bb9d5e03eac1cb76dc](https://github.com/gofiber/fiber/commit/b8c9ede6efa231116c4bd8bb9d5e03eac1cb76dc) ### W...

### Impact A malicious user can upload an SVG image containing JavaScript to their server. When matrix-media-repo is asked to serve that media via the `/_matrix/media/(r0|v3)/download` endpoint, it would be served with a `Content-Disposition` of `inline`. This can allow JavaScript to run in the browser if a client links to the `/download` endpoint directly. Server operators which do not share a domain between matrix-media-repo and other services are not affected, but are encouraged to upgrade regardless. ### Patches https://github.com/turt2live/matrix-media-repo/commit/77ec2354e8f46d5ef149d1dcaf25f51c04149137 and https://github.com/turt2live/matrix-media-repo/commit/bf8abdd7a5371118e280c65a8e0ec2b2e9bdaf59 fix the issue. Operators should upgrade to v1.3.0 as soon as possible. ### Workarounds The `Content-Disposition` header can be overridden by the reverse proxy in front of matrix-media-repo to always use `attachment`, defeating this issue at the cost of "worse" user experience when...

### Impact The proxy mode of WireMock, can be protected by the network restrictions configuration, as documented in [Preventing proxying to and recording from specific target addresses](https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses). These restrictions can be configured using the domain names, and in such a case the configuration is vulnerable to the DNS rebinding attacks. A similar patch was applied in WireMock 3.0.0-beta-15 for the WireMock Webhook Extensions. The root cause of the attack is a defect in the logic which allows for a race condition triggered by a DNS server whose address expires in between the initial validation and the outbound network request that might go to a domain that was supposed to be prohibited. Control over a DNS service is required to exploit this attack, so it has high execution complexity and limited impact. ### Affected versions - WireMock 3,x until 3.0.3 (security patch), on default sett...

## Issue On March 17th the vulnerability [CVE-2023-28115 was disclosed](https://github.com/KnpLabs/snappy/security/advisories/GHSA-gq6w-q6wh-jggc), allowing an attacker to gain remote code execution through PHAR deserialization. To fix this issue, the version 1.4.2 was released with an additional check in the affected function to prevent the usage of the `phar://` wrapper. However, because PHP wrappers are case-insensitive and the patch only checks the presence of the `phar://` string, it can be bypassed to achieve remote code execution again using a different case. As for the initial vulnerability, PHP 7 or below is required for a successful exploitation using the deserialization of PHP archives metadata via the `phar://` wrapper. ## Technical details ### Description The following [patch](https://github.com/KnpLabs/snappy/commit/1ee6360cbdbea5d09705909a150df7963a88efd6) was committed on the 1.4.2 release to fix CVE-2023-28115. ![patch](https://user-images.githubusercontent.com/1...

### Impact The Fides webserver API allows custom integrations to be uploaded as a ZIP file. This ZIP file must contain YAML files, but Fides can be configured to also accept the inclusion of custom Python code in it. The custom code is executed in a restricted, sandboxed environment, but the sandbox can be bypassed to execute any arbitrary code. The vulnerability allows the execution of arbitrary code on the target system within the context of the webserver python process owner on the webserver container, which by default is `root`, and leverage that access to attack underlying infrastructure and integrated systems. This vulnerability affects Fides versions `2.11.0` through `2.18.0`. Exploitation is limited to API clients with the `CONNECTOR_TEMPLATE_REGISTER` authorization scope. In the Fides Admin UI this scope is restricted to highly privileged users, specifically root users and users with the owner role. Exploitation is only possible if the security configuration parameter `al...

### Impact For Windows users of `github.com/cyphar/filepath-securejoin`, until v0.2.4 it was possible for certain rootfs and path combinations (in particular, where a malicious Unix-style `/`-separated unsafe path was used with a Windows-style rootfs path) to result in generated paths that were outside of the provided rootfs. It is unclear to what extent this has a practical impact on real users, but given the possible severity of the issue we have released an emergency patch release that resolves this issue. Thanks to @pjbgf for discovering, debugging, and fixing this issue (as well as writing some tests for it). ### Patches c121231e1276e11049547bee5ce68d5a2cfe2d9b is the patch fixing this issue. v0.2.4 contains the fix. ### Workarounds Users could use `filepath.FromSlash()` on all unsafe paths before passing them to `filepath-securejoin`. ### References See #9.

### Impact This is a Denial-of-Service (DoS) type vulnerability which causes the Router to panic and terminate when GraphQL Subscriptions are enabled. It can be triggered when **all of the following conditions are met**: 1. Running Apollo Router v1.28.0, v1.28.1 or v1.29.0 ("impacted versions"); **and** 2. The Supergraph schema provided to the Router (either via Apollo Uplink or explicitly via other configuration) **has a `subscription` type** with root-fields defined; **and** 3. The YAML configuration provided to the Router **has subscriptions enabled** (they are _disabled_ by default), either by setting `enabled: true` _or_ by setting a valid `mode` within the `subscriptions` object (as seen in [subscriptions' documentation](https://www.apollographql.com/docs/router/executing-operations/subscription-support/#router-setup)); **and** 4. An [anonymous](https://spec.graphql.org/draft/#sec-Anonymous-Operation-Definitions) (i.e., un-named) `subscription` operation (e.g., `subscription {...

### Impact Python's "format" functionality allows someone controlling the format string to "read" objects accessible (recursively) via attribute access and subscription from accessible objects. Those attribute accesses and subscriptions use Python's full blown `getattr` and `getitem`, not the policy restricted `AccessControl` variants `_getattr_` and `_getitem_`. This can lead to critical information disclosure. `AccessControl` already provides a safe variant for `str.format` and denies access to `string.Formatter`. However, `str.format_map` is still unsafe. Affected are all users who allow untrusted users to create `AccessControl` controlled Python code and execute it. ### Patches A fix will be introduced in the versions 4.4, 5.8 and 6.2. ### Workarounds There are no workarounds. ### References https://github.com/zopefoundation/RestrictedPython/security/advisories/GHSA-xjw2-6jm9-rf67 describes the corresponding problem for `RestrictedPython`.

Missing Authentication for Critical Function in GitHub repository answerdev/answer prior to v1.1.3.

### Impact WireMock can be configured to only permit proxying (and therefore recording) to certain addresses. This is achieved via a list of allowed address rules and a list of denied address rules, where the allowed list is evaluated first. [Documentation](https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses). Until WireMock Webhooks Extension [3.0.0-beta-15](https://github.com/wiremock/wiremock/releases/tag/3.0.0-beta-15), the filtering of target addresses from the proxy mode DID NOT work for Webhooks, so the users were potentially vulnerable regardless of the `limitProxyTargets` settings. Via the WireMock webhooks configuration, POST requests from a webhook might be forwarded to an arbitrary service reachable from WireMock’s instance. For example, If someone is running the WireMock docker Container inside a private cluster, they can trigger internal POST requests against unsecured APIs or even against secure ones by passin...