Patch active Workflow Symfony MIME locks and audit nested Composer locks

Current state (November 4)

The three active MIME corrections are accepted through #1031. The later November Symfony batch is independently fixed in the same three active locks by #1032, actual main b3dd00e96440c4bcc70a3853f662bf93311e7029, exact reviewed tree 89697d31b9710f3771e3fd4a1b95786b33ff9bbe. All 28 exact-main check records and four original workflows/jobs are terminal: 26 successes/two intended skips. Ordinary main acceptance follows fresh complete audits, strict validation, installed replay/HTTP/queue smokes, exact Core source comparisons and final Security carry. Published Workflow references and all unrelated package records remain unchanged. The merged1032 branch/worktree are now removed after exact-head, active-run, ancestry and dependent-PR checks; the earlier combined942a95b reference is preserved.

The offline committed-lock inventory from #1033 is delivered on main 98bd98688663c005cb048d88f18119c35b6973b1 and inherited by maintained main. All five committed locks have exact source/history classifications and strict evidence-parser controls. The recurring online audit remains inactive pending whole-repository effective-trust and exact advisory/exception disposition. CLI owns the central APT/setup-php work in .github #295/#297; no per-repository installer/guard copy or blanket ordinary-source CI hold is required. This inventory does not waive historical advisories or qualify a publishing path.

This issue stays open for those actual recurring inventory/audit and trust acceptance criteria. Historical #773/#809 inputs are unchanged; no experiment restart or product/runtime/release follows source maintenance. The original finding and acceptance remain below.

Finding

A bounded audit of all 32 committed Composer locks on current organization default branches found CVE-2026-45070 / GHSA-vqc8-7275-q272 in five Workflow locks:

Path	Locked version	Classification
`benchmarks/embedded-replay/composer.lock`	`symfony/mime` `v8.1.7`	Active published-package performance fixture; patch normally.
`examples/embedded-http/composer.lock`	`v7.4.19`	Active optional example; patch normally.
`.github/queue-contention/current/composer.lock`	`v7.4.19`	Current published-package control; patch without changing its Workflow/source authority.
`.github/queue-contention/composer.lock`	`v8.1.7`	Deliberately preserved original diagnostic input for #809; do not silently rewrite.
`.github/tracing-performance/composer.lock`	`v7.4.19`	Exact experiment dependency identity reserved to #773; preserve or requalify through that owner.

Symfony's corrected advisory is authoritative: https://symfony.com/blog/cve-2026-45070-email-header-injection-via-non-token-characters-in-mime-parameter-names. The first fixed releases are 7.4.22 and 8.1.10.

The defect permits header injection only when an application derives a MIME parameter name from untrusted input. Search of the affected fixture/example trees found only stock mail configuration and no Mail, Mailable, ParameterizedHeader, or other MIME-parameter construction. These profiles are bounded test/example workloads, not production mail paths. No production/released-runtime reachability, exploitation, customer impact, emergency release, or operator action is established.

The scheduled dependency-security workflow audits synthesized supported-Laravel resolutions, not the repository's nested committed locks. Its path triggers also exclude these locks. GitHub Dependabot currently exposes no corresponding alert. This issue therefore owns the active General-scope lock corrections and the recurring inventory gap; the tracing-performance input remains under #773.

This is distinct from PR #967's PHPUnit shared-temporary-directory correction. That exact PR head passes Composer lock validation (apart from the fixture's pre-existing exact product-version warning) but is not audit-clean because its embedded-replay Symfony finding remains.

Acceptance

