Assetpicker Bundle Laravel Package

Technical Evaluation

Architecture fit

• The package is netresearch/assetpicker-bundle — a Symfony bundle, not a Laravel package. It ships a bundle class, DI service definitions, and an importable proxy route. It will not autoload its service wiring into a Laravel container as-is.
• Functionally it is a thin, route-mounted HTTP proxy: a controller takes a to parameter and forwards the request. That is a small surface area, which is good for portability and bad for blast radius when it is wrong.
• The 2.0.1 fix is architecturally clean: it introduces a dedicated assetpicker.proxy.http_client service that decorates the framework http_client with Symfony's NoPrivateNetworkHttpClient, leaving the application's own http_client untouched. This is the correct isolation pattern and means the fix does not alter unrelated outbound traffic in the host app.

Integration feasibility

• Applying the patch itself is trivial: a version bump plus, for internal-host storage, a service redefinition supplying an allowList argument.
• Real integration cost depends on which of two worlds we are in:
  • Symfony host — native fit, low effort, standard service override.
  • Laravel host — no native bundle support. We would either isolate the bundle in a separate Symfony service, or port the proxy controller plus a NoPrivateNetworkHttpClient-equivalent guard (Guzzle handler with explicit loopback/RFC1918/link-local/.internal blocking) into Laravel middleware. The port is a few days of work and duplicates upstream security logic, so it needs a named owner and a re-sync cadence against upstream advisories.
• Hard dependency to validate: the allow-list mechanism requires symfony/http-client >= 8.1. Laravel 10/11 typically resolve Symfony 6/7 components, so the documented remediation path may be unavailable on our current stack until we upgrade. That is a potential upgrade blocker, not a config task.

Technical risk

• Pre-2.0.1 exposure is critical: any visitor could force the application server to fetch loopback, private networks, link-local, internal DNS names, and the cloud metadata endpoint 169.254.169.254. On IMDSv1 that is direct credential theft; on IMDSv2 it is still reconnaissance and, absent a hop-limit restriction, token acquisition.
• The advisory is a GitHub Security Advisory with no CVE referenced in the notes. Treat as high severity regardless; confirm CVE assignment and CVSS via the GHSA before scoring internally.
• Residual risk after patching shifts from confidentiality to availability and correctness: legitimate storage on an internal host now returns 403 Forbidden until explicitly allow-listed.
• The guard is DNS-resolution based. Validate whether the proxy follows redirects, and whether redirects are re-checked through the guarded client — classic bypass surface for NoPrivateNetworkHttpClient-style controls. Ask upstream directly; do not assume.
• Supply-chain posture materially improves: source archive, SPDX + CycloneDX SBOMs, build provenance, Cosign signatures, and gh attestation verify against a named signer workflow. This is a genuine compliance asset for our own SBOM and provenance obligations.
• Note the default branch moved to main. Any CI, mirroring, or Renovate/Dependabot config pinned to master will silently break.

Key questions

1. Do any of our applications import this bundle's route, and are any of them internet-reachable? This determines whether we are in incident response or routine patch.
2. Was 2.0.0 (or earlier) ever deployed to a cloud environment? Which provider, and is IMDSv1 disabled / hop limit set to 1?
3. Is there a CVE and a CVSS score, and does the maintainer publish a SECURITY.md with a disclosure SLA?
4. Is symfony/http-client >= 8.1 reachable on our current Laravel/Symfony version matrix, or does the documented allow-list fix require a framework upgrade?
5. Which internal hosts legitimately need to be reachable, and who owns that allow-list as a reviewed, version-controlled config rather than a production hotfix?
6. Are blocked requests logged and alerted, and is the proxy route authenticated and rate-limited?

Integration Approach

Stack fit

• For Symfony services: adopt 2.0.1 directly and override assetpicker.proxy.http_client with the allowList argument in services.yaml.
• For Laravel services: do not attempt to load the bundle. Either run the picker in a small Symfony sidecar behind an authenticated internal boundary, or port the proxy with a hard-blocking HTTP client handler. The sidecar is the lower-maintenance option; the port is the lower-latency option. Pick based on whether the asset picker is on a user-facing critical path.
• Either way, put the proxy route behind authentication and authorization. An unauthenticated server-side fetcher is the underlying design weakness, independent of the SSRF fix.

