JetBrains PhpStorm allowed arbitrary code execution through the interpreter before project trust

In JetBrains PhpStorm before 2026.2 arbitrary code execution was possible before granting project trust via the configured interpreter

• JetBrains PhpStorm is affected from version 0 through versions less than 2026.2 under semver. The record's default status is unaffected outside that declaration.
• JetBrains' Fixed security issues page lists this issue as fixed in 2026.2.
• The available evidence does not independently describe the status of later or parallel release branches, so the fix should not be generalized to every unverified branch.

JetBrains PhpStorm could invoke the configured interpreter before the IDE granted project trust, allowing arbitrary code execution. The defect is at the boundary between handling an untrusted project and interpreter execution, and the record classifies it as CWE-829. The supplied assessment describes a local, low-complexity path requiring no prior privileges and no additional user interaction; these are scoring properties, not a description of a specific payload or trigger. The affected component is the configured interpreter execution path, but the record does not identify the interpreter implementation, project artifact, or exact execution sequence. The available evidence also does not establish whether all interpreter types or configurations behave identically.

The attack path is assessed as local, so an attacker needs the ability to affect a workstation running PhpStorm rather than direct network reachability. The supplied assessment states that no prior privileges, low complexity, and no additional user interaction are required. The record does not identify a public exploit; the returned CISA enrichment records exploitation as none and automatable as no within that assessment. No specific campaign, victim, or observed exploitation event is named in the available evidence.

Successful exploitation could provide arbitrary code execution in the PhpStorm process context. The supplied impact metadata indicates high confidentiality, integrity, and availability impact with unchanged scope. In practical terms, this could allow code to read or modify data accessible to the IDE account or disrupt the development workstation; the exact reachable resources depend on operating-system permissions and IDE configuration. The record does not describe network propagation or a change in scope to other systems.

Organizations should treat affected JetBrains PhpStorm installations as developer-workstation exposure. Successful exploitation could affect source code, local data, secrets, build artifacts, or other resources accessible to the IDE account. The practical blast radius is likely bounded by the local user's permissions, but those permissions may include repository, package-registry, or internal-service access depending on the workstation configuration; this is a possible consequence, not a confirmed incident scenario. The supplied evidence names no breach, victim, campaign, or ransomware activity.

1. Upgrade JetBrains PhpStorm to 2026.2, the release listed by JetBrains for this issue. Do not interpret this as confirmation that every later or parallel release branch has been independently verified.
2. Inventory all PhpStorm installations, including standalone and centrally managed deployments, and identify hosts running a version less than 2026.2.
3. Review hosts with a configured interpreter and prioritize installations that regularly open untrusted projects.
4. If an immediate update is not possible, apply organization-approved isolation or compensating controls. The supplied evidence does not define a product-specific mitigation or a confirmed safe procedure for disabling the interpreter.

1. Inventory workstations with JetBrains PhpStorm installed and compare each installation with the affected version boundary. This is the primary exposure check.
2. Review IDE settings to identify hosts with a configured interpreter, and record projects that may be opened before project trust is granted.
3. On hosts under investigation, review endpoint and process telemetry around PhpStorm for unexpected code execution. Treat this as precautionary monitoring, not as a confirmed indicator of compromise.
4. Preserve IDE settings, project artifacts, and endpoint telemetry during an investigation. The record provides no specific file path, command, log event, or IOC, so the absence of one particular log entry must not be treated as proof of safety.