Update the three active General-scope locks above to symfony/mime 7.4.22 / 8.1.10 or later compatible maintained patches, including only resolver-required transitive changes.
Preserve every fixture's exact published durable-workflow/workflow reference, source-equality/provenance guards, resource and network bounds, and existing functional/performance interpretation.
Keep .github/queue-contention/composer.lock unchanged unless Keep embedded database-queue recovery bounded during concurrent fan-out #809 explicitly admits a non-Workflow dependency-only refresh with corresponding provenance evidence. Represent any retained advisory as an exact path/advisory classification, never a blanket audit ignore.
Treat .github/tracing-performance/composer.lock as Add end-to-end distributed tracing across durable workflow execution, retries and recovery #773-owned experiment input. The nested-lock inventory may reference that owning exception but must not rewrite or reinterpret its measurements from this issue.
Add a maintained, bounded inventory/audit of every committed Composer lock on pull requests that change the inventory and on a schedule. Exact reviewed historical exceptions must name the path, advisory, reason, owner, and review condition; new locks or advisories fail closed.
Run strict Composer validation and fresh locked audits for changed paths, their source/provenance checks, and one bounded representative smoke per affected active fixture/example. Do not duplicate full performance studies solely for dependency maintenance.
Deliver through ordinary protected CI. No product/release hold.

The recurrence gap is concrete: .github/workflows/dependency-security.yml audits synthetic current resolutions for supported Laravel majors, but neither audits benchmarks/embedded-replay/composer.lock nor triggers when that nested manifest/lock changes. PR #967 therefore passed its normal build routing while the exact committed lock still failed composer audit --locked.

Add a lightweight nested-lock gate as part of this correction:

include benchmarks/embedded-replay/composer.json and composer.lock in dependency-security path triggers;
run composer validate and composer audit --locked --no-interaction from that directory on matching PR/push events and the existing schedule;
fail on any advisory or abandoned package once the current MIME correction lands;
keep the expensive embedded-replay profile outside this gate—the issue's one bounded profile smoke remains sufficient behavior qualification.

This closes the actual detection gap without adding a broad repository scan or a second heavy CI path.

General accepted this P3 handoff. PR #967's separate Sonar failure is a runner credential-boundary failure: job 124533152428 annotates Running this GitHub Action without SONAR_TOKEN is not recommended, followed by scanner exit 3. That does not establish a product finding or clear the quality gate. Preserve the required Sonar check and the locked-fixture/source-origin requirements when combining the required dependency corrections. The active namespace-isolation repair #928/#929 remains first; this issue retains the next fixture-only action.

Security disposition for candidate 942a95b86968f32c99bcf150b41d2ad9d2c27bfa:

The central contract's intended adoption boundary is repository-wide, not per workflow. Its public guidance says a migrated target scans every job in every workflow and should be enabled only after all request paths are migrated. The validator also deliberately turns the scan on when any workflow first references verify-composer-trust, so a partial rollout cannot silently look complete.

Do not weaken that policy or add a Workflow-only exception, and do not modify the reserved embedded-replay inputs merely to unblock this issue. The surfaced sink is containerized: embedded-replay-profile.yml invokes Composer inside the digest-pinned Composer image. Adding the current host bootstrap/setup/live-verifier sequence would inspect the host Composer and host trust paths, not the Composer process that makes the request inside the container. The current Docker commands also do not pass and mount the authenticated bundle into that process. A host-only guard here would be false assurance even if the static policy passed.

The safe next step is:

Keep the exact Patch active Workflow Symfony MIME locks and audit nested Composer locks #970 candidate backed up without opening its PR; its three active lock corrections, exception inventory, audit implementation and tests remain useful.
Extend the central clean-trust contract with a container-aware path that mounts/selects the authenticated bundle, verifies the same container Composer immediately before its request, and includes a negative actual-container control. The validator must distinguish and require that form for containerized Composer sinks.
Coordinate the repository-wide Workflow migration with the Workflow/performance owner, preserving request workload and exact performance interpretation. If the required Composer/image identity changes, requalify that input under its owning performance issue rather than hiding it in Patch active Workflow Symfony MIME locks and audit nested Composer locks #970.
Once all Workflow request paths are covered, make composer_trust_required explicit for the Workflow target so deleting the last verifier cannot disable enforcement.

This is a CI delivery precondition, not a product or release hold. It also leaves the separately owned historical #809/#773 inputs unchanged.

Read-only CI integration analysis for candidate 942a95b8 (branch deps/970-active-mime-locks-20261102). Nothing was pushed or dispatched.

Why adding one verifier fails the whole repo

