Source
ghsa
A Cross-Site Request Forgery (CSRF) vulnerability has been identified in the application, which allows an attacker to obtain tokens and forge malicious requests on behalf of a user. This can lead to unauthorized actions being taken on the user's behalf, potentially compromising the security and integrity of the application. ## Vulnerability Details The vulnerability is caused by improper validation and enforcement of CSRF tokens within the application. The following issues were identified: 1. **Lack of Token Association**: The CSRF token was validated against tokens in storage but was not tied to the original requestor that generated it, allowing for token reuse. ### Specific Go Packages Affected github.com/gofiber/fiber/v2/middleware/csrf ## Remediation To remediate this vulnerability, it is recommended to take the following actions: 1. **Update the Application**: Upgrade the application to a fixed version with a patch for the vulnerability. 2. **Implement Proper CSRF Protecti...
A Cross-Site Request Forgery (CSRF) vulnerability has been identified in the application, which allows an attacker to inject arbitrary values and forge malicious requests on behalf of a user. This vulnerability can allow an attacker to inject arbitrary values without any authentication, or perform various malicious actions on behalf of an authenticated user, potentially compromising the security and integrity of the application. ## Vulnerability Details The vulnerability is caused by improper validation and enforcement of CSRF tokens within the application. The following issues were identified: 1. **Token Injection**: For 'safe' methods, the token was extracted from the cookie and saved to storage without further validation or sanitization. 2. **Lack of Token Association**: The CSRF token was validated against tokens in storage but not associated with a session, nor by using a Double Submit Cookie Method, allowing for token reuse. ### Specific Go Packages Affected github.com/gofib...
### Impact A vulnerability CVE-2023-39325 exists in [Go managing HTTP/2 requests](https://groups.google.com/g/golang-announce/c/iNNxDTCjZvo/m/UDd7VKQuAAAJ?pli=1), which impacts Traefik. This vulnerability could be exploited to cause a denial of service. ### References - [CVE-2023-44487](https://www.cve.org/CVERecord?id=CVE-2023-44487) - [CVE-2023-39325](https://www.cve.org/CVERecord?id=CVE-2023-39325) ### Patches - https://github.com/traefik/traefik/releases/tag/v2.10.5 - https://github.com/traefik/traefik/releases/tag/v3.0.0-beta4
### Impact It's possible for a user without any specific right to perform script injection and remote code execution just by inserting an appropriate title when creating a new Change Request. This vulnerability is particularly critical as Change Request aims at being created by user without any particular rights. ### Patches The vulnerability has been fixed in Change Request 1.9.2. ### Workarounds It's possible to workaround the issue without upgrading by editing the document `ChangeRequest.Code.ChangeRequestSheet` and by performing the same change as in the commit: https://github.com/xwiki-contrib/application-changerequest/commit/7565e720117f73102f5a276239eabfe85e15cff4. ### References * JIRA ticket: https://jira.xwiki.org/browse/CRAPP-298 * Commit of the fix: https://github.com/xwiki-contrib/application-changerequest/commit/7565e720117f73102f5a276239eabfe85e15cff4 ### For more information If you have any questions or comments about this advisory: * Open an issue in [J...
When a collaboration is deleted in vantage6, the linked resources (such as tasks from that collaboration) are not properly deleted. This is partly to manage data properly, but also to prevent a potential (but unlikely) side-effect, where if a collaboration with id=10 is deleted, and subsequently a new collaboration is created with id=10, the authenticated users in that collaboration could potentially see results of the deleted collaboration in some cases, resulting in information disclosure.
### Summary A template functionality which allows users to create templates allows them to execute any code on the server during the bad filtration and old twig version. Within `/cachet/app/Http/Routes/ApiRoutes.php`, and attacker could control `template` input which is passed to `laravel's` dispatched handler `/cachet/app/Bus/Handlers/Commands/Incident/CreateIncidentCommandHandler.php`. If an attacker is able to control this data, they may be able to trigger a server-side template injection vulnerability which can lead to remote code execution. This vulnerability does not exist within the [Twig](https://twig.symfony.com/) library itself, but exists during the process of the [Cachet](https://github.com/cachethq/cachet) processing of the data without any filtration. This has been patched in Cachet version 2.4. ### PoC 1. Log in as a default user (non-admin); 2. Create an incident with name `slug1` and with content: `{{ ['curl yourhost.com','']|sort('system') }}` or with any other ...
### Impact Undici clears Authorization headers on cross-origin redirects, but does not clear `Cookie` headers. By design, `cookie` headers are [forbidden request headers](https://fetch.spec.whatwg.org/#forbidden-request-header), disallowing them to be set in `RequestInit.headers` in browser environments. Since Undici handles headers more liberally than the specification, there was a disconnect from the assumptions the spec made, and Undici's implementation of fetch. As such this may lead to accidental leakage of cookie to a 3rd-party site or a malicious attacker who can control the redirection target (ie. an open redirector) to leak the cookie to the 3rd party site. ### Patches This was patched in [e041de359221ebeae04c469e8aff4145764e6d76](https://github.com/nodejs/undici/commit/e041de359221ebeae04c469e8aff4145764e6d76), which is included in version 5.26.2.
### Summary OpenTelemetry-Go Contrib has a [handler wrapper `otelhttp`](https://github.com/open-telemetry/opentelemetry-go-contrib/blob/5f7e6ad5a49b45df45f61a1deb29d7f1158032df/instrumentation/net/http/otelhttp/handler.go#L63-L65) that adds the following labels by deafult that have unbound cardinality: - `http.user_agent` - `http.method` This leads to the server's potential memory exhaustion when many malicious requests are sent to it. ### Details HTTP header User-Agent or HTTP method for requests can be easily set by an attacker to be random and long. The library internally uses [httpconv.ServerRequest](https://github.com/open-telemetry/opentelemetry-go/blob/v1.12.0/semconv/internal/v2/http.go#L159) that records every value for HTTP [method](https://github.com/open-telemetry/opentelemetry-go/blob/38e1b499c3da3107694ad2660b3888eee9c8b896/semconv/internal/v2/http.go#L204) and [User-Agent](https://github.com/open-telemetry/opentelemetry-go/blob/38e1b499c3da3107694ad2660b3888eee9c8b8...
### Impact Using Babel to compile code that was specifically crafted by an attacker can lead to arbitrary code execution during compilation, when using plugins that rely on the `path.evaluate()`or `path.evaluateTruthy()` internal Babel methods. Known affected plugins are: - `@babel/plugin-transform-runtime` - `@babel/preset-env` when using its [`useBuiltIns`](https://babeljs.io/docs/babel-preset-env#usebuiltins) option - Any "polyfill provider" plugin that depends on `@babel/helper-define-polyfill-provider`, such as `babel-plugin-polyfill-corejs3`, `babel-plugin-polyfill-corejs2`, `babel-plugin-polyfill-es-shims`, `babel-plugin-polyfill-regenerator` No other plugins under the `@babel/` namespace are impacted, but third-party plugins might be. **Users that only compile trusted code are not impacted.** ### Patches The vulnerability has been fixed in `@babel/traverse@7.23.2`. Babel 6 does not receive security fixes anymore (see [Babel's security policy](https://github.com/babel/bab...
Grafana is an open-source platform for monitoring and observability. The vulnerability impacts instances with several organizations, and allows a user with Organization Admin permissions in one organization to change the permissions associated with Organization Viewer, Organization Editor and Organization Admin roles in all organizations. It also allows an Organization Admin to assign or revoke any permissions that they have to any user globally. This means that any Organization Admin can elevate their own permissions in any organization that they are already a member of, or elevate or restrict the permissions of any other user. The vulnerability does not allow a user to become a member of an organization that they are not already a member of, or to add any other users to an organization that the current user is not a member of.