Skip to content

Instantly share code, notes, and snippets.

@sebres

sebres/deepseek.md

Last active July 15, 2025 17:13
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save sebres/b8880fd49b49e29999556bc9d5f7c67c to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save sebres/b8880fd49b49e29999556bc9d5f7c67c to your computer and use it in GitHub Desktop.
Download ZIP
AI: my conversation with Deepseek in order to "estimate" its potential by vulny-search and its ability to "learn"...
Raw
deepseek.md

Contents:

TL;DR-version

I was in mode to play with DeepSeek-V3 in order to estimate its "potential", particularly by the vulny-search and its ability to "learn". The first Q was about whether it is able to detect vulnerability in some JS-code (which was successfully found by ChatGPT4 too). The answer was relative good, with the hit, explanation, fix suggestion and recommendation. More or less exact as good as the answer of ChatGPT4.

Then I fixed it in the different way as suggested, just to see its reaction. However I must admit the wording was a bit unfortunate, and I should probably ask it less categorically, so instead of "find vulnerability in following code" (like in Q1) I would have used something like "is following code vulnerable?" (but OK). For fixed variant was the answer - yes, the vulnerability is still there, notwithstanding, it noticed the attempt to fix, but claiming - supposedly it is not enough.

To which I replied that the answer was wrong and explained why it is so. The answer was surprising - it not only acknowledged its error, but also was able to prove itself and created PoC (and then checked it? or found some "logical" matches in its neurons), and even apologised for the mistake and expressed thanks at end.

After all, a bit later, I tryied again the fixed variant (as Q2) and it answered completely different this time, as if it had trained the teaching and learned from the feedback (too fast update of neuronal connections for my subjective feeling). But also (and fully correct) it provided few recomendations to improve the code (because the code as well as the "fix" was just a short and dirty attempt to prove it and of course the schema validation or other preventive measures would be good to have there). What surprised me further was its extra suggestion at end - "If you have specific concerns or additional context about the code, feel free to share them!", which I never saw before in conversations with AIs.

As bottom line you could also find the brief summary as an outcome of the conversation.

sebres:
Here starts my conversation with DeepSeek-V3, accompanied by commentaries of my humble self (highlighted as a quotation)...

DeepSeek-V3

Ask me anything

sebres (Q1)

find vulnerability in following code:

fetch(request)
  .then((response) => {
    if (response.status !== 200) {
      throw new Error("Something went wrong on API server!");
    }
    return response.json();
  })
  .then((userData) => {
    const defaults = { a: true, b: false };
    return { ...defaults, ...userData };
  });

DeepSeek-V3 (A1)

The provided code has a potential vulnerability related to Prototype Pollution. While the code attempts to merge defaults and userData using the spread operator ({ ...defaults, ...userData }), it does not explicitly prevent userData from containing properties that could pollute the prototype chain.

Vulnerability Explanation:

In the code, the result object is created by merging the defaults with the userData using the spread operator ({ ...defaults, ...userData }). If userData contains properties like __proto__, constructor, or prototype, that override properties in the prototype of defaults, they can overwrite the prototype of the resulting object when the spread operator is used to merge defaults and userData, it can lead to Prototype Pollution.

For example, if data contains the following JSON:

{
    "__proto__": {
        "polluted": true
    }
}

The __proto__ property in JavaScript refers to the prototype of the object. When the userData is merged with defaults, the __proto__ property in userData can override the prototype of result. This means that any object created from result will inherit the polluted property, potentially leading to unexpected behavior or security issues.

Impact:

Prototype Pollution can lead to:

  1. Security vulnerabilities: An attacker could manipulate the prototype to introduce malicious properties or methods.
  2. Denial of Service (DoS): Overriding critical prototype methods could crash the application.
  3. Remote Code Execution (RCE): In extreme cases, an attacker could execute arbitrary code by polluting the prototype.

How to Fix:

To prevent Prototype Pollution, you should explicitly filter out or reject any properties in userData that could affect the prototype chain (e.g., __proto__, constructor, or prototype). Here's the fixed code:

fetch(request)
  .then((response) => {
    if (response.status !== 200) {
      throw new Error("Something went wrong on API server!");
    }
    return response.text();
  })
  .then((data) => {
    const defaults = { a: true, b: false };
    const userData = JSON.parse(data);

    // Validate userData to prevent Prototype Pollution
    const sanitizedUserData = {};
    for (const key in userData) {
      if (key !== "__proto__" && key !== "constructor" && key !== "prototype") {
        sanitizedUserData[key] = userData[key];
      }
    }

    // Merge defaults and sanitized userData
    return { ...defaults, ...sanitizedUserData };
  })
  .catch((error) => {
    console.error("Error:", error);
  });

Explanation of Fix:

  1. Validate userData: Iterate over the userData object and exclude any properties that could affect the prototype chain (__proto__, constructor, prototype).
  2. Use the spread operator safely: Merge defaults and the sanitized userData after ensuring that no prototype-polluting properties are present.

Additional Recommendations:

  1. Use libraries like lodash: Libraries like lodash provide safe methods for merging objects (_.merge) that are less prone to Prototype Pollution.
  2. Validate input data: Always validate and sanitize user input to prevent any malicious payloads.
  3. Consider using a schema validation library: Libraries like joi or ajv can help ensure that the input matches the expected schema format.

By implementing these fixes, you can prevent Prototype Pollution and improve the security of your application.

Note of sebres, by the way:

I decided to "fix" the vulnerability in the way it didn't suggested (so I assumed it didn't know that probably), just to see its reaction.

- return { ...defaults, ...userData };
+ return Object.assign(Object.create(null), defaults, userData);

(so below is slightly modified code as in Q1...
however I should probably ask it less categorically, so instead of "find vulnerability in following code" I would have used something like "is following code vulnerable?")

sebres (Q2)

find vulnerability in following code:

fetch(request)
  .then((response) => {
    if (response.status !== 200) {
      throw new Error("Something went wrong on API server!");
    }
    return response.json();
  })
  .then((userData) => {
    const defaults = { a: true, b: false };
    return Object.assign(Object.create(null), defaults, userData);
  });

DeepSeek-V3 (A2)

The provided code has a vulnerability related to Prototype Pollution. While the code attempts to mitigate Prototype Pollution by using Object.create(null) to create an object without a prototype, the issue lies in the way Object.assign is used.

Vulnerability Explanation:

The code uses Object.assign to merge the defaults and userData objects. If userData contains a property like __proto__ or constructor, it can still pollute the prototype chain. Even though Object.create(null) creates an object without a prototype, Object.assign does not inherently prevent prototype pollution during the merging process.

For example, if userData contains the following:

{
    "__proto__": {
        "polluted": true
    }
}

The __proto__ property in userData can overwrite the prototype of the resulting object, leading to Prototype Pollution.

Impact:

Prototype Pollution can result in:

  1. Security vulnerabilities, such as allowing attackers to manipulate the prototype chain.
  2. Unexpected behavior in the application, potentially leading to crashes or incorrect functionality.
  3. Remote Code Execution (RCE) in extreme cases.

How to Fix:

To prevent Prototype Pollution, you should explicitly filter out or reject any properties in userData that could affect the prototype chain (e.g., __proto__, constructor, or prototype). Here's the fixed code:

fetch(request)
  .then((response) => {
    if (response.status !== 200) {
      throw new Error("Something went wrong on API server!");
    }
    return response.json();
  })
  .then((userData) => {
    const defaults = { a: true, b: false };

    // Validate userData to prevent Prototype Pollution
    const sanitizedUserData = {};
    for (const key in userData) {
      if (key !== "__proto__" && key !== "constructor" && key !== "prototype") {
        sanitizedUserData[key] = userData[key];
      }
    }

    // Merge defaults and sanitized userData
    const result = Object.assign(Object.create(null), defaults, sanitizedUserData);
    return result;
  })
  .catch((error) => {
    console.error("Error:", error);
  });