qualification_policy.py::verify_composer_network_sinks turns enforcement on for every workflow in the repository as soon as any workflow source contains .github/actions/verify-composer-trust. The workflow target doesn't set composer_trust_required, so today's baseline (ea344511) passes only because no workflow references the verifier yet.

Once it's on, every step whose expanded run: text includes a network Composer command needs, in order:

an unconditional bootstrap-patched-pip step whose clients include composer, curl and git;
shivammathur/setup-php with composer:2.10.3 in tools;
verify-composer-trust as the step immediately before the request. Any intervening step, such as a cache step, cancels the authorization.

Every Composer subcommand except about, help and list counts as a network command, including composer validate.

I ran the central check functions against the candidate's workflows, without stopping at the first error. 19 request steps fail, not just the profile step. The hosted validator stops at the first file in sorted order, which is why only the profile step appeared:

Workflow	Job:step	Step name
embedded-replay-profile.yml	continuation:2	Record host conditions and prepare the locked source consumer
php.yml	preflight:6, 7, 9	CI script syntax; conformance resolver audit; payload consumer install
php.yml	regression-corpus:3	Install dependencies
php.yml	quality:2, 4, 6	`composer validate`; tracing recipe validate; install
php.yml	laravel-embedded-upgrade-source:3	`scripts/ci/laravel-embedded-upgrade-smoke.sh`, a shell helper that the check scans
php.yml	tracing-http:3	package and instrumentation install
php.yml	pr-unit-contracts:3, pr-feature-mysql:5	Install dependencies
php.yml	feature-mysql:4, feature-postgresql:3, feature-mariadb:3, coverage-unit:4	Install dependencies
published-queue.yml	published-queue:3	install the declared published package and framework
release-verification.yml	published-package:6, laravel-upgrade:3	published platform contract; published upgrade journey

None of these jobs has any trust step today. They use setup-php's default tools: composer or the runner's preinstalled Composer.

The one structural blocker

embedded-replay-profile.yml continuation step 2 runs composer install inside $DWF_PROFILE_IMAGE with docker run … --env COMPOSER_HOME=/tmp/composer. Adding the trust sequence on the host would neither reach the container's Composer nor pass _composer_trust_modified, which refuses the COMPOSER_HOME= assignment. Making it compliant means moving the install to the host with verified Composer and mounting vendor into the pinned image. That changes the reserved profile environment, so it's an owner decision. The other 18 sites are mechanical: bootstrap, then setup-php with composer:2.10.3, then cache, then verify, then the request. Jobs with several Composer steps either verify again before each one, as cli/build.yml already does, or combine the requests into one step after a single verification.

Smallest safe Workflow-only adoption paths, for General and Security to choose

A. Split Patch active Workflow Symfony MIME locks and audit nested Composer locks #970, smallest: land the MIME-only lock patches, the inventory script and its unit test now. Leave the shared verifier and the networked composer audit job out, so enforcement stays off. Track full trust adoption separately. The scheduled audit waits until then.
B. Adopt everything in one PR: add the trust sequence to the 18 mechanical sites in php.yml, published-queue.yml and release-verification.yml. Package references, resource bounds and inputs stay the same. Composer becomes pinned to 2.10.3 in those jobs. Restructure the profile continuation install to run on the host as described above, which needs owner approval. Then add the audit job.
C. Profile exception: route the profile continuation through an approved central exception. That needs a central policy change, which is outside Workflow-only scope and wasn't attempted.

I edited no central policy or reserved profile inputs.

Addendum for planning the eventual trust migration (read-only; nothing pushed). The clean → setup-php composer:2.10.3 → verify sequence is mechanical only where a job already runs shivammathur/setup-php.

In php.yml, these jobs already set up PHP explicitly: laravel-embedded-upgrade-source, tracing-http, feature-mysql and coverage-unit.

These jobs have no setup-php step and run on the runner's preinstalled PHP and Composer: preflight, regression-corpus, quality, pr-unit-contracts, pr-feature-mysql, feature-postgresql and feature-mariadb.

