ghsa

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

**Component**: Cosmovisor **Criticality**: Medium **Affected Versions**: Cosmovisor < v1.0.0 (distributed with Cosmos-SDK < 0.46) **Affected Users**: Validators and Node operators utilizing unsupported versions of Cosmovisor **Impact**: DOS, potential RCE on node depending on configuration An issue has been identified on unsupported versions of Cosmovisor which may result in a Denial of Service or Remote Code Execution path depending on configuration for a node or validator using the vulnerable version to manage their node. If a validator is utilizing an affected version of Cosmovisor with `DAEMON_ALLOW_DOWNLOAD_BINARIES` set to true, a non-default configuration, it may be possible for an attacker to trigger a Remote Code Execution path as well on the host. In this configuration it is recommended to immediately stop use of the `DAEMON_ALLOW_DOWNLOAD_BINARIES` feature, and then proceed with an upgrade of Cosmovisor. It is recommended that all validators utilizing unsupported versio...

### Impact Apps that are launched as command line executables are impacted. E.g. if your app exposes itself in the path as `myapp --help` Specifically this issue can only be exploited if the following conditions are met: * Your app is launched with an attacker-controlled working directory * The attacker has the ability to write files to that working directory This makes the risk quite low, in fact normally issues of this kind are considered outside of our threat model as similar to Chromium we exclude [Physically Local Attacks](https://github.com/electron/electron/security/advisories/GHSA-7x97-j373-85x5#:~:text=Physically%20Local%20Attacks) but given the ability for this issue to bypass certain protections like ASAR Integrity it is being treated with higher importance. Please bear this in mind when reporting similar issues in the future. ### Workarounds There are no app side workarounds, you must update to a patched version of Electron. ### Fixed Versions * `26.0.0-beta.13` * `25...

### Impact Apps using `contextIsolation` and `contextBridge` are affected. This is a context isolation bypass, meaning that code running in the main world context in the renderer can reach into the isolated Electron context and perform privileged actions. ### Workarounds This issue is exploitable under either of two conditions: * If an API exposed to the main world via `contextBridge` can return an object or array that contains a JS object which cannot be serialized, for instance, a canvas rendering context. This would normally result in an exception being thrown `Error: object could not be cloned`. * If an API exposed to the main world via `contextBridge` has a return value that throws a user-generated exception while being sent over the bridge, for instance a dynamic getter property on an object that throws an error when being computed. The app side workaround is to ensure that such a case is not possible. Ensure all values returned from a function exposed over the context bridge ...

### Impact A vulnerable node, can be made to consume unbounded amounts of memory when handling specially crafted p2p messages sent from an attacker node. Details about this bug will be released within 4-8 weeks, as per our official [vulnerability disclosure policy](https://geth.ethereum.org/docs/developers/geth-developer/disclosures). ### Patches The fix is included in geth version `1.12.1-stable`, i.e, `1.12.2-unstable` and onwards. ### Workarounds No known workarounds. ### Credits This bug was reported by Patrick McHardy and reported via [bounty@ethereum.org](mailto:bounty@ethereum.org). ### References

### Impact All users on Windows are impacted. MinIO fails to filter the `\` character, which allows for arbitrary object placement across buckets. As a result, a user with low privileges, such as an access key, service account, or STS credential, which only has permission to `PutObject` in a specific bucket, can create an admin user. ### Patches There are two patches that fix this problem comprehensively ``` commit b3c54ec81e0a06392abfb3a1ffcdc80c6fbf6ebc Author: Harshavardhana <harsha@minio.io> Date: Mon Mar 20 13:16:00 2023 -0700 reject object names with '\' on windows (#16856) ``` ``` commit 8d6558b23649f613414c8527b58973fbdfa4d1b8 Author: Harshavardhana <harsha@minio.io> Date: Mon Mar 20 00:35:25 2023 -0700 fix: convert '\' to '/' on windows (#16852) ``` ### Workarounds There are no known workarounds ### References The vulnerable code: ```go // minio/cmd/generic-handlers.go // Check if the incoming path has bad path components, // such as ".." and "." // SlashSep...

### Impact A Content-Security-Policy that disables eval, specifically setting a `script-src` directive and _not_ providing `unsafe-eval` in that directive, is not respected in renderers that have sandbox and contextIsolation disabled. i.e. `sandbox: false` and `contextIsolation: false` in the `webPreferences` object. This resulted in incorrectly allowing usage of methods like `eval()` and `new Function`, which can result in an expanded attack surface. ### Patches This issue only ever affected the 22 and 23 major versions of Electron and has been fixed in the latest versions of those release lines. Specifically, these versions contain the fixes: - 22.0.1 - 23.0.0-alpha.2 We recommend all apps upgrade to the latest stable version of Electron, especially if they use `sandbox: false` or `contextIsolation: false`. ### Workarounds If upgrading isn't possible, this issue can be addressed without upgrading by enabling at least one of `sandbox: true` or `contextIsolation: true` on all ren...

An Incorrect authorisation check in SQLLab in Apache Superset versions up to and including 2.1.0. This vulnerability allows an authenticated user to query tables that they do not have proper access to within Superset. The vulnerability can be exploited by leveraging a SQL parsing vulnerability.