AIL Framework CVE-2026-100177

Requires an authenticated AIL Framework user who holds the ability to create crawler tasks (one-shot or scheduled) via the api_add_crawler_task API. The attacker must additionally know or obtain a valid cookiejar UUID belonging to another organization, since cookiejar UUIDs are random and not enumerable - this is the primary practical limiter beyond authentication. No user interaction from a victim is needed. Exploitation is possible against default configurations of affected AIL Framework versions (before the fix in commit 3773ca36) specifically in multi-organization/multi-tenant deployments where more than one organization stores cookiejars; single-org installations have no cross-tenant boundary to violate.

This is a genuine but moderate cross-tenant authorization flaw (CWE-639 IDOR), not a critical drive-by. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, VC:N/VI:N/VA:N, SC:H) scores 6.3 and correctly captures the essence: no impact to the AIL system itself, but a HIGH confidentiality impact to a subsequent system - the victim organization's web sessions, since the leaked cookiejar contains their session tokens/auth credentials. Authentication is confirmed required (PR:L) - an attacker must already be a valid AIL user with crawler-task-creation rights. The description's own limiting factor undercuts the AC:L rating: the attacker 'must know or guess a valid cookiejar UUID belonging to another organization.' Cookiejar UUIDs are effectively unguessable random identifiers, so successful exploitation realistically depends on the attacker already knowing or otherwise obtaining a target UUID - a meaningful barrier that argues for AC:H rather than AC:L. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Net: a real multi-tenant isolation bug worth patching in shared AIL deployments, but the authenticated precondition plus the UUID-knowledge requirement keep real-world risk in the medium band rather than urgent.

An authenticated AIL user belonging to organization A creates a one-shot or scheduled crawler task and supplies a cookiejar UUID that actually belongs to organization B. Because the API only checked existence (and, for level-0 jars, owner match, with no check at all for non-zero levels), the crawler performs the web crawl using organization B's stored cookies, sending B's session tokens and credentials to the crawled target and exposing them to the attacker. No public exploit code was provided, so this is a manual, insider-style abuse requiring knowledge of a victim cookiejar UUID.