**Perspective 1:** The `claude` subprocess is invoked with the `--dangerously-skip-permissions` flag, which disables all permission checks. This means the LLM agent can execute arbitrary commands, read/write files, and access network resources without restriction. Combined with the API key in the environment, a compromised or malicious prompt could lead to data exfiltration or system compromise. This is a supply chain risk because the agent's behavior is not constrained. **Perspective 2:** The eval script passes the --dangerously-skip-permissions flag to the claude CLI, which disables all permission checks for file system and command execution. While this is a benchmark script, if the prompts or project directories contain untrusted content, the LLM could be tricked into executing arbitrary commands or reading sensitive files without any guardrails. This is an insecure default for the evaluation environment.

The WhatsApp bridge calls fetchLatestBaileysVersion() at runtime to determine which Baileys library version to use. This means the actual library version used is not pinned or verified — it depends on the latest version available from the registry at connect time. A compromised or malicious Baileys release could be pulled and executed without any integrity check, and the behavior of the bridge is non-deterministic across deployments. This is a dependency confusion / supply chain risk.

The code at line 1433 is truncated (`state=stat`), which is a syntax error / NameError. This will crash the entire message router loop, stopping the game. This is a critical correctness bug.

The build script defaults to the mutable `latest` tag for the container image. This makes it impossible to verify which exact code is running in production, and an attacker who can push a malicious image to the registry could overwrite the `latest` tag, causing the deployment to run untrusted code. The fix is to require an immutable, unique tag (e.g., git SHA) and avoid `latest`.

Remote skill files are downloaded from the OpenViking server and written to the sandbox without verifying the file's SHA-256 checksum against the manifest. The manifest includes a sha256 field for each file, but the download path does not validate that the downloaded bytes match the expected checksum. An attacker who can tamper with the server response (e.g., MITM, compromised server) could inject malicious skill content that gets executed in the sandbox.