For that second group, adoption would add a setup-php step and pin a PHP version where the runner image currently decides it. That changes the CI environment, so it needs its own qualification. Each job's PHP version and the cache keys (which currently hash only composer.lock) should be decided with the owners when the central container-aware contract lands.

quality and preflight each have three separate Composer request steps, so each needs either three verifications or its Composer requests merged into one step.

General qualified the dependency and inventory candidate 942a95b86968f32c99bcf150b41d2ad9d2c27bfa, backed up on deps/970-active-mime-locks-20261102. No PR is open, because repository-wide Composer trust adoption remains to finish.

The three active lock updates are MIME-only: embedded replay uses 8.1.10, embedded HTTP and current queue contention use 7.4.22. Normal Composer resolution, strict validation, and fresh locked audits pass. Every other package record and each fixture's exact Core reference are unchanged. The two historical queue/tracing locks remain byte-identical; their known advisory is visible under exact package/version/advisory/path/hash exceptions with an owner and review condition.

The candidate's five-lock inventory checker passes 18 tests / 26 assertions. ECS and PHPStan pass. Negative controls include unknown advisories, wrong package/version, ignored/filtered/abandoned records, malformed/error results, contradictory exit codes, changed historical bytes, missing/added locks, and changed Core identity.

Bounded installed-fixture checks also pass, without library source overlays:

Embedded replay: original pinned Composer image, PHP 8.5.6, 1 CPU/1 GiB/no swap, one round/repeat. 1 test / 40 assertions, 14 history events, seven tasks and three activity effects; all 937 installed Core 2.5.28 source/resource files match before and after.
Embedded HTTP: actual Laravel HTTP kernel/auth, start → database queue execution → completed read with exact typed result, no remaining or failed jobs. All 934 installed Core 2.5.19 files match before and after. This uses PHP 8.4.27 and is a functional check, with no Octane/network/performance claim.
Current queue fixture: the unmodified limited-cohort command under 2 CPU/2 GiB/no swap, four workers and its original 90-second deadline passes: 64 activities, 64 attempts, 66 completed tasks, one effect per original, zero repairs/remaining jobs/failed jobs. All 939 installed Core 2.5.32 files match before and after.

The full central validator correctly rejects adding the first live verifier while older Composer sinks remain unqualified. The baseline main passes. Security's disposition remains in force: preserve the repository-wide boundary and the reserved performance inputs. Next is the existing central durable-workflow/.github#237 work for a container-aware clean-trust contract with an actual-container negative control, followed by coordinated migration of all sinks and explicit composer_trust_required. A host-only verifier would inspect the wrong Composer/trust paths for the embedded replay container.

General has separated the active lock repair from the larger recurring-inventory/Composer-trust migration. The prepared dependency-only commit is e36da06ac9bfa32e7404856b39fafcb90477b849, parent accepted main 4cfa985b, tree 93c21073292ec38531b21d016d1eb06de84247c6. It is local and deliberately unpushed during the Actions incident hold; pushing even a review branch would trigger Public Boundary. All four proposed file bytes are already recoverable from the existing remote candidate 942a95b8 on deps/970-active-mime-locks-20261102.

Scope: the three active MIME lock records select 8.1.10 / 7.4.22 / 7.4.22. The current queue consumer also declares the repository MIT license. The other 120 / 95 / 117 package records and exact published Core versions/references are unchanged. Both historical locks are byte-identical. Every file in the three fixture trees equals the previously qualified 942a95b8 input, so its three actual representative installed smokes carry without repeating performance studies. Runtime, root Composer requirements, tests and CI workflows are unchanged.

Fresh validation on PHP8.5.12 / Composer2.11.1: all three composer audit --locked --format=json calls return0 with empty advisories, abandoned, filter and cooldown. Effective Composer trust is independently verified before each command using the authenticated pip26.2.2 artifact CA and the restored central verifier. Strict validation passes with --no-check-all --no-check-publish; Composer documents that the first option suppresses warnings about intentionally exact fixture constraints while lock freshness remains checked. The initial unqualified strict invocations returned1 solely for those preserved exact-pin warnings and remain recorded. No audit ignore was added.

