Laravel Created By Laravel Package

Getting Started

This release is a security floor, not a feature drop. Before anything else, confirm your app satisfies the new platform requirement, because composer update will refuse to install v2.0.0 otherwise:

php artisan --version   # must report 12.61.1+ or 13.12.0+
composer show laravel/framework | grep versions

Minimal upgrade path:

1. Bump the framework first, the package second. Raise laravel/framework to ^12.61.1 (or ^13.12.0) in composer.json and update in isolation. If you bump the package first you'll just hit an unresolvable constraint and waste time reading solver output.
2. Remove any Laravel 11 lock-ins — phpunit.xml matrix entries, Docker base images, CI workflow matrices, and .platform overrides in composer.json that pin an older PHP/framework combination.
3. Install v2.0.0 and run php artisan config:clear (stale cached config from an L11 deploy is the most common post-upgrade "it's broken" report).
4. First use case to exercise: the two code paths named in the advisory — temporary signed URLs and the default email validation rule. Hit a signed route with a tampered path suffix, and submit an address containing \r\n to any form using the default email rule. Both should now fail closed.

Where to look first: the package's composer.json constraints, then config/ for anything published that touches URL generation, then your FormRequest classes that validate emails.

Implementation Patterns

Pin the floor in your own composer.json. Don't rely on the lockfile alone — state the constraint so future composer update runs on other machines and in CI can't drift back under the patched versions:

"require": {
    "php": "^8.2",
    "laravel/framework": "^12.61.1|^13.12.0"
}

Treat the framework version as part of the package version. Because v2.0.0's only meaningful contract change is the platform requirement, your upgrade PR should touch composer.json, composer.lock, and CI config together. Splitting them across PRs creates a window where composer install succeeds locally and fails in CI (or vice versa, depending on cache state).

Update the CI matrix in the same commit. A matrix that still runs laravel/framework:^11.0 will fail on install, and a matrix that only runs 12.x silently drops your 13.x coverage. If you support both, run both — the package declares support for both branches, so both are your problem.

Sequence multi-package upgrades. If you have several packages that each publish a security floor, do them in dependency order. Bumping the framework to ^12.61.1 unlocks all of them at once; bumping packages first results in a solver dead-end. A quick way to see who's blocking you:

composer why-not laravel/framework 12.61.1

Roll out to staging before production, and specifically replay real traffic through the two patched paths. The signed-URL fix changes how paths are compared; if any of your own code generates signatures manually (rather than via URL::temporarySignedRoute()), verify it still validates. Similarly, if you have custom email validation that wraps the framework rule, confirm it inherits the CRLF fix rather than reimplementing the regex.

Audit for stored artifacts of the old behavior. The CRLF injection fix means inputs that previously passed now fail. If you have historical user records or queued jobs holding addresses with embedded newlines, expect new validation errors at replay time. Decide deliberately whether to sanitize data or let it fail.

Gotchas and Tips

• ^12.61.1 is not ^12.0. The caret respects the patch floor, so 12.0–12.61.0 are excluded. If a transitive dependency pins framework to an older 12.x, Composer will report a conflict against this package rather than an obviously-related error — read the solver output bottom-up, the real culprit is usually the last line.
• Laravel 11 will not receive these patches. Staying on L11 isn't "unsupported but working" in a benign sense here: the two advisories are unpatched on that branch. Budget the framework upgrade as part of the package upgrade, not as a follow-up ticket.
• Deploy-time config cache is the top false-positive. After upgrading, php artisan config:cache on the new build; a container still serving a config cache built under L11 can produce behavior that looks like the package is broken when it's just stale serialized state.
• Signed URL debugging: failures here are usually clock skew or a mismatched APP_URL between the signer and verifier (load balancer vs. app host). Before blaming the patch, confirm both sides agree on scheme, host, and port. URL::hasValidSignature() returning false for a URL you just generated is almost always this, not the advisory.
• Email rule debugging: the CRLF fix makes previously-accepted input invalid. If a test now fails on an address you consider legitimate, log the raw bytes — invisible \r/\n from a copy-paste or CSV import is the usual source.
• Extension point to check: if the package publishes config or registers a validator/signer extension, re-publish or diff the config after upgrading. Published config from an older version won't pick up new defaults automatically, and security-adjacent defaults are exactly what you don't want silently stale.
• Don't hand-roll the patched logic. If you previously worked around the path-confusion issue in your own middleware, remove the workaround — double-verification logic layered on top of the fixed behavior tends to reject valid URLs in ways that are hard to diagnose later.