Assetpicker Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the asset/media picker surface. This bundle supplies the "pick a file from a storage backend" UI and the server-side proxy that streams the selected asset into your app. That is a well-understood, non-differentiating UI capability; this release makes the buy side materially more defensible than it was a version ago.
• Whether to ship the bundled proxy route at all. 2.0.1 fixes a server-side request forgery (SSRF) flaw in the proxy route: any visitor could pass an arbitrary to URL and cause your application server to fetch loopback, private-network, link-local addresses (including the cloud metadata endpoint 169.254.169.254) and internal DNS names. As PM, this is the decision that matters — if you expose this route to untrusted users, the previous version was an infrastructure-level risk, not a UI nit. Options: upgrade and keep the route, upgrade and gate the route behind auth, or stop importing the bundle's route and implement your own fetch. Treat "do we even need this route exposed?" as a product question, not just a patch ticket.
• Feature scoping for internal-host storage. The fix introduces a deliberate behaviour change: any storage backend living on an internal host now requires an explicit allow list (assetpicker.proxy.http_client redefined with the allowList argument, symfony/http-client 8.1+). If your roadmap includes on-prem/S3-compatible internal endpoints, that configuration becomes a documented onboarding step and a support-burden line item — price it in.
• Security-response as a selection criterion. A same-day advisory plus a public PR from an outside contributor (@CybotTM) is a positive signal for the vendor-risk scorecard. It also means your dependency policy should be able to consume such fixes quickly — i.e. you need to know which of your apps import this route before the next advisory, not after.
• Supply-chain / procurement roadmap. 2.0.1 is the first release built, signed, and attested by the release workflow: source archive, SPDX and CycloneDX SBOMs, build provenance, and Cosign signatures, verifiable via gh attestation verify. This unlocks questions you can now answer for security review and enterprise customers — SBOM ingestion into your SCA tooling, artifact provenance checks in CI — that were previously "ask the vendor."
• Roadmap signal on maintenance health. The default branch moved to main and release automation is now centralised in netresearch/.github. Small, but it tells you the project is standardising its pipeline; expect more automated releases and a lower chance of ad-hoc, unattested tags.

When to Consider This Package

Adopt when:

• You need a ready-made, backend-agnostic asset/file picker UI in a PHP application and would otherwise spend a sprint or two building one.
• You are on (or can move to) symfony/http-client 8.1+ — required if you need the internal-host allow list.
• You can run this at 2.0.1 or later. Do not adopt 2.0.0 for any deployment reachable by untrusted users; the proxy route is an SSRF primitive.
• Your architecture lets you place the proxy route behind authentication/authorisation, or restrict it to trusted callers, so the allow-list is a belt-and-braces control rather than the only control.
• Supply-chain attestation matters to your buyers or your own security team — signed artifacts and SBOMs are now first-class, which is unusual for a package this size.
• Your storage backends are on public/normal hosts, or you're willing to maintain an explicit internal-host allow list as configuration.

Look elsewhere or defer when:

• You cannot upgrade off 2.0.0 quickly and the route is internet-reachable. That is a containment problem, not an evaluation problem — disable or firewall the route now, then re-evaluate.
• You are pinned below symfony/http-client 8.1 and depend on internal-host storage. Without the allow-list mechanism the upgrade path is friction, and the workaround is custom client wiring.
• You need first-class Laravel integration. This is a Symfony bundle; in a Laravel codebase expect glue work (service container mapping, routing, config translation) and no Laravel-native conventions, facade, or package discovery. If the team has no Symfony literacy, the integration cost can exceed the build cost.
• You want the picker as a JS/SPA component with the server doing nothing but signing uploads. The proxy-route model is the opposite shape, and the security surface follows from it.
• You need guarantees on long-term maintainership. One maintainer-org, a young release history, and a security advisory in its early versions is a real (if improving) maturity caveat. For a low-blast-radius admin tool that's fine; for a customer-facing surface, weigh it.
• You only need a handful of fixed assets. A CMS field or a few Blade/Twig templates is cheaper than a dependency plus its upgrade obligations.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source PHP component for the "choose a file" step in our product. Its previous version had a serious security flaw — an attacker could use it to make our servers fetch internal addresses, including cloud credentials endpoints — so it was not shippable as-is. The new 2.0.1 release closes that flaw, and the project now publishes signed releases with software bills of materials and build provenance, which is the kind of evidence our security reviews and enterprise buyers increasingly ask for. Recommendation: adopt at 2.0.1+ behind authentication rather than building this ourselves, and treat the upgrade as a same-week action because the flaw is remotely triggerable.

For engineering leads: Upgrade to 2.0.1 before anything else; 2.0.0's proxy route forwarded to any supplied to URL, so it was a straightforward SSRF into loopback, RFC1918, link-local (169.254.169.254), and internal DNS. The fix gives the proxy its own client (assetpicker.proxy.http_client) wrapping http_client in Symfony's NoPrivateNetworkHttpClient and returns 403 on refused targets; our own http_client is untouched, so no collateral changes. The breaking bit: any storage on an internal host now needs an explicit allowList on a redefined assetpicker.proxy.http_client, which requires symfony/http-client 8.1+. Ask: (1) do we actually need to expose this route, and to whom; (2) can we land the 8.1 bump in the same release; (3) can we add gh attestation verify to our artifact intake now that releases are signed.

For security and procurement: The advisory is GHSA-fjm5-jqj9-h9j2, fixed by PR #9. Releases from 2.0.1 onward are produced by netresearch/.github's release-source-archive.yml and ship a source archive, SPDX and CycloneDX SBOMs, build provenance, and Cosign signatures; verification is a single documented command. Practically, this means the component can enter SBOM-driven dependency tracking and provenance checks — worth capturing in the vendor record, and worth flagging that the project's first attested release is also its first security release, so we should set a review checkpoint on the next two versions rather than assume the process is proven.

Framing caution: the flaw was in the bundle's own proxy route, not in a transitive dependency we already run, and it was found and fixed publicly within the project. That is a reasonable story to tell — a component that publishes advisories and fixes them fast is safer than one whose bugs go unreported — but don't let it bury the operational point: our exposure window is set by how fast we can inventory and patch apps that import this route.