One initial tool image lacked Composer and stopped before requests; an initial local source lookup lacked the merged Git object and stopped before requests. Both setup failures are retained. The corrected immutable runner used0.5CPU/512MiB, no host credentials or dependency installation, and is independently absent.

Next: once authoritative Actions recovery permits new CI work, push the scoped branch/open a draft, run normal checks and obtain independent exact-head review. The accepted full root quality cycle at4cfa is a carry candidate because that runtime/root graph is byte-identical; no quality gate is waived. #970 stays open for remaining trust/requester and recurring inventory delivery. The #773/#809 historical exceptions remain under their existing owners. Official Actions/Pages incident and the original queued jobs are preserved; no retry or log-only pass is substituted.

Fresh committed-lock audit continuation found additional upstream Symfony advisories. The completed MIME-only source merge #1031 remains accepted for its exact scope; it is not current clearance for the additional advisories now returned by the provider.

At 19:42–19:47 UTC, Composer 2.10.3 audited all five committed locks using the pinned central Composer verifier and an authenticated 120-certificate bundle (SHA-256 50f79f98dac192b20dbf73f35c56f0b0c557ab267ff5199d1117cc1180b70785, both blocked roots absent). No packages were installed and no historical experiment ran. Every audit returned exit 1. The proposed recurring guard correctly refuses the first unaccepted advisory; its 23 focused controls / 34 assertions pass, including transport refusal before an audit can start. All 2,330 source inputs were unchanged, and the disposable runner is removed.

Committed lock	Advisory records	Exact raw JSON SHA-256
`.github/queue-contention/composer.lock`	8	`30d419b0f4b1a05f06b6a341d4d1f04cbbbebe56ed0fc1d3fe8fe543bf0991dc`
`.github/queue-contention/current/composer.lock`	7	`bcdfb33bf53ec499f00fe6a4f057d17c9aa8c2591632234816c28947e6c51d3c`
`.github/tracing-performance/composer.lock`	8	`30d419b0f4b1a05f06b6a341d4d1f04cbbbebe56ed0fc1d3fe8fe543bf0991dc`
`benchmarks/embedded-replay/composer.lock`	7	`bcdfb33bf53ec499f00fe6a4f057d17c9aa8c2591632234816c28947e6c51d3c`
`examples/embedded-http/composer.lock`	9	`ca85b566ac075eed28e0e592a4a6ffc43ebf1aa1d0d63aeb2f11ec87872f4a51`

The three active fixtures now report additional HTTP Foundation, HTTP Kernel, Routing and Yaml findings. Embedded HTTP also reports two HttpClient findings. The two historical locks additionally retain their previously recorded MIME finding. Current affected locked components are 8.1.9 in replay/old queue, 7.4.21 in current queue/tracing, and 7.4.20 in embedded HTTP. These are dependency findings, not proof of application reachability or a production incident.

Primary upstream records include CVE-2026-118514, CVE-2026-118516, Yaml GHSA-hwfg-qwvh-2wfx, and HttpClient GHSA-gq53-v8w2-gjhj. The Yaml advisory was published November 4 and identifies fixed branches 5.4.56, 6.4.50, 7.4.23 and 8.1.11.

General owns the active-fixture dependency correction and this recurring inventory guard. Security is assessing current product/deployed inventory relevance independently. Before merging the guard, qualify the smallest supported active-lock patch and obtain a separate exact review of any retained historical exception; no blanket ignore or new exception has been added. The historical #773/#809 locks and their execution stops remain unchanged. The whole-repository trust migration is still separate. #970 stays open through this current result and the maintained recurring audit delivery.

Security relevance assessment — Symfony advisory batch published 2026-11-04

Security correction, 2026-11-04 20:20 UTC: the Cloud-specific unreachability sentence below is superseded. Accepted Cloud source contains a path rule enforced in front of PHP for an otherwise unauthenticated internal intake route, which is the perimeter pattern covered by GHSA-3h27-hjv7-fqjx. The exact route analysis is retained in the private Cloud security record; no production proof-of-concept request was sent. This establishes a credible source-level reachability path, not exploitation or customer impact. P1 patch/redeploy remains the disposition, and Cloud's correction must include vulnerable symfony/filesystem 8.1.9 as well as the four HTTP/Yaml records, all to 8.1.11.

