Starcounter-Jack
Backport fix for GHSA-8gh8-hqwg-xf34 to v2
Currently ajv-cli is using v2 of this library - while I've opened a PR to update it to v3, I'm not sure when it might actually get merged and released as @epoberezkin is pretty busy and so the CLI doesn't get updated that frequently.
If you're open to backport fix for GHSA-8gh8-hqwg-xf34 to v2, that would allow people to resolve the vulnerability without needing a new version of ajv-cli released - looking at the changelogs and the v2 code it looks like the changes in #262 should land cleanly, and I'm happy to help if that would make it easier.
@Starcounter-Jack I've prepared a patch that applies #262 to v2.2.1 cleanly - I'm happy to open a PR if you want to create a v2 branch off v2.2.1:
diff --git a/src/core.ts b/src/core.ts
index 35f2c21..16302d5 100644
--- a/src/core.ts
+++ b/src/core.ts
@@ -256,7 +256,10 @@ export function applyOperation<T>(document: T, operation: Operation, validateOpe
while (true) {
key = keys[t];
- if(banPrototypeModifications && key == '__proto__') {
+ if(banPrototypeModifications &&
+ (key == '__proto__' ||
+ (key == 'prototype' && t>0 && keys[t-1] == 'constructor'))
+ ) {
throw new TypeError('JSON-Patch: modifying `__proto__` prop is banned for security reasons, if this was on purpose, please set `banPrototypeModifications` flag false and pass it to this function. More info in fast-json-patch README');
}
I think prototype pollution is not a real risk for CLI, where you control all inputs? There may be some complex attack scenario I am missing. Anyway, needs to be updated of course.
@epoberezkin yeah with a CLI-based program it's probably a lot harder to exploit, but why take the risk when it's easily patched? This backport isn't needed if you're happy to go with https://github.com/ajv-validator/ajv-cli/pull/227 instead which upgrades to v3.