@raishin/vanguard-frontier-agentic 3.1.1 → 3.3.0

package/skills/php/php-session-upload-deserialization-review/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: php-session-upload-deserialization-review
+description: Use this skill to statically review PHP code for object-injection risk from unserialize() on untrusted input, session fixation/hijacking from missing session_regenerate_id() or weak session cookie hardening, and unsafe file-upload handling that trusts the client or stores/executes uploads inside the webroot. Use when reviewing a PHP application for deserialization, authentication-session, or upload-handling security issues. Static review only; it never executes payloads, uploads, or requests against any system, and every unserialize()/session/upload claim is grounded in the current php.net manual rather than memory.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-16"
+  category: security
+  lifecycle: experimental
+---
+
+# PHP Session, Upload, and Deserialization Review
+
+## Purpose
+
+Review PHP source for the three failure modes where the language's own deserialization, session, and file-upload primitives are used in a way php.net's own manual explicitly warns against: `unserialize()` called on untrusted input (object injection, potentially remote code execution), a session that is not regenerated after a privilege change or that ships without cookie hardening (fixation/hijacking), and an upload handler that trusts the client or stores/executes accepted files inside the webroot.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review any code path that calls `unserialize()`, or a library/cache/session backend that transparently unserializes stored data, for object-injection risk;
+- review whether a login, role-elevation, or password-reset path correctly regenerates the session id and whether session cookie hardening (`use_strict_mode`, `httponly`, `secure`, `samesite`) is configured;
+- review a file-upload handler for client-trust, storage-location, or size/type/count-limit gaps.
+
+## When not to use
+
+Do not use this skill for:
+
+- designing or approving a backend authorization/permission model — this skill only checks whether a privilege change triggers session regeneration, not whether the privilege model itself is correct; hand that off to the owning backend/platform specialist.
+- executing, crafting, or sending any deserialization payload, session-fixation request, or file upload against any live, sandbox, or staging system. This skill is static review only.
+- issuing a compliance or audit attestation from an OWASP category mapping; the mapping is a classification aid, never a determination.
+
+## Preconditions
+
+- The code paths that call `unserialize()`, plus the source of the data passed to each call (request body/query/cookie, cache backend, queue message, database column).
+- The authentication/session-management code, specifically where `session_start()`, `session_regenerate_id()`, and `$_SESSION` writes occur relative to a login, role change, or password reset.
+- The active `session.*` INI settings in scope (`session.use_strict_mode`, `session.cookie_httponly`, `session.cookie_secure`, `session.cookie_samesite`) from `php.ini`, `.htaccess`, or runtime `ini_set()` calls.
+- The upload-handling code: how `$_FILES` is validated, where accepted files are stored, and the `upload_max_filesize`/`post_max_size`/`max_file_uploads` configuration in effect.
+- The PHP version in scope (`session.cookie_samesite` requires PHP 7.3+; destructor-on-fatal-error behavior changed at PHP 5.3.10).
+
+## Lean operating rules
+
+- Flag any `unserialize()` call on untrusted input regardless of `allowed_classes` — the manual's caution applies unconditionally, and `allowed_classes` narrows instantiable classes without making the call safe.
+- Name the reachable magic-method surface (`__wakeup()`, `__unserialize()`, `__destruct()`) for any class an untrusted `unserialize()` call could instantiate; PHP invokes these automatically on the reconstructed object or during the shutdown sequence.
+- Recommend `json_decode()`/`json_encode()` as the default remediation for untrusted data interchange unless serialized PHP objects are confirmed necessary.
+- Require `session_regenerate_id(true)` before the authenticated flag is written to `$_SESSION` on every login/elevation/reset path; a regeneration call placed after that write is a finding, not a pass.
+- Check `session.use_strict_mode`, `session.cookie_httponly`, `session.cookie_secure`, and `session.cookie_samesite` individually and explicitly; never infer hardening from defaults, since `use_strict_mode` is disabled by default.
+- Require upload handlers to validate the file's actual content server-side (never the client-supplied `$_FILES[...]['type']` or filename alone), store accepted files outside any web-servable path, and enforce `upload_max_filesize`, `post_max_size`, and `max_file_uploads`.
+- Never request, echo, store, or reproduce a secret, credential, session id, token, or PII found in reviewed code; redact-and-flag any such string.
+- Label every claim `repo evidence` (seen in the reviewed code) or `documentation-based` (current php.net manual); never assert a documented API behavior from memory.
+
+## Context7 documentation protocol
+
+This skill's `allowed-tools` is limited to `Read`, `Grep`, and `Glob` — it does not include a live documentation-lookup tool, so grounding is done against the bundled, php.net-sourced reference files rather than a runtime Context7 call. `unserialize()`, the `session.*` INI directives, and the upload-handling behaviors reviewed here are core-language documentation, not a third-party library whose API shifts release to release, so the bundled references (each fetched directly from php.net, with its own Sources section and verification date) are the grounding source of record. If a review surfaces a claim about PHP behavior not covered by the bundled references — a different function, a different INI directive, a different PHP version's behavior — do not assert it from memory; say the claim is unverified against a specific php.net page and escalate for direct verification rather than guessing.
+
+## Workflow
+
+1. Enumerate every `unserialize()` call site in scope and trace the data source of its argument; classify each as untrusted-input-reachable or not.
+2. For each untrusted-input-reachable `unserialize()` call, identify classes it could instantiate and check for `__wakeup()`, `__unserialize()`, and `__destruct()` magic methods that would fire automatically — see [Unserialize object injection](references/unserialize-object-injection.md).
+3. For each authentication/privilege-elevation path, confirm `session_regenerate_id(true)` is called before `$_SESSION` carries the authenticated flag, and check the four session-hardening directives — see [Session security](references/session-security.md).
+4. For each upload handler, confirm server-side content validation, non-webroot storage, and enforced size/type/count limits — see [File upload security](references/file-upload-security.md).
+5. Emit findings with evidence tiers, exploit/failure narratives, remediation, verification steps, and OWASP category mappings; hand off any authorization-model or infrastructure-scoped issue to the owning specialist.
+
+## Decision gates
+
+- Block only on a demonstrated untrusted-input-reachable `unserialize()` call, a missing/misordered `session_regenerate_id()` call, a missing `session.use_strict_mode`, or an upload handler that trusts the client, stores inside the webroot, or lacks enforced limits.
+- Every `unserialize()`, session-directive, or upload-limit claim cites the current php.net manual (`documentation-based`) or the reviewed code (`repo evidence`) — never memory.
+- Every OWASP mapping names the specific edition and category cited and is labeled a classification aid, never a compliance determination.
+- Every authorization-model-design or infrastructure-scoped finding is handed off, not adjudicated here.
+
+## Evidence classification
+
+Label each finding `repo evidence` (seen directly in the reviewed code or configuration) or `documentation-based` (the current php.net manual). This skill does not use `context7-grounded` (no Context7 tool in scope) and does not use `inference` for a documented API behavior — an undocumented or unverifiable behavior claim must be flagged as unverified rather than guessed.
+
+## Security and privacy constraints
+
+Static review only. Never request, transmit, store, or reproduce a secret, credential, session id, token, or PII found in reviewed code or configuration; treat any such string as a redact-and-flag finding. Never execute a deserialization payload, replay or forge a session id, upload a file, or send any request to a live, sandbox, or staging system. OWASP category mappings are classification aids, never compliance attestations.
+
+## Escalation conditions
+
+Escalate to incident response on any evidence the failure is already live: an object-injection payload observed in logs, a reachable uploaded web shell, or an observed session id reused across a privilege boundary. Escalate backend authorization-model design and infrastructure-scoped findings (webroot layout, TLS termination) to their owning specialist rather than adjudicating them here.
+
+## References
+
+Load these only when needed:
+
+- [Unserialize object injection](references/unserialize-object-injection.md) — why `unserialize()` on untrusted input is unsafe regardless of `allowed_classes`, the magic-method attack surface, and the `json_decode()` remediation.
+- [Session security](references/session-security.md) — `session_regenerate_id()` ordering around privilege changes and the four session cookie-hardening directives.
+- [File upload security](references/file-upload-security.md) — client-trust, storage-location, and size/type/count-limit review criteria for upload handlers.
+
+Each reference file carries its own Sources section citing the exact php.net (or OWASP) page backing its claims — there is no separate primary-source ledger file in this skill.
+
+## Response minimum
+
+Return, at minimum:
+
+- the call site/path in scope and, per finding, the failure class (`object-injection` / `session-fixation-hijacking` / `unsafe-upload`) and evidence tier;
+- the exploit or failure narrative (how the reachable input reaches a wrong outcome);
+- concrete remediation and an exact verification step;
+- the OWASP category mapping, labeled as a classification aid;
+- any authorization-model or infrastructure-scoped handoffs and incident-response escalation.
+
+## Anti-goals
+
+- Do not treat `allowed_classes` as a mitigation for `unserialize()` on untrusted input; the manual's caution is unconditional.
+- Do not design or approve a backend authorization/permission model; hand it off.
+- Do not execute any payload, upload, or request against any live, sandbox, or staging system.
+- Do not assert `unserialize()`, session-directive, or upload-limit behavior from memory; ground every such claim in the current php.net manual.
+- Do not echo, store, or reproduce any secret, session id, token, or PII found during review.

