- Laravel 13.35.0, published October 6, 2026, is mostly small fixes to database handling, with a smaller set for queues and scheduling, plus a few features.
- The notes list changes by title only and label none as a security fix, so the impact on any one application depends on which features it uses.
- Leaders should ask who owns framework upgrades and whether background jobs are monitored for stalls, not only crashes.
The releases that keep a business running rarely come with a launch event. Laravel 13.35.0, published on GitHub on October 6, is one of the quiet ones. It has no headline feature. It has a long list of corrections, and that list says something useful about where bugs turn up in a framework.
What the release contains
The release notes list about 60 changes from more than 20 named contributors. A few add capability. Laravel's queue worker command, queue:work, can now take its memory limit as a percentage. Routes can use the QUERY HTTP method. The response factory gains a markdown() method. A new Schedule::alwaysOnOneServer() method sets a scheduled task to run on a single server.
Most entries are fixes. The notes describe each by a one-line title only. They do not label any change as a security fix.
The idea: dependability is built from small corrections
The lesson here is that reliability rarely arrives as a big upgrade. It builds up as many small corrections. A release like this shows a slice of that work. Think of the maintenance checks airlines run between flights. Nobody advertises them, and passengers notice only when they are skipped.
Most fixes sit in the data layer
Most of the fixes concern how the framework reads, writes and links data. That covers Eloquent (Laravel's tool for working with database records), relations between records, query building, collections and file storage.
Several of these read as cases where results could be wrong without an obvious error. One fix stops forceCreate() from ignoring withAttributes(). Another stops collapse(), collapseWithKeys() and flatten() from dropping lazy collections. The notes also cite DatabaseRule where() and whereNot() "losing false values", cursorPaginate() losing union select and join bindings, and duration helpers truncating float values. The notes give titles only, so how each bug showed up is not stated.
A further fix covers partial edits to a JSON field. When a model cast the field into an object, pending changes on that object could be lost during a path update.
The notes give no detail on real-world impact. Whether any of these matter depends on whether an application uses the feature.
A few fixes near queues and schedules
A smaller set touches queues and scheduling. These are the background jobs that run without anyone watching, often overnight. Not every item in this set runs in production, so it helps to sort them.
Two items are not production features at all. Queue::fakeFor() is a helper for tests, and the fix makes it release unique job locks. The schedule:list command only displays upcoming runs, and the fix corrects its timezone conversion around a daylight saving change. Neither one runs your jobs.
Two items are database methods rather than queue features. chunkById() and lazyById() let code walk through a large table in batches, and batch jobs commonly use them. The fix stops them from "looping forever" on models with a cast primary key. In a batch job, an endless loop could mean work that never finishes. The notes do not say whether any job has hit this.
Other items do touch code that runs in production. One fixes isLocked() on a free Memcached lock. One fixes queue attributes that a child class ignored when it used Queueable. One normalizes the queue name in the SQS bulk method. The notes do not describe the effect on running systems. These, along with the chunking loop, are the items where a failure could be quiet, because a job that stalls raises no error page.
Two fixes address reference cycles: one in PendingRequest::throw() and one in the Mailable headers() and priority() callbacks. A reference cycle is when objects hold each other in memory so it cannot be released. The notes do not link these to workers.
What the public security record shows
The release is not framed as a security update, so the public record is context, not a finding about this release. WebPulse's CVE profile, built from NIST NVD data, lists the following for Laravel.
The profile also counts 2 critical CVEs across all time. A low count of public CVEs measures disclosed flaws, not the total number of flaws. It says nothing about the bugs this release fixes, which are not CVEs.
Questions to put to your team
First, who owns framework upgrades, and how far behind the current release are your production apps? Second, do your queue workers and scheduled tasks have monitoring that reports a stalled or silent job, not only a crashed one? Third, do you run long-lived workers with a memory limit, and what happens when it is hit? Fourth, do your tests cover batch jobs and scheduled tasks, or only web pages?
A release with no drama is still a decision. Reading the changelog before upgrading tells you which of these fixes touch code you actually run. Most of this one concerns data handling, and the few queue items are worth checking against your own jobs.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub (laravel/framework).
