Security Triage

Symfony Security Triage

Decides how a finding is handled, not whether the code is wrong. It complements symfony-security-review (which finds missing hardening) by making the disclosure call on a report.

The three dispositions and the conventions that record them:

This skill produces a recommendation. The final call belongs to the Symfony security team; treat its output as a structured argument, and defer to symfony.com/security for the authoritative "what is not a vulnerability" list.

Progress checklist

• Step 0: Establish the facts (reproduce, scope, trust model)
• Step 1: Apply the disposition decision tree
• Step 2: Assign severity and affected maintained branches
• Step 3: Route (branch prefix, labels, next workflow, reporter reply)

Confirmation rule

Whenever this skill says "Wait for confirmation", treat anything other than an explicit affirmative as no: stop and ask the user how they want to proceed.

---

Step 0 — Establish the facts

Before classifying, pin down four things. Guessing any of them produces a wrong call.

1. Reachability: is the vulnerable code on a path reachable from untrusted input in a default configuration, or does it need opt-in/insecure config?
2. Actor and precondition: what must the attacker already have? Unauthenticated and remote is the worst case; "already controls the serialized bytes" or "already has the app secret" usually means the precondition is itself game-over.
3. Impact: RCE, auth/authz bypass, SSRF to internal, signature/secret bypass that accepts forged input, XSS on a default-rendered surface, secret disclosure, open redirect, session fixation, or "only" DoS / info of low value.
4. Contract: is the component meant to defend this boundary (router, HttpFoundation/HttpClient, Security, webhook verification, HtmlSanitizer, Mime parsing), or is the unsafe behaviour documented as the caller's responsibility (deserializing untrusted bytes, a trusted-channel feature such as ESI, template_from_string)?

Reproduce if at all possible; an unreproducible report is not yet triable.

Step 1 — Disposition decision tree

Apply in order. The first matching bucket wins.

It is not a security issue if any of these hold

• Pure DoS / resource exhaustion. Generally excluded from the CVE pipeline. Fix as hardening with a limit if cheap, but no CVE.
• Requires misuse contrary to documentation, with no default-config attack. The component is not contracted to defend this (e.g. deserializing untrusted bytes through an API documented as trusted-only; using a trusted-channel feature to reach internal hosts).
• Dev-only tooling (profiler, debug, web-profiler) manifesting only in a dev environment.
• Precondition is already game-over (attacker already holds the app secret, controls the deserialized input contract, or has local/physical access).
• Not reproducible, or rooted in a third-party dependency outside Symfony's control.
• Not a realistic bypass (a comparison nuance with no working exploit, etc.).

It is a CVE only if all of these hold

1. Default-reachable: exploitable against a default or documented-safe config.
2. Expected actor: the attacker is at or below the trust level the boundary is meant to enforce (typically unauthenticated/remote, or a lower-privileged user escalating), with no game-over precondition.
3. Contracted boundary: the component is meant to defend this (see Step 0.4).
4. Real impact: RCE, auth/authz bypass, SSRF to internal, sanitizer/signature bypass accepting forged input on a sensitive sink, stored/reflected XSS on a default surface, secret disclosure, or open redirect with meaningful reach.
5. Maintained: the vulnerable code ships in a maintained version.

Otherwise it is public hardening

A genuine improvement where a CVE condition fails. Typical shapes:

• Defense-in-depth on top of an existing control, or that only matters once another bug already holds (an __unserialize __toString trampoline guard needs a pre-existing untrusted unserialize() entry to matter).
• Safer-default change where the old default was not a vulnerability under the threat model (adding a webhook IP allowlist, pinning the HMAC algorithm).
• Limited impact or exposure even though a boundary is technically crossed (a forged webhook against an opt-in endpoint with a user-configured secret injects only a delivery-status event).
• Robustness improvements (input-length caps, broader sanitizer coverage).

Step 2 — Severity and affected branches

Severity (match the low/medium/high labels; CVSS is a sanity check, not the goal):

• high: unauthenticated RCE, auth bypass, full sanitizer bypass enabling stored XSS, SSRF reaching internal services.
• medium: reflected XSS, open redirect, signature bypass with bounded impact, info disclosure of non-trivial data.
• low: defense-in-depth, narrow-config or low-impact issues, most hardening.

Affected branches: find the oldest version where the vulnerable code exists, intersect with maintained_versions from https://symfony.com/releases.json. Fix on the lowest maintained affected branch, then merge up (see the merge-up skill). Record the oldest exposure even if it predates maintained versions.