package/skills/php/php-session-upload-deserialization-review/metadata.json

@@ -0,0 +1,20 @@
+{
+  "id": "php-session-upload-deserialization-review",
+  "name": "PHP Session, Upload & Deserialization Security Review",
+  "type": "skill",
+  "provider": "php",
+  "harnesses": ["claude-code", "cursor", "codex", "gemini", "kiro", "other"],
+  "summary": "Skill for reviewing PHP application-security seams: user-reachable unserialize() object injection (allowed_classes is insufficient), session fixation/hijacking hardening (session_regenerate_id, use_strict_mode, cookie flags), and unsafe file-upload handling, each mapped to an OWASP category and the php.net-documented fix.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.php.net/manual/en/function.unserialize.php",
+    "https://www.php.net/manual/en/session.security.php",
+    "https://www.php.net/manual/en/features.file-upload.common-pitfalls.php",
+    "https://owasp.org/www-project-top-ten/"
+  ],
+  "security_notes": "Static-review-only skill: Read/Grep/Glob, no execution and no network. Never runs deserialization payloads, uploads, or exploits against any live or staging system. Any credential- or PII-shaped string is a redact-and-flag finding, never echoed. Every unserialize()/session/upload claim is grounded in current php.net documentation, not memory.",
+  "last_verified": "2026-07-16",
+  "path": "skills/php/php-session-upload-deserialization-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/php/php-session-upload-deserialization-review/references/file-upload-security.md