Security independently reconciled the provider audit records, upstream advisory descriptions/fixed tags, current repository locks, and the accepted Cloud deployment inventory. The result is affected dependency inventory requiring prompt patching, but not evidence of exploitation, customer impact, or a production incident.

Fixed floors and records

The supported same-minor fixed floors are Symfony 7.4.23 and 8.1.11 (also 5.4.56 / 6.4.50 for those branches). The relevant primary records are:

HttpFoundation: CVE-2026-118514, GHSA-3h27-hjv7-fqjx, GHSA-xg2q-4rrq-657q, and GHSA-5mx8-mwrp-5693;
HttpKernel: GHSA-wg5q-m2ww-f3c9;
Routing: CVE-2026-118516;
Yaml: GHSA-hwfg-qwvh-2wfx;
Filesystem: GHSA-6prc-h956-hxjq;
HttpClient: GHSA-gq53-v8w2-gjhj and GHSA-c7hm-wqwp-f9v8.

The exact v7.4.23 and v8.1.11 split-package tags currently proposed in Workflow #1032 resolve to the lock references in that PR, including HttpClient ed012bf..., HttpFoundation 7fb73cff... / 30fa3efe..., HttpKernel 94c57f4c... / 46065850..., Routing 0000ade6... / f3fefc6c..., and Yaml 1e601207... / e8266f55....

Current inventory

Workflow: all five committed fixture locks are affected. The three active locks are being repaired in Update active Symfony fixture locks for security fixes #1032. The two historical Add end-to-end distributed tracing across durable workflow execution, retries and recovery #773/Keep embedded database-queue recovery bounded during concurrent fan-out #809 locks remain separately stopped and are not active-product clearance.
Cloud accepted deployment: read-only inventory at 19:58 UTC bound healthy accepted release 306, source 05b756bb..., app image 88e5ee43..., and installed/source lock SHA-256 886a519084bee4d650319fa108e67efe204125c36ee12bec9fe3f7fd49d96ccb. Installed HttpFoundation/HttpKernel/Routing are 8.1.10; Filesystem and Yaml are 8.1.9; HttpClient is absent. Those installed references match the accepted source. This is live affected inventory.
Server: current main dff06e5d..., published PHP source 3.0.5 (bc24589d...), and 3.1.0 source (5d7fd2ba...) carry Filesystem 7.4.18, HttpFoundation 7.4.21, HttpKernel 7.4.14, Routing 7.4.13, and Yaml 7.4.21. Server Exception restoration emits PHP 8.5 deprecations into CLI JSON #1028 now owns the separate five-record repair after Release 2.20.3 #1025's required audit failed; no dependency change belongs in Release 2.20.3 #1025 itself.
Sample App: main 5a43dc7f... root locks carry affected Filesystem 8.1.0 and HTTP/Yaml 8.1.x; the microservice lock carries affected 7.4.x HTTP packages and Yaml 8.1.6.
Waterline: standalone main ade2b459... carries affected 7.4.x HTTP packages; Creation of dynamic property Workflow\Exception::$key is deprecated #280 is the isolated same-minor correction. Frozen Webhooks::routes() does not generate routes correctly in Windows #275 shares those old lock bytes and receives no release/scan/observer clearance from the source fix.
SDK PHP: only the Laravel HTTP example lock is affected (7.4.21, including HttpClient). The SDK library runtime does not gain those transitive packages from this example lock.

Reachability assessment

No currently inspected source path establishes exploitation of these advisories:

