Psalm 7 makes security analysis part of its default run, bringing checks for potentially dangerous data flows into the same pass as type checking. Daniil Gentili announced the PHP static analyser's release on November 2, 2026. For teams already using Psalm, an upgrade can therefore surface security findings without a separate scan. We reviewed the release notes and documentation; we haven't tested its detection accuracy or performance.
The announcement also identifies new checks for NoSQL and LLM prompt injection, alongside broader tracking through closures and generators. Those changes matter when untrusted input passes through application code before reaching an operation that uses it. A warning still needs investigation.
What the prompt-injection check establishes
Psalm's TaintedLlmPrompt documentation describes a warning when user-controlled input can reach an LLM prompt. Its example annotates a method's prompt parameter as an llm_prompt sink, then passes a query-string value into that method. That shows the data-flow relationship the analyser is looking for.
The page calls this a potential vulnerability. It doesn't demonstrate that a particular model obeyed an attack, or that an application exposed a tool or secret. Developers should read the warning as a reason to inspect how input reaches instructions and what the model can access. The documented mitigations include separating user input from instructions, restricting available data and tools, and treating model output as untrusted.
Check the analyser's runtime before changing application code
The upgrade guide says PHP 8.1 and 32-bit PHP are no longer supported for running Psalm. Code targeting older PHP versions can still be analysed. A legacy application's target version and the PHP installation running its analyser are separate upgrade decisions.
There is also a baseline detail worth reviewing: --update-baseline only removes resolved entries. The guide says to regenerate a baseline with --set-baseline=psalm-baseline.xml after upgrading. Review new findings before recording them, so a regenerated baseline doesn't obscure what the upgrade uncovered.
For plugin authors, the same guide warns that a minor or patch release may now break the plugin API. Plugins must depend on psalm/psalm-plugin-api; checking Psalm's version alone is no longer enough to express that compatibility requirement.
The next useful evidence will be how these default checks behave on teams' own code. Compare the reported paths with the application's actual input handling, and record scan time alongside findings. The release establishes a broader default scan; its value in a particular project depends on which warnings lead to fixes.