CISA Adds 3 KEV Bugs: Joomla Page Builders and Langflow Authorization Flaw

CISA added three actively exploited vulnerabilities to its Known Exploited Vulnerabilities Catalog on July 7, 2026, covering JoomShaper SP Page Builder, Langflow, and Joomlack Page Builder after receiving evidence that attackers are already using the flaws in the wild. The update is small in count but large in implication: two Joomla page-builder bugs and one AI workflow authorization flaw neatly capture where modern exposure lives. The old patching problem was “Which CVEs are severe?” The current one is “Which exposed systems hand attackers a working foothold before the next maintenance window?”
As detailed in CISA’s July 7 alert, the new KEV entries are CVE-2026-48908 in JoomShaper SP Page Builder, CVE-2026-55255 in Langflow, and CVE-2026-56290 in Joomlack Page Builder. CISA did not publish exploit chains or indicators in the alert, but the agency’s KEV threshold matters: a listing is not a theoretical severity score, it is a statement that exploitation has been observed. That distinction is why this particular batch should make both web admins and AI platform teams uncomfortable.

Cybersecurity infographic showing scanning exposed web assets and known exploited vulnerabilities with patch/verify guidance.CISA’s Small Update Lands in the Middle of a Bigger Patching Reset​

For years, the KEV Catalog functioned as a corrective to CVSS theater. Security teams could argue endlessly over whether a vulnerability was 8.8 or 9.8, but CISA’s exploited list cut through that debate with a simpler claim: attackers are already using this one, so treat it differently. The July 7 additions continue that tradition, but they now sit under a newer federal framework that makes the catalog more operationally consequential.
That framework is Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk,” which CISA released on June 10, 2026. FedRAMP’s public notice described the directive as a shift toward prioritizing remediation based on public exposure, KEV status, automation potential, and technical impact. In plain English, the government is telling agencies to stop pretending that a vulnerability buried on an internal workstation is the same operational problem as an exploited flaw on an internet-facing service.
That is the right correction. It is also a tacit admission that vulnerability management programs have been drowning in numerically severe but operationally ambiguous findings. CISA’s new model elevates a narrower and more dangerous class of bugs: those that are reachable, exploited, easy to repeat, and capable of handing over meaningful control.
The July 7 trio fits that model almost too cleanly. The two Joomla extension vulnerabilities sit in the classic web-exposure lane, where attackers scan broadly and monetize quickly. The Langflow vulnerability belongs to the newer AI infrastructure lane, where self-hosted developer tools and workflow systems often carry secrets, integrations, and privileged access far beyond what their friendly low-code interfaces suggest.

Joomla Page Builders Remain a Soft Target Because They Sit Where Attackers Want to Be​

The JoomShaper entry, CVE-2026-48908, is the kind of vulnerability that gives incident responders a grim sense of déjà vu. According to NIST’s National Vulnerability Database and third-party vulnerability writeups from firms including SentinelOne and IONIX, the flaw affects SP Page Builder for Joomla and allows unauthenticated users to upload arbitrary files, potentially leading to PHP code execution. Reports place affected versions in the SP Page Builder 1.0.0 through 6.6.1 range, with fixed releases in the 6.6.2 line or later depending on the advisory source.
That is not a subtle bug class. An unauthenticated file upload that can become remote code execution is one of the web’s oldest disaster patterns. The attacker does not need stolen credentials, a phishing foothold, or a carefully staged client-side compromise. If the vulnerable component is exposed and the upload path can be reached, the server itself becomes the entry point.
SP Page Builder matters because site-builder extensions are not obscure admin niceties. They are installed precisely to make public websites easier to design, extend, and update. That convenience puts them close to the public web surface, the file system, media upload handlers, template logic, and plugin permissions — a dangerous neighborhood when input validation and authorization checks fail.
CVE-2026-56290, the Joomlack Page Builder vulnerability, rhymes with the JoomShaper flaw even if the implementation differs. CISA describes it as an improper access control vulnerability in Joomlack Page Builder, and vulnerability databases have characterized the issue as a serious Joomla extension flaw with potential for arbitrary upload and full compromise in affected Page Builder CK deployments. The important point for defenders is not whether the vulnerable endpoint is named like another vendor’s endpoint; it is that page-builder extensions keep becoming privileged pathways into web servers.
The pattern should be familiar to anyone who has administered WordPress, Joomla, Drupal, or Magento at scale. The content management system core may be reasonably maintained, but the ecosystem of templates, builders, sliders, forms, galleries, and add-ons becomes the real attack surface. The business sees a brochure site. The attacker sees a PHP application stack with writable directories, third-party code, and an owner who probably does not read extension changelogs.

The Langflow Bug Shows AI Tooling Has Joined the Ordinary Web Attack Surface​

The Langflow entry, CVE-2026-55255, is different in flavor but not in lesson. Langflow is an open-source tool for building AI agents and workflows, often used to wire together models, prompts, APIs, databases, retrieval systems, and automation steps. According to Snyk and SentinelOne’s vulnerability database, the flaw involves an authorization bypass through a user-controlled key, affecting Langflow components before patched versions such as 1.9.2 in reported advisories.
The reported issue is an insecure direct object reference pattern, or IDOR, in which an authenticated user can manipulate an identifier and access or invoke resources that should belong to someone else. In some writeups, the vulnerable behavior centers on flow access through API handling, where supplying another flow identifier can lead to unauthorized execution or access. That may sound less dramatic than unauthenticated remote code execution, but in an AI workflow platform the blast radius can be stranger and wider.
A Langflow instance may hold API tokens, model provider credentials, vector database connections, internal knowledge sources, automation hooks, and business logic that was never designed to be exposed across tenants. A flaw that lets one user execute or reach another user’s flow can cross from “authorization bug” into “data boundary failure” very quickly. In the wrong deployment, the compromised object is not just a saved workflow; it is a map of the organization’s AI plumbing.
That is why the Langflow listing is arguably the most forward-looking of the three. Traditional web CMS exploitation often leads to shells, spam, redirects, credential theft, or staging infrastructure. AI workflow exploitation can also do those things, but it adds a newer category of exposure: prompts, embeddings, internal connectors, automation secrets, and model-adjacent data paths that many organizations have not fully inventoried.
The security industry spent 2023 and 2024 warning that AI systems would create novel risks. In practice, many of the first serious risks look depressingly familiar. They are broken authorization, unsafe object references, exposed admin panels, overprivileged tokens, and software deployed faster than it is governed. The novelty is not that the bugs are magical; it is that the systems behind them are increasingly wired into everything else.

KEV Is Not a Hall of Shame, It Is a Triage Machine​

The phrase “known exploited” carries more operational weight than many CVE announcements. A vulnerability can be severe without being exploited. It can be elegant in a researcher’s proof of concept and still be difficult to weaponize at scale. KEV status narrows the field to flaws for which the exploitation question has moved from could they? to they are.
That is why CISA’s catalog has become more important than ordinary vulnerability feeds. It is not comprehensive, and it is not meant to replace vendor advisories, asset management, exposure management, or threat intelligence. But it supplies a public, government-backed signal that a vulnerability has crossed a threshold security teams cannot responsibly ignore.
BOD 26-04 sharpens that signal for federal civilian agencies. Under the directive’s logic, an internet-facing asset with an exploited vulnerability that can be automated and grants total control deserves a much faster remediation path than a lower-impact flaw on a non-exposed system. Some summaries of the directive from vulnerability-management vendors and government-adjacent programs describe the most urgent combinations as requiring action in days, not weeks.
Private organizations are not legally bound by the federal directive, but they should still pay attention. CISA’s operational model reflects attacker economics, not just government compliance. If a bug is exposed, exploited, automatable, and high-impact, ransomware crews, botnet operators, initial-access brokers, and opportunistic scanners do not care whether the victim is a federal agency, a small business, a university, or a hobbyist running Joomla on a neglected VPS.
The uncomfortable truth is that KEV has become one of the few vulnerability signals that travels well across organizational maturity levels. A Fortune 500 security team can plug it into exposure graphs and SLA engines. A small IT shop can use it as a daily “drop everything else” list. A volunteer webmaster can treat it as a warning that the internet has already moved from scanning to exploitation.