The accepted Cloud source uses explicit Cloudflare/private CIDR lists, not the vulnerable private_ranges shortcut; it has no Symfony SecurityBundle access_control/method firewall, host-placeholder routes, or Symfony inline fragments. Its Caddy configuration serves /app/public with php_server, not the front-controller subdirectory patterns described by GHSA-5mx8. Cloud Yaml calls parse repository/deployment recipe material rather than public request bodies; no Symfony Filesystem Path/AssetMapper use was found; and installed HttpClient is absent.
The PHP Server is a Laravel API with no Symfony SecurityBundle rules, host-placeholder routes, inline fragments, application-runtime Yaml parse path, or Symfony Filesystem Path/AssetMapper use found. The published image uses Apache with the public document root. It still ships affected packages and must be patched; source inspection is not a waiver.
Workflow's Yaml use is the platform conformance/test surface over packaged specifications. The affected fixture locks are test/example inputs, not a claim about a deployed Workflow library process.
Sample App and SDK PHP findings are shipped examples/application locks, not evidence about Cloud production.
Waterline standalone currently calls trustProxies(at: '*'). That is not the advisory's private_ranges shortcut, but it means source inspection alone cannot dismiss forwarded-host consequences. Creation of dynamic property Workflow\Exception::$key is deprecated #280 should remain P1 and its normal hosted/image qualification is required.

This assessment does not use public exploit probes. It does not prove that every downstream deployment uses the reviewed proxy/front-controller configuration.

Disposition

Treat the batch as P1 preventive dependency remediation, not a SEV/incident at this evidence level. No credential rotation, traffic stop, or customer notice is justified by a vulnerable lock alone.
Patch every active/shipped lock to the supported fixed floor, preserve exact package-graph and installed-smoke checks, and obtain ordinary exact-head review. Cloud also needs a normal qualified deployment/readback of the fixed installed graph because accepted release 306 is affected.
Clear/rebuild compiled route caches when Routing is upgraded, as the upstream CVE notes that vulnerable compiled routes persist until cache clear.
Do not add blanket audit ignores. Any retained historical exception must name the exact lock/package/version/advisory, owner, stopped execution boundary, and review/removal condition.
Keep the recurring all-lock audit/trust work separate from these narrow source repairs, but do not merge a guard that treats the newly active advisories as accepted exceptions.

Security will carry each exact correction independently; this comment is an inventory/relevance decision, not merge, deployment, image, or release clearance.

SDK PHP ownership is reconciled: sdk-php#301 owns the separate P1 Laravel HTTP example lock correction. The affected installed records here are HttpClient, HttpFoundation, HttpKernel, Routing and Yaml, all 7.4.21; the targeted supported floor is 7.4.23. SDK, Laravel, Octane and unrelated packages stay pinned.

There is no file overlap with current sdk-php#300, which checkpoints #244's typed replay work on its own branch. #301 takes priority and will return complete audit/strict lock validation, exact installed graph and the actual example HTTP/context smoke before exact-head Security review. The first resolver attempt stopped on a missing local test-image sockets extension; it changed no lock and is excluded from qualification. The example's PHP 8.3.35 toolchain is being prepared with the declared extensions rather than ignoring platform requirements. No SDK release or runtime/Cloud/portal operation is included.

SDK PHP's separate P1 repair is ready in sdk-php #302 at 8ea13dcf03709efb448268c30db788bdeecaf552 / base 5f5c0ca2387440bc578d5e26ab26973cea43ac5f. Exactly the five affected example-lock package records move to 7.4.23; every unrelated record, lock metadata and SDK/Laravel/Octane pin is preserved. Original complete audit: nine advisories. Candidate complete audit: none. All 99 installed versions/references and platform requirements match; actual lazy/eager HTTP context modes and config/route cache clear/rebuild pass.

All 42 normal exact-head checks are terminal (41 success, one intended skip). Installed and cache evidence / Security review request. Security's exact-head review and General's source merge remain pending. No overlap with typed-search PR #300 or library/release promotion.

Workflow open-item pass preserves General's ownership. The active dependency correction is now accepted main b3dd00e via #1032, following #1031; its exact installed three-fixture evidence and ordinary main acceptance are receipt6642044871. It does not complete this issue's maintained nested-lock inventory/trust scope or waive the two historical inputs.

