@fastify/reply-from is a Fastify plugin that forwards requests to an upstream HTTP server. In versions up to and including 12.8.0, the plugin validated proxy paths against forward-slash dot-segments only and then built the target with the WHATWG URL parser, which normalizes a backslash and its percent-encoded form to a forward slash on the http, https, ws, and wss schemes. A path that uses backslash dot-segments therefore bypasses the traversal check and resolves to a different upstream path, so an application that scopes proxying to an upstream prefix, or relies on route guards in front of the forwarding call, can have an unauthenticated request escape the intended prefix and reach other upstream endpoints. The resulting access to unintended upstream resources is primarily a confidentiality impact with limited integrity impact. The issue is fixed in @fastify/reply-from 12.8.1, where the path is normalized and any segment resolving to a single or double dot, along with control characters and ambiguous whitespace, is rejected before the URL is constructed, and users should upgrade to 12.8.1 or later. There is no workaround other than upgrading.
Prefab UI's Generative UI sandbox runs caller-supplied Python inside Pyodide, Python compiled to WebAssembly, in a Deno subprocess. The feature is documented as isolation for untrusted code, including LLM-written UI. From prefab-ui 0.14.0 through 0.20.2 the launcher starts Deno with unrestricted --allow-read, --allow-write, and --allow-net, and the runner leaves the Deno API on the JavaScript global object. Pyodide's js module proxies that global, so the Python can call Deno.readTextFileSync and Deno.writeTextFileSync. A caller who can supply the code can read and write files as the server OS user, and can persist code execution by writing a .pth file into the server virtualenv's site-packages. The usual remote path is FastMCP's GenerativeUI provider, which registers the MCP tool generate_prefab_ui and forwards that tool's code argument into this sandbox. On a FastMCP server with no authentication configured, any client who can reach the server can call the tool. With authentication, any client allowed to call tools can. Generative UI is opt-in, and the host must have Deno installed. Confirmed on prefab-ui 0.20.2. Fixed in 0.21.0: after the runtime and Prefab sources load, the runner revokes Deno read, write, and network permission before it accepts code, the process is started with --no-prompt so a permission request cannot grant them again, and bootstrap network access is limited to cdn.jsdelivr.net. The fix is commit 030f074 (pull request 538).
The Beta9 worker serves the sandbox file API from outside the container. getHostPathFromContainerPath turns the tenant's container path into a worker path. If the unresolved path starts with a mount destination, including the default upload mount at /tmp/.beta9, the remainder is joined onto that mount's source with filepath.Join, which cleans parent-directory segments after the prefix check. A long enough run of those segments names any absolute path on the worker. A path that matches no mount is joined onto the container root and opened in the worker's own filesystem, so an absolute symbolic link such as /var/run pointing at /run is followed against the worker root. Upload, download, stat, list, find-in-files, replace-in-files, and delete-file all call this helper. A tenant with a workspace token and one running sandbox can read, write, list, and delete files on the hosting worker as root, including files of other tenants on that machine. A read-only proof downloaded the worker pod's Kubernetes service account token through the file API for a path that did not exist inside the sandbox. In the shipped remote-node manifests that service account is bound to cluster-admin. Fixed in worker 0.1.756: sandbox file operations and workspace sync open paths with os.OpenRoot, so parent-directory and symlink lookups stay inside the container root or the mount source.
The Uncanny Toolkit for LearnDash plugin for WordPress is vulnerable to Authentication Bypass in versions up to, and including, 3.8.2 via the `email` parameter of the `uo_login_action()` function. This is due to a parser-differential flaw in which the plugin's account-verification gate resolves the submitted `email` value using the raw, unsanitized string passed to `get_user_by()`, while the subsequent `wp_signon()` call relies on WordPress core's internal `sanitize_user()` to strip appended junk characters — causing the gate lookup to fail and be skipped entirely while the real account is still resolved and authenticated. This makes it possible for unauthenticated attackers to log in to unverified or administrator-suspended accounts whose credentials they already possess, obtaining a valid `wordpress_logged_in` session cookie and defeating the plugin's account-approval and account-suspension controls. The nonce required to reach the handler is freely obtainable in the same request from the unauthenticated `ult-refresh-nonce` endpoint, making exploitation trivial for any attacker with network access to the site and knowledge of a target account's credentials.
A vulnerability in glob versions 9.0.0 through 14.0.1 allows asynchronous directory traversal operations to continue consuming CPU and filesystem I/O after an abort signal or timeout has been triggered. This occurs because abort branches in the code call callbacks without returning, causing continued recursive directory reads even after cancellation. The issue impacts availability by allowing excessive resource consumption, potentially degrading service performance. The flaw is fixed in glob version 14.0.2.
A denial of service vulnerability exists in node-forge's TLS implementation due to recursive processing of TLS records, which can exhaust the call stack. An attacker can send a chunk of thousands of small TLS records (e.g., heartbeat records) before handshake completion, causing a RangeError that terminates Node.js processes using the documented socket wiring. This flaw affects both client and server connections. The issue is fixed in node-forge version 1.4.1 by changing the processing to an iterative approach.
The russh SSH agent server does not call the Agent::confirm method before signing with keys added with the confirm constraint (ssh-add -c). This confirm constraint is intended to require user approval before signing. The issue was introduced in version 0.50.0-beta.12 and affects all versions up to and including 0.64.1. As a result, keys added with the confirm constraint are signed without user confirmation, allowing any process with access to the agent to use those keys without approval. This undermines the security purpose of the confirm constraint defined in RFC 9987.
TAKO AI Agent for Okta is a local-first AI agent that helps Okta administrators query tenant data using natural language. Prior to 3.0.1-beta, any authenticated user with a valid `fctr_session` cookie can submit arbitrary Python source in the `script_code` field of `POST /api/react/execute-script`, without administrator privilege. In `src/api/routers/react_stream.py`, the source is stored with `skip_discovery=True`, bypassing AI-based content filtering, and is passed to `validate_generated_code` in `src/utils/security_config.py`. `BLOCKED_PATTERNS` recognizes direct `__import__` calls but misses the import name passed as a string, `getattr` is in `ALLOWED_BUILTINS`, and the AST checker handles `ast.Name` and `ast.Attribute` targets but fails to handle `ast.Call` targets. Dynamic `getattr` call chains through `__builtins__` therefore evade validation. The `_write_temp_script` helper writes the accepted code to disk, and `asyncio.create_subprocess_exec()` executes it as the application process user, which is root in the default container. Command output is returned as Server-Sent Events through `GET /api/react/stream-react-updates?process_id=<id>`. The resulting container compromise can disclose environment secrets including Okta API tokens and the JWT key, expose the SQLite database, and permit backend-service pivoting and persistence. This issue is fixed in version 3.0.1-beta.
Element Call versions from 0.16.0 up to but not including 0.20.3 log the password URL query parameter in error reports (rageshakes). These logs are shared with the application operator, potentially exposing the encryption password and compromising call confidentiality. The issue is fixed in version 0.20.3. Upgrading prevents future disclosures but does not remove secrets from previously collected logs, which require manual cleanup.
OpenVM is a performant and modular zkVM framework built for customization and extensibility. Before 1.7.0 in the 1.x line and in affected 2.0 and 2.1 prereleases, `OpenVmHalo2Verifier.verify` constructs raw proof calldata from user-controlled `proofData`, performs a `staticcall` to `address(this)`, and treats a successful call as proof acceptance. If the first four proof bytes match another external selector exposed by the wrapper, dispatch can invoke a successful non-verifier function instead of the generated Halo2 fallback verifier. Applications using the generated Solidity wrapper can consequently accept arbitrary app commitments and public values without checking the proof suffix, accumulator, app commitments or public values. This issue is fixed in versions 1.7.0, 2.0.0-rc.3 and 2.1.0-preview.
Missing queue-set type validation in the queue-set selection system call in FreeRTOS-Kernel before V11.3.3 on MPU-enabled ports with queue sets enabled allows a local unprivileged task to write actor-controlled data beyond a pointer-sized object on the privileged kernel stack, affecting privileged memory across the MPU isolation boundary.
To remediate this issue, users should upgrade to FreeRTOS-Kernel V11.3.3, rebuild, and reflash affected firmware. Builds that do not enable queue sets are not affected.
Chamilo LMS is an open-source learning management system. Prior to 2.0.1, `public/main/inc/lib/career.lib.php` and `public/main/cron/import_csv.php` call PHP's native `unserialize()` on `user_career.extra_data` retrieved from the database without the `allowed_classes: false` safety option. An attacker able to write crafted serialized PHP objects to that column, for example through a separate SQL injection, a compromised admin CSV import, or a lower-privilege admin panel, can instantiate arbitrary PHP objects and trigger POP gadget chains in autoloaded `Symfony`, `Doctrine`, or `Monolog` components. This permits arbitrary OS commands as the web server user, compromising server confidentiality, integrity, and availability. This issue is fixed in version 2.0.1.
A race condition in Epiphany allows a malicious website to bypass the TLS/SSL certificate warning page.
Epiphany registers the main-world script message handler "tlsErrorPage" so its internal TLS error page can implement "Accept Risk and Proceed". The handler was registered immediately before loading the error page, leaving a brief window where the previously loaded untrusted origin could still call window.webkit.messageHandlers.tlsErrorPage.postMessage(...). The only authorization check compares a numeric WebKit page id that increments predictably; an attacker can burst-guess ids and approve a certificate exception with no user click.
If a victim visits malicious site A that redirects to site B with an invalid certificate, site A can, for a few milliseconds, disable TLS certificate error warnings for host B until Epiphany is restarted, enabling man-in-the-middle or site spoofing for that host.
Upstream report: https://gitlab.gnome.org/GNOME/epiphany/-/work_items/2978
Proof of concept: https://beford.net/poc/ssl_poc.html
Fix: https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/2245 (register handlers on LOAD_COMMITTED). No fixed release tagged yet; reporter and maintainer describe all current versions as affected. Maintainer notes the risky registration timing dates to commit 1da1caed (Epiphany 45.x era); before that the handlers were always registered and similarly reachable from web content.
Moodle 4.2.0 through 4.5.15, 5.0.0 through 5.0.11, 5.1.0 through 5.1.8, 5.2.0 through 5.2.4, and 5.3.0 contain a missing capability check in the core_grades_get_gradeitems web service that allows enrolled students to view hidden grade items. Authenticated course users can call the AJAX or mobile web service to list hidden grade item ids, names, and categories that the gradebook conceals from them.
Jellyfin through 12.4 contains an authorization bypass vulnerability in SuggestionsController.GetSuggestions that allows authenticated non-administrator users to bypass library and parental restrictions by omitting the userId parameter. Attackers can repeatedly call GET /Items/Suggestions without userId to enumerate restricted items, including IDs and server filesystem paths, and then stream them.
The Gravity Forms plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 3.1.2 via a Post Custom Field whose input type is List. This is due to GFFormsModel::create_post() passing the submitted value to WordPress' unrestricted global maybe_unserialize() rather than the plugin's own hardened GFCommon::maybe_unserialize(), which was added in 3.1.1 and passes allowed_classes => false precisely to prevent object instantiation. Where the field has a content template enabled, the submitted row reaches that call verbatim. This makes it possible for unauthenticated attackers to inject a PHP object into post meta. No PHP Object Injection gadget chain is present in the plugin itself; however, if a gadget chain is present via an additional plugin or theme, it could allow the attacker to perform actions such as remote code execution. Where the custom field is mapped to the protected _wp_page_template meta key, WordPress itself supplies the chain: validate_file() accepts non-scalars, WP_Theme::__toString() then resolves an attacker-controlled path, and on hosts with a readable PEAR install and register_argc_argv enabled this yields remote code execution.
The Cool FormKit Lite – Advanced Form Builder for Elementor plugin for WordPress is vulnerable to Stored DOM-Based Cross-Site Scripting via the '_elementor_data.form_fields[].custom_id' parameter in all versions up to, and including, 2.7.9 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The esc_html() call applied at server emission is bypassed because the HTML fragment-serialization algorithm restores " to a raw double-quote inside text nodes when jQuery .html() extracts the template, allowing the attacker-controlled custom_id to break out of an HTML attribute context within the plugin's own frontend script.
UnixFileLock, used by FileLock and AsyncFileLock on Unix systems, truncates and can change permissions (chmod) of any regular file that another local user renames or hard-links onto the lock path. This occurs because UnixFileLock empties the file it finds at the lock path once it acquires the lock and applies an explicit mode if specified. The vulnerability requires another local user to rename or hard-link a file of the lock user onto the lock path before the lock user's next acquire call. This can lead to unintended truncation and permission changes, allowing the other user to read and modify the file contents thereafter. The issue affects all filelock releases up to and including 4.2.0, with the chmod behavior introduced since version 3.10.2. The vulnerability is mitigated by directory sticky bits and Linux kernel settings that restrict hard-link creation. A fix is available in filelock version 1.79.0_1.
A vulnerability in filelock versions 4.1.0 through 4.2.0 allows a local unprivileged user to exploit a race condition involving symbolic links in a shared lock directory without the sticky bit. This can lead to the creation of a hard link to another user's file, exposing metadata and enabling the attacker to manipulate the file's name. The issue arises due to the os.link call following symbolic links on CPython 3.12+ on Linux and macOS, combined with directory permissions that allow the attacker to replace lock files with symbolic links. The vulnerability has medium severity with a CVSS score of 5.3.
LangGraph Python SDK v3 streaming client versions 0.4.0 through 0.4.5 improperly handle unencoded thread_id and assistant_id values in request paths, allowing relative path segments to redirect authenticated GET requests to other paths on the same server. This affects both synchronous and asynchronous call sites in the get_tree and _fetch_state functions. The LangGraph Platform itself is not affected. Applications passing attacker-controlled identifiers may have responses redirected to attacker-chosen readable paths, but no write operations are possible. Upgrading langgraph-sdk to 0.4.6 or later and langgraph to 1.2.14 or later mitigates the issue.