The Web Admin’s Problem Is Inventory, Not Awareness​

Most administrators do not ignore critical web vulnerabilities because they enjoy risk. They ignore them because they do not know the vulnerable component is present, do not know which version is installed, do not know who owns the site, or cannot safely patch without breaking a revenue-generating page. CMS ecosystems amplify every one of those problems.
Joomla extensions are often installed during a redesign and then forgotten. A contractor builds the site, the business keeps the look, and years later the plugin remains in place because nobody wants to touch the template stack. When the extension later becomes exploitable, the organization’s official software inventory may show “Linux server” or “Joomla site,” but not “SP Page Builder 6.6.1 with a vulnerable upload controller.”
That gap is where attackers live. They do not need a clean CMDB entry. They need a recognizable endpoint, a version clue, a vulnerable route, or simply enough sites running the same extension to make broad scanning worthwhile. If public exploit code exists or the exploit is easy to reproduce, the time between advisory and compromise can collapse.
The practical answer is not merely “patch Joomla.” It is to inventory Joomla extensions and page-builder plugins with the same seriousness applied to operating systems and endpoint agents. If a site depends on SP Page Builder or Page Builder CK, the owner should know the installed version, the public exposure, the update path, the backup state, and the rollback plan before the next exploited CVE appears.
This is also where Windows-heavy environments should resist a false sense of distance. A Microsoft-centric shop may not think of Joomla as “its” platform, but web properties frequently sit outside the neat boundaries of endpoint management. Marketing sites, intranet-adjacent portals, partner microsites, legacy campaign pages, and externally hosted CMS deployments often become part of the organization’s risk whether or not they appear in the Windows admin console.

AI Workflow Servers Are Becoming the New Forgotten Admin Panels​

Langflow adds a different inventory challenge. AI tools often enter organizations through developer experimentation rather than formal platform engineering. Someone spins up a container, connects a model provider key, wires in a vector store, tests an agent workflow, and leaves the service available to a team. The deployment may be “temporary” in the same way every forgotten server is temporary: right up until it is found by someone else.
The authorization-bypass class in CVE-2026-55255 should force organizations to ask whether their AI workflow tools are treated as production systems. If Langflow can access internal documents, execute chains, call APIs, or store provider keys, it is no longer a sandbox in any meaningful sense. It is middleware.
That middleware deserves normal controls: authentication, authorization boundaries, network segmentation, logging, version management, secret rotation, and least-privilege service accounts. Those controls are not glamorous, which is exactly why they matter. The more “AI-native” the interface looks, the easier it becomes to forget that underneath it sits an ordinary web application with ordinary web bugs.
There is also a cultural problem. Many AI orchestration tools sell speed and experimentation, while enterprise security sells restraint and auditability. The compromise is often informal: tools are allowed because they seem useful, but they are not brought fully into governance because doing so would slow the experiment. KEV listings like this one are reminders that attackers do not wait for the governance model to mature.
The safest interpretation of CVE-2026-55255 is not that every Langflow deployment is doomed. It is that AI workflow platforms have graduated into the category of software that must be continuously tracked. Once attackers know these tools can contain secrets and cross-system connections, they will treat them less like toys and more like control planes.

Federal Deadlines Will Shape Private-Sector Expectations​

