One morning, a shop owner's phone buzzes. It is a message from the developer who built their website: "There is a security update from the framework. Install it now or tomorrow?" (An illustrative scenario, not a story about any real client.)

Two answers come up most often: "whatever is safest" or "later, orders are busy right now". Both point to the same problem. The update decision gets made when a message arrives, not by a schedule agreed in advance.

October 2026 shows why that matters. Security flaws piled up across PHP, Laravel, and Node.js within days of each other. This article focuses on the one that has had less coverage: Laravel.

What happened in Laravel

Laravel is a PHP framework behind many websites and business applications. On 19 October 2026, the Laravel team published a security advisory for CVE-2026-114509, rated critical with a score of 9.2 out of 10 (CVSS 4.0). The problem sits in TokenGuard, the built-in feature for protecting APIs with tokens. An attacker with no login can sign in as an existing user on any route protected by that guard.

Affected versions: everything below 12.68.0, and the 13 series below 13.29.0. The flaw is reported on MySQL or MariaDB configurations.

Laravel flaw timeline: fix released 25 August, advisory published 19 October, CVE recorded 21 October, proof-of-concept public 22 October

Look at the dates. The fix in Laravel 12.68.0 and 13.29.0 shipped on 25 August. The advisory came almost two months later. A site that was updated routinely from late August was already safe from this flaw long before the news broke. The ones scrambling now are the ones that waited for a headline.

According to Ostorlab's analysis, proof-of-concept code has been public since 22 October. As of 24 October they had no record of attacks in the wild, and the flaw was not in CISA's KEV catalog. That status can change fast, so do not treat it as a reason to wait.

How the flaw works

Without code: the guard only checks that the token is not empty. If an attacker sends the token as a list, for example one holding the number 0, that check passes. Then the database joins in. MySQL and MariaDB convert text to numbers when comparing, and text starting with a letter reads as 0. The fake token ends up matching a real user. Per Ostorlab, the match is the first user found, often an admin.

Four steps of the flaw: send an odd token, pass the check, database misreads it, an account matches

Not every Laravel website is automatically exposed. It takes a guard with the token driver, a route that uses it, and a MySQL or MariaDB database. Public analysis indicates PostgreSQL and SQLite do not behave the same way. A second advisory, CVE-2026-114508 (medium, score 6.5), is fixed by the same updates.

It is not only Laravel

In the same week, on 21 October, PHP shipped emergency patches for two flaws nicknamed PHP2Shell (CVE-2026-109618 and CVE-2026-109619). Both allow remote code execution without a login. Safe versions: PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. According to BleepingComputer, Cloudflare's CTO said early attacks were already visible before the patches came out.

On the same day, Node.js closed 10 flaws, four of them high severity, in versions 22.23.4, 24.22.1, and 26.12.1. One is a Brotli decoder flaw that can lead to code execution.

Three layers of a website: framework, language and runtime, server and database

One website has several layers, and each layer ships on its own schedule. If the developer only watches one, the others can fall months behind.

Patching is a routine, not a reaction

Reacting to headlines has two flaws. Either the update is rushed in untested and the site breaks, or it is postponed because things are busy and then forgotten. A fixed schedule avoids both: watch the releases, test on a copy of the site, apply in a quiet window, record the version and date. Once a month is enough for routine updates.

One honest caveat. The Laravel flaw was lucky, because its fix had been waiting for two months. PHP2Shell was not: attacks started before the patch existed. So a monthly schedule needs an emergency lane, meaning a rule agreed upfront about which flaws get installed the same day.

Five questions for your developer

If someone else built your website, you do not need to read code. Just ask for written answers to the following:

  1. The Laravel (and PHP) version running now, and the date of the last update.
  2. Whether any guard uses the token driver in the auth configuration, and which routes use it.
  3. Whether the database is MySQL or MariaDB.
  4. Whether the logs were checked for requests with api_token sent as a list (array).
  5. Whether a restorable backup exists before the update is applied.
Seven things to ask your developer: version, token guard, routes, database, logs, last update date, backup

Developers usually check this with commands like `composer show laravel/framework` and `php artisan config:show auth`. If the update cannot go in today, there is a temporary guard: middleware that rejects a non-string api_token, or a WAF rule that blocks it. That only buys time. It does not replace the update.

One more thing. If your website still runs on Laravel 11 or older, this advisory lists no fixed version for it, and according to Convika, Laravel 11's security support ended on 12 March 2026. That is a reason to discuss a version upgrade, not just a patch.

If you want a second look

XETUP builds and maintains systems for businesses. If you would like a quick check of your website, the versions it runs, and its update schedule, message us on WhatsApp at +62 823 1499 5005 or visit xetup.id. You do not have to change who manages your site.