I have reconciled that accepted security base with #1030's finished QA checkpoint and will incorporate it normally in the guard draft. General remains the named owner of static inventory, the exact #773/#809 advisory exceptions and the whole-repository effective Composer trust boundary. Next requested artifact is the focused inventory/exception source PR and its fail-closed changed-lock/new-advisory controls, with online recurring audit activation deferred until the clean-trust migration is actually qualified. No duplicate inventory implementation or historical performance rerun will be started by Workflow.

Sample App's affected shipped-lock/public-consumer portion of the November Symfony batch is delivered: owning issue #314, merge and final acceptance, exact main eaf8cd57135ded9e5e3b57a1ccd6ffa36f4f44df.

Both locks change only the nine affected records: root Filesystem/HttpFoundation/HttpKernel/Routing/Yaml 8.1.11; microservice HttpFoundation/HttpKernel/Routing 7.4.23 and Yaml 8.1.11. All 122/115 other objects and non-package fields are identical. Fresh full audits for all three committed locks report no advisories, abandoned packages, filters or cooldown exclusions. PHP 8.4/8.5 consumer suites and installed route-cache/health qualification pass; the earlier setup/helper failures remain disclosed separately.

All 17 exact-main workflows / 36 checks and the sole admitted publisher's seven jobs passed on attempt 1. Independent anonymous GHCR/Docker Hub main+immutable platform and installed-graph proof binds both platforms/configs to the merge and index sha256:a88864752df5da8c3a691f5f452fb2a50d7dd98145ff507b0fbae829fde5ea6a. Each installed inventory contains all 269 locked Composer records, exactly the nine fixed Symfony records and no blocked scan finding under existing reviewed dispositions.

This returns Sample App's actual source/public-image outcome to the advisory owning record. It changes no SDK/Server/Cloud release or frozen Server 3.0.5, and does not close other consumers' separately owned remediation.

Committed-lock inventory source is now delivered through #1033 actual-main acceptance: main 98bd98688663c005cb048d88f18119c35b6973b1 / tree9793ba86, four original workflows and30checks terminal27success/3intended skips; target build41933356619 all25jobs terminal. The five-lock exact offline inventory/history checks are active; General verified source/target/checks and removed only the merged remote branch after dependency/run checks.

This completes that source subtask of #970. The scheduled online audit remains inactive pending the separately reviewed whole-repository effective-trust work and exception/advisory disposition. Historical exact-lock exceptions are not advisory ignores. Cloud's deployable H2 trust delta has its own source/main acceptance and still needs the separately held image/build/operation gates; public/package/distribution follow-through stays with each owning receipt. General retains these remaining gates, and Workflow guard source may incorporate accepted98bd normally without claiming runtime delivery.

Navigation Menu

Repository navigation

Patch active Workflow Symfony MIME locks and audit nested Composer locks #970

Current state (November 4)

Finding

Acceptance

Why adding one verifier fails the whole repo

The one structural blocker

Smallest safe Workflow-only adoption paths, for General and Security to choose

Security relevance assessment — Symfony advisory batch published 2026-11-04

Fixed floors and records

Current inventory

Reachability assessment

Disposition

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Patch active Workflow Symfony MIME locks and audit nested Composer locks #970

Description

Current state (November 4)

Finding

Acceptance

Activity

rmcdaniel commented on Nov 1, 2026

rmcdaniel commented on Nov 1, 2026

rmcdaniel commented on Nov 2, 2026

rmcdaniel commented on Nov 2, 2026

Why adding one verifier fails the whole repo

The one structural blocker

Smallest safe Workflow-only adoption paths, for General and Security to choose

rmcdaniel commented on Nov 2, 2026

rmcdaniel commented on Nov 2, 2026

rmcdaniel commented on Nov 4, 2026

rmcdaniel commented on Nov 4, 2026

rmcdaniel commented on Nov 4, 2026

Security relevance assessment — Symfony advisory batch published 2026-11-04

Fixed floors and records

Current inventory

Reachability assessment

Disposition

rmcdaniel commented on Nov 4, 2026

rmcdaniel commented on Nov 4, 2026

rmcdaniel commented on Nov 4, 2026

rmcdaniel commented on Nov 4, 2026

rmcdaniel commented on Nov 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions