FastGPT is an AI Agent building platform. Prior to 4.15.0-beta1, the JavaScript sandbox worker at projects/code-sandbox/src/pool/worker.ts:356 blocks dynamic import() with the regex /\bimport\s*\(/.test(code). JavaScript syntax accepts a block comment between import and (; the regex matches only ASCII whitespace, and the bytes /, *, *, / are not in the \s character class. The payload import/**/("child_process") parses as a syntactically valid dynamic import that the regex does not detect. Because import() is not wrapped by the safeRequire Proxy (which only proxies require), the attacker loads child_process and calls execSync - arbitrary command execution as uid=100(sandbox) inside the sandbox container. This vulnerability is fixed in 4.15.0-beta1.

FastGPT is an AI Agent building platform. Prior to version 4.14.17, FastGPT had an inconsistent SSRF protection gap in MCP tool URL handling. The direct MCP preview/run endpoints already rejected internal/private network URLs, but the MCP tool create/update endpoints could still save an internal MCP server URL. That stored URL could later be used by workflow execution without revalidating the destination. An authenticated user with permission to create or manage MCP toolsets could store an internal endpoint such as http://localhost:3000/mcp and later cause the FastGPT backend workflow runner to connect to that internal destination. This issue has been patched in version 4.14.17.

FastGPT is an AI Agent building platform. In 4.14.7 and earlier, FastGPT's Python Sandbox (fastgpt-sandbox) includes guardrails intended to prevent file writes (static detection + seccomp). These guardrails are bypassable by remapping stdout (fd 1) to an arbitrary writable file descriptor using fcntl. After remapping, writing via sys.stdout.write() still satisfies the seccomp rule write(fd==1), enabling arbitrary file creation/overwrite inside the sandbox container despite the intended no file writes restriction.

Sealos is an open source cloud operating system distribution based on the Kubernetes kernel. In versions of Sealos prior to 4.2.1-rc4 an improper configuration of role based access control (RBAC) permissions resulted in an attacker being able to obtain cluster control permissions, which could control the entire cluster deployed with Sealos, as well as hundreds of pods and other resources within the cluster. This issue has been addressed in version 4.2.1-rc4. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Code by Zapier before 2022-08-17 allowed intra-account privilege escalation that included execution of Python or JavaScript code. In other words, Code by Zapier was providing a customer-controlled general-purpose virtual machine that unintentionally granted full access to all users of a company's account, but was supposed to enforce role-based access control within that company's account. Before 2022-08-17, a customer could have resolved this by (in effect) using a separate virtual machine for an application that held credentials - or other secrets - that weren't supposed to be shared among all of its employees. (Multiple accounts would have been needed to operate these independent virtual machines.)

LiquidFiles before 4.1.2 supports FTP SITE CHMOD for mode 6777 (setuid and setgid), which allows FTPDrop users to execute arbitrary code as root by leveraging the Actionscript feature and the sudoers configuration.

In Apache Iceberg, the table's metadata files are control files: they tell readers which data files belong to the table and which table version to read. `write.metadata.path` is an optional table property that tells Polaris where to write those metadata files. For a table already registered in a Polaris-managed catalog, changing only that property through an `ALTER TABLE`-style settings change (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses the commit-time branch that is supposed to revalidate storage locations. The full persisted / credential-vending variant requires the affected catalog to have `polaris.config.allow.unstructured.table.location=true`, with `allowedLocations` broad enough to include the attacker-chosen target. `allowedLocations` is the admin-configured allowlist of storage paths that the catalog is allowed to use. Public project materials suggest that this flag is a real supported compatibility / layout mode, not just a contrived lab-only prerequisite. In that configuration, a user who can change table settings can cause Apache Polaris itself to write new table metadata to an attacker-chosen reachable storage location before the intended location-validation branch runs. If the later concrete-path validation also accepts that location, Polaris persists the resulting metadata path into stored table state. Later table-load and credential APIs can then return temporary cloud-storage credentials for the same location without revalidating it. In plain terms, Polaris can later hand out temporary storage access for the same attacker-chosen area. That attacker-chosen area does not need to be limited to the poisoned table's own files. If it is a broader storage prefix, another table's prefix, or, depending on configuration or provider behavior, even a bucket/container root, the resulting disclosure or corruption scope can extend to any data and metadata Polaris can reach there. The practical consequences are therefore similar to the staged-create credential-vending issue already discussed: data and metadata reachable in that storage scope can be exposed and, if write-capable credentials are later issued, modified, corrupted, or removed. Even before that later credential step, Polaris itself performs the metadata write to the unchecked location. So the core issue is not only later credential vending. The primary defect is that Polaris skips its intended location checks before performing a security- sensitive metadata write when only `write.metadata.path` changes. When `polaris.config.allow.unstructured.table.location=false`, current code review suggests the later `updateTableLike(...)` validation usually rejects out-of-tree metadata locations before the unsafe path is persisted. That may reduce the persisted / credential-vending variant, but it does not prevent the underlying defect: Polaris still skips the intended pre-write location check when only `write.metadata.path` changes.

OpenClaw versions prior to 2026.3.1 fail to enforce sandbox inheritance during cross-agent sessions_spawn operations, allowing sandboxed sessions to create child processes under unsandboxed agents. An attacker with a sandboxed session can exploit this to spawn child runtimes with sandbox.mode set to off, bypassing runtime confinement restrictions.

Under certain conditions SAP NetWeaver AS for ABAP and ABAP Platform (Internet Communication Framework) allows an attacker to access restricted information due to weak access controls. This can have a significant impact on the confidentiality, integrity, and availability of an application

Hitachi Vantara Pentaho Data Integration & Analytics versions before 10.2.0.6 and 11.0.0.0, including 9.3.x and 8.3.x, does not apply ACLs on certain API endpoints related to platform mail notfications.

SAP BusinessObjects Business Intelligence Platform (Promotion Management) - versions 420, 430, under certain condition allows an authenticated attacker to view sensitive information which is otherwise restricted. On successful exploitation, the attacker can completely compromise the application causing high impact on confidentiality, integrity, and availability.

Plone through 5.2.4 allows remote authenticated managers to perform disk I/O via crafted keyword arguments to the ReStructuredText transform in a Python script.

Incorrect Permission Assignment for Critical Resource vulnerability in PruvaSoft Informatics Apinizer Management Console allows Accessing Functionality Not Properly Constrained by ACLs. This issue affects Apinizer Management Console: before 2024.05.1.

When creating a journal entry template in SAP S/4HANA (Manage Journal Entry Template) - versions S4CORE 104, 105, 106, 107, an attacker could intercept the save request and change the template, leading to an impact on confidentiality and integrity of the resource. Furthermore, a standard template could be deleted, hence making the resource temporarily unavailable.