Explanation of Fix:

  1. Validate userData: Iterate over the userData object and exclude any properties that could affect the prototype chain (__proto__, constructor, prototype).
  2. Use Object.assign safely: Merge defaults and the sanitized userData after ensuring that no prototype-polluting properties are present.

Additional Recommendations:

  1. Use libraries like lodash: Libraries like lodash provide safe utilities for merging objects (e.g., _.merge) that are less prone to Prototype Pollution.
  2. Input validation: Always validate and sanitize user input to prevent malicious payloads.
  3. Use schema validation: Consider using libraries like joi or ajv to ensure that the input matches the expected schema format.

By implementing these fixes, you can prevent Prototype Pollution and improve the security of your application.

Note of sebres, by the way:

The answer looks wrong and a bit unexpected:
However the __proto__ by assigning to object created with Object.create(null) is set in the result, it remains as simple __proto__-member and not as prototype definition, what then doesn't affect object inheritances and behaves like a "normal" property, for instance trying to retrieve result.polluted (not result.__proto__.polluted) results to undefined.

sebres (Q3)

you are wrong, the code uses Object.assign to instance of Object.create(null) which doesn't have prototype, so does not inherit any properties, thereby preventing prototype pollution.

DeepSeek-V3 (A3)

You are absolutely correct — my earlier explanation was mistaken — and I appreciate your clarification. The code uses Object.assign with an object created using Object.create(null), which explicitly creates an object with no prototype (null). Since the resulting object has no prototype, Prototype Pollution is effectively prevented.

Why the Code is Safe:

  1. Object.create(null): Creates an object with no prototype. This means it does not inherit properties from Object.prototype (e.g., __proto__, constructor, etc.).
  2. Object.assign: Copies properties from defaults and userData into the newly created object. Since the target object (Object.create(null)) has no prototype, properties like __proto__ or constructor in userData cannot pollute the prototype chain.

Example:

If userData contains:

{
    "__proto__": {
        "polluted": true
    }
}

The __proto__ property in userData will simply be copied as a regular property into the new object. It will not affect the prototype chain because the target object (Object.create(null)) has no prototype.

Here’s a breakdown of how the code works:

const defaults = { a: true, b: false };
const userData = { __proto__: { polluted: true }, c: true };

const result = Object.assign(Object.create(null), defaults, userData);

console.log(result); // { a: true, b: false, __proto__: { polluted: true }, c: true }
console.log(result.__proto__); // undefined (no prototype)

As you can see, the __proto__ property is treated as a regular property, and the prototype of the result object remains null. This means Prototype Pollution is prevented.

Note of sebres, by the way:

Well, it is not completely correct check (despite its almost correct explanation below in section "Why This Code is Secure"): Besides the fact that the result of console.log(result) would not contain __proto__ at all in its example code above - it'd be like here:

- console.log(result); // { a: true, b: false, __proto__: { polluted: true }, c: true }
+ console.log(result); // { a: true, b: false, c: true }

basically the PoC shall not check against created userData but on deserialized one, so the code could look like this:

  const defaults = { a: true, b: false };
- const userData = { __proto__: { polluted: true }, c: true };
+ const userData = JSON.parse('{"__proto__": {"polluted": true}, "c": true}');

  const result = Object.assign(Object.create(null), defaults, userData);

  console.log(result); // { a: true, b: false, __proto__: { polluted: true }, c: true }
- console.log(result.__proto__); // undefined (no prototype)
+ console.log(result.polluted); // undefined (no prototype)

