ghsa

### Summary The `ConfigCommentParser#parseJSONLikeConfig` API is vulnerable to a Regular Expression Denial of Service (ReDoS) attack in its only argument. ### Details The regular expression at [packages/plugin-kit/src/config-comment-parser.js:158](https://github.com/eslint/rewrite/blob/bd4bf23c59f0e4886df671cdebd5abaeb1e0d916/packages/plugin-kit/src/config-comment-parser.js#L158) is vulnerable to a quadratic runtime attack because the grouped expression is not anchored. This can be solved by prepending the regular expression with `[^-a-zA-Z0-9/]`. ### PoC ```javascript const { ConfigCommentParser } = require("@eslint/plugin-kit"); const str = `${"A".repeat(1000000)}?: 1 B: 2`; console.log("start") var parser = new ConfigCommentParser(); console.log(parser.parseJSONLikeConfig(str)); console.log("end") // run `npm i @eslint/plugin-kit@0.3.3` and `node attack.js` // then the program will stuck forever with high CPU usage ``` ### Impact This is a Regular Expression Denial of Serv...

It was discovered that the SBOM files generated by melange in apks had file system permissions mode 666: ``` $ apkrane ls https://packages.wolfi.dev/os/x86_64/APKINDEX.tar.gz -P hello-wolfi --full --latest | xargs wget -q -O - | tar tzv 2>/dev/null var/lib/db/sbom drwxr-xr-x root/root 0 2025-06-23 14:17 var/lib/db/sbom -rw-rw-rw- root/root 3383 2025-06-23 14:17 var/lib/db/sbom/hello-wolfi-2.12.2-r1.spdx.json ``` This issue was introduced in commit 1b272db ("Persist workspace filesystem throughout package builds (#1836)") ([v0.23.0](https://github.com/chainguard-dev/melange/releases/tag/v0.23.0)). ### Impact This potentially allows an unprivileged user to tamper with apk SBOMs on a running image, potentially confusing security scanners. An attacker could also perform a DoS under special circumstances. ### Patches This issue was addressed in melange in e29494b ("fix: tighten up permissions for written SBOM files and signature tarballs (#2086)") ([v0.29.5](https://github...

It was discovered that the ld.so.cache in images generated by apko had file system permissions mode `0666`: ``` bash-5.3# find / -type f -perm -o+w /etc/ld.so.cache ``` This issue was introduced in commit [04f37e2 ("generate /etc/ld.so.cache (#1629)")](https://github.com/chainguard-dev/apko/commit/04f37e2d50d5a502e155788561fb7d40de705bd9)([v0.27.0](https://github.com/chainguard-dev/apko/releases/tag/v0.27.0)). ### Impact This potentially allows a local unprivileged user to add additional additional directories including dynamic libraries to the dynamic loader path. A user could exploit this by placing a malicious library in a directory they control. ### Patches This issue was addressed in apko in [aedb077 ("fix: /etc/ld.so.cache file permissions (#1758)")](https://github.com/chainguard-dev/apko/commit/aedb0772d6bf6e74d8f17690946dbc791d0f6af3) ([v0.29.5](https://github.com/chainguard-dev/apko/releases/tag/v0.29.5)). ### Acknowledgements Many thanks to Cody Harris from [H2O.ai](htt...

### Summary A bug in Wasmtime's implementation of the WASIp1 set of import functions can lead to a WebAssembly guest inducing a panic in the host (embedder). The specific bug is triggered by calling `path_open` after calling `fd_renumber` with either: - two equal argument values - second argument being equal to a previously-closed file descriptor number value The corrupt state introduced in `fd_renumber` will lead to the subsequent opening of a file descriptor to panic. This panic cannot introduce memory unsafety or allow WebAssembly to break outside of its sandbox, however. There is no possible heap corruption or memory unsafety from this panic. This bug is in the implementation of Wasmtime's `wasmtime-wasi` crate which provides an implementation of WASIp1. The bug requires a specially crafted call to `fd_renumber` in addition to the ability to open a subsequent file descriptor. Opening a second file descriptor is only possible when a preopened directory was provided to the guest, ...

An attacker can pass a malicious malformed token which causes unexpected memory to be consumed during parsing.

### Impact The `lastIndexOf(bytes,byte,uint256)` function of the `Bytes.sol` library may access uninitialized memory when the following two conditions hold: 1) the provided buffer length is empty (i.e. `buffer.length == 0`) and position is not `2**256 - 1` (i.e. `pos != type(uint256).max`). The `pos` argument could be used to access arbitrary data outside of the buffer bounds. This could lead to the operation running out of gas, or returning an invalid index (outside of the empty buffer). Processing this invalid result for accessing the `buffer` would cause a revert under normal conditions. When triggered, the function reads memory at offset `buffer + 0x20 + pos`. If memory at that location (outside the `buffer`) matches the search pattern, the function would return an out of bound index instead of the expected `type(uint256).max`. This creates unexpected behavior where callers receive a valid-looking index pointing outside buffer bounds. Subsequent memory accesses that don't check...

### Impact A bug in on-headers versions `< 1.1.0` may result in response headers being inadvertently modified when an array is passed to `response.writeHead()` ### Patches Users should upgrade to `1.1.0` ### Workarounds Uses are encouraged to upgrade to `1.1.0`, but this issue can be worked around by passing an object to `response.writeHead()` rather than an array.

### Impact A vulnerability in Multer versions >= 1.4.4-lts.1, < 2.0.2 allows an attacker to trigger a Denial of Service (DoS) by sending a malformed request. This request causes an unhandled exception, leading to a crash of the process. ### Patches Users should upgrade to `2.0.2` ### Workarounds None

### Impact In Livewire v3 (≤ 3.6.3), a vulnerability allows unauthenticated attackers to achieve remote command execution in specific scenarios. The issue stems from how certain component property updates are hydrated. This vulnerability is unique to Livewire v3 and does not affect prior major versions. Exploitation requires a component to be mounted and configured in a particular way, but does not require authentication or user interaction. ### Patches This issue has been patched in Livewire v3.6.4. All users are strongly encouraged to upgrade to this version or later as soon as possible. ### Workarounds There is no known workaround at this time. Users are strongly advised to upgrade to a patched version immediately. ### Resources No public references available at this time to avoid exposure. Details will be published after a responsible disclosure window.

### Summary An attacker can forge a request to redirect an authenticated user to any arbitrary website. ### Details On the login page, we have a `redirect` field which is the location where the server will redirect the user. This URI is not verified, and can be an arbitrary URI. Paired with a parameter pollution, we can hide our malicious URI (ex: `https://dns.com/?param1=im_hidden_if_theres_lot_of_args?param1=bbb`). ### PoC https://diracx-cert.app.cern.ch/auth?redirect=https://ipcim.com/en/where/?dsdsd=qsqsfsjfnsfniizaeiaapzqlalkqkaizqqijsjaopmqmxna?redirect=https://diracx-cert-app.cern.ch/auth This POC can leak user's position. ### Impact This could be used for phishing and extracting new data (such as redirecting to a new "log in" page, and asking users to reenter credentials).