Migration path

1. Inventory composer.lock across all repos for netresearch/assetpicker-bundle and record resolved versions.
2. For any reachable instance on <= 2.0.0, apply an interim edge mitigation first (WAF deny on requests whose to parameter resolves to private/link-local ranges, and egress deny to 169.254.169.254 at the network layer). Do not wait for the composer bump.
3. Bump to 2.0.1, resolve symfony/http-client to ^8.1 where the framework permits.
4. Redefine assetpicker.proxy.http_client with an explicit allowList limited to the specific internal hosts required — never a subnet-wide or wildcard entry.
5. Regression-test both directions: an allowed internal host returns content, and loopback / RFC1918 / 169.254.169.254 / an internal DNS name each return 403.
6. Adopt attestation verification in CI: gh attestation verify ... --signer-workflow netresearch/.github/.github/workflows/release-source-archive.yml, and pin the artifact hash.

Compatibility

• Treat the patch as operationally breaking for anyone proxying internal storage, despite the patch-level version. Our change record should say so explicitly.
• Confirm the supported PHP range and Symfony component constraints before scheduling; a framework upgrade may be prerequisite work, which changes the estimate from hours to weeks.
• Audit tooling for master references following the branch rename.

Sequencing

• Week 0: exposure triage and interim network/WAF controls; confirm or rule out reachable deployments.
• Week 0–1: patch all confirmed-exposed and all reachable instances; verify attestation on the downloaded artifact.
• Week 1–2: allow-list configuration, functional regression on the picker, blocked-request logging turned on.
• Week 3–4: remaining non-exposed instances; add dependency scanning rule so this package is flagged on future advisories; document the Laravel-port owner if the sidecar path was rejected.

Operational Impact

Maintenance

• Low steady-state cost: one route, one service definition, one config knob. The main ongoing obligation is tracking upstream advisories — the fact that a critical SSRF shipped in 2.0.0 and was fixed in 2.0.1 within a patch release means this dependency must be in an automated alerting path, not a manual watch list.
• The bundle is maintained under the netresearch org with a small contributor set. Bus factor is a real but bounded concern given the shallow surface; the port-to-Laravel fallback doubles as our exit strategy.

Support

• Upstream provides an advisory, a PR, and a README section for the allow-list. There is no stated LTS or backport policy for 1.x/2.0.x lines — assume only the latest patch is supported.
• Request a SECURITY.md and a disclosure SLA as part of our vendor-risk record. Absent that, budget for us finding the next issue ourselves via scanning.

Scaling

• The proxy is a per-request server-side fan-out. It doubles bandwidth and adds latency for every asset fetch, and it inherits the application server's egress and connection pool.
• Because it is an unauthenticated-by-default fetcher, it is abusable for amplification and for using our infrastructure as a request origin. Enforce: authentication, per-user rate limits, response size caps, timeout bounds, and no redirect-following (or re-validated redirects).
• Allow-list entries are a scaling lever in the good direction — a short, static list keeps DNS lookups and guard evaluation cheap and predictable.

Failure modes

• 403 Forbidden on legitimate internal asset storage immediately after upgrade — the most likely production symptom, and the one to pre-empt with a staged rollout.
• Container compilation failure where symfony/http-client cannot reach 8.1 and the allow-list argument is configured anyway.
• Upstream timeout / 5xx propagation when an allowed host is slow; the proxy has no documented circuit breaking, so add a timeout at the client definition.
• DNS rebinding or redirect-based bypass if the guard is not applied to redirect hops — the highest-severity residual risk post-patch.
• Silent failure: blocked attempts returning 403 with no log line means we cannot tell an attack from a misconfiguration. Ensure the guard's decisions are logged and alerted on.
• CI breakage from the master → main branch rename in any pinned automation.

Ramp-up

• For a Symfony-fluent engineer: under a day to patch, configure the allow-list, and validate blocked/allowed paths.
• For a Laravel-only team: one to two weeks including the proxy port, guard implementation, tests, and security review — plus permanent ownership of a piece of security-sensitive code we now maintain ourselves.
• Prerequisite reading for whoever picks this up: the GHSA, PR #9, and the NoPrivateNetworkHttpClient documentation, specifically its redirect and DNS-resolution behavior.