ghsa

Jenkins Git Parameter Plugin implements a choice build parameter that lists the configured Git SCM’s branches, tags, pull requests, and revisions. Git Parameter Plugin 439.vb_0e46ca_14534 and earlier does not validate that the Git parameter value submitted to the build matches one of the offered choices. This allows attackers with Item/Build permission to inject arbitrary values into Git parameters. Git Parameter Plugin 444.vca_b_84d3703c2 validates that the Git parameter value submitted to the build matches one of the offered choices.

Jenkins Statistics Gatherer Plugin 2.0.3 and earlier stores the AWS Secret Key unencrypted in its global configuration file `org.jenkins.plugins.statistics.gatherer.StatisticsConfiguration.xml` on the Jenkins controller as part of its configuration. This key can be viewed by users with access to the Jenkins controller file system. Additionally, the global configuration form does not mask this key, increasing the potential for attackers to observe and capture it. As of publication of this advisory, there is no fix.

Jenkins HTML Publisher Plugin 425 and earlier displays log messages that include the absolute paths of files archived during the Publish HTML reports post-build step, exposing information about the Jenkins controller file system in the build log. HTML Publisher Plugin 427 displays only the parent directory name of files archived during the Publish HTML reports post-build step in its log messages.

Jenkins Aqua Security Scanner Plugin 3.2.8 and earlier stores Scanner Tokens for Aqua API unencrypted in job config.xml files on the Jenkins controller as part of its configuration. These tokens can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system. As of publication of this advisory, there is no fix.

Jenkins Credentials Binding Plugin 687.v619cb_15e923f and earlier does not properly mask (i.e., replace with asterisks) credentials present in exception error messages that are written to the build log. Credentials Binding Plugin 687.689.v1a_f775332fc9 rethrows exceptions that contain credentials, masking those credentials in the error messages.

### Summary Possibility to craft a request that will crash the Qwik Server in the default configuration. ### Details When a Qwik Server Action QRL is executed it dynamically load the file containing the symbol. When an invalid qfunc is sent, the server does not handle the thrown error. The error then causes Node JS to exit. ### PoC 1. Setup a Qwik Project `pnpm create qwik@latest` 2. Start the Qwik Server using `pnpm run preview` 3. Execute the following curl command to crash the instance ```bash curl --location 'http://localhost:4173/?qfunc=PPXYallGsCE' \ --header 'Content-Type: application/qwik-json' \ --header 'X-Qrl: PPXYallGsCE' \ --data '{"_entry":"2","_objs":["\u0002_#s_PPXYallGsCE",1,["0","1"]]}' ``` Here the `qfunc` query parameter, `X-Qrl` header and payload need to have the same qrl. The Qwik Server will then crash with the message ``` qrl s_PPXYallGsCE failed to load Error: Dynamic require of "_.js" is not supported at file:///home/michele/Code/qwik/server/en...

### Impact Applications that use the `verifyWebhook()` helper to verify incoming Clerk webhooks are susceptible to accepting improperly signed webhook events. ### Patches * `@clerk/backend`: the helper has been patched as of `2.4.0` * `@clerk/astro`: the helper has been patched as of `2.10.2` * `@clerk/express`: the helper has been patched as of `1.7.4` * `@clerk/fastify`: the helper has been patched as of `2.4.4` * `@clerk/nextjs`: the helper has been patched as of `6.23.3` * `@clerk/nuxt`: the helper has been patched as of `1.7.5` * `@clerk/react-router`: the helper has been patched as of `1.6.4` * `@clerk/remix`: the helper has been patched as of `4.8.5` * `@clerk/tanstack-react-start`: the helper has been patched as of `0.18.3` ### Resolution The issue was resolved in **`@clerk/backend` `2.4.0`** by: * Properly parsing the webhook request's signatures and comparing them against the signature generated from the received event ### Workarounds If unable to upgrade, developers ...

### Background The [`VOLUME`](https://docs.docker.com/reference/dockerfile/#volume) directive in Dockerfiles, or the [`config.volumes`](https://github.com/opencontainers/image-spec/blob/06e6b47e2ef69021d9f9bf2cfa5fe43a7e010c81/config.md?plain=1#L168-L170) field in OCI image descriptors, indicates filesystem paths "where the process is likely to write data". While these paths have special semantics in Docker, they are only hints in the OCI spec and are not treated specially by Kubernetes. However, containered implements the [specified conversion logic](https://github.com/opencontainers/image-spec/blob/06e6b47e2ef69021d9f9bf2cfa5fe43a7e010c81/conversion.md?plain=1#L100-L105) and adds a mount point if there is none set by Kubernetes. Unfortunately, the specification leaves it open whether the mount point is populated with any and what data, so the runtime needs to be able to push arbitrary data to the Kata agent. However, this is almost always not what the user wants: 1. A declared `VO...

### Summary You can affect the agent binaries used in a Juju controller and the code that is run in the binaries by simply having a user account on a controller. You aren't required to have a model or any permissions. This just requires a user account in the controller database. ### Details Because of the way Juju upload tools code works in the controller it only checks that the user uploading agent binaries is authenticated and is a user tag. No more checks are performed and it allows that user to upload binaries to any model they like (as long as they know the model uuid) or upload binaries to the controller (attacker doesn't need to know any uuid's for controller or controller model). Once the poison binaries have been uploaded any new machine that is started in the affected model or controller will get started with the poison binaries. Alternatively administrator's of the controller running either `juju upgrade-controller` or `juju upgrade-model` will force distribution of the po...

### Impact Any user with a Juju account on a controller can read debug log messages from the `/log` endpoint. No specific permissions are required - it's just sufficient for the user to exist in the controller user database. The log messages may contain sensitive information. ### Details The `/log` endpoint is accessible at the following endpoints: - `wss://<controller-ip>/log` - `wss://<controller-ip>/model/<model-uuid>/log` In order to connect to these endpoints, the client must pass an X-Juju-Client-Version header that matches the current version and pass credentials in a Basic Authorization header. Once connected, the service will stream log events even though the user is not authorised to view them. To reproduce: ``` juju bootstrap juju add-user testuser juju change-user-password testuser ``` Run the [wscat](https://github.com/websockets/wscat) command below to connect to `wss://<controller-ip>:17070/api`. Update the JSON payload to include the username and password that were...