Source
ghsa
### Summary This advisory addresses a security vulnerability in Mautic where unpublished page previews could be accessed by unauthenticated users and potentially indexed by search engines. This could lead to the unintended disclosure of draft content or sensitive information. Unauthorized Access to Unpublished Page Previews: The page preview functionality for unpublished content, accessible via predictable URLs (e.g., `/page/preview/1`, `/page/preview/2`), lacked proper authorization checks. This allowed any unauthenticated user to view content that was not yet intended for public release, and allowed search engines to index these private preview URLs, making the content publicly discoverable. ### Mitigation Mautic has patched this vulnerability by enforcing proper permission checks on preview pages. Users should upgrade to the patched version of Mautic or later.
### Impact A potential vulnerability exists in ZITADEL's password reset mechanism. ZITADEL utilizes the Forwarded or X-Forwarded-Host header from incoming requests to construct the URL for the password reset confirmation link. This link, containing a secret code, is then emailed to the user. If an attacker can manipulate these headers (e.g., via host header injection), they could cause ZITADEL to generate a password reset link pointing to a malicious domain controlled by the attacker. If the user clicks this manipulated link in the email, the secret reset code embedded in the URL can be captured by the attacker. This captured code could then be used to reset the user's password and gain unauthorized access to their account. It's important to note that this specific attack vector is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled. ### Patches Patched version ensure proper validation of the headers and do not allow downgradin...
### Impact This vulnerability allows an attacker to perform arbitrary actions on behalf of the victim via the API, such as creating, modifying, and deleting Kubernetes resources. Due to the improper filtering of URL protocols in the repository page, an attacker can achieve cross-site scripting with permission to edit the repository. In `ui/src/app/shared/components/urls.ts`, the following code exists to parse the repository URL. https://github.com/argoproj/argo-cd/blob/0ae5882d5ae9fe88efc51f65ca8543fb8c3a0aa1/ui/src/app/shared/components/urls.ts#L14-L26 Since this code doesn't validate the protocol of repository URLs, it's possible to inject `javascript:` URLs here. https://github.com/argoproj/argo-cd/blob/0ae5882d5ae9fe88efc51f65ca8543fb8c3a0aa1/ui/src/app/shared/components/repo.tsx#L5-L7 As the return value of this function is used in the `href` attribute of the `a` tag, it's possible to achieve cross-site scripting by using `javascript:` URLs. Browsers may return the proper ho...
### Impact CSS Selector expressions are not properly encoded, which can lead to XSS (cross-site scripting) vulnerabilities. ### Patches This is patched in v1.14.0. ### Workarounds Users can apply encoding manually to their selectors, if they are unable to upgrade.
Improper Access Control vulnerability in Apache Commons. A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). Starting in ve...
### Summary [Amazon Redshift Python Connector](https://docs.aws.amazon.com/redshift/latest/mgmt/python-redshift-driver.html) is a pure Python connector to Redshift (i.e., driver) that implements the [Python Database API Specification 2.0](https://www.python.org/dev/peps/pep-0249/). When the Amazon Redshift Python Connector is configured with the BrowserAzureOAuth2CredentialsProvider plugin, the driver skips the SSL certificate validation step for the Identity Provider. ### Impact An insecure connection could allow an actor to intercept the token exchange process and retrieve an access token. **Impacted versions:** >=2.0.872;<=2.1.6 ### Patches Upgrade Amazon Redshift Python Connector to version 2.1.7 and ensure any forked or derivative code is patched to incorporate the new fixes. ### Workarounds None ### References If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via em...
### Summary Using `Issue_comment` on `.github/workflows/scalafmt-fix.yml` an attacker can inject malicious code using `github.event.comment.body`. By exploiting the vulnerability, it is possible to exfiltrate high privileged `GITHUB_TOKEN` which can be used to completely overtake the repo since the token has content privileges. In addition ,it is possible to exfiltrate also the secret: - `BROADBOT_GITHUB_TOKEN ` ### Details The `Issue_comment` in GitHub Actions might be an injection path if the variable isn't handle as it should. In the following step it's vulnerable because it directly interpolates untrusted user input into a shell script. ``` - name: Check for ScalaFmt Comment id: check-comment run: | if [[ "${{ github.event_name }}" == "issue_comment" && "${{ github.event.comment.body }}" == *"scalafmt"* ]]; then echo "::set-output name=comment-triggered::true" else echo "::set-output name=comment-triggered::false" ...
### Impact When the Contrast initializer is configured with a `CONTRAST_LOG_LEVEL` of `info` or `debug`, the workload secret is logged to `stderr` and written to Kubernetes logs. Since `info` is the default setting, this affects all Contrast installations that don't customize their initializers' log level. The following audiences are **intended** to have access to workload secrets (see https://docs.edgeless.systems/contrast/1.7/architecture/secrets#workload-secrets): * Contrast Coordinator (can derive all workload secrets) * Contrast Initializer (obtains only the secret configured in the manifest) * Seedshare owner (can derive all workload secrets) * Workload owner (can update manifests to obtain secrets) This vulnerability allows the following parties **unintended access** to workload secrets issued by a Coordinator: * Kubernetes users with `get` or `list` permission on `pods/logs`. * Others with read access to the Kubernetes log storage (most notably, the cloud provider). Thi...
### Impact All objects for which an object-management configuration exists can be listed, viewed, edited, created or deleted by unauthorised users. If object-urls are exposed via other channels, the contents of these objects can be viewed independent of object-management configurations. ### Attack requirements The following conditions have to be met in order to perform this attack: - A user must be logged in - No relevant application roles are required - At least one object-type must be configured via object-management - The scope of the attack is limited to objects that are configured via object-management. - The value of `showInDataMenu` is irrelevant for this attack ### Patches No patch is available yet ### Workarounds It is possible to override the endpoint security as defined in `ObjectenApiHttpSecurityConfigurer` and `ObjectManagementHttpSecurityConfigurer`. Depending on the implementation, this could result in loss of functionality.
## Impact There is a potential vulnerability in Traefik managing the requests using a `PathPrefix`, `Path` or `PathRegex` matcher. When Traefik is configured to route the requests to a backend using a matcher based on the path, if the URL contains a URL encoded string in its path, it’s possible to target a backend, exposed using another router, by-passing the middlewares chain. ## Example ```yaml apiVersion: traefik.io/v1alpha1 kind: IngressRoute metadata: name: my-service spec: routes: - match: PathPrefix(‘/service’) kind: Rule services: - name: service-a port: 8080 middlewares: - name: my-middleware-a - match: PathPrefix(‘/service/sub-path’) kind: Rule services: - name: service-a port: 8080 ``` In such a case, the request `http://mydomain.example.com/service/sub-path/%2e%2e/other-path` will reach the backend `my-service-a` without operating the middleware `my-middleware-a` unless the computed p...