Code Execution via Untrusted Angular CLI Schematics Loader in WebStorm

In JetBrains WebStorm before 2026.3, 2026.2.4 code execution was possible in untrusted projects via the Angular CLI schematics loader

Altair: DOM-based XSS via attacker-controlled script URLs in the iframe sandbox

Altair is a GraphQL client for all platforms. From 7.2.4 until 8.5.8, packages/altair-iframe-sandbox/src/main.ts reads plugin_sandbox_opts from the iframe-sandbox query string and passes attacker-controlled scriptUrls to injectScript() in packages/altair-core/src/utils/inject.ts, which creates script elements in the page. The intended parent iframe flow places the page in an iframe with sandbox allow-scripts and without allow-same-origin, but direct navigation to a crafted iframe-sandbox URL omits that isolation and executes the supplied script in the origin serving Altair. Exploitation requires a victim to open the crafted URL, and the resulting script can access script-readable storage and make same-origin requests according to the deployment's authentication and cookie controls. This issue is fixed in version 8.5.8.

IRISPowerscan Insufficient restriction of untrusted scripts allows arbitrary code execution

IRISPowerscan insufficiently restrict the use of untrusted scripts. An authenticated user with access to script functionality can import or modify scripts that are executed by the application, potentially resulting in arbitrary code execution in the security context of the Windows user running IRISPowerscan.

operator-foundry: operator-foundry: GitHub Actions and reusable workflow not pinned to commit SHA

A flaw was found in operator-foundry. GitHub Actions and reusable workflows within the component are referenced using mutable tags (e.g., `@v0`, `@v4`) instead of fixed commit SHAs. This allows an attacker to potentially alter the code executed in the Continuous Integration (CI) pipeline through an upstream compromise or by re-pointing a tag, leading to unauthorized code execution or manipulation.

operator-sdk-builder: operator-sdk-builder: Base image referenced by mutable tag rather than sha256 digest

A flaw was found in operator-sdk-builder. The software uses a flexible label, called a mutable tag, to identify its base container image instead of a unique, fixed identifier. This practice allows the underlying base image to change unexpectedly between builds. Such a change could introduce vulnerabilities or malicious code into the build process, posing a supply chain integrity risk.

konflux-operator-tasks: konflux-operator-tasks: GitHub Actions referenced by mutable tag/branch instead of commit SHA

A flaw was found in konflux-operator-tasks. GitHub Actions within this component are configured to use mutable tags or branches instead of specific, immutable commit SHAs. This vulnerability could allow a remote attacker to introduce malicious code into the build process if they compromise the referenced mutable tag or branch. Such a compromise could lead to unauthorized code execution or integrity issues within the affected system.

Black: GitHub Action installs unvalidated required-version from pyproject.toml

Black is the uncompromising Python code formatter. Prior to 26.10.1, the Black GitHub Action with use_pyproject: true accepts tool.black.required-version from pyproject.toml without validating that it is a released Black version specifier. An attacker who can submit a pull request can change that field to a direct reference to attacker-controlled code, causing the workflow to install and execute the code in the victim repository's GitHub Actions context. This issue is fixed in version 26.10.1.

Mistral Vibe before 3.0.3 RCE via Repository-Configured gpg.program

Mistral Vibe before 3.0.3 contains a remote code execution vulnerability that allows attackers to run commands by abusing repository-configured gpg.program during project context collection. A crafted repository setting gpg.program and log.showSignature with a signed commit makes git log execute the attacker's program at session start, before any trust prompt.

Mistral Vibe before 2.25.7 Code Execution via Git Filter Drivers

Mistral Vibe before 2.25.7 contains a remote code execution vulnerability that allows attackers to run commands by configuring malicious Git clean or process filter drivers in a repository. When a user opens a crafted repository, ProjectContextProvider._fetch_git_status runs git status at startup, invoking the filters and executing commands with user privileges before any trust prompt.

PyCharm Safe Mode Code Execution via Jupyter Widget Module

In JetBrains PyCharm before 2026.3 code execution was possible in Safe Mode via a crafted Jupyter notebook widget module

Code Execution via Untrusted Grunt/Gulp Task Loading in WebStorm

In JetBrains WebStorm before 2026.3, 2026.2.3 code execution via Grunt and Gulp task loading was possible in untrusted projects

Code Execution via Project‑Controlled JVM Options in IntelliJ IDEA Safe Mode

In JetBrains IntelliJ IDEA before 2026.3, 2026.2.2 code execution was possible in Safe Mode via project-controlled JVM options of the build process

In JetBrains CLion before 2026.2 code execution was possible in Safe Mode via JSON compilation database

Code Execution via Unsafe Meson Project Settings in JetBrains CLion Safe Mode

In JetBrains CLion before 2026.2, 2026.1.4 code execution was possible in Safe Mode via Meson project settings

Untrusted Remote Code Inclusion via Plugin Sandbox Page in JetBrains YouTrack

In JetBrains YouTrack before 2025.3.170763, 2026.1.14150, 2026.2.19656 inclusion of untrusted remote code was possible via the plugin sandbox page

In JetBrains CLion before 2026.3, 2026.2.4.1 code execution was possible in Safe Mode via a crafted GDB server debug profile

Distributed-workloads: github actions pinned by mutable tag/branch, including third-party snyk/actions/setup@master

A flaw was found in distributed-workloads. A remote attacker could exploit a vulnerability in the pull_request_target workflow by submitting a specially crafted pull request. This workflow processes untrusted code from the pull request author while operating with the base repository's sensitive secrets, such as the SNYK_TOKEN, and its default write token. Consequently, an attacker could exfiltrate these secrets, leading to unauthorized access to the Snyk integration and potential control over the repository.

Untrusted Project Auto‑Upload to Deployment Server

In JetBrains PhpStorm before 2026.3 project files could be automatically uploaded to a deployment server from untrusted projects

Gitea Actions fork workflow trust through pull request review commit

Workflows triggered by a pull request review were read from the commit named in the review's `commit_id`, while the fork restrictions were decided by the reviewed pull request, and the commit was not checked to belong to that pull request. A user with read access to a repository could place a commit of their own in it, through a fork pull request or an AGit push, and submit a review naming that commit on a pull request whose head branch is in the same repository. On instances with a runner serving the repository, the attacker's workflow then ran without approval, received the Actions secrets of the repository and its owner, and got a `GITEA_TOKEN` with write access to the repository. Review-triggered workflows now run on the pull request head.

Wildfly: wildfly-iiop: wildfly-ejb3: wildfly: authentication bypass on iiop ejb invocations as csiv2 ittprincipalname accepted without transport binding

A flaw was found in Wildfly. A remote attacker can bypass authentication on IIOP EJB invocations as the CSIv2 security interceptor accepts ITTPrincipalName identity assertions in the service context without verifying transport-level authentication, allowing a pre-auth attacker on the port 3528 to impersonate any principal on every IIOP-exposed @Remote EJB.