AI & LLM Vulnerabilities

PraisonAI's `praisonai serve` command accepts an `--api-key` flag for authentication, but the flag is parsed and never actually used to protect the server. The FastAPI application (a web framework for building APIs) is created without any authentication middleware (code that checks credentials before allowing access), leaving endpoints like `POST /agents` completely open to anyone, even though the help text promises the key would protect them. This affects version 4.6.50 and likely all versions since 4.6.34 when the serve system was introduced.

PraisonAI's `praisonai serve agents` command accepts an `--api-key` flag that claims to enable authentication, but the code that creates the HTTP server never actually uses this key. This means anyone on the network can invoke agents through the `POST /agents` and `POST /agents/{agent_name}` routes without providing any credentials, even though the operator thought they were securing the service. The problem is made worse because a working authentication function already exists in the same codebase (called `verify_token`, which guards other API routes), but it is simply not applied to these agent-invocation routes.

PraisonAI's workspace containment system, which is supposed to prevent agent tools from accessing files outside a designated directory, has three critical flaws. First, the `read_file`, `write_file`, `apply_diff`, and `search_replace` tools use `os.path.abspath()` instead of `realpath()` (a function that fully resolves symbolic links, or pointers to other files), allowing attackers to use symlinks inside the workspace to read or modify files outside it. Second, `list_files()` doesn't check containment at all, letting attackers escape using `../` path traversal (a technique where `../` moves up one directory level). Third, `execute_command()` doesn't validate the working directory, letting attackers run commands from outside the workspace.

The web_crawl tool in praisonaiagents has a security flaw where it validates a URL's hostname only once at the start, but then fetches the URL using a library that follows HTTP redirects and re-resolves the hostname without re-checking. An attacker can bypass this by either redirecting to an internal address (like a cloud metadata endpoint) or using DNS rebinding (changing what the hostname resolves to between validation and fetch) to trick the tool into reading private internal services and leaking sensitive data like credentials.

PraisonAI's `praisonai serve agents` command accepts an `--api-key` parameter to secure agent access, but the key is not actually enforced on the public endpoints (`POST /agents` and `POST /agents/{agent_name}`). This means anyone on the network can run agents without providing any credentials, even if the operator started the server with an API key. The vulnerability affects versions 4.6.34 through 4.6.48.

The praisonaiagents library has a security flaw in its SSRF (server-side request forgery, where an attacker tricks a server into making requests to internal systems) protection. The `_host_is_blocked()` function checks if hostnames are blocked, but it never performs DNS resolution (looking up what IP address a hostname points to). This means attackers can use services like `127.0.0.1.nip.io` (a public DNS service that resolves to the local machine) to bypass the protection and access internal services. The four tools `scrape_page`, `extract_links`, `crawl`, and `extract_text` are exposed as LLM-callable functions, so an AI agent can be tricked into making these malicious requests.

PraisonAI's workflow include feature automatically executes a `tools.py` file (a Python script that defines custom functions) from included recipes even when the security settings that should prevent this are turned off. This bypasses earlier security fixes and allows an attacker to run arbitrary code if they can trick a victim into using a workflow that includes an untrusted recipe directory.

The `web_crawl` tool in praisonaiagents only validates the initial URL's IP address against a blocklist of private/internal addresses, but then follows HTTP redirects without re-checking the redirect target's IP. An attacker can supply a public URL that redirects to an internal address (like cloud metadata services at 169.254.169.254 or localhost services), allowing the tool to fetch and leak internal data that should have been blocked by SSRF (server-side request forgery, where a tool fetches data from internal systems it shouldn't access) protection.

The Continue CLI (a tool for running AI agents from the command line) uses an incomplete blocklist as its only protection against destructive shell commands when running unattended, meaning it tries to block dangerous commands by listing which ones are unsafe rather than allowing only safe ones. An attacker can bypass this protection through prompt injection (tricking the AI by hiding malicious instructions in content like web pages or files the AI reads), allowing them to delete a user's data by using unblocked commands like recursive deletion of certain directories or tools like shred and wipefs.

Xinference (a model-serving tool) was loading AI models from Hugging Face with remote code execution (the ability to run code from external sources) always enabled before version 2.12.0, and users had no way to turn it off. An attacker who could register a new model could trick the system into running malicious code hidden in the model's configuration files, giving that code the same permissions as the server running Xinference.

Hydra's `instantiate()` function (which constructs objects and calls functions based on configuration files) can execute arbitrary code if an attacker controls the `_target_` field in untrusted config. This means if your application loads config from an untrusted source and passes it to `instantiate()`, an attacker can trick it into running malicious code.

Infracost, a tool that calculates cloud costs for engineering teams and AI systems, had a vulnerability before version 0.10.45 where it could accidentally send secret authentication tokens (credentials that prove who you are to Terraform Cloud services) to the wrong server. If an attacker controlled the Terraform configuration files being scanned, they could trick Infracost into sending the token to their own server instead of the legitimate one, allowing them to steal it. This happens in CI/CD pipelines (automated build and deployment systems) when a token is provided during scanning.

Infracost (a tool that calculates cloud costs) had a vulnerability before version 0.10.45 where certain file-reading functions didn't properly handle symlinks (shortcuts that point to other locations). An attacker could create a symlink in a repository that points outside the checked-out code, allowing the tool to read sensitive files that the system running Infracost could access, potentially exposing repository secrets through dashboards or pull request comments.