ghsa

Unprivileged users (for example, those with the database editor role) can create or modify fields in records that contain functions or `futures`. `Futures` are values which are only computed when the value is queried. The query executes in the context of the querying user, rather than the user who originally defined the future. Likewise, fields containing functions or custom-defined logic (`closures`) are executed under the privileges of the invoking user, not the creator. This results in a confused deputy vulnerability: an attacker with limited privileges can define a malicious function or future field that performs privileged actions. When a higher-privileged user (such as a root owner or namespace administrator) executes the function or queries or modifies that record, the function executes with their elevated permissions. ### Impact An attacker who can create or update function/future fields can plant logic that executes with a privileged user’s context. If a privileged user per...

### Impact Protected files uploaded through Umbraco Forms may be served to unauthenticated users when a CDN or caching layer is present and ImageSharp processes the request. ImageSharp sets aggressive cache headers by default, which can cause intermediary caches to store and serve files that should require authentication. ### Patches This issue affects all (supported) versions Umbraco Forms and is patched in 13.9.0, 16.4.0 and 17.1.0. ### Workarounds Add middleware to set cache headers for form uploads. Place the following code in your `Startup.cs` or `Program.cs` after `app.UseStaticFiles()` and any image processing middleware: ```cs app.Use(async (context, next) => { var path = context.Request.Path.Value; if (!string.IsNullOrEmpty(path) && path.StartsWith("/media/forms/upload/", StringComparison.OrdinalIgnoreCase)) { context.Response.OnStarting(() => { context.Response.Headers["Cache-Control"] = "private, no-store, no-cache, must-revalidate...

## Summary Dragonfly Manager's Job REST API endpoints lack authentication, allowing unauthenticated attackers to create, query, modify, and delete jobs, potentially leading to resource exhaustion, information disclosure, and service disruption. ## Affected Products - **Product**: Dragonfly - **Component**: Manager (REST API) - **Affected Versions**: v2.x (based on source code analysis, including v2.4.0) - **Affected Endpoints**: `/api/v1/jobs` ## Vulnerability Details ### Description Dragonfly Manager's Job API endpoints (`/api/v1/jobs`) lack JWT authentication middleware and RBAC authorization checks in the routing configuration. This allows any unauthenticated user with access to the Manager API to perform the following operations: 1. **List all jobs** (GET `/api/v1/jobs`) 2. **Create new jobs** (POST `/api/v1/jobs`) 3. **Query job details** (GET `/api/v1/jobs/:id`) 4. **Modify jobs** (PATCH `/api/v1/jobs/:id`) 5. **Delete jobs** (DELETE `/api/v1/jobs/:id`) ### Technical Root...

### Summary - **Vulnerability Type:** Path Traversal (CWE-22) leading to Arbitrary File Permission Modification. - **Root Cause Component:** wheel.cli.unpack.unpack function. - **Affected Packages:** 1. wheel (Upstream source) 2. setuptools (Downstream, vendors wheel) - **Severity:** High (Allows modifying system file permissions). ### Details The vulnerability exists in how the unpack function handles file permissions after extraction. The code blindly trusts the filename from the archive header for the chmod operation, even though the extraction process itself might have sanitized the path. ``` # Vulnerable Code Snippet (present in both wheel and setuptools/_vendor/wheel) for zinfo in wf.filelist: wf.extract(zinfo, destination) # (1) Extraction is handled safely by zipfile # (2) VULNERABILITY: # The 'permissions' are applied to a path constructed using the UNSANITIZED 'zinfo.filename'. # If zinfo.filename contains "../", this targets files...

### Impact A PyYAML-related Remote Code Execution (RCE) vulnerability, namely CVE-2020-14343, is exposed in `docling-core >=2.21.0, <2.48.4` and, specifically only if the application uses `pyyaml < 5.4` and invokes `docling_core.types.doc.DoclingDocument.load_from_yaml()` passing it untrusted YAML data. ### Patches The vulnerability has been patched in `docling-core` version **2.48.4**. The fix mitigates the issue by switching `PyYAML` deserialization from `yaml.FullLoader` to `yaml.SafeLoader`, ensuring that untrusted data cannot trigger code execution. ### Workarounds Users who cannot immediately upgrade `docling-core` can alternatively ensure that the installed version of `PyYAML` is **5.4 or greater**, which supposedly patches CVE-2020-14343. ### References * GitHub Issue: #482 * Upstream Advisory: CVE-2020-14343 * Fix Release: [v2.48.4](https://github.com/docling-project/docling-core/releases/tag/v2.48.4)

Serialization of objects with extreme depth can **exceed the maximum call stack limit**. **Mitigation**: `Seroval` introduces a `depthLimit` parameter in serialization/deserialization methods. **An error will be thrown if the depth limit is reached.**

### Summary Client-side script execution in Typebot allows stealing all stored credentials from any user. When a victim previews a malicious typebot by clicking "Run", JavaScript executes in their browser and exfiltrates their OpenAI keys, Google Sheets tokens, and SMTP passwords. The `/api/trpc/credentials.getCredentials` endpoint returns plaintext API keys without verifying credential ownership --- ### Details The Script block with "Execute on client" enabled runs arbitrary JavaScript in the victim's browser with their authenticated session. This allows API calls on their behalf. The `/api/trpc/credentials.getCredentials` endpoint returns plaintext credentials: ```http GET /api/trpc/credentials.getCredentials?input={"json":{"scope":"user","credentialsId":"cm6sofgv200085ms9d2qyvgwc"}} Response: { "result": { "data": { "json": { "name": "My OpenAI Key", "data": { "apiKey": "sk-proj-abc123...xyz789" } } } } } ``` The endpoint only checks i...

ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file. The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado.

### Impact _What kind of vulnerability is it? Who is impacted?_ This issue impacts every Soft Serve instance. A critical authentication bypass allows an attacker to impersonate any user (including Admin) by "offering" the victim's public key during the SSH handshake before authenticating with their own valid key. This occurs because the user identity is stored in the session context during the "offer" phase and is not cleared if that specific authentication attempt fails. ### Patches _Has the problem been patched? What versions should users upgrade to?_ Yes, please upgrade to version 0.11.3 as soon as possible. ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ You need to upgrade

### 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.