Skip to main content

YETI Platform CVE-2026-63489

| EUVDEUVD-2026-116263 HIGH
Improper Neutralization of Special Elements in Data Query Logic (CWE-943)
2026-11-03 GitHub_M
7.6
CVSS 3.1 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Authenticate as low-privileged YETI user
  2. Exploit
    Craft malicious sorting or filter_aliases value
  3. Execution
    POST to a /api/v2/*/search endpoint
  4. Impact
    Injected AQL parsed and evaluated against internal collections

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Query language parameterization
Exploitation Conditions

Requires a valid but low-privileged (non-admin) authenticated YETI account; no administrator role is needed. The attacker must be able to call one of the search endpoints (POST /api/v2/observables/search, /entities/search, /indicators/search, /dfiq/search, /search/, or /graph/search) and supply a sorting field or a filter_aliases attribute path, which are interpolated unvalidated into AQL identifier/expression positions in the filter() and neighbors() construction. No special non-default configuration is needed - default search functionality is exploitable. The primary limiting factor is the authentication requirement (PR:L): anonymous internet users cannot exploit it, so realistic risk centers on insiders or compromised analyst credentials; impact is bounded to read/search contexts, so arbitrary database writes were not established.

Impact

This is a credible, verified authenticated injection flaw rather than an inflated high-CVSS score. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N) describes a network-reachable, low-complexity attack needing only a low-privileged authenticated account and no user interaction, which is consistent with the GHSA advisory's live-lab confirmation of an AQL syntax-error oracle, a successful cross-collection subquery against the internal users collection, and failure against a bogus collection - proving attacker-controlled AQL is actually parsed and evaluated. The vuln.today decision label is 'this_week' (priority but not act_now/emergency), and there is no CISA KEV listing and no EPSS score provided, so there is no evidence of widespread active exploitation; the realistic risk is targeted abuse by an already-authenticated insider or a compromised analyst account. Signals are largely consistent: the only tension is that the C:H rating is somewhat generous given the verified impact is cross-collection expression evaluation and error-oracle enumeration rather than a demonstrated bulk data dump, and the advisory itself notes the integrity/availability components could be scored more conservatively. EPSS is absent and KEV is NO, so priority rests on the reproducible PoC and the low privilege barrier, not on observed in-the-wild use.

Exploit ScenarioDerived

A user with any ordinary (non-admin) YETI account - or an attacker who has phished/compromised such an account - sends a crafted POST to a search endpoint with a malicious sorting or filter_aliases value that closes the intended identifier and appends attacker AQL. Because low complexity and no user interaction are required, they can repeatedly probe the database as an error/boolean oracle to enumerate collections and evaluate subqueries against internal collections such as users, or issue deliberately expensive AQL to burden ArangoDB. The GHSA advisory includes detailed, lab-verified curl PoCs for all three injection patterns.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
No patch listed yet

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Nov 03, 2026

Authenticated AQL injection in YETI 2.5.0 and earlier lets any low-privileged analyst account push attacker-controlled subexpressions into ArangoDB queries through the sorting and filter_aliases fields accepted by the search API, giving that user a cross-collection read primitive and a parser-level error oracle. Exploitation requires only a valid non-admin account and default search functionality - no administrator role or special configuration - so realistic risk centers on insiders or compromised analyst credentials, and impact is bounded to read/search contexts (arbitrary database writes were not established). The GitHub advisory documents working request payloads that were verified only against the reporter's authorized local lab instance; it is not confirmed as active in the wild, but the public PoC reference lowers the effort needed to reproduce it and a fix is available upstream.

RemediationAI

Apply the upstream fix from PR #1277 / commit 89d8b61, published under the 2.5.1 release tag (https://github.com/yeti-platform/yeti/releases/tag/2.5.1); the patch validates every sort field and filter alias against ^[A-Za-z0-9_.]+$ in core/database_arango.py and raises ValueError on anything outside that pattern. If the guard is backported rather than taken from 2.5.1, replicate it in both the filter() and neighbors() sort construction and in the filter_aliases path, keeping the existing tags exemption, and add the advisory's regression payloads (value); RETURN COLLECTIONS() //, value, LENGTH(FOR u IN users RETURN 1), value, LENGTH(FOR u IN nonexistent_coll_xyz RETURN 1), value, @arg0_value, true) OR (1==1) to the test suite per https://github.com/yeti-platform/yeti/security/advisories/GHSA-vw33-fwfx-6m9p. Expect a compatibility side effect: client integrations that send sort or alias names containing characters outside alphanumerics, underscore or dot will now be rejected, and the advisory recommends surfacing that as a controlled HTTP 400 instead of letting the database parser return 500. Where the update cannot be applied immediately, the practical exposure reduction is to constrain which accounts can reach the six search endpoints, since the flaw lives in default search functionality and any authenticated non-admin analyst can reach it - accepting that this limits normal analyst workflows rather than removing the injection.

Affected VersionsENISA

yeti ≤ 2.5.0

Affected Packages

euvd yeti no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

YETI builds ArangoDB AQL query text in core/database_arango.py, specifically in the filter() and neighbors() helpers, and interpolates request-supplied strings into identifier and expression positions such as o.{field} for sort clauses and o.{alias} inside ANALYZER(LIKE(...), 'norm') for filter aliases. Because AQL bind variables can safely bind values but cannot bind attribute names or collection names, any identifier-like input must be allowlisted; CWE-943 (Improper Neutralization of Special Elements in Data Query Logic) captures the root cause, and the advisory also cross-references CWE-89 as the SQL-analogue. The result is query injection into a NoSQL/graph query language rather than SQL: an attacker can close the intended expression and append their own AQL, which ArangoDB then parses and evaluates. Live lab testing demonstrated a syntax-error oracle (HTTP 500), successful evaluation of an injected subquery LENGTH(FOR u IN users RETURN 1) returning HTTP 200, and a 500 when the same shape referenced a nonexistent collection - evidence that the injected text reaches the AQL parser. The upstream fix in PR #1277 (commit 89d8b61) adds a compiled regex _SAFE_FIELD_RE = ^[a-zA-Z0-9_.]+$ and a _validate_safe_field_name() guard applied to sort fields in filter()/neighbors() and to filter aliases other than tags.

Know when Yeti gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (GitHub_M) PRIMARY 7.6 HIGH
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L
vuln.today AI 7.6 HIGH

Network API reachable (AV:N), simple crafted JSON (AC:L), needs a low-privileged account (PR:L), no interaction; confirmed cross-collection read-expression evaluation (C:H), search-logic tampering (I:L), and expensive-query DoS (A:L).

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
Low
Availability
Low

DescriptionCVE.org

Yeti bridges the gap between CTI and DFIR practitioners by providing a Forensics Intelligence platform and pipeline. In version 2.5.0 and earlier, YETI directly interpolates user-controlled sorting fields and filter_aliases attribute paths into ArangoDB AQL identifier and expression positions in core/database_arango.py. A low-privileged authenticated user can send crafted values to POST /api/v2/observables/search, POST /api/v2/entities/search, POST /api/v2/indicators/search, POST /api/v2/dfiq/search, POST /api/v2/search/, or POST /api/v2/graph/search, causing attacker-controlled AQL subexpressions to be parsed and evaluated. This can provide an error oracle, evaluate expressions against internal collections such as users, alter intended search logic, enumerate schema information, and consume excessive database resources. The verified injection points are read and search contexts, so arbitrary database writes are not established. No fixed version is available as of this review.

Technical POC Analysis

CWE-943 (Improper Neutralization of Special Elements in Data Query Logic), also mapped to CWE-89 by the reporter, in core/databasearango.py of YETI (yeti-platform/yeti).

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

CVE-2026-63489 is an authenticated injection flaw in YETI 2.5.0 and earlier that lets any low-privileged analyst account read data beyond their intended scope, affecting the platform's search functionality. While exploitation requires a valid analyst account and is most likely to originate from insiders or compromised credentials, the cross-collection read capability and parser error oracle could expose sensitive threat intelligence data. Leadership should prioritize remediation because the vulnerability is easily reproducible with a public proof-of-concept and impacts a core data access control boundary.

Business Impact: Medium
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

Prevalence
Low
niche CTI/DFIR threat-intelligence platform, no mass enterprise footprint
Data Quality
3 sources
Confidence: Low

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS N/A
Patch available No
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
No
Human Impact
Medium

Priority Score

38
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +38
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Code Injection CRITICAL

Code injection occurs when an application accepts user input and passes it directly into a language interpreter or evaluator without proper sanitization.

NoSQL injection exploits databases that don't use traditional SQL syntax-like MongoDB, CouchDB, or Redis-by manipulating queries through unsanitized user input.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy