Skip to content
Security & Trust

Craft CMS flaw lets a control panel user run code on the web server

CVE-2026-112770 turns a control panel login into code execution in Craft versions before 4.18.8 and 5.11.0.

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
Craft CMS flaw lets a control panel user run code on the web server
In brief
  • NIST's NVD record for CVE-2026-112770 says Craft CMS 4.x before 4.18.8 and 5.x before 5.11.0 lets authenticated control panel users run code on the server.
  • The record rates it 8.8 (High) on CVSS 3.1. The flaw is a missing safety check in one Twig filter, not a stolen password.
  • Confirm your Craft version, move to 4.18.8 or 5.11.0 or later, and review who holds control panel accounts.

A login is not a wall. It is a ticket. The question for any system is what the lowest ticket can do once it is inside. A newly published record for Craft CMS shows how far that can go.

What the record says

NIST's National Vulnerability Database (NVD) published CVE-2026-112770 on October 19, 2026. The entry covers Craft 4 releases older than 4.18.8 and Craft 5 releases older than 5.11.0. It describes a flaw that lets an attacker's code run on the server. Security teams call this remote code execution.

The NVD record says authenticated control panel users can use the flaw to write a webshell to the webroot. A webshell is a small script that lets someone run commands through the website. The record says the code then runs as the web user, the account the web server itself runs under.

VulnCheck scored the flaw 8.8 (High) on CVSS 3.1 and 8.7 (High) on CVSS 4.0. The vector shows it can be attacked over the network, with low complexity, low privileges and no user interaction. VulnCheck is the source of both scores.

How the flaw works

Craft uses Twig, a templating language, to shape content on a page. A Twig filter is a small function that reorganises data. The Twig group filter sorts items into groups. Some filters accept an "arrow" argument, a short inline instruction that tells the filter how to do its job.

According to the NVD record, the group filter treats non-string arrow arguments as callables. A callable is a reference to a function that the system will run. The record says the group filter does this without the checkArrow guard that other arrow-accepting filters use.

That guard is the missing piece. With it absent, the record says a signed-in user can pass an array-callable such as FileHelper::writeToFile through the condition rules attached to element-select fields. In plain terms, the user hands the filter the name of a function, and the filter runs it.

The record says the user can use this to write a webshell to the webroot. A webshell there gives them a way to run commands.

The record does not say which control panel roles or permissions are needed. It also does not report any attacks in the wild. Both gaps matter when you judge your own exposure.

The lesson: one missed check

The record points to a simple cause. Other filters that accept arrow arguments carry the guard, and this one does not. That is a pattern in how software is built. A safety check that must be remembered at every place it applies can be missed in one.

For an executive, the lesson is about distance. The gap between "can build content" and "can run code on the server" is only as wide as the weakest check in between. Here, that distance was one filter.

This also changes how to read the phrase "requires authentication." It lowers the odds of attack from strangers. It does not remove the risk from stolen credentials, shared accounts, former contractors or any user whose access was never reviewed. The scoring vector lists the required privilege level as low.

What to ask your team

Start with inventory. Ask which Craft sites you run, and whether each is on 4.18.8 or later in the 4.x line, or 5.11.0 or later in the 5.x line. The record puts those versions outside the affected range. Include agency-run and forgotten sites.

Then ask who holds control panel accounts. Count them, check that each person still needs access, and confirm that multi-factor sign-in covers them. The record names control panel users with low privileges as the ones who can use the flaw.

Ask whether anyone has checked for files that should not be in the webroot. The record describes writing a webshell there, so unexpected new files are worth a look. Finally, ask what the web user account can reach. If it can read secrets or database credentials, the damage from this flaw grows with it.

NVD lists two references for the details: Craft's GitHub security advisory GHSA-xmwr-88vw-5ghh and a VulnCheck advisory. Your engineers should read both before they sign off on the upgrade.

A login proves who someone is. It does not limit what the software will do for them.

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: NIST NVD.

Share this insight