Source
ghsa
### Impact **This issue only applies to applications starting authorization sessions using an explicit initial `nonce`.** When [`Context::start_auth_session`](https://docs.rs/tss-esapi/7.0.1/tss_esapi/struct.Context.html#method.start_auth_session) was called with a `nonce` argument value of `Some(...)`, the nonce pointer passed down through FFI to `Esys_StartAuthSession` would be a dangling pointer, left over from a defunct instance of `TPM2B_NONCE`. This could lead to an incorrect value being used as a nonce, though whether that value is controllable is unclear (so should be assumed as possible). The error became apparent due to changes in v1.61.0 of the Rust compiler. Logs indicating a failure due to this issue (with the 1.61.0 version of the Rust toolchain) look as follows: ``` 2022-05-24T01:04:41.9131341Z WARNING:esys:src/tss2-esys/api/Esys_StartAuthSession.c:390:Esys_StartAuthSession_Finish() Received TPM Error 2022-05-24T01:04:41.9132192Z ERROR:esys:src/tss2-esys/api/Esys_Sta...
### Impact Datasets exported to file (e.g. CSV / XLS) are not sufficiently sanitized, to neutralize potential formula injection ### Patches - The issue is addressed in the upcoming 0.8.0 release - This fix will also be back-ported to the 0.7.x branch, applied to the 0.7.2 release ### Workarounds Users exporting untrusted data should open the files in safe mode (e.g. in Microsoft Excel). ### References - https://huntr.dev/bounties/e57c36e7-fa39-435f-944a-3a52ee066f73/ - https://owasp.org/www-community/attacks/CSV_Injection ### For more information If you have any questions or comments about this advisory: * Open an issue in [github](http://github.com/inventree/inventree) * Email us at [[email protected]](mailto:[email protected])
### Impact InvenTree allows unrestricted upload of files as attachments to various database fields. Potentially dangerous files (such as HTML files containing malicious javascript) can be uploaded, and (when opened by the user) run the malicious code directly in the users browser.  *Note that the upload of malicious files must be performed by an authenticated user account* ### Solution The solution for this vulnerability is to ensure that attachment files are downloaded to the local machine before opening, rather than opening the file in the current browser context. ### Patches - The issue is addressed in the upcoming 0.8.0 release - This fix will also be back-ported to the 0.7.x branch, applied to the 0.7.2 release ### Workarounds Users can alleviate risk of opening malicious files by right-clicking on the attachment link and selecting "Save link as"  in an upstream library means an authenticated attacker can abuse locale input to execute arbitrary commands from a file that has previously been uploaded using the file upload functionality in the post editor. ### Patches Fixed in 5.2.3, all 5.x sites should update as soon as possible. Fixed in 4.48.2, all 4.x sites should update as soon as possible. ### Workarounds Patched versions of Ghost add validation to the locale input to prevent execution of arbitrary files. Updating Ghost is the quickest complete solution. As a workaround, if for any reason you cannot update your Ghost instance, you can block the `POST /ghost/api/admin/settings/` endpoint, which will also disable updating settings for your site. ### For more information If you have any questions or comments about this advisory: * Email us at [[email protected]](mailto:[email protected]) ### Credits * devx00 - https://twitter.com/devx00
### Impact The /api/v2/config endpoint exposes message bus credentials to local unauthenticated users. In security-enabled mode, message bus credentials are supposed to be kept in the EdgeX secret store and require authentication to access. This vulnerability bypasses the access controls on message bus credentials when running in security-enabled mode. (No credentials are required when running in security-disabled mode.) As a result, attackers could intercept data or inject fake data into the EdgeX message bus. ### Patches Users should upgrade to EdgeXFoundry Kamakura release (2.2.0) or to the June 2022 EdgeXFoundry LTS Jakarta release (2.1.1). The issue has been patched in the following docker containers and snaps: #### Patched go modules github.com/edgexfoundry/device-sdk-go/v2 >= v2.1.1 github.com/edgexfoundry/app-functions-sdk-go/v2 >= v2.1.1 #### Patched docker containers URL: https://hub.docker.com/r/edgexfoundry - docker.io/edgexfoundry/core-metadata:>=2.1.1 - docker.io/...
### Impact A malicious actor with the ability to register entities in the Software Catalog is able to write files to arbitrary paths on the techdocs backend host instance when `techdocs.publisher.type` is set to `local`. This vulnerability is mitigated by the fact that the Software Catalog must be configured with non-standard field format validators and/or non-standard entity policies. ### Patches Those affected are advised to upgrade to `@backstage/plugin-techdocs-node` version `1.1.2` or higher. ### Workarounds If patching or upgrading is not possible, it would be sufficient to update any custom Catalog field format validators and/or custom entity policies to disallow entity names, kinds, and namespaces containing `..` <!-- ### References todo: Link to blog post / published report. --> ### For more information If you have any questions or comments about this advisory: - Open an issue in the [Backstage repository](https://github.com/backstage/backstage) - Visit our chat, linked ...
### Impact A path traversal issue was found in the (g *GitArtifactReader).Read() API. Read() calls into (g *GitArtifactReader).readFromRepository() that opens and reads the file that contains the trigger resource definition: ```go func (g *GitArtifactReader) readFromRepository(r *git.Repository, dir string) ``` No checks are made on this file at read time, which could lead an attacker to read files anywhere on the system. This could be achieved by either using symbolic links, or putting `../` in the path. ### Patches A patch for this vulnerability has been released in the following Argo Events version: v1.7.1 ### Credits Disclosed by [Ada Logics](https://adalogics.com/) in a security audit sponsored by CNCF and facilitated by OSTIF. ### For more information Open an issue in the [Argo Events issue tracker](https://github.com/argoproj/argo-events/issues) or [discussions](https://github.com/argoproj/argo-events/discussions) Join us on [Slack](https://argoproj.github.io/community/joi...
### Impact Several `HandleRoute` endpoints make use of the deprecated `ioutil.ReadAll()`. `ioutil.ReadAll()` reads all the data into memory. As such, an attacker who sends a large request to the Argo Events server will be able to crash it and cause denial of service. Eventsources susceptible to an out-of-memory denial-of-service attack: - AWS SNS - Bitbucket - Bitbucket - Gitlab - Slack - Storagegrid - Webhook ### Patches A patch for this vulnerability has been released in the following Argo Events version: v1.7.1 ### Credits Disclosed by [Ada Logics](https://adalogics.com/) in a security audit sponsored by CNCF and facilitated by OSTIF. ### For more information Open an issue in the [Argo Events issue tracker](https://github.com/argoproj/argo-events/issues) or [discussions](https://github.com/argoproj/argo-events/discussions) Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-events
### Description `Undici.ProxyAgent` never verifies the remote server's certificate, and always exposes all request & response data to the proxy. This unexpectedly means that proxies can MitM all HTTPS traffic, and if the proxy's URL is HTTP then it also means that nominally HTTPS requests are actually sent via plain-text HTTP between Undici and the proxy server. ### Impact This affects all use of HTTPS via HTTP proxy using **`Undici.ProxyAgent`** with Undici or Node's global `fetch`. In this case, it removes all HTTPS security from all requests sent using Undici's `ProxyAgent`, allowing trivial MitM attacks by anybody on the network path between the client and the target server (local network users, your ISP, the proxy, the target server's ISP, etc). This less seriously affects HTTPS via HTTPS proxies. When you send HTTPS via a proxy to a remote server, the proxy can freely view or modify all HTTPS traffic unexpectedly (but only the proxy). Example: ```js setGlobalDispatcher(new...