The `_url_to_base64` method fetches any URL supplied by the user/agent without validation. An attacker controlling the `base_image` or `mask` parameter (e.g., via a prompt injection or a malicious agent) can point it at internal services (e.g., http://169.254.169.254/latest/meta-data/, http://localhost:xxxx) and exfiltrate their content by having the response base64-encoded and returned to the caller. The URL is passed directly to `httpx.AsyncClient.get(url)` with no allowlist, scheme, or host validation.

The `dest` parameter (user/LLM-controlled) and the file URI-derived local path are concatenated without sanitization and passed to `sandbox.write_file(relative, text)`. A malicious `dest` value such as `../../etc` or a viking URI containing `../` segments can escape the intended sandbox workspace directory and overwrite arbitrary files the sandbox user can write. Trace: tool parameter `dest`/`uri` -> `local_path_for_viking_uri` -> `relative` -> `sandbox.write_file`.

**Perspective 1:** The `web_fetch` tool validates that the URL uses http/https and has a netloc, but does not restrict the hostname or IP. An agent (or a user controlling the agent's input) can fetch `http://169.254.169.254/`, `http://localhost:1933/`, or other internal endpoints, enabling SSRF to internal services, cloud metadata, or the OpenViking server itself. The URL enters from the tool invocation, which is driven by LLM/user input. **Perspective 2:** The `web_fetch` tool validates only that the URL uses http/https and has a netloc, but does not block private/internal IP addresses (e.g., 127.0.0.1, 169.254.169.254, 10.x.x.x). An attacker who can control the `url` parameter (e.g., via a prompt injection or a malicious agent) can make the bot fetch internal metadata endpoints or internal services, leaking sensitive data. This is a direct input-to-sink path: `url` -> `client.get`. **Perspective 3:** The web_fetch tool uses `httpx.AsyncClient` without explicitly configuring TLS certificate verification. While httpx verifies certificates by default, the code does not set `verify=True` explicitly, and there's no handling for certificate errors. If the default behavior is changed or if a custom client is passed, this could allow man-in-the-middle attacks.

In _parse_data_uri, when a data_uri does not start with data:, http://, https://, or send://, the code treats it as a local file path and reads it with path_obj.read_bytes(). An attacker who can send a message to the bot can supply an absolute path such as /etc/passwd or /home/user/.ssh/id_rsa and the bot will read and return the file contents. The input originates from the chat message boundary and reaches a file-read sink with no path validation or restriction to a safe directory.

**Perspective 1:** The _parse_data_uri method, when given a non-URL, non-data URI string, treats it as a local file path and reads its bytes. An attacker who can control the 'media' list of an inbound message (e.g., via a crafted email or chat message) can read arbitrary files from the bot's filesystem. The input is the media URL/path from an inbound message, which is attacker-controlled. **Perspective 2:** In `_parse_data_uri`, when a data URI does not match `data:`, `http://`, `https://`, or `send://`, the code falls through to treat the input as a local file path and calls `path_obj.read_bytes()` on it. The `data_uri` originates from an untrusted chat message (e.g. a user sending a message with a media attachment or a URL-like string). An attacker who can send a message to the bot can supply an absolute path such as `/etc/passwd` or `../../etc/shadow` and the bot will read and return the file contents, leaking arbitrary local files. There is no validation that the path is within an allowed directory, no allowlist of extensions, and no size limit on the read. **Perspective 3:** When a data_uri is not a data:, http(s):, or send:// URI, the code treats it as a local file path and calls path_obj.read_bytes() directly. If the file does not exist or is unreadable, a raw OSError/FileNotFoundError propagates to the caller with no context about which URI was being parsed or that it was a local-path fallback. This makes debugging failures difficult and can crash the message handling pipeline with an unhelpful error.

HTTP request with user-controlled URL in bot/vikingbot/channels/discord.py at line 228 enables SSRF attacks.

The proxy route forwards all requests to the OpenViking API. The gateway token is verified, but the caller's OpenViking identity is not resolved or verified before forwarding. An attacker who has the gateway token (or can reach the gateway on localhost) can make arbitrary API calls to the OpenViking server, potentially accessing or modifying data they should not have access to.

In trusted auth mode, the gateway accepts X-OpenViking-Account and X-OpenViking-User headers from the client and uses them to build an OpenViking connection. While it does check the upstream health response for matching account/user, the headers themselves are client-controlled. An attacker who can reach the gateway can supply arbitrary account/user IDs, and if the upstream health check returns matching values (which it may for a valid API key), the attacker can impersonate any user. The API key is also optional in this mode if a configured key exists, but the account/user headers are not validated against the configured identity.

**Perspective 1:** The `WhatsAppChannel.start` method connects to the bridge URL using `websockets.connect` without explicitly verifying the TLS certificate or enforcing a secure `wss://` scheme. The `bridge_url` comes from the channel config, which may be attacker-influenced. The bridge auth token is sent over this connection without any integrity or confidentiality guarantee if the connection is not properly secured. An attacker who can intercept the connection (e.g., via a misconfigured proxy or DNS poisoning) can steal the token and impersonate the bot. **Perspective 2:** The `bridge_url` from config is passed directly to `websockets.connect`. If the config is malicious or misconfigured (e.g., `file://` or a non-websocket scheme), the connection will fail, but the error may not be clear. More importantly, if the bridge_url is attacker-controlled, it could be used to connect to an unintended WebSocket endpoint, potentially leaking data or causing unexpected behavior.

**Perspective 1:** `load_config` reads the ov.conf JSON and runs `os.path.expandvars` over the raw text before parsing. This expands `${VAR}` and `$VAR` from the process environment into the config. If an attacker can influence the config file content (e.g., a shared or writable config path, or a config imported from an untrusted source), they can inject `${OPENVIKING_ROOT_API_KEY}` or `${HOME}` style references and cause the bot to embed environment secrets (API keys, tokens) into the parsed config, which may then be logged, sent to the LLM provider, or persisted. Even without file write access, a malicious config supplied via `OPENVIKING_CONFIG_FILE` can read arbitrary environment variables into the bot's runtime config. **Perspective 2:** The config loader expands $VAR and ${VAR} in the JSON config text. If a variable is unset, it is left unchanged, but if a secret is embedded via env var and later logged or dumped, the expanded value could be exposed. More importantly, this allows the config file to reference environment variables, which is a legitimate pattern, but the expanded raw text is parsed and could be included in error messages if JSON parsing fails, potentially leaking secret values.

The LangfuseConfig model defines a hardcoded default secret_key value. If a deployment enables Langfuse without overriding this value, all instances share the same secret, allowing an attacker to forge or read observability data. This is a default credential that must be changed.

The sandbox backend defaults to DIRECT, which executes commands directly on the host without isolation. Combined with the default restrict_to_workspace=False, this allows the agent to run arbitrary commands and access the entire filesystem. This is an insecure default for a production agent.

**Perspective 1:** The Gradio config editor exposes all configuration fields, including API keys, provider credentials, and sandbox settings, as editable form fields. Since the console is unauthenticated and binds to 0.0.0.0, any network attacker can read and modify the full bot configuration, including injecting malicious provider endpoints or exfiltrating secrets. **Perspective 2:** The Config tab's `save_config_fn` takes values from Gradio components (which are populated from the current config and editable by any user who can reach the console) and constructs a new `Config` object, then persists it via `save_config`. Since the console has no authentication and binds to 0.0.0.0, an attacker can modify any config field, including provider API keys, endpoints, and sandbox settings. This can lead to credential theft (by pointing endpoints to attacker-controlled servers), arbitrary command execution (via sandbox config), or denial of service. Trace: network attacker -> unauthenticated console -> Config tab -> `save_config_fn` -> `Config(**config_dict)` -> `save_config` -> config file overwritten.

**Perspective 1:** The `load_session` function reads session JSONL files from disk and injects the `content` field directly into an HTML string without any escaping. The resulting HTML is rendered in a `gr.HTML` component. Session content originates from user messages (attacker-controlled) and is persisted to disk. When an admin opens the Sessions tab and selects a session, any `<script>` or event-handler payload stored in a message is executed in the admin's browser context. Trace: user message -> session JSONL file -> `load_session` -> `gr.HTML` -> browser. This is a stored XSS with no sanitization at the sink. **Perspective 2:** Session message content is inserted directly into HTML strings without escaping. If a session contains attacker-controlled content (e.g., from a chat message), it will be rendered as HTML in the console, enabling stored XSS. Combined with the unauthenticated console, this could allow an attacker to execute arbitrary JavaScript in the context of any user viewing the console.

In the exception handler of `load_session`, when a line fails to parse as JSON, the raw line is inserted directly into an HTML string and rendered in `gr.HTML`. A malformed or attacker-crafted line in a session file containing HTML/script is executed in the admin's browser. Trace: session file line -> `load_session` exception path -> `gr.HTML` -> browser. No escaping is applied.

**Perspective 1:** The Vikingbot console server (Gradio app) binds to 0.0.0.0, exposing the full configuration editor, session viewer, and workspace file explorer to any network client. The console has no authentication, and the config editor allows modifying all bot settings including API keys and provider credentials. The workspace tab also allows reading any file under the workspace path. This is a direct unauthorized access path to sensitive data and configuration. **Perspective 2:** The Vikingbot console server (Gradio app) binds to `0.0.0.0` on port 18791 with no authentication. The console exposes the Config tab (which can read and write the bot's configuration, including API keys and provider credentials), the Sessions tab (which displays full conversation content), and the Workspace tab (which reads arbitrary files within the workspace). Any network-reachable attacker can access the console, modify configuration, and exfiltrate sensitive data. Trace: network attacker -> unauthenticated Gradio console -> config read/write, session content disclosure, file read. **Perspective 3:** The console server runs over plaintext HTTP with no TLS. Any credentials, session data, or configuration viewed or edited through the console can be intercepted by network observers. The health endpoint and OpenAPI router are also served over plaintext. **Perspective 4:** The console server runs with log_level="warning", suppressing access logs. This reduces visibility into who is accessing the unauthenticated console, hindering incident detection and forensics. **Perspective 5:** The Gradio/FastAPI console app does not set security headers such as Content-Security-Policy, X-Frame-Options, or X-Content-Type-Options. This increases the risk of clickjacking and other browser-based attacks against console users. **Perspective 6:** The console endpoints, including the config editor and session viewer, have no rate limiting. An attacker can brute-force or abuse the unauthenticated console without restriction.

The FUSE mount is created with allow_other=True, which makes the mounted filesystem readable and writable by every user on the host, not just the mounting user. The mount proxies to the OpenViking data directory (.original_files), so any local user can read, create, modify, or delete files in the OpenViking data store. This is a direct privilege escalation / data exposure path for multi-user hosts. The mount also runs with default_permissions=True but no allow_root, and the underlying OpenVikingMount.add_resource is invoked on every file write, so any local user can inject resources into the OpenViking index.

**Perspective 1:** The `_prepare_image` method treats any string that does not start with 'http://' or 'https://' as a local filesystem path and reads it without validation. An attacker who can control the `images` argument (e.g., via a chat endpoint that accepts image paths) can read arbitrary files from the server's filesystem, including sensitive configuration files, API keys, or user data. The path is not resolved against a safe base directory, and no check is made to prevent path traversal (e.g., '../../etc/passwd'). This is a direct arbitrary file read vulnerability. **Perspective 2:** `_prepare_image` reads the entire image file into memory with no size limit. A user-supplied image path (e.g., via an API that accepts a file path) pointing to a multi-GB file will exhaust memory. This is reachable from any vision completion call that accepts a Path or local file string. **Perspective 3:** In _prepare_image, when the image is a local file path, the file is opened and read with no try/except. If the file is missing, unreadable, or a permission error occurs, the raw OSError propagates up through the VLM call stack without being wrapped or categorized. The caller receives a generic OSError with no indication that it was an image-loading failure, making it hard to distinguish from a model API error. There is no retry for transient I/O errors.

In `_materialize_drive_folder`, downloaded images are written via `image_path = markdown_path.parent / rel_path`, where `rel_path` comes from `_resolve_image_refs` and ultimately from Feishu document image tokens/URLs. If `rel_path` contains `../` or absolute path components, the write escapes the intended directory. The same pattern exists in `access()` at line 474. Input trace: Feishu document image reference -> `_resolve_image_refs` -> `rel_path` -> `Path` join -> `write_bytes`.

**Perspective 1:** The `branch` parameter originates from user-supplied kwargs (e.g., `branch` or `ref` in the access call). It is URL-encoded with `quote(..., safe="/")` but not validated against path traversal or control characters. A branch value like `../../etc/passwd` or `..%2F..` could be used to construct a URL that downloads an unintended archive or triggers SSRF-like behavior against GitHub. The encoded value is directly interpolated into `zip_url = f"https://github.com/{owner}/{repo_slug}/archive/{ref}.zip"`, and the response is written to disk and extracted. This allows an attacker to control the downloaded content and potentially write arbitrary files into the extraction directory. **Perspective 2:** The `branch` parameter is URL-encoded with `quote(..., safe="/")`, but control characters (e.g., `\n`, `\r`) are not explicitly rejected. While URL encoding neutralizes most injection, the encoded value is still used in a URL that is fetched and extracted. Control characters could potentially cause issues in the HTTP request or in the extraction path.

File operation with user-controlled path in openviking/parse/accessors/git_accessor.py at line 478. Attacker can read arbitrary files via ../ sequences.

**Perspective 1:** The `branch` parameter (user-supplied via kwargs) is directly interpolated into the GitLab archive URL without any encoding or validation. A branch value containing `/`, `..`, or URL metacharacters can alter the URL path, potentially causing the download of an unintended archive or enabling path traversal in the resulting extraction. The response is written to disk and extracted, so an attacker controlling the branch can influence what files are written into the local filesystem. **Perspective 2:** The GitLab archive URL is built from a branch name or 'HEAD' (mutable reference). The downloaded content is not pinned to a specific commit, so the code being ingested can change between runs. This breaks build reproducibility and provenance tracking, and the downloaded archive is not verified against a known-good hash. **Perspective 3:** The `branch` parameter is directly interpolated into the GitLab archive URL without any encoding or validation. Control characters (e.g., `\n`, `\r`) are not rejected. While the URL is fetched via `urllib`, control characters could potentially cause issues in the HTTP request or in the extraction path.

**Perspective 1:** The HTTPAccessor and URLTypeDetector accept arbitrary URLs from user input (e.g., a user-provided URL to ingest) and issue HEAD/GET requests to them. The request_validator is only applied when event_hooks are built, but the detect() method's HEAD request at line 210 and the download GET at line 581 can be called with request_validator=None, allowing requests to internal network addresses (e.g., 169.254.169.254, localhost, internal services). This enables SSRF attacks where an attacker can probe or access internal resources. The URL is attacker-controlled via the source parameter, and there is no host allowlist or scheme restriction beyond http/https. **Perspective 2:** The HTTPAccessor accepts arbitrary URLs from user input (e.g., via the 'viking add' command or API) and performs HEAD/GET requests without validating the target host against an allowlist. An attacker can supply a URL pointing to internal services (e.g., http://169.254.169.254/ or http://localhost:8080/admin) to probe or interact with internal network resources. The request_validator is optional and not enforced here. Trace: user-supplied URL -> _download_url -> _url_detector.detect -> client.head(url). **Perspective 3:** The HTTP accessor uses follow_redirects=True for both HEAD and GET requests. If a user-supplied URL redirects to an internal address (e.g., http://169.254.169.254/ or http://localhost:PORT/), the client will follow it. The request_validator may not be applied to redirected requests, and the network guard hooks only validate the initial request. This can enable SSRF to internal services.

**Perspective 1:** The _download_url method issues a GET request to an attacker-controlled URL. The request_validator is optional and only applied if provided; when absent, the request proceeds without any SSRF protection. An attacker can supply a URL pointing to internal services (e.g., http://169.254.169.254/latest/meta-data/, http://localhost:port/) and the server will fetch and return the content, enabling SSRF and potential data exfiltration. The URL is derived from user input (source parameter) and is not restricted to public hosts. **Perspective 2:** The HTTPAccessor performs a GET request to a user-supplied URL without validating the target host. This enables SSRF attacks to access internal services, cloud metadata endpoints, or other restricted resources. The request_validator is optional and not enforced here. Trace: user-supplied URL -> _download_url -> client.get(url). **Perspective 3:** The GET request in _download_url uses follow_redirects=True. A user-supplied URL that redirects to an internal service (e.g., cloud metadata endpoint) will be followed, and the downloaded content is written to disk and potentially parsed. The request_validator is only applied to the initial request, not to redirect targets.

HTTP request with user-controlled URL in openviking/parse/accessors/web_feed_accessor.py at line 599 enables SSRF attacks.

The WebFeedAccessor fetches URLs extracted from a user-supplied sitemap or feed. `_filter_entries` only checks `same_host_only` (default True) against the feed's netloc, but `_apply_robots` and `_mirror` fetch each `entry.url` without validating the resolved host against an allowlist or the network guard. A malicious sitemap can list internal URLs (e.g. http://169.254.169.254/...) that the accessor will fetch, enabling SSRF. The `request_validator` is only applied to the initial feed fetch via event hooks, not to per-page fetches. Trace: user-supplied feed URL -> `_collect` -> `_mirror` -> `client.get(entry.url)`.

**Perspective 1:** The video parser reads the entire video file into memory via `file_path.read_bytes()` with no size limit. An attacker can upload a multi-GB video file, causing the server to exhaust memory and crash (OOM). The file is also written to viking_fs as `video_bytes`, doubling memory usage. This is a direct DoS vector via the upload/parse path. **Perspective 2:** The VideoParser reads the entire video file into memory with file_path.read_bytes() before any size limit is applied. An attacker who can upload or reference a large video file can cause the server to exhaust memory. The file size is never validated against a configured limit, and the magic-byte check happens only after the full file is loaded. Trace: untrusted video file path -> read_bytes() -> memory exhaustion. **Perspective 3:** The VideoParser reads the entire video file into memory without verifying its integrity (e.g., hash check against a known value). The file content is trusted as-is and written to storage. An attacker who can tamper with the source file could inject malicious content that is then persisted and served to users. **Perspective 4:** In `VideoParser.parse`, `file_path.read_bytes()` can raise an `OSError` (e.g., permission denied, I/O error) that propagates without being wrapped with context about the resource being parsed. This loses error categorization and makes debugging harder.

**Perspective 1:** The UnderstandingAPI downloads a ZIP file from a URL returned by the parser API (zip_url). The entire response is buffered into memory via rsp.content with no size limit. An attacker who controls the parser API response (or a malicious parser API server) can return a multi-GB ZIP, exhausting server memory. This is reachable from add_resource with a URL that routes to the UnderstandingAPI. The zip_url is attacker-influenced (it comes from the parser API response). **Perspective 2:** The `_download_zip` method fetches the `zip_url` returned by the Understanding API and writes the entire response body (`rsp.content`) to a temp file with no size limit. The `zip_url` originates from the remote Understanding API response, which is attacker-influenced when a user submits a URL for parsing. A malicious or compromised Understanding API (or a redirect target) can return an arbitrarily large body, exhausting local disk. This is a memory/disk exhaustion vector with no validation on response size. **Perspective 3:** The `_download_zip` method makes a single HTTP GET request with no retry logic. Transient network errors or 5xx responses will cause the entire parse operation to fail. The zip_url is typically a presigned URL that may be valid for a limited time, so a quick retry would likely succeed.

safe_extract_zip extracts the ZIP to a temp dir, but there is no limit on total extracted size or number of files. A malicious ZIP (zip bomb) can expand to fill the disk. Additionally, each file is read entirely into memory via child.read_bytes() before writing to VikingFS, so a single large file inside the ZIP can exhaust memory. The resource_name is derived from the ZIP content (archive_root) or user-supplied source_name, and is interpolated into the URI without sanitization, allowing path traversal via '..' in resource_name (e.g. if source_name is '../../etc/passwd').

resource_name is derived from display_name (user-supplied source_name) or inferred from the URL path or ZIP archive root. It is interpolated directly into the VikingFS URI without sanitization. A user can pass source_name='../../etc' or a URL whose path contains '..', causing the mkdir/write to escape the intended temp directory and write to arbitrary VikingFS paths. This is reachable from add_resource with a URL and source_name.

**Perspective 1:** The new API key format is base64url(account_id).base64url(user_id).base64url(secret). The account_id and user_id segments are plaintext base64, so anyone who sees a key can decode the identity. More critically, the identity segments are not cryptographically bound to the secret. An attacker who obtains a valid key for one user can modify the account_id/user_id segments (re-encode a different identity) and, if the secret segment still matches a stored key for that identity, could impersonate another user. The resolve() path decodes the identity directly from the key and only verifies the secret against the stored key for the decoded identity, so a key with a valid secret but tampered identity would fail unless the secret also matches the target user. However, the lack of an HMAC or signature over the identity segments means the key format provides no integrity protection against substitution if a secret is reused or leaked across users. **Perspective 2:** In resolve(), for a new-format key, account_id and user_id are decoded directly from the client-supplied key string (parse_api_key), then the code checks whether that account/user exists and whether the secret matches. The identity is not independently derived from a server-side lookup keyed by a random token; it is entirely attacker-influenced. While the secret comparison provides some protection, this design means any leaked or brute-forced secret for one user can be replayed with a different account_id/user_id if the same secret value is reused across users (e.g., when a deterministic seed is used). This weakens the separation between identity and credential. **Perspective 3:** In resolve(), for a new-format key, the code decodes account_id and user_id from the key itself, looks up the stored user, and then compares the full api_key string against stored_key_or_hash using hmac.compare_digest. When api_key_hashing_enabled is False (the default per the constructor docstring), stored_key_or_hash is the plaintext full key, so this is correct. However, when hashing is enabled, the code checks `user_info.get("key_prefix", "").startswith("$argon2") or stored_key_or_hash.startswith("$argon2")` and then calls _verify_api_key(api_key, stored_key_or_hash). If an attacker supplies a key whose decoded account_id/user_id match a real user but whose secret segment is empty or malformed, the Argon2 verify will fail and fall through to legacy — but if the stored key is plaintext and the attacker can guess the secret segment (e.g. because it is short or derived from a weak seed), the compare succeeds. The real risk is that the new format leaks the identity in the key itself, so any leak of a key fragment (e.g. in logs that redact only the secret) reveals the account/user, and the secret is only 256 bits of hex — acceptable, but the identity disclosure combined with weak-seed derivation (see above) makes forgery practical.

**Perspective 1:** When api_key_hashing_enabled is False (the default), the stored key is the full plaintext API key. resolve() compares the client-supplied key against the stored plaintext. If an attacker obtains the users JSON (e.g., via file read, backup, or path traversal), they can directly impersonate any user. Combined with the default of hashing disabled, this is a direct credential-theft path. The code does use hmac.compare_digest, which is timing-safe, but the underlying storage is plaintext. **Perspective 2:** When api_key_hashing_enabled is False (the default), the full API key is stored in plaintext in the users JSON file (stored_key = key). This means the entire credential is persisted at rest without any hashing, protected only by file-level AES encryption. If the storage layer is compromised or the file is exfiltrated, all API keys are directly readable, allowing full account takeover. The docstring even states 'Default: false - rely on file-level AES encryption for protection', which is a defense-in-depth gap. API keys should be stored as salted hashes (e.g., Argon2id) by default.

**Perspective 1:** create_account() accepts a caller-supplied seed and passes it to generate_api_key(), producing a deterministic admin API key. An attacker who can invoke create_account with a chosen seed can predict the admin key for a new account, gaining full admin access to that account. This is a self-service privilege escalation / authentication bypass. Input: create_account request with seed -> generate_api_key() -> predictable admin key. **Perspective 2:** create_account(account_id, admin_user_id, seed) passes the caller's `seed` directly to generate_api_key. Any caller who can invoke this method (e.g. an unauthenticated account-creation endpoint, or a lower-privilege user who can create sub-accounts) can choose a seed and compute the exact admin API key offline for any account_id/user_id. Combined with the new format's plaintext identity segments, this lets an attacker mint a valid admin key for an account they do not own, achieving full privilege escalation. The seed parameter is attacker-controlled input reaching a cryptographic key-derivation sink. **Perspective 3:** create_account passes the optional seed directly to generate_api_key. If a caller (e.g., an admin provisioning script or an API consumer) passes a low-entropy or predictable seed, the admin key is predictable, allowing an attacker to forge a root-level admin credential. The API does not enforce entropy requirements on the seed. **Perspective 4:** create_account() accepts a 'seed' parameter that is passed directly to generate_api_key(). If this seed is attacker-controlled (e.g., from an API request or CLI argument), the attacker can choose a known seed and predict the resulting admin API key, gaining full administrative access to the newly created account. Even if the seed is only from trusted internal callers, the ability to supply a deterministic seed undermines the randomness guarantee of the credential. The seed parameter should be removed from the public API surface or restricted to a securely managed server-side secret.

delete_account delegates to self._legacy.delete_account(account_id) with no verification that the caller is root or an admin of the target account. The legacy implementation (already flagged) has no authorization gate, so any code path that reaches NewAPIKeyManager.delete_account — e.g. an admin API endpoint that does not itself verify the caller's role — lets an attacker delete any account, destroying all its users and keys. The new manager adds no defense, so the vulnerability is inherited and reachable through the new-format key path.

**Perspective 1:** register_user() accepts a caller-supplied seed and derives the user's API key deterministically. An attacker who can call register_user with a chosen seed can predict the resulting user key, allowing them to authenticate as that user without knowing a stored secret. Combined with the ability to choose user_id, this enables impersonation of any user in an account. Input: register_user request with seed and user_id -> generate_api_key() -> predictable key. **Perspective 2:** register_user(account_id, user_id, role, seed) passes the caller's `seed` to generate_api_key. If the register_user endpoint is reachable by an authenticated user (or unauthenticated in some deployments), the caller can choose a seed and compute the exact API key for any user_id in an account they can name, then use that key to impersonate the user. The new format base64-encodes account_id and user_id, so the attacker only needs to guess/choose the seed to forge the secret. This is a direct credential-forgery / privilege-escalation path. **Perspective 3:** register_user passes the optional seed to generate_api_key. A predictable seed yields a predictable user key, enabling account takeover. The seed is exposed as a public parameter without entropy validation. **Perspective 4:** register_user() accepts a 'seed' parameter passed to generate_api_key(). If an attacker can control this seed (e.g., via an API endpoint that calls register_user), they can predict the API key issued to a new user, then use it to impersonate that user. Even with trusted callers, deterministic key derivation from a caller-supplied seed weakens credential security. The seed should be removed or restricted to a server-side secret.

regenerate_key(account_id, user_id, seed) checks only that the account and user exist, and that the user is not mid-deletion. It does not verify that the caller is root or an admin of the target account, or that the caller is the user themselves. Any code path that reaches NewAPIKeyManager.regenerate_key — e.g. an admin API endpoint that does not itself verify the caller's role — lets an attacker rotate any user's key, locking them out and obtaining the new key (which is returned). The new manager adds no authorization gate, so the vulnerability is inherited from the legacy design and reachable through the new-format key path.

**Perspective 1:** regenerate_key() accepts a caller-supplied seed and derives the new key deterministically. An attacker who can trigger a key regeneration with a chosen seed can predict the new key for any user, enabling authentication bypass. Input: regenerate_key request with seed -> generate_api_key() -> predictable key. **Perspective 2:** regenerate_key(account_id, user_id, seed) passes the caller's `seed` to generate_api_key. If the regenerate endpoint is reachable by a user who can name an account_id/user_id (e.g. an admin or, in some flows, a self-service user), the caller can choose a seed and compute the exact new key offline, then use it to impersonate the target user. The new format's plaintext identity segments make this trivial once the seed is chosen. This is a direct credential-forgery / privilege-escalation path. **Perspective 3:** regenerate_key passes the optional seed to generate_api_key. If a caller supplies a predictable seed, the regenerated key is predictable, allowing an attacker to take over the account after a rotation. The API does not validate seed entropy. **Perspective 4:** regenerate_key() accepts a 'seed' parameter passed to generate_api_key(). If an attacker can control this seed, they can predict the new API key issued to a user after rotation, defeating the purpose of key rotation and allowing continued unauthorized access. The seed should be removed or restricted to a server-side secret.

set_role delegates directly to self._legacy.set_role(account_id, user_id, role) with no check that the caller is an admin or root. The legacy implementation (already flagged) has no authorization gate, so any code path that reaches NewAPIKeyManager.set_role — e.g. an admin API endpoint that does not itself verify the caller's role — lets an attacker escalate any user (including themselves) to admin. The new manager adds no defense, so the vulnerability is inherited and reachable through the new-format key path.

The DevAuthPlugin.resolve_identity returns Role.ROOT for every request without any authentication, and accepts arbitrary x_openviking_account/x_openviking_user headers to impersonate any account/user. While validate_config() attempts to restrict this to localhost, the check only inspects config.host at startup. If the server is bound to 0.0.0.0 or behind a reverse proxy that forwards to localhost, or if the config is changed at runtime, this exposes an unauthenticated ROOT endpoint. An attacker who can reach the server can access all data and perform any action. The validate_config() gate is a defense-in-depth check that can be bypassed by misconfiguration, and the plugin itself is the insecure default when auth_mode='dev' is set.

The /api/v1/search/grep endpoint accepts a user-supplied 'pattern' field and passes it directly to service.fs.grep without any validation. The grep implementation (as noted in prior findings) uses the pattern as a regex, allowing catastrophic backtracking (ReDoS) attacks. An attacker can supply a malicious regex pattern (e.g., '(a+)+$') that causes exponential CPU consumption, leading to denial of service. Trace: HTTP request -> GrepRequest.pattern -> service.fs.grep -> regex engine.

The WebDAV router decodes the URL path with unquote() before checking for '..' segments. However, the check happens after a single decode pass. An attacker can double-encode the traversal payload (e.g. %252e%252e%252f) so that unquote() yields '%2e%2e%2f' which does not match the literal '.'/'..' check, and the path is then passed to service.fs operations. A second decode happens downstream in the filesystem layer, turning it into a real '..' traversal that escapes the viking://resources root. Trace: HTTP request path -> _normalized_resource_path -> service.fs.rm/mv/write_file with the traversal path.

The MOVE handler parses the Destination header with urlparse. If the header contains an absolute URL with a scheme (e.g. http://attacker.com/../../etc/passwd), parsed.path is used directly. The check only verifies the path starts with /webdav/resources, but the host portion is ignored, so an attacker can supply a Destination pointing to an arbitrary host while the path still passes the prefix check. Combined with the double-decode issue, this can move resources outside the intended root or to unintended locations. Trace: HTTP Destination header -> _destination_path -> service.fs.mv.

Upload tokens are only 6 characters (base62), providing ~35.7 bits of entropy. They are exposed in URL query strings (?token=), making them visible in server logs, browser history, and referrer headers. An attacker who obtains or guesses a token can upload files as another user and trigger resource ingestion with the victim's identity and parameters. The token carries account_id, user_id, and business parameters, making this a privilege escalation vector.

**Perspective 1:** In `_plan_one_session`, the condition `if validate_user_id(owner):` treats a *valid* user ID as an error and a *invalid* one as acceptable. `validate_user_id` returns an error string when the ID is invalid and None when valid. The code appends an error to the plan when validation *succeeds* (returns None, which is falsy), and proceeds to create migration operations for invalid owner IDs. This allows a legacy session with a malicious or malformed `owner_user_id` (e.g. containing path traversal `../` or null bytes) to be copied into `user/{owner}/sessions/...`, potentially writing outside the intended user namespace or into another user's directory, causing cross-tenant data corruption or unauthorized data access. **Perspective 2:** The code checks `if validate_user_id(owner):` and treats a truthy return as an error, but `validate_user_id` typically returns an error string (truthy) on invalid input. If the function returns `None` or empty string on valid input, the logic is correct; however, if it returns a boolean `True` for valid input, this would incorrectly flag valid owners. This needs verification against the actual `validate_user_id` contract.

In `_delete_ctx_for_prune_record`, when a record has an `owner_user_id` different from the caller's, the code constructs a new `RequestContext` with `UserIdentifier(ctx.account_id, str(owner))` and the caller's `role`. This context is then used to call `vikingdb.delete(ids, ctx=delete_ctx)`. If the caller is an ADMIN (or the role is preserved), the delete is performed under the owner's identity, bypassing any per-user authorization checks that would normally apply. An admin reindexing a namespace could delete vectors belonging to other users without verifying the caller has manage permission on those specific records. The `_is_orphan_vector_record` check reads the source file with `owner_ctx`, but the delete itself uses the same constructed context, so a malicious admin could prune (delete) another user's vectors by crafting a URI that matches their records. This is reachable from the admin prune_orphans endpoint.

`PersistentTaskStore.delete` calls `_task_path` with user-controlled `account_id`, `user_id`, and `task_id`, then passes it to `agfs.rm(..., force=True)`. If any of these values contain path traversal sequences (e.g., `../../`), the rm operation can delete arbitrary files outside the intended task directory. This is reachable from `TaskTracker.delete` which is called by user-facing task management endpoints. Trace: user-supplied task_id -> `_task_path` -> `agfs.rm(force=True)`.

`_task_path` concatenates `account_id`, `user_id`, and `task_id` directly into a filesystem path without sanitization. These values are passed from `TaskTracker` calls that originate from user-controlled request parameters (e.g., task_id in API routes). An attacker who can supply a `task_id` like `../../../../etc/cron.d/evil` or a `user_id` with path separators can write or read arbitrary files under the AGFS root. The `_write_task` and `get` methods use this path for `agfs.write` and `agfs.read`. Trace: user-supplied task_id -> `_task_path` -> `agfs.write/read`.

In `_process`, the `target_account_id` and `target_user_id` come directly from the queue message parsed by `_parse_message`. These values are used to construct a `RequestContext` with `Role.ROOT` and then passed to `viking_fs.rm(canonical_user_root(cleanup_ctx), recursive=True)` and `vector_store.delete_user_data`. If an attacker can inject a message with a crafted `target` (e.g., `../../` or a system path), the canonical_user_root could resolve outside the intended user directory, leading to arbitrary file deletion. The fields are not sanitized against path traversal or length limits. Trace: queue message target -> `_process` -> `RequestContext(role=ROOT)` -> `viking_fs.rm`.

The `_parse_message` method in `_UserDeletionProcessor` deserializes a queue message without validating the source or authenticating the sender. The `data` dict comes from the queuefs named queue, which is populated by `_deletion_message` but can also be enqueued by any internal component. The message contains `account_id`, `user_id`, and `target` fields that are used directly in `_process` to construct a `RequestContext` with `Role.ROOT` and delete the target user's data. An attacker who can enqueue a message to the USER_DELETION queue (e.g., via an unauthenticated queuefs write path) can delete any user's data. The message fields are only type-checked (str), not validated against the actor's permissions or the deletion fence. Trace: queue message -> `_parse_message` -> `_process` -> `cleanup_ctx = RequestContext(role=Role.ROOT)` -> `viking_fs.rm(canonical_user_root(cleanup_ctx), recursive=True)`.

The `_UserDeletionProcessor.on_dequeue` schedules `_process` on the service loop via `run_coroutine_threadsafe`. If the queue delivers the same message more than once (e.g., due to a crash after ack, or a retry), or if `initialize()` re-enqueues a task that is already being processed, two concurrent `_process` coroutines can run for the same target user. Both will call `_cancel_user_tasks`, `viking_fs.rm`, and `finish_user_deletion` without any lock or idempotency guard beyond the tracker status check, which is itself racy (read-then-act). This can lead to partial deletion, double-deletion of shared resources, or a crash from concurrent filesystem operations. The `_request_lock` only guards `delete_user`, not `_process`.

**Perspective 1:** The OpenViking root or user API key is stored in the `_policy_set_metadata` dict under `openviking_api_key`. This metadata is attached to the `ExperienceSet` and later serialized into the run report JSON (`_write_report`) and the train rollout cache files (`_write`), which are written to the repository's `result/` directory. Anyone with read access to those artifacts (e.g., a CI log, shared volume, or backup) obtains a live credential that can impersonate the configured account/user. The key is attacker-reachable only if the artifacts leak, but the exposure is direct and unnecessary. **Perspective 2:** The batch train/eval runner writes the OpenViking API key into the policy set metadata (`_policy_set_metadata`), which is then serialized into the run report and event logs. This exposes the credential in plaintext in artifacts that may be shared, archived, or committed, increasing the risk of credential leakage and unauthorized access to the OpenViking server. The key originates from config or environment and flows into metadata that is persisted via `_write_report` and event recording. **Perspective 3:** `_policy_set_metadata` includes the raw `openviking_api_key` (from `client._api_key`) in the policy set metadata. This metadata flows into `ExperienceSet.metadata`, which is used in `_write_report` (report.json) and `event_recorder.record` (events.jsonl). The API key is therefore persisted to disk in plaintext in the report and event files. Anyone with read access to the result directory (or the events file) can extract the OpenViking API key, which may be a root or user key granting access to the server. This is a credential leak to disk. **Perspective 4:** The OpenViking API key is written into the policy set metadata dict, which is later serialized to disk in the run report and potentially persisted in the experience set. This exposes the credential in plaintext at rest, allowing anyone with filesystem access to the result directory to retrieve it. The key originates from config.server_url/api_key or server_config.root_api_key and is passed to the client, then copied into metadata.

**Perspective 1:** The dataset service exposes `/v1/cases/query`, `/v1/rollouts/execute`, and `/v1/rollouts/executions/{execution_id}` without any authentication or authorization. Any unauthenticated caller can query dataset cases, trigger expensive rollouts (consuming compute/LLM tokens), and read rollout results including full messages, tool outputs, prompts, and reasoning. This is an unauthenticated data-exposure and resource-abuse vector. **Perspective 2:** The generic dataset service exposes `/v1/cases/query`, `/v1/rollouts/execute`, and `/v1/rollouts/executions/{id}` without any authentication or authorization. Any network client that can reach the service can submit arbitrary rollouts (consuming compute/LLM tokens) and read rollout results, which may contain sensitive conversation data. There is also no rate limiting, enabling resource-exhaustion attacks. The service is intended to be a remote benchmark host, but the lack of auth means it cannot be safely exposed beyond localhost.

The `/v1/rollouts/execute` endpoint accepts a full `policy_set` (including policy content) and `case` from the client and passes them directly to the rollout executor. An unauthenticated attacker can submit a crafted policy set that causes the executor to load arbitrary content or execute unintended logic, and can consume unbounded compute/LLM resources. The policy content is trusted without integrity verification or provenance checks, and the execution context is also client-controlled.

**Perspective 1:** The `import_ovpack` function opens a user-supplied `.ovpack` file with `zipfile.ZipFile` without enforcing limits on the total archive size, number of members, or individual member sizes. An attacker could provide a maliciously crafted ZIP (e.g., a zip bomb) that decompresses to an enormous size, causing disk exhaustion or memory DoS during extraction and processing. The `validated_import_members` function may validate paths but does not limit sizes. **Perspective 2:** The `import_ovpack` and `restore_ovpack` functions open a ZIP archive from a user-supplied path without verifying a digital signature or a trusted checksum. The archive contents are extracted and written into the Viking filesystem, and vector snapshots are restored. A malicious or tampered .ovpack file could inject arbitrary content into the user's context store. While the manifest includes SHA-256 hashes for individual files, there is no verification of the archive's overall authenticity or provenance. **Perspective 3:** The `import_ovpack` function opens a ZIP file without any size limit on the archive or its members. A malicious or oversized `.ovpack` file could cause excessive memory or disk usage during extraction, leading to denial of service. This is a configuration hardening gap.

**Perspective 1:** In `import_ovpack`, the code reads each ZIP member with `zf.read(safe_zip_path)` without checking the member's uncompressed size. A malicious `.ovpack` file could contain a member that decompresses to an enormous size, causing memory exhaustion when the data is loaded into memory and then written to the filesystem. **Perspective 2:** In `import_ovpack`, the code reads each file member from the ZIP archive entirely into memory with `data = zf.read(safe_zip_path)` before writing it to the filesystem. A malicious or corrupted `.ovpack` file can contain a member that is extremely large (e.g., a multi-GB file), causing the server to allocate an unbounded amount of memory, leading to OOM and a crash. This is a DoS vector if an attacker can upload a crafted `.ovpack` file. The same pattern exists in `restore_ovpack` at line 713.

The `restore_ovpack` function opens a user-supplied `.ovpack` file with `zipfile.ZipFile` without enforcing limits on the total archive size, number of members, or individual member sizes. An attacker could provide a zip bomb, causing disk exhaustion or memory DoS during restore.

In `restore_ovpack`, the code reads each ZIP member with `zf.read(safe_zip_path)` without checking the member's uncompressed size. A malicious backup file could contain a member that decompresses to an enormous size, causing memory exhaustion.

validate_manifest_content reads each file member fully into memory via zf.read() to verify size and sha256. A malicious OVPack with a large file (e.g., 10GB) or many files will exhaust memory. There is no per-file or total size cap. This is a ZIP bomb DoS vector when importing an untrusted OVPack.

In read_dense_vectors, `dimensions` comes from the OVPack manifest (attacker-controlled if the package is untrusted). The format string `f"<{dimensions}f"` is built directly from this value. A malicious manifest can set dimensions to a huge number (e.g. 2^31), causing struct.unpack_from to attempt allocating and reading gigabytes of memory, or raise an unhandled struct.error on truncated data. This can crash the import process or exhaust memory.

The `AddResourceProcessor` dequeues messages from a durable queue and constructs a `RequestContext` directly from `msg.account_id`, `msg.user_id`, `msg.role`, `msg.group_ids`, and `msg.bypass_acl` without validating that these values are trusted or that the message was authenticated. If an attacker can enqueue a message (e.g., via an unauthenticated or weakly-authenticated queue producer, or by replaying/forging a message), they can set `bypass_acl=true` and an arbitrary `role` to escalate privileges and bypass ACL checks during resource processing. The `RequestContext` is then used for filesystem operations (`viking_fs`) and resource service calls, enabling unauthorized read/write/delete of resources.

In `on_cancelled`, the code parses the queue message payload and constructs a `RequestContext` with `bypass_acl` and `role` taken directly from the message without validation. An attacker who can inject or forge a cancellation message can set `bypass_acl=true` and an elevated role, causing the processor to release locks or clean up staged sources with elevated privileges. This can lead to unauthorized deletion of staged resources or lock manipulation.

The `_ctx_from_semantic_msg` method builds a `RequestContext` with `bypass_acl=True` directly from fields in a `SemanticMsg` (account_id, user_id, role, group_ids) that are deserialized from the queue payload. If an attacker can inject or tamper with a message in the semantic queue (e.g., via a compromised queue producer or a supply chain attack on a component that enqueues messages), they can set an arbitrary role (e.g., ROOT) and bypass ACL checks for file operations performed during semantic processing. This allows unauthorized access to resources that should be protected by ACLs.

_ctx_from_semantic_msg constructs a RequestContext with bypass_acl=True for every message. This means semantic processing operations (file reads, writes, directory listings) skip ACL enforcement entirely. If a queue message is crafted with another user's account_id/user_id, the processor would operate on that user's files without authorization. The message fields are trusted without verification against the actual authenticated identity.

The `on_dequeue` method deserializes a `SemanticMsg` directly from the queue payload (`data`) without any integrity verification (e.g., signature, checksum, or provenance). The message contains fields like `account_id`, `user_id`, `role`, `group_ids`, `target_uri`, and `lock_handoff` that are used to construct a `RequestContext` with `bypass_acl=True` and to perform filesystem operations. An attacker who can inject or tamper with a message in the semantic queue can set an arbitrary role (e.g., ROOT) and bypass ACL checks, potentially reading or writing files they should not access. This is a supply chain integrity gap because the queue is trusted without verification.

**Perspective 1:** The `on_cancelled` method deserializes a `SemanticMsg` from the queue payload and, if `msg.lock_handoff` is present, adopts and releases the pathlock lease. An attacker who can inject or tamper with a message in the semantic queue can supply a crafted `lock_handoff` to release a lock they do not own, potentially causing a denial of service or allowing unauthorized access to a locked resource. There is no integrity verification on the message payload. **Perspective 2:** In `on_cancelled`, if the pathlock adopt/release fails (e.g., the lock was already released or the AGFS is unavailable), the exception is caught and only logged as a warning. The method then reports success. This means a lock that was not actually released remains held, potentially blocking subsequent operations on the same path indefinitely. The caller has no way to know the lock was not released.

The fetch_data method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

**Perspective 1:** The delete_data method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit. **Perspective 2:** The delete_all_data method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

The search_by_vector method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

The search_by_id method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

The search_by_multimodal method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

The search_by_random method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

The search_by_keywords method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

The search_by_scalar method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

The aggregate_data method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

The `serialize` method constructs a `struct` format string by interpolating the length of user-supplied list fields (e.g. `f"{len(items)}q"`). A caller can pass a list with millions of elements, causing `struct.calcsize(fmt)` to allocate a huge buffer and the format string to grow without bound, exhausting memory. The input originates from data-plane API requests (e.g. `upsert_data`), so an authenticated user can trigger OOM. There is no cap on list length or total serialized size.

**Perspective 1:** The `/DeleteVikingdbCollection` endpoint calls `project.drop_collection()` with no authentication or authorization. Any caller can delete any collection by name. This is a data-loss vulnerability. The endpoint is registered on the collection_router with no auth dependency. **Perspective 2:** The DeleteVikingdbCollection endpoint accepts a `CollectionName` from the HTTP request and passes it directly to `project.drop_collection` without validating the name. An attacker can supply a collection name with path traversal sequences or special characters, potentially causing the backend to delete files or directories outside the intended collection storage. The endpoint also lacks an authorization check to ensure the caller is allowed to drop the collection.

The /api/vikingdb/data/upsert endpoint accepts a `fields` payload from the HTTP request and passes it directly to `collection.upsert_data` without validating the data against the collection's schema. An attacker can send arbitrary field names, types, and values (including oversized strings, nested objects, or vectors of unexpected dimensions), potentially corrupting stored records, bypassing schema constraints, or causing the backend to misinterpret data types. The `data_utils.convert_dict` only performs a shallow conversion and does not enforce the collection's field definitions. This is a direct input-validation gap at the API boundary.

The `/api/vikingdb/data/delete` endpoint with `del_all=true` calls `collection.delete_all_data()`. There is no authentication or authorization check on this endpoint — any caller who can reach the API can wipe an entire collection. This is a data-loss vulnerability. The endpoint is registered on the data_router with no auth dependency.

**Perspective 1:** The deserialize_field method reads a string length (str_len) from the serialized data without validating that the offset and length are within the bounds of the serialized_data buffer. An attacker who can control the serialized row data (e.g., via a crafted database file or API payload) can supply a large length value, causing the subsequent slice serialized_data[str_offset : str_offset + str_len] to read beyond the buffer. This can lead to out-of-bounds memory access, information disclosure, or a crash. The same pattern is repeated for binary, text, and list_string fields. **Perspective 2:** In deserialize_field, for string/binary/text/list types, the offset and length values are read directly from the serialized_data buffer without validating that they are within the buffer bounds. A corrupted or maliciously crafted row (e.g., from a partially written file or a tampered store) can supply an offset/length that causes struct.unpack_from to raise struct.error or return data from an unintended region, or cause an IndexError. This can crash the deserialization path with an uncaught exception, breaking store reads. The input path is any stored row that is read back from disk, which can be corrupted by a crash mid-write or by an attacker with write access to the store.

The deserialize_field method reads a list length (list_len) from the serialized data without validating that the list_offset and the total size of the list elements are within the bounds of the serialized_data buffer. An attacker controlling the serialized data can set a large list_len, causing the loop to read beyond the buffer (for list_string) or struct.unpack_from to read out of bounds (for list_int64 and list_float32). This can lead to memory disclosure or a crash.

**Perspective 1:** The `pattern` parameter is user-controlled (from the HTTP API / CLI) and is compiled directly with `re.compile` without any length or complexity limits. A malicious pattern with nested quantifiers (e.g. `(a+)+$`) can cause catastrophic backtracking, leading to CPU exhaustion (ReDoS). This affects the `_grep_in_files` path used by the vikingdb_then_fs engine. The same issue exists at line 485 in `_grep_encrypted`. **Perspective 2:** The `pattern` parameter is user-controlled (from the `grep` API) and is compiled directly with `re.compile` without any complexity limits. A malicious pattern like `(a+)+$` against a long string of 'a's can cause catastrophic backtracking, consuming 100% CPU and blocking the event loop. This is reachable via the `_grep_in_files` and `_grep_encrypted` paths, which process every line of every candidate file.

The `pattern` parameter is user-controlled and compiled directly with `re.compile` in the `_grep_encrypted` path. A malicious pattern with catastrophic backtracking (e.g. `(a|aa)+$`) can cause CPU exhaustion. This path is reached when encryption is enabled or when agfs native grep is unavailable.

`VikingDBManagerProxy.delete_account_data` passes `account_id` directly to the manager with the proxy's bound ctx. If the caller can control `account_id` (e.g. from a request), they can delete another tenant's data. The proxy binds a ctx but the method takes an explicit account_id parameter, which may not be validated against the ctx's account. This is a cross-tenant data deletion vulnerability.

**Perspective 1:** The install_ollama function downloads and executes a shell script from https://ollama.com/install.sh by piping it directly to `sh` via `bash -c`. The script is fetched over HTTPS but there is no integrity check (checksum, signature, or pinned version). If the remote endpoint is compromised or serves a malicious script, arbitrary code is executed with the privileges of the current user. This is a supply chain risk that can lead to RCE during installation. The same pattern is used for both Darwin and Linux platforms. **Perspective 2:** The install_ollama function pipes a remote install script directly into a shell. The script is fetched over HTTPS but its content is not pinned to a known hash, signature, or version. A compromised or tampered script at ollama.com (or a MITM if TLS is bypassed) would execute arbitrary code with the privileges of the OpenViking server process. This is a classic remote-code-execution supply chain vector: untrusted network content -> subprocess shell execution. **Perspective 3:** The `install_ollama` function executes `curl -fsSL https://ollama.com/install.sh | sh` via a shell. This downloads and executes a remote script without verifying its integrity (checksum/signature). If the download is intercepted or the upstream is compromised, arbitrary code is executed with the privileges of the user running the CLI.

Same as the macOS path: the Linux install path also pipes an unverified remote script into a shell. The script is fetched over HTTPS but its content is not pinned to a known hash, signature, or version. A compromised or tampered script at ollama.com (or a MITM if TLS is bypassed) would execute arbitrary code with the privileges of the OpenViking server process. This is a classic remote-code-execution supply chain vector: untrusted network content -> subprocess shell execution.

The `user_search_filter` is a configurable template that is formatted with the username. While `ldap.filter.escape_filter_chars` is applied to the username, the template itself is not validated. If an administrator configures a filter that does not use the `%s` placeholder (e.g., a static filter or one that concatenates the username in an unsafe way), an attacker-controlled username could inject LDAP filter syntax. More critically, the template is applied with `%` formatting, which can raise a `TypeError` or `ValueError` if the username contains `%` characters, potentially causing a denial of service. The input path is: HTTP request -> `_extract_credentials` -> `_authenticate_ldap` -> `_search_user_attributes` -> this line.

When `auth_mode` is not set and `root_api_key` is not configured, `get_effective_auth_mode()` returns `AuthMode.DEV.value`, which grants unauthenticated ROOT access (as reported in the dev auth plugin). This means a default deployment with no explicit `root_api_key` exposes the entire API without any authentication, allowing anyone to read, modify, or delete all data. This is a critical insecure default that should require explicit configuration of an auth mode or root key.

**Perspective 1:** The server config defaults `cors_origins` to `["*"]`, which allows any website to make authenticated cross-origin requests to the OpenViking API. Since the API uses API keys sent via the `X-API-Key` header, a malicious site could trigger state-changing requests (e.g., resource deletion, session commits) on behalf of a logged-in user if the user visits the malicious page. This is a direct CORS misconfiguration that enables cross-site request forgery against the API. **Perspective 2:** The default `cors_origins` of `["*"]` combined with the API's use of `X-API-Key` headers means any malicious website can make authenticated requests to the OpenViking API. Since the API key is stored in sessionStorage by the web studio, a cross-origin request from a malicious page could read or modify user data if the user is logged in. This is a direct CORS misconfiguration enabling cross-site request forgery and data theft.

The server config defaults `api_key_hashing_enabled` to `False`. When file-level encryption is disabled (the default for `encryption_enabled`), API keys are stored in plaintext on disk. Even when file encryption is enabled, the code explicitly logs that keys are stored in plaintext within AES-GCM encrypted files. An attacker with filesystem access (e.g., via a compromised container or backup) can read all API keys and impersonate any user. This is an insecure default that should enable hashing by default.

**Perspective 1:** In exchange_refresh_token, the role downgrade check wraps the role resolver call in a broad except (ValueError, Exception) that sets both token_role and current_role to None. If the role resolver raises (e.g., transient DB error, malformed stored role), the check is skipped entirely and the refresh proceeds. This defeats the security invariant that a demoted user cannot mint fresh access tokens at their old privilege level. An attacker who previously held a high-privilege refresh token can keep rotating it indefinitely whenever the resolver errors, or can trigger the error condition (e.g., by corrupting the stored role string) to bypass the gate. The except clause should only catch ValueError from Role() parsing, not swallow resolver failures; a resolver failure should fail closed (reject the refresh). **Perspective 2:** The role downgrade gate in exchange_refresh_token catches (ValueError, Exception) and sets both token_role and current_role to None. This means any exception during role resolution (e.g. a transient DB error from the role_resolver) silently disables the privilege-escalation protection, allowing a demoted user to continue minting access tokens at their old higher role. The catch-all also swallows programming errors. The input is the refresh_token.role and the role_resolver result; the sink is the subsequent rank comparison that is skipped when both are None. This is a security-relevant error handling flaw because a failure to resolve the current role should fail closed (reject the refresh), not fail open. **Perspective 3:** In exchange_refresh_token, the role downgrade gate catches (ValueError, Exception) and sets both roles to None, which then skips the rank comparison. This means any exception (including a transient DB error from the role_resolver) silently disables the privilege-escalation protection, allowing a demoted user to continue minting access tokens at their old higher role. The input is the refresh_token.role and the role_resolver result; the sink is the skipped rank check. **Perspective 4:** In `exchange_refresh_token`, the `role_resolver` callback is wrapped in a broad `except (ValueError, Exception)` that sets both `token_role` and `current_role` to `None`. This means that if the role resolver fails (e.g., due to a database error or a misconfigured user), the role downgrade gate is silently bypassed, and the refresh token is rotated without enforcing the role check. An attacker who can cause the role resolver to fail (e.g., by triggering an exception) could potentially obtain a refresh token at a higher privilege level than their current role. **Perspective 5:** The role resolution in exchange_refresh_token catches all exceptions and sets both roles to None. This could mask errors and potentially allow a role downgrade check to be bypassed if the role resolver fails. This is a defense-in-depth gap.

**Perspective 1:** The comment claims a missing fp makes the token unusable because the bearer-auth path fails closed against a NULL stored value. But this line converts None to an empty string before insert_access/insert_refresh. If the storage layer stores '' rather than NULL, the bearer-auth check that compares against a NULL may not trigger, and the token could be accepted without a valid authorizing key fingerprint. This weakens the security property that rotating the API key invalidates the entire OAuth token chain. An attacker who obtains a token minted through a path that omitted the fp (e.g., a legacy or malformed flow) could keep using it even after the authorizing key is rotated. **Perspective 2:** In _issue_token_pair(), if authorizing_key_fp is None (e.g., a legacy flow or a code path that doesn't record it), the code substitutes an empty string and still issues a valid access/refresh token pair. The comment acknowledges that a missing fp makes the token 'unusable' in the bearer-auth path, but the token is still stored and returned to the client. If the bearer-auth path fails open (or if another consumer trusts the token without checking fp), an attacker could obtain a token that is not bound to any API key, defeating key-rotation revocation. This is a fail-open configuration for a security-critical binding. **Perspective 3:** In _issue_token_pair, when authorizing_key_fp is None it is coerced to an empty string and stored. The comment acknowledges the bearer-auth path will fail-closed against a NULL stored value, but here an empty string is stored instead of NULL, which may bypass that fail-closed check if the bearer-auth path treats empty string as 'no binding'. This can occur if a code path calls _issue_token_pair without a fingerprint (e.g. a future flow or a bug in the OTP verification). The result is an access token that may authenticate without the API-key binding, weakening the rotation-invalidation guarantee. The input is the authorizing_key_fp parameter; the sink is the stored token record. **Perspective 4:** In `_issue_token_pair`, the `authorizing_key_fp` is set to an empty string (`""`) when it is `None`. This means that if a token is issued without a valid authorizing key fingerprint (e.g., due to a bug or a compromised flow), the token will be stored with an empty fingerprint. The comment notes that the bearer-auth path will fail-closed against a NULL stored value, but an empty string may not be treated as NULL, potentially allowing a token to be used without a valid authorizing key binding. This could weaken the security of the token chain.

HTTP request with user-controlled URL in openviking/server/oauth/router.py at line 133 enables SSRF attacks.

The repo_url is user-supplied via the manifest/catalog YAML and passed directly to `asyncio.create_subprocess_exec` as an argument. While `create_subprocess_exec` avoids shell interpretation, the URL is not validated against a scheme allowlist beyond `require_remote_resource_source`. A URL like `https://host/../../etc/passwd` or one with a crafted path could cause git to read arbitrary local files or interact with unexpected endpoints. The `_validate_clone_url` only checks for control chars, leading '-', and remote-helper prefixes; it does not restrict the scheme or host. An attacker controlling the manifest can point git at internal network resources (SSRF) or local file paths.

**Perspective 1:** The `account_id` path parameter is interpolated directly into an AGFS filesystem path without validation or sanitization. An attacker who can reach this endpoint (requires root auth) could supply an account_id containing path traversal sequences such as `../../` or absolute path components. Since `rm` is called with `recursive=True`, this could delete arbitrary directories under the AGFS root, including system or other tenants' data. The input originates from the HTTP path parameter `account_id` and reaches the `rm` sink without any allowlist or normalization. **Perspective 2:** The `delete_account` endpoint constructs an AGFS path directly from the `account_id` path parameter and calls `rm` recursively. If `account_id` contains path traversal characters (e.g., `../`), it could delete data outside the intended account directory. The account_id should be validated against a safe pattern. **Perspective 3:** The `delete_account` endpoint does not acquire any locks on the account being deleted. If a concurrent request is writing to the account (e.g., adding a resource, creating a session) while the deletion is in progress, the deletion could remove data that is being written, or the write could fail with a 'not found' error. This can lead to data loss or inconsistent state. The input is the `account_id` path parameter, reaching the `rm` and `delete_account_data` sinks. **Perspective 4:** The `delete_account` endpoint wraps the AGFS and VectorDB cleanup in broad `try/except` blocks that log a warning and continue. This means if the cleanup fails (e.g., permission denied, disk full, network error), the failure is silently ignored and the account metadata is still deleted, leaving orphaned data. The input is the `account_id` path parameter, reaching the `rm` and `delete_account_data` sinks. **Perspective 5:** The `delete_account` endpoint checks for account existence (via `_check_account_exists`) and then performs the deletion. Between the check and the deletion, another request could create the same account, leading to the deletion of the newly created account's data. This is a time-of-check-to-time-of-use (TOCTOU) race. The input is the `account_id` path parameter, reaching the `rm` and `delete_account_data` sinks. **Perspective 6:** The `delete_account` endpoint does not prevent deletion of the default account or system accounts. If an attacker with root access deletes the default account, it could break the entire system, as many operations may depend on the default account existing. The input is the `account_id` path parameter, reaching the `rm` and `delete_account_data` sinks. **Perspective 7:** The `delete_account` endpoint does not prevent concurrent deletion of the same account. If two requests delete the same account simultaneously, the second request may fail with a 'not found' error, or the two deletions may interfere with each other, causing data corruption. The input is the `account_id` path parameter, reaching the `rm` and `delete_account_data` sinks. **Perspective 8:** The `delete_account` endpoint calls `viking_fs._async_agfs.rm` without a timeout. If the AGFS rm operation blocks (e.g., due to a network issue or a very large directory), the request could hang indefinitely, tying up a worker thread and potentially exhausting the thread pool. The input is the `account_id` path parameter, reaching the `rm` sink. **Perspective 9:** The `delete_account` endpoint does not call `_check_account_exists` before attempting the deletion. If the account does not exist, the AGFS rm and VectorDB delete will likely fail, and the `manager.delete_account` may also fail. The error handling is inconsistent, and the caller may receive a generic 500 error instead of a clear 'not found' message. The input is the `account_id` path parameter, reaching the `rm` and `delete_account_data` sinks. **Perspective 10:** The `delete_account` endpoint deletes the account's data without checking for active sessions or resources. If the account has active sessions, deleting the account could cause those sessions to fail or leave orphaned state. The input is the `account_id` path parameter, reaching the `rm` and `delete_account_data` sinks. **Perspective 11:** The `delete_account` endpoint allows a root caller to delete their own account. This could lock the caller out of the system and cause data loss. The input is the `account_id` path parameter, reaching the `rm` and `delete_account_data` sinks. **Perspective 12:** The `delete_account` endpoint calls `storage.delete_account_data(account_id)` which may need to delete a very large number of vector records. This operation could take a long time or exhaust memory. The input is the `account_id` path parameter, reaching the `delete_account_data` sink. **Perspective 13:** The `delete_account` endpoint calls `viking_fs._async_agfs.rm` with `recursive=True`. If the account has a very large number of files, this operation could take a long time or exhaust memory. The input is the `account_id` path parameter, reaching the `rm` sink. **Perspective 14:** The `delete_account` endpoint deletes the account's data but does not explicitly clean up groups or group members. If the account has a large number of groups, this could leave orphaned group data. The input is the `account_id` path parameter, reaching the `rm` and `delete_account_data` sinks. **Perspective 15:** The `delete_account` endpoint deletes the account's data but does not explicitly clean up all users in the account. If the account has a large number of users, this could leave orphaned user data. The input is the `account_id` path parameter, reaching the `rm` and `delete_account_data` sinks.

The `/preflight` endpoint accepts a `repo_url`, `branch`, `commit`, and optional `auth_config` (username/token) from the caller and uses them to verify source readability by connecting to the git repository. An attacker who can call this endpoint can supply an arbitrary `repo_url` (e.g., an attacker-controlled server) and credentials, causing the server to make outbound connections to that server (SSRF) and potentially exfiltrate the provided credentials or probe internal network resources. There is no allowlist of trusted repositories or verification of the repo's integrity.

The cleanup pipeline (deleting the user's entire viking_fs tree, vector store data, uploads, OAuth tokens, and usage audit records) constructs a RequestContext with role=Role.ROOT for the target user. This bypasses all ACL checks and runs with root privileges. While the deletion is initiated by an authorized actor, the hardcoded ROOT role means any bug in the deletion flow or a compromised queue message could cause deletion of arbitrary user data without proper authorization checks.

The list_vikingdb_collections function constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

**Perspective 1:** The HttpCollection class sets its URL prefix to plaintext HTTP, and all subsequent methods (update, drop, upsert_data, search_by_vector, etc.) use this prefix. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit. **Perspective 2:** The `HttpCollection.__init__` hardcodes the `http://` scheme in `url_prefix`. All subsequent operations (upsert, search, delete, etc.) use this prefix, transmitting data in plaintext. This is a systemic issue affecting every method in this class.

The update method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

The get_meta_data method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

The drop method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

The create_index method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

The list_indexes method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

The update_index method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

The upsert_data method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

The update_data method constructs its API endpoint using plaintext HTTP. This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit.

**Perspective 1:** Default database credentials are set to weak values: _APP_DB_USER='user', _APP_DB_PASS='password', _APP_DB_ROOT_PASS='rootsecretpassword'. These are common weak passwords that should not be used in production. **Perspective 2:** The environment variable _APP_EXECUTOR_SECRET is set to 'your-secret-key' which appears to be a placeholder/hardcoded value. This secret is used for inter-service communication authentication and having a predictable/default value compromises service-

The build-multiarch.sh script defaults IMAGE_TAG to 'latest', a mutable tag. When PUSH=true, the built image is pushed under this mutable tag, overwriting whatever was previously published. This breaks artifact provenance — the 'latest' tag no longer points to a specific, verifiable build, and a later build can silently replace a previously validated image. The script should require an explicit immutable version tag for pushes.

The deploy.sh script defaults IMAGE_TAG to 'latest' and runs the container with '${IMAGE_NAME}:${IMAGE_TAG}'. The 'latest' tag is mutable, so a subsequent pull or a compromised registry could serve a different, unverified image. There is no digest pinning (e.g. image@sha256:...) and no signature verification of the image before running it. This breaks container image provenance and allows running unverified artifacts in production.

The deploy.sh script runs the container using '${IMAGE_NAME}:${IMAGE_TAG}' where IMAGE_TAG defaults to 'latest'. The image is not referenced by digest and its signature is not verified before execution. A compromised or tampered image in the registry would be pulled and executed with access to the mounted ~/.vikingbot directory containing gateway tokens and API keys. This violates container image provenance requirements.

**Perspective 1:** The deployment script prints a hardcoded default admin password for the Langfuse web UI. This password is a predictable, static value that is also present in the docker-compose.yml. An attacker who gains access to the deployment environment or reads the script can use these credentials to log into the Langfuse admin console, potentially accessing sensitive LLM traces, prompts, and API keys. This is a supply chain risk as it ships a known credential in the repository. **Perspective 2:** The deployment script prints a hardcoded default admin password for Langfuse. If this password is used in production, an attacker can gain unauthorized access to the Langfuse instance. This is a supply chain integrity gap because the default credentials are not changed. **Perspective 3:** The Langfuse deployment script prints a hardcoded default admin password ('vikingbot-admin-password-2026') and the corresponding docker-compose.yml (already flagged separately) configures Langfuse with this fixed credential. Anyone who reads the repo or the deploy output knows the admin password for any deployment that does not override it, giving full access to the Langfuse observability UI and its stored traces/prompts. This is a default-credential misconfiguration.

The image upload script defaults the remote image tag to 'latest' when use_timestamp_tag is not set to true. Pushing to a mutable 'latest' tag means consumers pulling this image cannot verify they are running a specific, known build, and a compromised or accidental push overwrites the tag for all downstream users. This is a supply chain integrity gap: no digest pinning or immutable tag is enforced.

The docker-compose file pins the container image to the mutable 'latest' tag. This means deployments can pull different, untracked versions of the image over time, making builds non-reproducible and potentially pulling a compromised or unintended image. An attacker who compromises the registry or the image pipeline could push a malicious 'latest' that gets silently deployed.

**Perspective 1:** The docker-compose file provides a default ENCRYPTION_KEY of all zeros. If the operator does not override it, Langfuse will encrypt all sensitive data (API keys, secrets) with a publicly known key. This is a hardcoded credential in a deployment artifact, allowing anyone who knows the default to decrypt stored secrets. The input is the deployment configuration itself; the sink is Langfuse's encryption-at-rest for stored credentials. **Perspective 2:** The Langfuse encryption key defaults to a well-known all-zero value. If the operator does not set ENCRYPTION_KEY, all sensitive data (API keys, prompts, trace payloads) encrypted by Langfuse is protected by a publicly documented constant, allowing anyone who obtains the database to decrypt it. This is a hardcoded secret in production configuration. **Perspective 3:** The docker-compose file provides a default ENCRYPTION_KEY of all zeros. If the operator does not override it, all Langfuse-encrypted data (API keys, secrets, credentials) is encrypted with a publicly known key, allowing anyone with database access to decrypt it. This is a supply-chain/secret-management risk in the deployment dependency stack.

**Perspective 1:** The docker-compose file provides a default NEXTAUTH_SECRET of 'vikingbot-nextauth-secret-2026'. NextAuth uses this secret to sign session cookies. A publicly known signing secret allows an attacker to forge admin session cookies and gain unauthorized access to the Langfuse UI. The input is the deployment configuration; the sink is NextAuth session cookie signing. **Perspective 2:** NextAuth secret defaults to a predictable constant 'vikingbot-nextauth-secret-2026'. This secret signs session cookies and CSRF tokens. With a known secret, an attacker can forge session cookies and impersonate any Langfuse user, including the admin, gaining full access to trace data and configuration. **Perspective 3:** The NextAuth secret used to sign session cookies and tokens defaults to a predictable string. An attacker who knows this default can forge session cookies and authenticate as any Langfuse user, including the admin account, gaining access to all traced LLM data and stored credentials.

**Perspective 1:** The docker-compose file provides a default Langfuse project secret key of 'sk-lf-vikingbot-secret-key-2026'. This key is used to authenticate ingestion API calls. A publicly known secret key allows an attacker to inject forged tracing/audit data into the Langfuse system. The input is the deployment configuration; the sink is Langfuse's ingestion API authentication. **Perspective 2:** The Langfuse project secret key defaults to a predictable constant 'sk-lf-vikingbot-secret-key-2026'. This secret key authenticates ingestion and querying of trace data. With a known secret key, an attacker can read or inject arbitrary trace data into the default project, compromising observability data integrity and confidentiality. **Perspective 3:** The Langfuse project secret key used to authenticate ingestion API calls defaults to a predictable string. Anyone knowing this default can inject forged trace data into the Langfuse instance, corrupting observability data and potentially poisoning downstream analytics.

**Perspective 1:** The docker-compose file provides a default MinIO root password of 'miniosecret'. If not overridden, the MinIO object store is protected by a publicly known root credential, allowing an attacker to read, modify, or delete all stored Langfuse data. The input is the deployment configuration; the sink is MinIO root authentication. **Perspective 2:** MinIO root password defaults to 'miniosecret'. Combined with the default root user 'minio' and the MinIO port exposed on all interfaces, this allows unauthenticated access to the object store. **Perspective 3:** The MinIO root password defaults to 'miniosecret'. If not overridden, anyone who can reach the MinIO console or S3 endpoint can gain full administrative access to the object store, reading/writing all stored trace data.

The MinIO service is published on port 9090 bound to all interfaces (0.0.0.0), while the comment in the file recommends restricting it to localhost. Combined with the default MINIO_ROOT_USER=minio and MINIO_ROOT_PASSWORD=miniosecret, any remote attacker can access the object store, read/write Langfuse trace events and media, and potentially pivot to other services.

**Perspective 1:** The docker-compose file provides a default PostgreSQL password of 'postgres'. If not overridden, the Langfuse database is protected by a publicly known credential, allowing an attacker to read, modify, or delete all stored tracing/audit data. The input is the deployment configuration; the sink is PostgreSQL authentication. **Perspective 2:** PostgreSQL password defaults to 'postgres'. The postgres service is bound to localhost, but the default credentials are publicly known and would allow full database access if the port is reachable. **Perspective 3:** The PostgreSQL password defaults to 'postgres'. If not overridden, anyone who can reach the PostgreSQL port can read/write all Langfuse database data, including user accounts, API keys, and trace data.

**Perspective 1:** The root key file is created with open() using default permissions (typically 0644) before os.chmod(self.key_file, 0o600) is applied. This creates a race window where the file is world-readable, and if the process crashes between open() and chmod(), the root key remains exposed. An attacker with local filesystem access could read the root key and decrypt all account/file keys. **Perspective 2:** The LocalFileProvider writes the newly generated root key to disk using a non-atomic open/write pattern. If the process crashes mid-write, the key file may be truncated or corrupted, and on next startup the provider will fail to parse it, potentially leading to data loss or a new key being generated that invalidates all previously encrypted data. Additionally, the file content is not verified against a checksum on read, so tampering with the key file could go undetected. **Perspective 3:** The root key file is created with open(self.key_file, 'w') which uses the process umask (typically 0644), then chmod 0600 is applied afterward. There is a window where the file exists with world-readable permissions before the chmod executes. On a multi-user system, another process could read the root key during this window. This is a race condition on sensitive key material.

**Perspective 1:** When the role mapping source is 'fixed', the configured value is directly converted to a `Role` enum. If the configuration is attacker-controlled or misconfigured, this could assign an unintended role (e.g., ROOT) to a user, leading to privilege escalation. The configuration should validate that the fixed value is a legitimate role. **Perspective 2:** In `map_role`, when `role_config.source == 'fixed'`, the configured `value` is passed directly to `Role(role_config.value)`. If the config value is 'root' or 'admin', any user authenticating via this provider gets that role. While config is typically trusted, a misconfiguration or a shared config with an overly permissive fixed role grants all users elevated privileges. The value is not validated against a safe allow-list of roles.

When the role mapping source is a claim or attribute, the raw value is lowercased and directly converted to a `Role` enum. If an attacker can control the claim/attribute value (e.g., via a compromised OIDC provider or LDAP attribute), they could potentially assign themselves a higher-privilege role (e.g., 'root', 'admin') if the enum accepts those values. The mapping should be restricted to an explicit allowlist.

**Perspective 1:** When the role mapping source is 'group_membership', the configured group-to-role mapping is used to assign roles. If an attacker can control group membership (e.g., via a compromised LDAP or OIDC provider), they could be assigned a higher-privilege role if the group mapping is misconfigured. The mapping should be validated to ensure only legitimate roles are assigned. **Perspective 2:** In `map_role`, when `role_config.source == 'group_membership'`, the `group_mapping` dict maps group names to role strings, and the matched role string is passed directly to `Role(role_str)`. If the config maps a group to 'root' or 'admin', any user in that group gets elevated privileges. The group names come from the IdP (attacker-influenced if the IdP allows self-service group membership), and the role string is not validated against an allow-list.

The create_account endpoint accepts a caller-supplied `seed` parameter (CreateAccountRequest.seed) that is passed directly to manager.create_account. This allows a root user (or any caller able to reach this endpoint) to force a deterministic, predictable API key for a new account, undermining the security of the generated credential. The seed is attacker-controlled input entering the key-generation sink. This is a supply-chain integrity issue because the generated key is not derived from a secure random source, making it guessable and enabling unauthorized access to the new account.

The register_user endpoint accepts a caller-supplied `seed` parameter (RegisterUserRequest.seed) that is passed directly to manager.register_user. This allows an admin (or any caller able to reach this endpoint) to force a deterministic, predictable API key for a new user. The seed is attacker-controlled input entering the key-generation sink. This is a supply-chain integrity issue because the generated key is not derived from a secure random source, making it guessable and enabling unauthorized access to the new user's account.

**Perspective 1:** The regenerate_key endpoint accepts a caller-supplied `seed` parameter (RegenerateKeyRequest.seed) that is passed directly to manager.regenerate_key. This allows an admin (or any caller able to reach this endpoint) to force a deterministic, predictable API key for a user. The seed is attacker-controlled input entering the key-generation sink. This is a supply-chain integrity issue because the generated key is not derived from a secure random source, making it guessable and enabling unauthorized access to the user's account. **Perspective 2:** The `regenerate_key` endpoint accepts a caller-supplied `seed` in the request body. If the underlying key manager derives the API key from `sha256(user_id + "\0" + seed)`, an attacker who can reach this endpoint (requires admin/root) can set a known seed and predict the resulting API key. This allows an attacker to regenerate a victim user's key to a value they control, effectively taking over the account. The input is the `seed` field from the request body, reaching the `regenerate_key` sink.

The `/api/v1/debug/vector/scroll` endpoint is accessible to any authenticated user (only `get_request_context` dependency). It allows scrolling through vector records with an optional URI filter. While it uses a proxy for tenant isolation, the endpoint is a debug feature that should not be exposed to regular users in production, as it may bypass normal access control checks or expose internal data structures.

The `/api/v1/debug/vector/count` endpoint is accessible to any authenticated user. It allows counting vector records with an optional filter and URI. This debug endpoint should not be exposed to regular users in production, as it may reveal internal data distribution or bypass normal access controls.

The SemanticProcessor initializes a default RequestContext with Role.ROOT and uses it as a fallback whenever a message does not carry an explicit context (e.g. in _process_memory_directory when ctx is None). This means semantic processing of queue messages runs with ROOT privileges, bypassing normal ACL checks. If a queue message can be injected or its context fields manipulated, file reads/writes would occur with elevated privileges. The _ctx_from_semantic_msg method does derive context from the message, but the ROOT fallback is a privilege escalation risk.

The pydantic dependency is declared with only a minimum version constraint (>=2.0.0). This allows pip to install any future version, including a compromised or broken release. This is a supply-chain risk because the installed version is not deterministic and could introduce a vulnerability or malicious code.

The defusedxml dependency is declared with only a minimum version constraint (>=0.7.1). This allows pip to install any future version, including a compromised or broken release. This is a supply-chain risk because the installed version is not deterministic and could introduce a vulnerability or malicious code.

The volcengine dependency is declared with only a minimum version constraint (>=1.0.216). This allows pip to install any future version, including a compromised or broken release. This is a supply-chain risk because the installed version is not deterministic and could introduce a vulnerability or malicious code.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

**Perspective 1:** The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors. **Perspective 2:** In a Kubernetes (VKE) environment, the OpenSandbox server URL is hardcoded to plaintext HTTP (http://opensandbox-server:8080). The API key used to authenticate to this server is transmitted over an unencrypted connection, and the sandbox execution commands (which may contain sensitive data) are also sent in plaintext. An attacker with network access to the cluster could intercept these communications. **Perspective 3:** In Kubernetes/VKE environments the OpenSandbox server is contacted over plaintext HTTP (http://opensandbox-server:8080). The ConnectionConfig is built with this URL and no TLS verification is configured. An attacker able to intercept or spoof the in-cluster service (e.g., via DNS rebinding, a compromised sidecar, or a malicious pod) could impersonate the sandbox server and return arbitrary command output or accept malicious file writes. There is no certificate verification or integrity protection on the control channel.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

**Perspective 1:** The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors. **Perspective 2:** The HttpCollection client constructs all API endpoints using plaintext HTTP (e.g., http://host:port/CreateVikingdbCollection). This means all data transmitted to and from the vector database — including vector embeddings, search queries, and potentially sensitive metadata — is sent in cleartext. An attacker on the network path can intercept, modify, or inject data, compromising the integrity and confidentiality of the vector store. This is a supply chain integrity issue because the client cannot verify the authenticity of the server or the integrity of the data in transit. **Perspective 3:** The HttpCollection class and the get_or_create_http_collection function construct all API URLs using the `http://` scheme (e.g., line 56, 85, 110, 123, 137, 157, 174, 201, 232, 246, 264, 282, 300, 318, 353, 370, 397, 440, 484, 527, 570, 616, 658). All requests to the vector database service are sent in plaintext, allowing an on-path attacker to intercept or modify data, including vector embeddings and search queries/results. The default host is 127.0.0.1, but the code accepts arbitrary host/port parameters, so in a distributed deployment this could expose sensitive data over the network. **Perspective 4:** The HttpCollection client constructs all API URLs with the hardcoded `http://` scheme. When connecting to a remote VikingDB service, credentials and vector data are transmitted in plaintext, allowing interception or modification by a network attacker. This affects all operations in this file (create, list, update, drop, upsert, search, delete).

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

**Perspective 1:** The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors. **Perspective 2:** The setup wizard configures the Ollama embedding provider with an unencrypted http:// API base URL. If the server is accessed over a network (not just localhost), API requests and any credentials would be transmitted in plaintext, allowing interception.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

**Perspective 1:** The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors. **Perspective 2:** The 'baseURL' is set to localhost. This may cause links to not work if deployed. **Perspective 3:** When no api_base is configured for the ollama provider, the code defaults to 'http://localhost:11434/v1'. This sends embedding requests (including any content being embedded) over unencrypted HTTP. While localhost is typically trusted, if the service is bound to a non-loopback interface or accessed remotely, the data would be transmitted in cleartext. This is a default-insecure transport configuration.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

Global classes, methods, and variables should be avoided (especially in managed packages) as they can never be deleted or changed in signature. Always check twice if something needs to be global.

Global classes, methods, and variables should be avoided (especially in managed packages) as they can never be deleted or changed in signature. Always check twice if something needs to be global.

Global classes, methods, and variables should be avoided (especially in managed packages) as they can never be deleted or changed in signature. Always check twice if something needs to be global.

Global classes, methods, and variables should be avoided (especially in managed packages) as they can never be deleted or changed in signature. Always check twice if something needs to be global.

Global classes, methods, and variables should be avoided (especially in managed packages) as they can never be deleted or changed in signature. Always check twice if something needs to be global.

Global classes, methods, and variables should be avoided (especially in managed packages) as they can never be deleted or changed in signature. Always check twice if something needs to be global.

Global classes, methods, and variables should be avoided (especially in managed packages) as they can never be deleted or changed in signature. Always check twice if something needs to be global.

Global classes, methods, and variables should be avoided (especially in managed packages) as they can never be deleted or changed in signature. Always check twice if something needs to be global.

Global classes, methods, and variables should be avoided (especially in managed packages) as they can never be deleted or changed in signature. Always check twice if something needs to be global.

Global classes, methods, and variables should be avoided (especially in managed packages) as they can never be deleted or changed in signature. Always check twice if something needs to be global.

When a Session is created without an explicit RequestContext, it defaults to `Role.ROOT`. This means any code path that instantiates a Session without passing a context (e.g., internal services, background tasks, or misconfigured callers) will run with full ROOT privileges, bypassing any ACL or permission checks. This is an insecure default that could allow unauthorized access to session data or operations.

Global classes, methods, and variables should be avoided (especially in managed packages) as they can never be deleted or changed in signature. Always check twice if something needs to be global.

Global classes, methods, and variables should be avoided (especially in managed packages) as they can never be deleted or changed in signature. Always check twice if something needs to be global.