https://vulnerability.circl.lu/rss/recent/all/10 Most recent entries from all 2026-09-29T21:10:30.652760+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent entries. https://vulnerability.circl.lu/vuln/certfr-2026-avi-1233 certfr-2026-avi-1233 — De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre elles permettent à un attaquan… 2026-09-29T21:10:32.827833+00:00 certfr-2026-avi-1233 https://vulnerability.circl.lu/vuln/cleanstart-2026-ke27596 CLEANSTART-2026-KE27596 — js-yaml is a JavaScript YAML parser and dumper 2026-09-29T21:10:32.828053+00:00

Affected: CleanStart: argo-workflows, CleanStart: qdrant

CVE-2026-84375 affects multiple packages. js-yaml is a JavaScript YAML parser and dumper. See references for individual vulnerability details.

 https://vulnerability.circl.lu/vuln/fkie_cve-2026-84375 fkie_cve-2026-84375 2026-09-29T21:10:32.828166+00:00

js-yaml is a JavaScript YAML parser and dumper. From 3.0.0 until 3.15.2, 4.3.2, and 5.4.1, maxTotalMergeKeys in lib/js-yaml/loader.js and lib/loader.js does not count empty mapping sources while processing the merge key <<. An attacker can alias a large sequence of empty mappings into many merge targets, causing O(N * K) processing while totalMergeKeys remains unchanged and the configured resource limit is never reached. A relatively small YAML document can therefore cause prolonged CPU consumption in applications that parse untrusted YAML, and merge processing is enabled by default on these release lines. In v3 & v4, merge is enabled by default so the severity score is higher. This issue is fixed in versions 3.15.2, 4.3.2, and 5.4.1.

 https://vulnerability.circl.lu/vuln/ghsa-2883-xcg3-v3hh GHSA-2883-xcg3-v3hh — js-yaml: maxTotalMergeKeys does not limit CPU use for empty merge sources 2026-09-29T21:10:32.828243+00:00

Affected: npm: js-yaml

## Summary

`maxTotalMergeKeys` does not count empty mappings. An attacker can repeatedly merge a large sequence of them and consume significant CPU without reaching the configured limit.

## Example

```yaml arr: &arr [{}, {}, {}, ...] # N empty mappings targets: - <<: *arr # repeated K times ```

For every target, the loader iterates all `N` elements of `arr`. This results in `O(N * K)` work while `totalMergeKeys` remains unchanged.

## PoC

```js import { performance } from 'node:perf_hooks' import { load, YAML11_SCHEMA } from 'js-yaml'

const n = 20000

const src = 'arr: &arr [' + '{},'.repeat(n).slice(0, -1) + ']\n' + 'targets:\n' + ' - <<: *arr\n'.repeat(n)

const started = performance.now()

load(src, { schema: YAML11_SCHEMA })

console.log(`${(performance.now() - started).toFixed(1)} ms`) ```

Observed results:

| N | YAML size | Time | |---:|---:|---:| | 800 | ~13 KB | ~20 ms | | 3200 | ~50 KB | ~180 ms | | 20000 | ~500 KB | ~13 s |

## Impact

An attacker can submit a relatively small YAML document that causes prolonged CPU consumption despite the default `maxTotalMergeKeys` limit.

## Fix

Count each merge-source mapping as one budget unit, in addition to counting its keys.

## Difference with v5

In v3 & v4, merge is enabled by default. So, the severity score is higher.

 https://vulnerability.circl.lu/vuln/oesa-2026-4060 OESA-2026-4060 — nodejs-js-yaml security update 2026-09-29T21:10:32.828337+00:00

Affected: openEuler:24.03-LTS-SP4: nodejs-js-yaml, openEuler:20.03-LTS-SP4: nodejs-js-yaml, openEuler:22.03-LTS-SP4: nodejs-js-yaml, openEuler:24.03-LTS-SP1: nodejs-js-yaml, openEuler:24.03-LTS-SP3: nodejs-js-yaml

This is an implementation of YAML (YAML Ain&amp;apos;t Markup Language), a human friendly data serialization language. It started as PyYAML port, and was completely rewritten from scratch. Now it&amp;apos;s very fast, and supports the 1.2 spec. Security Fix(es):

js-yaml is a JavaScript YAML parser and dumper. From 3.0.0 until 3.15.2 and 4.3.2, maxTotalMergeKeys in lib/js-yaml/loader.js and lib/loader.js does not count empty mapping sources while processing the merge key &lt;&lt;. An attacker can alias a large sequence of empty mappings into many merge targets, causing O(N * K) processing while totalMergeKeys remains unchanged and the configured resource limit is never reached. A relatively small YAML document can therefore cause prolonged CPU consumption in applications that parse untrusted YAML, and merge processing is enabled by default on these release lines. This issue is fixed in versions 3.15.2 and 4.3.2.(CVE-2026-84375)

 https://vulnerability.circl.lu/vuln/rhsa-2026:62810 RHSA-2026:62810 — Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update 2026-09-29T21:10:32.828405+00:00

js-yaml: js-yaml: Denial of Service vulnerability in YAML parsing

 https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-84375 UBUNTU-CVE-2026-84375 2026-09-29T21:10:32.828443+00:00

Affected: Ubuntu:18.04:LTS: node-js-yaml, Ubuntu:20.04:LTS: node-js-yaml, Ubuntu:22.04:LTS: node-js-yaml, Ubuntu:24.04:LTS: node-js-yaml, Ubuntu:26.04:LTS: node-js-yaml

js-yaml is a JavaScript YAML parser and dumper. From 3.0.0 until 3.15.2 and 4.3.2, maxTotalMergeKeys in lib/js-yaml/loader.js and lib/loader.js does not count empty mapping sources while processing the merge key <<. An attacker can alias a large sequence of empty mappings into many merge targets, causing O(N * K) processing while totalMergeKeys remains unchanged and the configured resource limit is never reached. A relatively small YAML document can therefore cause prolonged CPU consumption in applications that parse untrusted YAML, and merge processing is enabled by default on these release lines. This issue is fixed in versions 3.15.2 and 4.3.2.