Feb 26, 2026·5 min read·63 visits
dottie.js versions 2.0.4-2.0.6 contain a trivial bypass for a previous prototype pollution fix. By using a path like 'key.__proto__.polluted' instead of '__proto__.polluted', attackers can execute arbitrary code or cause denial of service. Fixed in v2.0.7.
A classic example of a failed patch. The popular dottie.js library attempted to fix a prototype pollution vulnerability by blocking malicious keys, but only checked the first segment of the property path. Attackers could simply nest their payload one level deep to bypass the check completely.
JavaScript developers love dot-notation helpers. Why write obj && obj.db && obj.db.config when you can just use dottie.get(obj, 'db.config')? Libraries like dottie.js exist to make accessing and mutating nested objects painless. But as we've seen time and time again in the Node.js ecosystem, convenience often comes at the cost of security.
This isn't a story about a new, groundbreaking exploit technique. It's a story about a "zombie" vulnerability—a bug that was supposedly killed, buried, and marked as fixed, only to crawl back out of the grave because the stake wasn't driven deep enough.
We are looking at CVE-2026-27837, a bypass of the patch for CVE-2023-26132. It highlights a critical lesson in input validation: if you are going to police user input, you have to check the entire payload, not just the first five characters.
To understand the bypass, we have to look at the original fix. In 2023, the maintainers of dottie.js realized that allowing users to set keys like __proto__ was dangerous. It enables Prototype Pollution, where an attacker modifies the base Object.prototype, affecting every object in the Node.js process.
Their solution was logical, but short-sighted. They added a guard clause that looked like this:
// The old, vulnerable check
if (pieces[0] === '__proto__') return;This code splits the input path (e.g., user.name) into an array (['user', 'name']) and checks the first element. If you try to pass __proto__.polluted, pieces[0] is __proto__, and the function returns. The front door is locked.
But the logic flaw here is assuming that the attack vector must be the root of the operation. dottie.js is recursive. It walks down the object tree. If an attacker provides a path like user.__proto__.isAdmin, the array becomes ['user', '__proto__', 'isAdmin'].
Here, pieces[0] is 'user'. The check passes. The library then happily traverses into user, then into __proto__ (which points to Object.prototype), and finally sets isAdmin on the global prototype. The bouncer checked the first guy in line, saw he was cool, and let the entire gang of hackers in behind him.
Exploiting this requires zero advanced knowledge of memory corruption or heap layouts. You just need to shift your malicious payload one index to the right.
Here is a functional Proof of Concept (PoC) demonstrating the bypass:
const dottie = require('dottie');
// A harmless looking object
const payload = {};
// The Attack: We prefix the malicious path with literally anything.
// The check `pieces[0] === '__proto__'` sees 'config' and allows it.
const maliciousPath = 'config.__proto__.polluted';
console.log("Before:", ({}).polluted); // undefined
try {
// dottie traverses 'config' (creates it), then accesses '__proto__',
// then sets 'polluted' on the global Object prototype.
dottie.set(payload, maliciousPath, "pwned");
} catch (e) {
console.log("Blocked?");
}
console.log("After:", ({}).polluted);
// Output: "pwned"
// Every object in the process now has this property.This vulnerability affects both dottie.set() and dottie.transform(). In a real-world scenario, this usually happens when an application takes a JSON body from a request (e.g., updating user preferences) and passes it directly to dottie to update a database object.
Prototype pollution is often dismissed as a "theoretical" risk, but in JavaScript, it is a loaded gun. By polluting Object.prototype, an attacker can:
if (user.isAdmin), and isAdmin is undefined on the user object, it looks up the prototype chain. If the attacker polluted the prototype with isAdmin: true, they are now an admin.toString or valueOf can cause the application to crash instantly whenever it tries to log an object or coerce a string.shell, exec, or outputFunctionName) can trick the engine into executing arbitrary shell commands.With a CVSS score of 6.3, it's marked "Medium," but in the right environment (like a server-side rendering app), it is critical.
The fix in version 2.0.7 replaces the lazy index-0 check with a comprehensive scan of the path. The developers finally realized that any part of the path could be a weapon.
Here is the corrected code logic:
// The Fix: Check EVERY piece of the path
var DANGEROUS_KEYS = ['__proto__', 'constructor', 'prototype'];
// Array.some() returns true if any element matches the condition
if (pieces.some(function(p) {
return DANGEROUS_KEYS.indexOf(p) !== -1;
})) return;They also expanded the blacklist. Previously, they only feared __proto__. Now, they correctly block constructor and prototype as well. This prevents attacks that try to walk up the prototype chain via constructor.prototype.
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L| Product | Affected Versions | Fixed Version |
|---|---|---|
dottie.js mickhansen | >= 2.0.4, < 2.0.7 | 2.0.7 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-1321 (Prototype Pollution) |
| CVSS v3.1 | 6.3 (Medium) |
| Attack Vector | Network (AV:N) |
| Exploit Maturity | Proof of Concept (PoC) |
| User Interaction | None (if automated processing) |
| Complexity | Low (AC:L) |
CVE-2026-64849 is a critical Server-Side Request Forgery (SSRF) vulnerability affecting MLflow tracking servers prior to version 3.15.0. It allows unauthenticated remote attackers to bypass outbound request destination filters using DNS rebinding or HTTP redirects. This exposure risks compromising sensitive cloud infrastructure metadata and internal microservices.
This technical report details a missing authorization vulnerability (CVE-2026-69146 / GHSA-3p64-6gvh-82v5) affecting the MLflow platform from version 3.13.0 to 3.15.0. When MLflow is configured with the built-in basic-auth plugin, authenticated users can bypass run-level UPDATE authorization checks, enabling unauthorized dataset and model lineage metadata injection.
MLflow prior to version 3.15.0 fails to perform proper authorization checks when registering model versions, allowing authenticated users with access to a registered model to link and access artifacts from runs and models belonging to other users without authorization.
A high-severity Regular Expression Denial of Service (ReDoS) vulnerability in the sqlparse Python library prior to version 0.6.0 allows unauthenticated remote attackers to trigger CPU exhaustion and application denial of service via crafted SQL inputs containing unmatched dollar-quoted literals or unclosed multiline comments.
A high-severity logic inversion flaw in the uniget CLI completely bypasses Sigstore cryptographic signature verification on metadata files by default. If an attacker can poison the package metadata cache or repository, they can execute arbitrary OS commands under the privileges of the active user.
A technical analysis of CVE-2026-59903 in Netty's HTTP CORS handler, where the CorsHandler overwrites existing application Vary headers with Origin, leading to unauthorized caching of sensitive information.