All tracked items across vulnerabilities, news, research, incidents, and regulatory updates.
A critical vulnerability in marked@18.0.0 allows an unauthenticated attacker to crash any Node.js application using this library by sending just 3 special characters (a tab, vertical tab, and newline). These characters trick the parser into infinite recursion (a function calling itself endlessly), which allocates memory indefinitely until the application runs out of memory (OOM, or out-of-memory error) and crashes.
OpenClaw versions before 2026.4.15 had a security flaw where the webchat audio embedding feature could read local files from the host system without proper security checks. An attacker who could control the output of an agent or tool could trick the system into embedding audio files from the host into chat responses, bypassing the containment restrictions that protect other file-serving paths.
A vulnerability in n8n (a workflow automation tool) allows authenticated users to exploit the XML Node through prototype pollution (a technique where an attacker modifies object properties that affect all instances of that object type) to achieve RCE (remote code execution, where attackers can run arbitrary commands on the system). This is particularly dangerous because it affects users with permission to create or edit workflows.
n8n had a vulnerability in its XML webhook parser caused by the `xml2js` library that allowed prototype pollution (a type of attack where an attacker modifies a JavaScript object's base properties to affect all objects). An authenticated user with workflow creation permissions could exploit this flaw and combine it with the Git node's SSH operations to achieve RCE (remote code execution, where an attacker runs commands on a system they don't own).
n8n (a workflow automation tool) has a vulnerability where an attacker could inject malicious code through a fake OAuth client name, causing it to run in a victim's browser when they revoke access. This XSS (cross-site scripting, injecting malicious code into a webpage) attack could let attackers steal login credentials, take over sessions, or modify workflows.
n8n (a workflow automation tool) had a security flaw where authenticated users could steal API keys belonging to other users by exploiting the `dynamic-node-parameters` endpoints (parts of the system that handle credential references). An attacker with access to a shared workflow could submit another user's credential ID and trick the backend into sending that credential to a server the attacker controls, allowing them to capture and reuse the stolen API key.
n8n (a workflow automation tool) has a vulnerability where authenticated users who can create or modify workflows can escape the sandbox (an isolated environment meant to restrict code execution) and run arbitrary code on the task runner container, but only if the Python Task Runner feature is enabled.
n8n, a workflow automation tool, had a security flaw where authenticated users with an API key could read variables (data storage containers) from projects they shouldn't have access to by manipulating a query parameter, potentially exposing secrets like passwords or tokens. This vulnerability only affected enterprise or team deployments with multiple projects enabled.
n8n has a vulnerability where an unauthenticated attacker can crash an n8n instance (a workflow automation tool) by sending large amounts of data to the MCP OAuth client registration endpoint (the system that lets external applications connect to n8n). The endpoint doesn't properly limit how much data it accepts or how many clients can register, allowing attackers to use up all the server's memory and make it unavailable.
n8n's Chat Trigger feature had a security flaw where the `/chat` WebSocket endpoint (a communication channel) didn't check if users were authorized to access workflow executions. An attacker who could guess a valid execution ID (a unique identifier for a running workflow instance) could connect to an unprotected chat workflow, intercept prompts meant for legitimate users, and inject their own commands to change how the workflow behaves.
A SQL injection (inserting malicious code into database queries) flaw in n8n's SeaTable node allowed attackers to manipulate search and row retrieval operations when user-controlled input was passed into the node without proper safeguards, potentially exposing unintended database rows. The vulnerability required a specific workflow setup where external input from sources like forms or webhooks was directly used in search parameters.
n8n has a vulnerability where its OAuth consent flow allows attackers to register fake redirect URLs (destinations where users are sent after denying permission) without authentication. An attacker can trick a user into clicking a malicious link, and when the user clicks "Deny" on the consent dialog, they get redirected to the attacker's website instead of staying safe. This could be used for phishing (tricking users into giving up sensitive information).
n8n, a workflow automation tool, had a SQL injection vulnerability (a type of attack where malicious SQL commands are inserted into input fields) in its Oracle Database node. The flaw allowed attackers to inject arbitrary SQL commands through the `Limit` field when external user input was used, potentially letting them steal data from the connected Oracle database.
n8n's Snowflake and MySQL v1 nodes have a SQL injection vulnerability (a type of attack where malicious SQL code is inserted into input fields) because they directly insert user-controlled table and column names into database queries without proper protection. An attacker who can create workflows could use this to steal, change, or delete data in the connected database.
Google reported record-breaking search queries in Q1 2026, with CEO Sundar Pichai attributing the growth to AI investments and new AI experiences integrated into their products. The company saw 19% revenue growth in search, over 350 million paid subscriptions across services like Gemini App and YouTube, and Pichai highlighted this as their strongest quarter for consumer AI products.
The OneCollector exporter (a tool that sends telemetry data, which is information about how a program is running, to a backend server) has a flaw where it reads error responses from failed HTTP requests without limiting how much data it accepts. If an attacker controls the backend server or intercepts the connection, they can send an extremely large response that exhausts the application's memory and crashes it (a denial-of-service attack, where a system is made unavailable).
LLM 0.32a0 is an alpha release that redesigns how the LLM Python library handles inputs and outputs to better support modern AI models. Instead of the old simple text-in, text-out model, it now represents conversations as sequences of messages (with user and assistant roles) and allows responses to contain different types of content, making it easier to work with APIs like OpenAI's chat completions.
This is a brief announcement about llm version 0.32a0, posted by Simon Willison on April 29, 2026. The post appears to be part of a monthly briefing series covering important LLM developments, with an option for readers to sponsor the author for curated updates.
Fix: Upgrade to OpenClaw version 2026.4.15 or later (the latest public release 2026.4.21 also contains the fix). The fix works by adding the local media root containment check to the webchat audio path and calling `assertLocalMediaAllowed` before reading local audio content. An additional `trustedLocalMedia` gate was added to prevent untrusted model or tool outputs from accessing local audio embedding.
GitHub Advisory DatabaseFix: The vulnerability has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1 or later. If immediate upgrade is not possible, administrators can temporarily: (1) Limit workflow creation and editing permissions to fully trusted users only, or (2) Disable the XML node by adding `n8n-nodes-base.xml` to the `NODES_EXCLUDE` environment variable. The source notes these workarounds do not fully remediate the risk and are only short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later. If upgrading is not immediately possible, administrators should limit workflow creation and editing permissions to fully trusted users only, though this is only a temporary mitigation and does not fully remediate the risk.
GitHub Advisory DatabaseFix: This issue has been fixed in n8n version 2.14.2. Users should upgrade to this version or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should restrict access to the n8n instance and the MCP OAuth registration endpoint to trusted users only, or disable MCP server functionality if not actively required. However, the source notes these workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n version 2.18.0. Users should upgrade to this version or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should restrict n8n access to fully trusted users only and avoid sharing workflows with users who should not have access to the credentials those workflows reference. The source notes these workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later. As temporary workarounds if upgrading is not immediately possible, administrators can limit workflow creation and editing permissions to fully trusted users only, or disable the Python Code node by adding `n8n-nodes-base.code` to the `NODES_EXCLUDE` environment variable, or disable the Python Task Runner entirely. However, the source notes these workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should restrict n8n access and API key issuance to fully trusted users only, and audit existing project variables for sensitive values and rotate any secrets that may have been exposed (though these workarounds do not fully remediate the risk and should only be used as short-term mitigation measures).
GitHub Advisory DatabaseFix: Upgrade to n8n version 1.123.32, 2.17.4, 2.18.1, or later. If immediate upgrade is not possible, administrators can temporarily: (1) restrict network access to the n8n instance to prevent requests from untrusted sources, or (2) reduce the maximum accepted payload size by lowering the `N8N_PAYLOAD_SIZE_MAX` environment variable from its default value. The source notes these workarounds do not fully fix the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later. As a temporary workaround, administrators can enable authentication on all Chat Trigger nodes by setting the Authentication field to `n8n User Auth` rather than `None`, though this does not fully eliminate the risk.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later. If upgrading is not immediately possible, temporary mitigations include: restricting workflow creation and editing permissions to trusted users only; disabling the SeaTable node by adding `n8n-nodes-base.seaTable` to the `NODES_EXCLUDE` environment variable; and avoiding unvalidated external user input in SeaTable node parameters.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later. If upgrading is not immediately possible, administrators can restrict network access to the n8n instance to prevent untrusted users from reaching the MCP OAuth endpoints, or limit access to the n8n instance to fully trusted users only. However, the source notes these workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, temporary mitigations include: limiting workflow creation and editing permissions to fully trusted users only, disabling the Oracle Database node by adding `n8n-nodes-base.oracleDatabase` to the `NODES_EXCLUDE` environment variable, and avoiding passing unvalidated external user input into the Oracle Database node's `Limit` field via expressions. The source notes these workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later. If immediate upgrade is not possible, temporary workarounds include: limit workflow creation and editing permissions to trusted users only; migrate from the legacy MySQL v1 node to MySQL v2 node, which has identifier escaping (protection against SQL injection); disable the Snowflake node by adding 'n8n-nodes-base.snowflake' to the 'NODES_EXCLUDE' environment variable; and avoid passing unvalidated external user input into table name, column name, or update key fields in the affected nodes. The source notes these workarounds do not fully remediate the risk and should only be used as short-term measures.
GitHub Advisory DatabaseFix: Update to the version with PR #4117 applied, which limits the number of bytes read from error response bodies to 4MiB (megabytes). Additionally, use network-level controls like firewall rules, mTLS (mutual TLS, a security protocol for encrypting connections), or a service mesh to prevent Man-in-the-Middle attacks on the configured backend/collector endpoint.
GitHub Advisory DatabaseStarting with GPT-5.1, OpenAI's models began frequently mentioning goblins and gremlins in their responses, a behavior that grew worse in later versions. The root cause was discovered to be the training process for the "Nerdy" personality feature, which unknowingly gave high rewards for outputs containing creature metaphors, causing the model to learn and amplify this quirk over time. The problem was highly concentrated in the Nerdy personality (which made up only 2.5% of responses but accounted for 66.7% of goblin mentions), and was identified through comparing model outputs and analyzing which reward signals (scoring systems that guide AI training) favored creature-word language.
This document outlines how to build safety and trust into AI applications using Amazon Bedrock (AWS's generative AI service) by following a responsible AI framework. Organizations that implement responsible AI practices see significant business benefits, including 82% improvement in employee trust and 25% increase in customer loyalty. Safety should be integrated throughout the AI development lifecycle across three phases: design and development (evaluating risks and building guardrails), deployment (implementing multiple layers of protection including red team testing, which simulates attacks to find vulnerabilities), and operations (continuous monitoring and adaptation as technology and usage patterns evolve).
Fix: The source text describes approaches rather than specific technical fixes. For the design and development phase, it recommends thoroughly evaluating safety risks, understanding application capabilities and limits, and building safety guardrails from the beginning. For deployment, it recommends implementing robust safety measures through multiple layers including comprehensive user training, proactive monitoring and review processes, clear safety protocols and user guidelines, and red team testing. For the operations phase, it recommends implementing real-time feedback mechanisms, conducting regular performance evaluations, and continuously monitoring for shifts in application usage or functions that could compromise safety.
AWS Security Blog