@@ -0,0 +1,119 @@
+# File upload security
+
+## Why this matters
+
+An upload handler is the one place in most PHP applications where a client
+supplies content the server will store, and often later serve, on its own
+filesystem. Every trust decision the manual warns against — believing the
+client's stated MIME type, believing the client's filename, skipping the
+configured size/count ceilings, or placing accepted content somewhere the
+web server will execute it — turns a routine upload feature into a path for
+an attacker to plant and run a web shell, exhaust server resources, or read
+files the application never meant to expose.
+
+## NORMATIVE: configuration ceilings gate every upload
+
+Per the php.net manual's common-pitfalls guidance for file uploads:
+
+- **`upload_max_filesize`** caps the size PHP will accept per file: "The
+  `MAX_FILE_SIZE` item cannot specify a file size greater than the file size
+  that has been set in the `upload_max_filesize` in the php.ini file. The
+  default is 2 megabytes." A form-field `MAX_FILE_SIZE` hint is a
+  client-side convenience only; the server-enforced ceiling is
+  `upload_max_filesize`.
+- **`post_max_size`** must accommodate the request as a whole: "If
+  `post_max_size` is set too small, large files cannot be uploaded. Make
+  sure you set `post_max_size` large enough." A `post_max_size` smaller than
+  `upload_max_filesize` silently caps effective upload size below what
+  `upload_max_filesize` alone suggests.
+- **`max_file_uploads`** bounds how many files one request can carry: "The
+  `max_file_uploads` configuration setting controls the maximum number of
+  files that can [be] uploaded in one request. If more files are uploaded
+  than the limit, then `$_FILES` will stop processing files once the limit
+  is reached" — silently, not with an error the handler is guaranteed to
+  check for.
+- **`memory_limit`**, **`max_execution_time`**, and **`max_input_time`** must
+  also be sized for uploads: the manual specifically notes `max_input_time`
+  "sets the maximum time, in seconds, the script is allowed to receive
+  input; this includes file uploads. For large or multiple files, or users
+  on slower connections, the default of `60` seconds may be exceeded,"
+  causing an otherwise-valid upload to fail partway through.
+
+A review must confirm these are set deliberately (not left at silent
+defaults that either reject legitimate uploads or, in the case of
+`max_file_uploads`, silently truncate a batch without the handler noticing).
+
+## NORMATIVE: do not trust which file you operate on
+
+The manual's common-pitfalls page states plainly: "Not validating which file
+you operate on may mean that users can access sensitive information in
+other directories." This is the manual's own framing of path-traversal and
+client-trust risk in upload handling — a filename or path is untrusted input
+like any other and must be validated, not built into a filesystem operation
+directly. The manual separately cautions that "due to the large amount of
+directory listing styles we cannot guarantee that files with exotic names
+(like containing spaces) are handled properly," reinforcing that the
+client-supplied filename cannot be relied on to behave predictably and
+should not be used to construct a storage path or to make a security
+decision (such as inferring file type from its extension).
+
+## RECOMMENDATION: validate content, not client claims; store outside the webroot
+
+The manual's guidance above establishes the principle — validate the file
+you actually operate on — but does not itself specify a validation
+algorithm or a storage location; the following are this skill's operating
+recommendations applying that principle, to be checked as reviewer evidence
+criteria below rather than cited as separate manual quotations:
+
+- Treat `$_FILES[...]['type']` (client-reported MIME type) and
+  `$_FILES[...]['name']` (client-reported filename) as untrusted metadata
+  only. A security decision — what kind of file this is, whether it is
+  acceptable — must be made from the file's actual content on the server,
+  not from either client-supplied field.
+- Store accepted uploads outside any path the web server will serve
+  directly, and generate the stored filename server-side rather than
+  reusing the client-supplied name verbatim, closing both the
+  path-traversal risk above and the risk of an executable extension being
+  preserved into a servable location.
+- Never `include()`, `require()`, or otherwise execute an uploaded file as
+  PHP code, and never configure the storage directory to be
+  script-executable by the web server.
+
+## Reviewer evidence criteria
+
+For each upload handler in scope:
+
+- Confirm `upload_max_filesize`, `post_max_size` (sized larger than
+  `upload_max_filesize`), and `max_file_uploads` are set to deliberate,
+  documented values rather than left at framework/PHP defaults without
+  review, and confirm the handler does not assume a client-side
+  `MAX_FILE_SIZE` hint is enforced.
+- Confirm the handler checks the actual number of files processed against
+  what the client claims to have sent, given that `$_FILES` silently stops
+  populating once `max_file_uploads` is reached.
+- Confirm the handler validates the file's real type/content server-side,
+  not `$_FILES[...]['type']` or the client filename's extension alone.
+- Confirm accepted files are stored outside any web-servable path, with a
+  server-generated filename, not the client-supplied one used verbatim in
+  a filesystem path.
+- Confirm no code path `include()`s, `require()`s, or otherwise executes an
+  uploaded file, and that the storage location is not configured as
+  script-executable.
+- Treat trusting client-supplied MIME type/filename for a security decision,
+  storing inside the webroot, or having no enforced size/type/count limit as
+  a blocking finding.
+
+## Applicable versions
+
+The `upload_max_filesize` default (2 megabytes) and the `max_file_uploads`
+silent-truncation behavior described above are current php.net manual
+guidance as of this review; re-verify against the live manual page before
+citing an exact default value, since PHP distribution defaults (and
+distro-specific `php.ini` overrides) can differ from the documented
+upstream default.
+
+## Sources
+
+- [PHP Manual — Common Pitfalls (file uploads)](https://www.php.net/manual/en/features.file-upload.common-pitfalls.php) — supports the `upload_max_filesize` default and `MAX_FILE_SIZE` client-hint framing, the `post_max_size` sizing guidance, the `max_file_uploads` silent-stop behavior, the `max_input_time` upload-duration caution, and the "not validating which file you operate on" and "exotic names" client-trust cautions.
+
+Last verified: 2026-07-16.

package/skills/php/php-session-upload-deserialization-review/references/session-security.md

@@ -0,0 +1,126 @@
+# Session security
+
+## Why this matters
+
+A session id is a bearer credential: whoever presents it is treated as the
+user it belongs to. Two distinct failures let an attacker end up holding a
+victim's session id: fixation, where the attacker sets the session id before
+the victim authenticates and it is never replaced, and hijacking, where the
+attacker steals an already-authenticated session id after the fact (via
+script injection, packet sniffing, or physical access). php.net's own
+session-security guidance treats both as core, not edge-case, concerns, and
+documents specific configuration and code-ordering requirements to close
+each path.
+
+## NORMATIVE: regenerate the session id on privilege change
+
+Per the php.net manual's session-management-basics guidance:
+
+- "Session IDs **must** be regenerated when user privileges are elevated,
+  such as after authenticating. `session_regenerate_id()` must be called
+  prior to setting the authentication information to `$_SESSION`."
+  `session_regenerate_id()` saves the current session data automatically, so
+  the call itself does not lose session state — but it must come **before**
+  the authenticated flag is written, so that only the new session id carries
+  it.
+- More generally: "Session ID regeneration reduces the risk of stolen
+  session IDs, thus `session_regenerate_id()` must be called periodically.
+  E.g. Regenerate the session ID every 15 minutes for security sensitive
+  content."
+- `session_regenerate_id()` does **not** delete the outdated session's data
+  by default. The manual is explicit: "`session_regenerate_id()` does not
+  delete outdated sessions by default. Obsolete authenticated sessions may
+  be present for use. Developers must prevent outdated sessions to be
+  consumed by anyone." A regeneration call without also invalidating the
+  prior session's stored data leaves a still-valid, still-authenticated old
+  session id usable by anyone who captured it before regeneration.
+
+## NORMATIVE: `session.use_strict_mode` is mandatory and off by default
+
+Per the manual: "enabling `session.use_strict_mode` is mandatory for secure
+sessions. It is disabled by default. This prevents the session module [from
+using] an uninitialized session ID. Put differently, the session module only
+accepts valid session IDs generated by the session module. It rejects any
+session ID supplied by users." With strict mode enabled, "an uninitialized
+session ID is rejected and a new one is created. This prevents an attack that
+forces users to use a known session ID" — the core session-fixation vector,
+where an attacker "may paste links or send emails that contain the session
+ID" and hope the victim's session simply adopts it.
+
+Because this directive is **disabled by default**, a review must check for
+an explicit `session.use_strict_mode=1` (or equivalent `ini_set()` call) —
+absence of an error or warning is not evidence it is on.
+
+## NORMATIVE: cookie-hardening directives
+
+Per the php.net manual's session INI-settings guidance, four directives
+harden the session cookie itself:
+
+- **`session.cookie_httponly`** — "Refuses access to the session cookie from
+  JavaScript. This setting prevents cookies snatched by a JavaScript
+  injection." The manual states: "Almost all applications must use the
+  httponly attribute for the session ID cookie."
+- **`session.cookie_secure`** — "Allow access to the session ID cookie only
+  when the protocol is HTTPS. If a website is only accessible via HTTPS, it
+  should enable this setting." (The manual separately notes HSTS should be
+  considered for HTTPS-only sites.)
+- **`session.cookie_samesite`** — "As of PHP 7.3 the `SameSite` attribute can
+  be set for the session ID cookie. This attribute is a way to mitigate CSRF
+  (Cross Site Request Forgery) attacks." `Lax` allows the cookie on a
+  cross-site GET navigation; `Strict` does not send it cross-site at all —
+  the manual frames the choice as that accessibility trade-off, not a
+  recommendation of one value for every application.
+- Session hijacking generally (not fixation) is mitigated, per the manual,
+  by transport: "There are several ways to leak an existing session ID to
+  third parties. E.g. JavaScript injections, session IDs in URLs, packet
+  sniffing, physical access to the device, etc... The solution is to
+  implement SSL/TLS on the server and make it mandatory for users" —
+  `session.cookie_secure` is the configuration lever that enforces this for
+  the session cookie specifically.
+
+## Reviewer evidence criteria
+
+For every authentication, privilege-elevation, or password-reset path:
+
+- Confirm `session_regenerate_id(true)` is called, and confirm it is called
+  **before** the code writes the authenticated/elevated-privilege flag into
+  `$_SESSION`. A call present anywhere in the function is not sufficient —
+  check the ordering.
+- Confirm the prior session's data is invalidated or is not relied upon as
+  still-authenticated after regeneration; a regeneration call with the old
+  session id left independently valid and authenticated is a finding.
+
+For the effective session configuration in scope (`php.ini`, `.htaccess`,
+`ini_set()` calls, or a framework's session configuration layer):
+
+- Confirm `session.use_strict_mode` is explicitly enabled; do not treat its
+  absence from configuration as acceptable, since it is disabled by default.
+- Confirm `session.cookie_httponly` is enabled.
+- Confirm `session.cookie_secure` is enabled for any application served over
+  HTTPS (and flag its absence as a finding for an HTTPS-only application).
+- Confirm `session.cookie_samesite` is set to `Lax` or `Strict` (requires
+  PHP 7.3+); flag an unset value, and flag PHP < 7.3 as unable to set this
+  directive at all (a version-upgrade finding, not a configuration finding).
+
+Treat a missing `session_regenerate_id()` call (or one ordered after the
+authenticated flag is set) and a missing/disabled `session.use_strict_mode`
+as blocking findings. Treat missing `cookie_httponly`, `cookie_secure`, or
+`cookie_samesite` as findings that escalate to blocking when combined with
+any independently confirmed session-id-leak or fixation path.
+
+## Applicable versions
+
+`session.cookie_samesite` requires PHP 7.3 or later — on an earlier version
+this is a version-upgrade finding rather than a configuration omission. The
+other directives and the `session_regenerate_id()` ordering guidance are
+current php.net manual guidance as of this review; re-verify against the
+live manual page before citing behavior for a PHP version outside current
+support.
+
+## Sources
+
+- [PHP Manual — Session Management Basics](https://www.php.net/manual/en/features.session.security.management.php) — supports the `session_regenerate_id()` ordering requirement around privilege elevation, the periodic-regeneration guidance, and the "does not delete outdated sessions by default" caution.
+- [PHP Manual — Securing Session INI Settings](https://www.php.net/manual/en/session.security.ini.php) — supports `session.use_strict_mode` being mandatory-but-disabled-by-default, `session.cookie_httponly`, `session.cookie_secure`, and `session.cookie_samesite` (PHP 7.3+) directive behavior.
+- [PHP Manual — Sessions and Security (overview)](https://www.php.net/manual/en/session.security.php) — top-level page framing session security as core to web application security and pointing to the two subsection pages above.
+
+Last verified: 2026-07-16.

package/skills/php/php-session-upload-deserialization-review/references/unserialize-object-injection.md

@@ -0,0 +1,121 @@
+# Unserialize object injection
+
+## Why this matters
+
+`unserialize()` does not just decode data — it can rebuild arbitrary objects
+and then automatically hand them control. If the serialized string an
+attacker controls names a class the application has autoloaded (directly or
+transitively), reconstructing that object can invoke its magic methods with
+attacker-influenced property values, and one of those methods reaching a
+dangerous sink (a file write, a command, a second `unserialize()`, a query)
+is enough to turn a data-parsing call into code execution. This is PHP
+object injection, and php.net's own manual treats it as unconditional: there
+is no safe way to call `unserialize()` on untrusted input, only safer
+alternatives to use instead.
+
+## NORMATIVE: php.net's unconditional caution
+
+Per the php.net manual page for `unserialize()`:
+
+- "Do not pass untrusted user input to `unserialize()` regardless of the
+  `options` value of `allowed_classes`. Unserialization can result in code
+  being loaded and executed due to object instantiation and autoloading, and
+  a malicious user may be able to exploit this."
+- The manual's stated alternative for untrusted data interchange is "a safe,
+  standard data interchange format such as JSON (via `json_decode()` and
+  `json_encode()`)."
+- After successfully reconstructing an object, PHP "will automatically
+  attempt to call the `__unserialize()` or `__wakeup()` methods (if one
+  exists)" — this invocation happens as part of `unserialize()` itself, not
+  as a separate step a caller can skip.
+
+This is the single controlling fact for this review: the caution is not
+scoped to "when `allowed_classes` is absent" — it applies **regardless of**
+that option's value. A review must not treat `allowed_classes` as the fix.
+
+## RECOMMENDATION: what `allowed_classes` actually does, and does not do
+
+`allowed_classes` restricts which class names `unserialize()` is willing to
+instantiate (e.g. `unserialize($string, ['allowed_classes' => false])`
+instantiates no objects at all, converting them to `__PHP_Incomplete_Class`
+instead). Use it as defense-in-depth when a design genuinely requires
+`unserialize()` over data that cannot be fully untrusted-input-free, but do
+not present it to engineers as a fix for untrusted-input reachability — the
+manual's caution stands regardless of the option, and per user-contributed
+notes on the same manual page, `allowed_classes` does not follow class
+inheritance (allowing an interface does not allow its implementers, and
+subclasses of an allowed class do not automatically pass).
+
+## The wider magic-method attack surface: `__destruct()` too
+
+Object-injection ("PHP Object Injection" / gadget-chain) exploitation is not
+limited to `__wakeup()`/`__unserialize()`. Any class instantiated by the
+`unserialize()` call is a live PHP object with its full lifecycle ahead of
+it, including destruction. Per the php.net manual for destructors: "The
+destructor method will be called as soon as there are no other references to
+a particular object, or in any order during the shutdown sequence." This
+means a reconstructed object with attacker-controlled properties can trigger
+consequential logic in its `__destruct()` even if it has no `__wakeup()` or
+`__unserialize()` at all — including at request shutdown, when no other code
+runs after it. Two destructor-execution details a reviewer should carry
+into any gadget-chain analysis, per the same page:
+`__destruct()` calls made during shutdown happen "in any order" (no
+guaranteed sequence among unrelated objects), and destructors are called
+even when the script stops via `exit()`. When reviewing a class reachable
+from `unserialize()`, check `__wakeup()`, `__unserialize()`, and
+`__destruct()` — all three are automatic, attacker-triggerable entry points
+once the object exists.
+
+## RECOMMENDATION: prefer `json_decode()` for untrusted data
+
+Match the manual's own stated remediation: for any data interchange that
+crosses a trust boundary (request body, query string, cookie, cache key
+sourced from user input, a queue message an external party can influence),
+use `json_decode()`/`json_encode()` rather than `serialize()`/`unserialize()`.
+If a legacy format genuinely requires PHP's native serialization for
+internal, fully-trusted data only, confirm the value never round-trips
+through anything a client can influence, and consider the manual's mention
+of `hash_hmac()`-based integrity verification for data an application stores
+externally and later reads back, so that tampering can be detected before
+`unserialize()` (or `json_decode()`) is ever called on it.
+
+## Reviewer evidence criteria
+
+For each `unserialize()` call site:
+
+- Identify the exact source of the string passed in. Untrusted sources
+  include request parameters, headers, cookies, uploaded file contents,
+  values read back from a cache/session/queue backend that a client can
+  influence, and any database column a client-facing write path can reach.
+- If the source is untrusted, this is a blocking finding regardless of
+  whether `allowed_classes` is set, per the manual's unconditional caution.
+- If `allowed_classes` is present, do not close the finding on that basis;
+  note it as partial defense-in-depth only, and still require remediation
+  toward `json_decode()` or a fully-trusted data path.
+- For any class the call could instantiate (open allowlist, `false`, or a
+  named list), check for `__wakeup()`, `__unserialize()`, and `__destruct()`
+  definitions in that class and its parents; if any exists, name it as a
+  live attack-surface entry point in the finding, not just a theoretical one.
+- Confirm the recommended remediation is `json_decode()`/`json_encode()`
+  (or an equivalent non-object-instantiating format) unless the review
+  independently confirms native PHP serialization is required and the data
+  never crosses a trust boundary.
+
+## Applicable versions
+
+The `unserialize()` caution, the automatic `__unserialize()`/`__wakeup()`
+invocation, and the `allowed_classes` behavior described above are current
+php.net manual guidance as of this review; the destructor shutdown-ordering
+and `exit()` behavior is also current manual guidance, with the manual
+separately noting that destructors are not run on shutdown caused by a fatal
+error as of PHP 5.3.10. Re-verify against the live manual pages before citing
+an exact figure for a PHP version outside current support, since documented
+behavior can be refined between manual revisions.
+
+## Sources
+
+- [PHP Manual — `unserialize()`](https://www.php.net/manual/en/function.unserialize.php) — supports the unconditional caution against passing untrusted input to `unserialize()` regardless of `allowed_classes`, the automatic `__unserialize()`/`__wakeup()` invocation on reconstructed objects, and the `json_decode()`/`json_encode()` remediation recommendation.
+- [PHP Manual — Destructors](https://www.php.net/manual/en/language.oop5.decon.php) — supports the `__destruct()` invocation timing (on last reference removal or in any order during shutdown), invocation even after `exit()`, and the PHP 5.3.10 fatal-error exception to shutdown-time destructor execution.
+- [OWASP Top 10:2021 — A08:2021 Software and Data Integrity Failures](https://owasp.org/Top10/2021/A08_2021-Software_and_Data_Integrity_Failures/index.html) — supports the OWASP category mapping for insecure-deserialization findings (CWE-502: Deserialization of Untrusted Data is listed among this category's notable weaknesses). OWASP has since published a Top 10:2025 edition (https://owasp.org/Top10/2025/) that renumbers this category to A08:2025 – Software or Data Integrity Failures and moves Injection to A05:2025; cite the specific edition and number in any finding rather than assuming 2021 numbering is still current.
+
+Last verified: 2026-07-16.

package/skills/php/wordpress-rest-block-security-review/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: wordpress-rest-block-security-review
+description: Use this skill to review WordPress plugin, theme, REST API, and block-editor code for missing or overly permissive REST permission_callback registration, unescaped dynamic block render_callback output, missing input validation/sanitization or output escaping, and missing nonce/capability checks on state-changing requests. Use when reviewing register_rest_route() calls, dynamic block render_callback/render.php files, form/admin-ajax handlers, or any code path that takes untrusted input and produces WordPress-rendered output. Static review only; it does not execute plugin/theme code and never contacts a live, sandbox, or staging WordPress install.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-16"
+  category: security
+  lifecycle: experimental
+---
+
+# WordPress REST & Block Security Review
+
+## Purpose
+
+Review the WordPress-specific security seams that a generic PHP reviewer is likely to miss: REST routes registered without an explicit `permission_callback`, dynamic blocks whose `render_callback` emits data without escaping, input that is neither validated nor sanitized before use, and state-changing requests with no nonce or capability check. Plugins and themes are where the WordPress ecosystem's own advisory sources place the large majority of disclosed vulnerabilities, and each of these four gaps is a documented anti-pattern against WordPress's own core APIs, not a stylistic preference.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review a `register_rest_route()` call or a REST controller class for a missing or overly permissive `permission_callback`,
+- review a dynamic block's `render_callback` or `render.php` for unescaped output,
+- review input handling (REST params, `$_POST`/`$_GET`, shortcode or block attributes) for validation/sanitization gaps, or output for missing escaping,
+- review a form submission, admin-ajax action, or REST write for missing nonce or capability checks.
+
+## When not to use
+
+Do not use this skill for:
+
+- generic PHP defects with no WordPress-specific dimension (raw SQL concatenation with no WordPress DB API involved, generic type-juggling, unrelated logic bugs) — use a general PHP security review for those.
+- infrastructure or hosting-environment hardening (server configuration, TLS, hosting-provider WAF rules); this skill reviews source, not deployment environment.
+- dependency/supply-chain review (vulnerable third-party libraries pulled in via Composer); hand that to a supply-chain reviewer.
+- any live exercise of a WordPress install — executing plugin/theme code, submitting forms, calling REST endpoints, or triggering admin-ajax actions. This skill is static review only.
+
+## Preconditions
+
+- The plugin or theme source in scope: REST route registrations, block registration and `render_callback`/`render.php` files, form handlers, admin-ajax actions, and shortcode callbacks.
+- The WordPress version the code targets, where relevant to a version-gated API such as `permission_callback` enforcement.
+- Whether any REST route or block output is genuinely intended to be public, so a correctly-scoped `__return_true` or unauthenticated render is not misflagged.
+
+## Lean operating rules
+
+- Confirm `permission_callback` is present on every `register_rest_route()` call in scope, and that `__return_true` (or an equivalent always-true callback) is used only where the route is genuinely public.
+- Trace every dynamic value in a block's `render_callback`/`render.php` from its source to its output point and confirm the matching escaping function is applied there, not merely present somewhere in the file.
+- Require validation or sanitization of every untrusted input before use, favoring validation/rejection over sanitization alone where a specific check is possible.
+- On non-REST state-changing handlers (form POSTs, `admin-post`/`admin-ajax` actions), require both an explicit nonce verification (`check_admin_referer`/`wp_verify_nonce`) and a `current_user_can()` capability check; neither alone is sufficient.
+- For `register_rest_route()` endpoints, do not flag the absence of an in-handler nonce call: under cookie authentication the REST infrastructure verifies the `wp_rest` nonce automatically before the route runs, so the requirement there is a capability-checking `permission_callback`. A missing/invalid nonce silently demotes the request to anonymous, so it is a finding only when the `permission_callback` assumes an authenticated user.
+- Never request, echo, store, or reproduce a secret, API key, credential, or credential-shaped string found in code; redact-and-flag it instead.
+- Label every claim `repo evidence`, `documentation-based`, or `inference`.
+
+## Context7 documentation protocol
+
+WordPress REST route requirements, nonce/capability semantics, and block-rendering behavior are documented on developer.wordpress.org and are the only acceptable ground truth for a version or API-behavior claim. Before asserting how `register_rest_route()`, `render_callback`, nonces, or escaping/sanitizing functions behave, cite the current developer.wordpress.org page and label the claim `documentation-based`. If a Context7-indexed source is available for the API in question, prefer it (`resolve-library-id` then `query-docs`) and label the result `context7-grounded`; otherwise use the official documentation directly. Never rely on memorized API behavior for a version-gated claim.
+
+## Workflow
+
+1. Enumerate the REST routes, dynamic blocks, and state-changing handlers in scope from the files provided.
+2. For each `register_rest_route()` call: confirm `permission_callback` is present; if it is `__return_true` or absent, confirm public-data justification or flag it. See [REST API permission_callback enforcement](references/rest-api-permission-callback.md).
+3. For each dynamic block `render_callback`/`render.php`: trace every dynamic value to its output point and confirm escaping is applied there. See [Dynamic block output escaping](references/dynamic-block-output-escaping.md).
+4. For each input source and output point in scope: confirm validation/sanitization on input and escaping on output, and confirm nonce plus capability checks on state-changing requests. See [Input validation, sanitization, and output escaping](references/input-sanitize-output-escape.md).
+5. Emit findings with evidence tiers, concrete exploit narratives, remediation, and verification steps; hand off any non-WordPress-specific finding to the owning reviewer.
+
+## Decision gates
+
+- Block only on a finding with a demonstrated reachable path (unauthenticated REST access, unescaped render output, unchecked state change) — not on the mere absence of a keyword.
+- Every WordPress-API version or behavior claim is `documentation-based` (or `context7-grounded` where available), never memory.
+- Every finding names the specific route, block, or handler, not a general area of the codebase.
+- Non-WordPress-specific findings are handed off, not adjudicated here.
+
+## Evidence classification
+
+Label each finding `repo evidence` (seen directly in the code), `context7-grounded` (current documentation via Context7), `documentation-based` (official developer.wordpress.org documentation fetched directly), or `inference`. Documentation describes the intended pattern; it does not prove what a specific file actually does — always tie the claim back to the file and code path observed.
+
+## Security and privacy constraints
+
+Static review only. Never execute plugin/theme code, submit forms, call REST endpoints, or trigger admin-ajax actions against any live, sandbox, or staging WordPress install. Never request, echo, store, or reproduce a secret, API key, database credential, or credential-shaped string found in code; treat any such string as a redact-and-flag finding.
+
+## Escalation conditions
+
+Escalate to incident response any evidence the gap is already reachable in a live, publicly deployed site rather than merely present in source under review. Hand off non-WordPress-specific findings (generic PHP, infrastructure, supply-chain) to the reviewer who owns that area instead of adjudicating them here.
+
+## References
+
+Load these only when needed:
+
+- [REST API permission_callback enforcement](references/rest-api-permission-callback.md) — the required `permission_callback` argument, the `__return_true` public-endpoint pattern, and REST nonce/capability enforcement.
+- [Dynamic block output escaping](references/dynamic-block-output-escaping.md) — how `render_callback`/`render.php` execute and what escaping is required at each output point.
+- [Input validation, sanitization, and output escaping](references/input-sanitize-output-escape.md) — the validate-input/escape-output discipline, sanitizing and escaping function reference, and nonce/capability checks for state-changing requests.
+
+## Response minimum
+
+Return, at minimum:
+
+- the route(s), block(s), or handler(s) in scope and, per finding, the failure class and evidence tier;
+- the concrete exploit narrative (how the gap is actually reachable, not just theoretically present);
+- concrete remediation naming the specific WordPress function or pattern to add, and an exact verification step;
+- handoffs for any non-WordPress-specific finding, and any incident-response escalation.
+
+## Anti-goals
+
+- Do not expand into generic PHP review; own the WordPress-specific seam, hand off everything else.
+- Do not execute plugin/theme code or contact any live, sandbox, or staging WordPress install.
+- Do not echo, reproduce, or transmit any secret, credential, or credential-shaped string.
+- Do not assert a WordPress API version or behavior from memory.

package/skills/php/wordpress-rest-block-security-review/metadata.json

@@ -0,0 +1,20 @@
+{
+  "id": "wordpress-rest-block-security-review",
+  "name": "WordPress REST & Block Security Review",
+  "type": "skill",
+  "provider": "php",
+  "harnesses": ["claude-code", "cursor", "codex", "gemini", "kiro", "other"],
+  "summary": "Skill for reviewing WordPress plugin and theme security: REST register_rest_route permission_callback enforcement (required since WordPress 5.5) and nonce/capability checks, dynamic-block render_callback output escaping, and the validate-on-input, escape-on-output discipline behind the plugin-dominated WordPress CVE surface.",
+  "source_type": "original",
+  "official_docs": [
+    "https://developer.wordpress.org/apis/security/",
+    "https://developer.wordpress.org/rest-api/extending-the-rest-api/routes-and-endpoints/",
+    "https://developer.wordpress.org/block-editor/getting-started/fundamentals/static-dynamic-rendering/",
+    "https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/"
+  ],
+  "security_notes": "Static-review-only skill: Read/Grep/Glob, no execution and no live WordPress access. Flags missing permission_callback, unescaped output, and missing nonce/capability checks from source only; treats any credential- or PII-shaped string as a redact-and-flag finding; grounds REST and block-editor API claims in current developer.wordpress.org documentation.",
+  "last_verified": "2026-07-16",
+  "path": "skills/php/wordpress-rest-block-security-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}