wordpress-security-validation

Implement strict input validation on the MCP tool's parameters. Block tool calls that attempt to modify the agent's system prompt, configuration, or tool definitions.

Likely FP if the match is a tool that legitimately updates configuration (e.g., a settings manager) and mentions prompt editing only for user-facing customization.

Pin Git dependencies to specific commit hashes instead of branch names or tags. Branches and tags are mutable and can be updated to point to malicious code.

Likely FP if the Git reference points to a tagged release of a well-known repository, though tags are technically mutable.

Add input validation between the user-controlled data source and the security-sensitive sink (e.g., file writes, command execution). Implement allowlisting for acceptable input patterns.

Likely FP if the user input passes through explicit validation or sanitization before reaching the sensitive operation, and the taint tracker missed the sanitization step.

Isolate security-sensitive operations from untrusted data flows. Use separate execution contexts or privilege levels for operations that handle both user input and sensitive resources.

Likely FP if the toxic flow analysis connected two unrelated code paths, or if the data undergoes transformation that removes the taint (e.g., parsed as a known enum value).

Pin Cargo/Gem packages to specific versions (e.g., cargo install tool@0.1.0, gem install tool -v 1.2.3). Use lock files for reproducibility.

Likely FP if the matched text is a very short fragment (3 words or fewer) or uses placeholder package names.