Review a FastMCP security report

A working proof of concept establishes behavior, not ownership or classification. Identify the component that violates a promised security boundary before changing code or advisory state.

Preserve the evidence

Before editing an advisory, export the report, comments, proof of concept, configuration, and claimed affected versions. Record the reproduced commit and derive affected releases from history.

Keep the investigation read-only until classification. Do not mutate the advisory or prepare a fix merely because the proof of concept works.

Reproduce the claim

Use the smallest end-to-end reproduction against a supported release. Record:

• defaults, non-default arguments, environment, and deployment assumptions;
• what the attacker controls, what the victim does, and what authority the attacker gains;
• the check or trust boundary allegedly bypassed; and
• whether the attacker's prerequisites already provide equal or greater authority than the claimed impact.

A non-default configuration may still be vulnerable; a default may intentionally delegate a security decision elsewhere.

Identify the responsible layer

• FastMCP vulnerability: FastMCP violates a promised boundary in a supported configuration.
• FastMCP bug: FastMCP behaves incorrectly without creating attacker capability.
• Upstream vulnerability: The defect belongs to a standard, dependency, identity provider, client, proxy, or platform.
• Insecure deployment: The operator omits, disables, or delegates a required control without supplying the replacement required by its contract.
• Expected behavior: The result follows the documented API contract or protocol.
• Documentation gap: The implementation follows its intended contract, but the guidance creates a reasonable expectation of protection.