Latest News

I am reporting a code injection vulnerability in Orval’s mock generation pipeline affecting @orval/mock in both the 7.x and 8.x series. This issue is related in impact to the previously reported enum x-enumDescriptions (https://github.com/advisories/GHSA-h526-wf6g-67jv), but it affects a different code path in the faker-based mock generator rather than @orval/core. The vulnerability allows untrusted OpenAPI specifications to inject arbitrary TypeScript/JavaScript into generated mock files via the const keyword on schema properties. These const values are interpolated into the mock scalar generator (getMockScalar in packages/mock/src/faker/getters/scalar.ts) without proper escaping or type-safe serialization, which results in attacker-controlled code being emitted into both interface definitions and faker/MSW handlers. I have confirmed that this occurs on orval@7.19.0 and orval@8.0.2 with mock: true, and that the generated mocks contain executable payloads such as require('child_proces...

### Impact Instances of Moonraker configured with the `ldap` component enabled are vulnerable to LDAP search filter injection techniques via the login endpoint. The 401 error response message can be used to determine whether or not a search was successful, allowing for brute force methods to discover LDAP entries on the server such as user IDs and user attributes. ### Patches Users should upgrade to Moonraker 0.10.0 which patches this vulnerability. ### Workarounds Admins can set the `max_login_attempts` option in the `[authorization]` section to a reasonable value. Any IP attempting to exploit this vulnerability will be locked out after it has reached the specified number of consecutive failed login attempts. This condition is cleared after a Moonraker restart. Note that if an attacker knows a valid user password they can bypass this protection by successfully logging in. The most secure workaround for users unable to upgrade is to remove the `ldap` section from `moonrak...

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

Cybersecurity researchers have disclosed details of a new ransomware family called Osiris that targeted a major food service franchisee operator in Southeast Asia in November 2025. The attack leveraged a malicious driver called POORTRY as part of a known technique referred to as bring your own vulnerable driver (BYOVD) to disarm security software, the Symantec and Carbon Black Threat Hunter