@raishin/vanguard-frontier-agentic 3.2.0 → 3.4.0

package/skills/php/php-runtime-eol-opcache-fpm-review/references/php-version-lifecycle.md

@@ -0,0 +1,102 @@
+# PHP version lifecycle
+
+## Why this matters
+
+A PHP branch that has left php.net's supported window stops receiving fixes of
+any kind once it reaches end of life (EOL) — including for actively exploited
+vulnerabilities — while a branch in its security-only window still receives
+critical security fixes but no bug fixes, and is itself counting down to its
+own EOL. A service can look fully healthy at the application-code level (green
+tests, current dependencies) while the runtime underneath it has already
+crossed one of these boundaries. This file is the sole source the skill uses
+for those dates; every version-lifecycle claim in a review must resolve to a
+row below, and to no other memory or estimate.
+
+## NORMATIVE: php.net's support policy
+
+Per php.net's Supported Versions page (`documentation-based`):
+
+- Each release branch of PHP is fully supported for **two years** from its
+  initial stable release. During this period, reported bugs and security
+  issues are fixed and released in regular point releases.
+- After that two-year active-support period, each branch is then supported
+  for **two additional years** for critical security issues only. Releases
+  during this window are made on an as-needed basis — there may be multiple
+  point releases, or none, depending on the number of reports.
+- After the combined four-year window (two years active plus two years
+  security-only), a branch is **end of life (EOL)**: no further fixes of any
+  kind are published for it, including for actively exploited
+  vulnerabilities.
+
+## NORMATIVE: current per-branch dates
+
+Per php.net's Supported Versions page, the currently listed branches and
+their published dates are:
+
+| Branch | Active support until | Security support until (EOL) |
+|---|---|---|
+| PHP 8.2 | 31 Dec 2024 | 31 Dec 2026 |
+| PHP 8.3 | 31 Dec 2025 | 31 Dec 2027 |
+| PHP 8.4 | 31 Dec 2026 | 31 Dec 2028 |
+| PHP 8.5 | 31 Dec 2027 | 31 Dec 2029 |
+
+Reading this table for a review:
+
+- A branch is in **active support** if the current review's target/committed
+  version date is before its "Active support until" date.
+- A branch is in **security-only support** if that date is on or after
+  "Active support until" but before "Security support until."
+- A branch is **EOL** once that date reaches or passes "Security support
+  until" — no fixes of any kind are published past that point.
+
+Any PHP version not listed in php.net's current supported-versions table
+(either older than the branches php.net still lists, or a malformed/future
+version string) has no dates in this file — say the evidence is missing
+rather than inferring a status.
+
+## Reviewer evidence criteria
+
+- Resolve the exact PHP version from the strongest available evidence:
+  a running-version banner or `phpversion()`/`php -v` output outranks a
+  Dockerfile/base-image tag, which outranks a loose Composer `require.php`
+  constraint (e.g. `^8.2` does not tell you which point release is actually
+  deployed, only the minimum branch). State which evidence tier the version
+  claim rests on.
+- Match the resolved branch against the table above exactly; do not round a
+  point release to a different branch or assume a branch's status from a
+  prior review.
+- Classify the branch precisely as active support, security-only (cite the
+  exact security-support-until date), or EOL (cite the exact date it was
+  reached) — never collapse these into an undifferentiated "outdated" label.
+- Determine the branch's **current phase** by comparing this file's published
+  cutoff dates against the review date — the current date, or an explicitly
+  supplied review/support-horizon date when one is given. This file's
+  per-branch dates are the fixed ground truth (sourced from php.net, never
+  invented, rounded, or extrapolated); only the comparison against the review
+  date is a review-time judgment, so a branch correctly transitions from
+  active support to security-only to EOL as the review date passes each
+  published cutoff.
+- For a security-only branch, compare its "Security support until" date
+  against both the review date and the review's stated release/support
+  horizon. If EOL has already been reached, or that date falls within the
+  horizon with no tracked upgrade plan, this is a blocking finding per the
+  skill's decision gates, not merely advisory.
+- For an EOL branch, the finding is blocking unconditionally — there is no
+  "well-maintained otherwise" exception, since EOL means no fixes of any kind
+  are published, including for actively exploited vulnerabilities.
+
+## NORMATIVE vs. RECOMMENDATION
+
+The support-policy structure and the per-branch dates above are NORMATIVE —
+sourced directly from php.net and not to be altered, rounded, or
+extrapolated. The recommended target version for an upgrade (e.g. "move to
+the newest branch still in active support") is a RECOMMENDATION: name a
+target that is currently in active support per the table above, but leave the
+final choice, timeline, and any compatibility work to the owning engineering
+team.
+
+## Sources
+
+- [PHP: Supported Versions](https://www.php.net/supported-versions.php) — supports the two-year active-support / two-year security-only / EOL support-policy structure and the per-branch dates for PHP 8.2 through 8.5 above.
+
+Last verified: 2026-07-16.

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.