CISA’s July 7 alert says BOD 26-04 applies to Federal Civilian Executive Branch agencies, but also encourages all organizations to adopt risk-based vulnerability management and prioritize KEV vulnerabilities. That language is familiar, but it should not be dismissed as boilerplate. Federal security expectations have a way of becoming procurement expectations, insurance questions, customer questionnaires, and board-level benchmarks.
FedRAMP’s response is especially telling. By aligning FedRAMP vulnerability detection and reporting expectations with BOD 26-04, the federal cloud ecosystem is turning CISA’s prioritization model into a practical compliance pressure for cloud service providers. If a provider serves government customers, it cannot treat KEV as a passive feed.
The private sector will follow unevenly. Large enterprises will map KEV status into exposure-management platforms and ticket prioritization. Smaller organizations will continue to struggle with who owns the Joomla site, who maintains the AI lab server, and whether the patch will break something visible. But the direction of travel is clear: exploited-plus-exposed is becoming the remediation category that executives can understand.
That may be the most important policy change hidden inside this otherwise routine alert. CISA is not asking agencies to patch everything faster. It is asking them to patch the most attackable things first and to check whether compromise happened before remediation. That second obligation matters because a patched web shell is still a web shell if nobody looked for it.
For the newly listed Joomla vulnerabilities, that means administrators should not stop at updating the extension. They should review uploaded files, web roots, recently modified PHP files, new Joomla administrator accounts, suspicious scheduled tasks, unfamiliar plugins, and outbound connections. For Langflow, teams should review users, flow access, execution logs, API tokens, environment variables, connected data stores, and any workflow that could have been invoked across authorization boundaries.

Patch Management Finally Meets the Systems Attackers Actually Scan​

The cleanest reading of the July 7 KEV update is that attackers continue to favor boring, reachable, high-impact bugs. Page-builder upload flaws are not conceptually new, but they remain devastating because public websites are easy to find and hard to uniformly maintain. Authorization bugs in AI workflow platforms are newer in context, but they exploit a very old weakness: trusting a user-supplied identifier more than the access-control model.
For administrators, the immediate response should be concrete rather than philosophical. Identify any Joomla sites using JoomShaper SP Page Builder or Joomlack Page Builder CK, verify versions, apply vendor fixes, and hunt for post-exploitation artifacts. Identify any Langflow deployments, especially self-hosted or internet-reachable instances, and update to a patched release while reviewing cross-user access and secret exposure.
The broader response is to change how these systems are classified. A public CMS extension that can write files is not cosmetic software. An AI workflow tool that can call APIs and hold keys is not a toy. Both are part of the attack surface, and both deserve owners, update channels, logs, and incident-response playbooks.
That is where CISA’s risk-based approach is useful beyond federal compliance. It gives defenders permission to deprioritize some noise while escalating the ugly combinations that actually become intrusions. In a world where every scan produces too many findings, KEV plus exposure plus technical impact is one of the few triage formulas that maps cleanly to attacker behavior.

The July 7 KEV Additions Leave Little Room for Comfortable Delay​

CISA’s latest update should push teams toward a short, practical sequence: find the affected software, patch it, and then assume the vulnerable system may have been touched before the fix. That final step is the one organizations most often skip, and it is the one BOD 26-04 is trying to normalize.
  • Organizations running JoomShaper SP Page Builder should verify whether they are on an affected version and update immediately, especially if the Joomla site is publicly reachable.
  • Organizations using Joomlack Page Builder or Page Builder CK should treat CVE-2026-56290 as an exposed web-application risk, not merely a plugin maintenance issue.
  • Langflow deployments should be inventoried as production-relevant infrastructure if they contain API keys, internal data connectors, shared flows, or automation privileges.
  • Patching should be paired with compromise assessment, because KEV status means exploitation has already been observed before many defenders act.
  • Security teams should use CISA’s BOD 26-04 logic even outside government: public exposure, known exploitation, automation potential, and attacker control are better triage signals than severity scores alone.
The lesson of this CISA update is not that Joomla is uniquely doomed or that AI tooling is uniquely reckless. It is that attackers keep winning where organizations misclassify convenience software as low-risk infrastructure. The next KEV batch will almost certainly contain a different set of products, but the same operational divide will remain: defenders who know what they expose and can move quickly, and defenders who discover their inventory only after someone else has already used it.

References​

  1. Primary source: CISA
    Published: 2026-07-07T12:00:00+00:00
  2. Related coverage: tlctc.net
  3. Related coverage: nucleussec.com
  4. Related coverage: minimus.io
  5. Related coverage: insideprivacy.com
  6. Related coverage: vulncheck.com
  1. Related coverage: crowdsec.net
  2. Related coverage: executivegov.com
  3. Related coverage: cybrsecmedia.com
  4. Related coverage: techradar.com
  5. Related coverage: labs.cloudsecurityalliance.org
 

Back
Top