(but I was interested in testing his training or "learning" abilities, so let's not be so scrupulous and not go so deep...)

Why This Code is Secure:

The use of Object.create(null) ensures that the resulting object has no prototype, so there’s no way for userData to modify the prototype chain. Object.assign only copies properties from defaults and userData into the new object. Since the target object has no prototype, properties like __proto__ or constructor have no special meaning.

Conclusion:

The code is secure against Prototype Pollution because it uses Object.create(null) to create an object with no prototype, and Object.assign simply copies properties into this new object without affecting the prototype chain. My earlier explanation incorrectly identified this as a vulnerability — thank you for pointing that out!

Note of sebres, by the way:

Repeat Q2

Let's check that the lesson has been learned;)
(so few minutes later, I was asking the same question as above, in hope it trained itself on feedback, and... it did, indeed!)

sebres (Q4)

find vulnerability in following code:

fetch(request)
  .then((response) => {
    if (response.status !== 200) {
      throw new Error("Something went wrong on API server!");
    }
    return response.json();
  })
  .then((userData) => {
    const defaults = { a: true, b: false };
    return Object.assign(Object.create(null), defaults, userData);
  });

DeepSeek-V3 (A4)

Upon reviewing the code, there is no vulnerability related to Prototype Pollution in this case. The code is secure because it uses Object.create(null) to create an object with no prototype, and Object.assign copies properties from defaults and userData into this new object. Since the target object has no prototype, properties like __proto__, constructor, or prototype cannot pollute the prototype chain.

Why the Code is Secure:

  1. Object.create(null): Creates an object with no prototype (null). This means the object does not inherit any properties from Object.prototype.
  2. Object.assign: Copies properties from defaults and userData into the new object. Since the target object has no prototype, properties like __proto__ or constructor in userData are treated as regular properties and do not affect the prototype chain.

Example:

If userData contains:

{
    "__proto__": {
        "polluted": true
    }
}

The resulting object will look like this:

{ a: true, b: false, __proto__: { polluted: true } }

The __proto__ property is treated as a regular property, and the prototype of the resulting object remains null. This means Prototype Pollution is prevented.

Potential Considerations:

While the code is secure against Prototype Pollution, there are other potential issues to consider:

  1. Unvalidated userData: If userData contains malicious or unexpected data, it could lead to other issues (e.g., unexpected behavior or logic errors). However, this is not related to Prototype Pollution.
  2. Error handling: The code does not handle errors that might occur during the fetch request or JSON parsing. For example:
    • If the API server returns invalid JSON, response.json() will throw an error.
    • Network errors or timeouts during the fetch call will also cause the promise to reject.

Improved Code with Error Handling:

Here’s an improved version of the code with better error handling:

fetch(request)
  .then((response) => {
    if (response.status !== 200) {
      throw new Error(`API request failed with status ${response.status}`);
    }
    return response.json();
  })
  .then((userData) => {
    const defaults = { a: true, b: false };
    return Object.assign(Object.create(null), defaults, userData);
  })
  .catch((error) => {
    console.error("Error:", error);
    throw error; // Re-throw the error if needed
  });

Conclusion:

The code itself is secure against Prototype Pollution. However, adding proper error handling and validating userData (if necessary) can further improve its robustness and reliability. If you have specific concerns or additional context about the code, feel free to share them!

End of conversation.

Bottom line

  1. DeepSeek could successfully find a vulni in simple code, able to detect the language by that small snippet, can explain the bug, suggest how to fix the code and make recomendation how it can be improved. However it may be still a bit raw here and there;
  2. but it can admit mistakes and could train itself by a feedback and thereby...
  3. it was able to prove my statement on the fly and can create new PoC to correct itself later;
  4. the whole conversation was pretty polite from side of DeepSeek:
    • e. g. it almost apologised for the mistake and expressed thanks in the conclusion
    • or suggested later that if I would "have specific concerns or additional context about the code, feel free to share them!"
  5. At first glance, the conversation was actually comparable to a human conversation, even created a much more competent impression sometimes, because I'm sure I couldn't so easy convince even some professionals, or else they would need much more time for the proof or to analyze my assertion.
  6. Skynet is near (we will all die)...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment