🔴 HIGH: Unauthenticated OpenAI Responses API with IDOR (CVSS 8.2) - GHSA-4p3r-2v29-452x

[jjasghar]

🔴 HIGH PRIORITY: Unauthenticated OpenAI Responses API with IDOR (CVSS 8.2) - GHSA-4p3r-2v29-452x

SECURITY ADVISORY STATUS: Triage (Not yet published - URGENT ACTION REQUIRED)
GHSA ID: GHSA-4p3r-2v29-452x
Severity: HIGH (CVSS 8.2)
Vulnerability Type: Authentication Bypass + Insecure Direct Object Reference (IDOR)

---

⚠️ CRITICAL: Production Deployment Risk

This vulnerability affects default configurations of beeai-framework Python OpenAI server deployments. Any instance exposing port 9999 (or custom port) to untrusted networks without explicitly setting an api_key is directly exploitable. The issue was reported June 17, 2026 (yesterday) and remains in triage.

Immediate action required for all production deployments!

---

Vulnerability Description

The OpenAIServer in beeai-framework Python binds to 0.0.0.0 with api_key=None by default, which:

1. Disables authentication entirely on the POST /responses endpoint
2. Allows any unauthenticated attacker who knows or guesses a conversation_id to:
   • Read complete conversation history (confidentiality breach)
   • Inject arbitrary messages into existing sessions (integrity compromise)
   • Exfiltrate sensitive data: prompts, PII, API keys, secrets from any active session
   • Poison agent memory via malicious message injection

Root Cause Analysis

# VULNERABLE DEFAULT CONFIGURATION:
OpenAIServer(
    host="0.0.0.0",  # Exposes to all network interfaces
    api_key=None,     # NO AUTHENTICATION REQUIRED!
    port=9998         # Default exposed port
)

This is a CWE-306: Missing Authentication for Critical Function combined with IDOR (CWE-639).

---

Attack Scenario

Step 1: Reconnaissance

Attacker scans for beeai-framework instances on common ports (9998, 9999, etc.) or discovers via documentation/examples.

Step 2: Enumerate Conversation IDs

# Guess or brute-force conversation IDs
for id in $(seq 1 100); do
  curl -X POST http://victim-host:9998/responses \
    -H "Content-Type: application/json" \
    -d '{"conversation_id": "'"$id"'", "messages": []}' \
    --silent | jq .;
done

Step 3: Exploit IDOR to Read/Inject

# Read entire conversation history (NO AUTHENTICATION!)
curl -X POST http://victim-host:9998/responses \
  -H "Content-Type: application/json" \
  -d '{
    "conversation_id": "KNOWN_ID_HERE",
    "messages": []
  }'

# Inject malicious messages into victim's session!
curl -X POST http://victim-host:9998/responses \
  -H "Content-Type: application/json" \
  -d '{
    "conversation_id": "KNOWN_ID_HERE", 
    "messages": [{
      "role": "user",
      "content": "Execute this malicious command..."
    }]
  }'

Impact Summary

• ✅ No authentication required (api_key=None by default)
• ✅ No user interaction needed
• ✅ Remote attack vector over HTTP
• ✅ Complete session compromise via IDOR
• ✅ Mass exfiltration possible with ID enumeration

---

Affected Versions

• beeai-framework Python ≤ 0.1.81 (all versions using default OpenAIServer configuration)
• Default configurations documented in official examples are vulnerable
• Any deployment that doesn't explicitly set api_key and restricts binding to localhost

---

Impact Assessment

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N (8.2 - High)

Confidentiality: HIGH

• Full conversation history exposure
• PII, secrets, API keys, prompts exfiltration
• Cross-session data leakage via IDOR

Integrity: LOW-MEDIUM

• Message injection possible
• Agent memory poisoning achievable
• Session manipulation potential

Availability: NONE (not directly affected)

Scope: CHANGED

• Attacker can access resources beyond their initial scope (other users' conversations)

---

Immediate Mitigation Steps

1. Emergency Configuration Hardening (CRITICAL)

Update all production deployments immediately:

# SECURE CONFIGURATION:
from beeai_framework.backends.openai import OpenAIServer

OpenAIServer(
    host="127.0.0.1",        # Bind ONLY to localhost!
    api_key="YOUR_SECURE_KEY",  # ALWAYS require authentication!
    port=9998,
    cors_origins=[]          # Restrict CORS if not needed externally
)

# If external access is REQUIRED:
OpenAIServer(
    host="0.0.0.0",          # External binding ONLY if absolutely necessary
    api_key=os.environ["BEEAI_API_KEY"],  # Load from secure environment variable!
    port=9998,
    cors_origins=["https://trusted-domain.com"]  # Strict CORS policy
)

2. Network-Level Protections

If you must expose the API externally:

• ✅ Enable firewall rules restricting access to known IPs
• ✅ Deploy behind reverse proxy with authentication (nginx + auth_request, OAuth, JWT)
• ✅ Implement rate limiting and IP whitelisting at load balancer
• ✅ Use VPC/private network isolation for agent deployments
• ✅ Never expose default port 9998/9999 publicly without validation

3. Immediate Audit Checklist

Check all environments running beeai-framework Python:

# Find vulnerable configurations:
grep -r "OpenAIServer" --include="*.py" | grep -v "api_key"
grep -r 'host="0.0.0.0"' --include="*.py" | grep OpenAI

# Check for exposed ports in production:
netstat -tlnp | grep -E "(9998|9999)"
lsof -i :9998,9999

# Review deployment configs:
find /etc /opt /var/www -name "*.py" -exec grep -l "beeai_framework" {} \; 2>/dev/null

4. Monitoring & Detection

Deploy alerts for:

• Unauthenticated requests to /responses endpoints
• Multiple conversation ID enumeration attempts
• Unexpected message injection patterns
• Cross-session data access anomalies

---

Remediation Priority

P0 - IMMEDIATE (Within 24 hours):

• Audit all production deployments of beeai-framework Python ≤ 0.1.81
• Enforce api_key requirement in all environments
• Restrict host binding to 127.0.0.1 for internal services
• Implement network-level access controls

P1 - WITHIN 48 HOURS:

• Deploy patched version when available from maintainers
• Rotate any potentially compromised conversation IDs or session tokens
• Review logs for exploitation attempts
• Update deployment documentation with security warnings

P2 - WITHIN 1 WEEK:

• Implement API gateway authentication layer
• Add monitoring and alerting for IDOR patterns
• Conduct security review of all agent deployments
• Update CI/CD pipelines to enforce secure defaults

---

Responsible Disclosure Timeline

• 2026-06-17: Vulnerability reported by security researcher via GitHub Security Advisory
• Current Status: Triage (not yet published)
• Action Required: Immediate patching before public CVE assignment

Note: The advisory is in triage, providing maintainers a window to develop and release a fix. However, given the default configuration exposure, urgent community awareness may be needed.

---

References

• GitHub Security Advisory: https://github.com/i-am-bee/beeai-framework/security/advisories/GHSA-4p3r-2v29-452x
• CWE-306: Missing Authentication for Critical Function
• CWE-639: Authorization Bypass Through User-Controlled Key (IDOR)
• OWASP API Security Top 10: API1:2023 Broken Object Level Authorization

---

Maintainer Notification & Request

This vulnerability has been automatically flagged for the following maintainers:

• @Tomas2D (Tomáš Dvořák)
• @xjacka (Lukáš Janeček)
• @ajbozarth (Alex Bozarth)

Please confirm receipt and provide:

1. Timeline for patch release addressing default api_key=None behavior
2. Emergency hotfix guidance for production deployments
3. Updated security documentation with secure defaults
4. Version pinning recommendations until fix is available

---

Classification

• Tags: security, high-priority, authentication-bypass, idor, "openai", "production-risk"
• Priority: 🔴🔴 HIGH - Production Deployment Risk (Default Config Vulnerable)
• Affected Component: Python OpenAIServer backend in beeai-framework
• Exploitation Status: Likely actively exploitable in default configurations

---

Additional Notes

Why This Is Critical Despite "High" CVSS:
While CVSS scores this as HIGH, the practical risk is elevated because:

1. Default documentation shows vulnerable configuration
2. No authentication by default violates security best practices
3. IDOR enables mass compromise with simple enumeration
4. Common deployment patterns expose services publicly

Recommendation: Treat as emergency even though advisory says "HIGH" due to widespread default exposure risk.

---

This issue was automatically generated from i-am-bee security monitoring. The vulnerability is tracked under GHSA-4p3r-2v29-452x and should be handled according to responsible disclosure guidelines.

[Tomas2D]

The secure-by-default hardening (loopback default + warning on unauthenticated non-loopback bind) landed in #1531. Remaining for the community: scope /responses conversation memory to the caller so conversation_id isn't an IDOR even among authenticated clients. Marking help wanted for that follow-up.

[dosubot]

Hi, @jjasghar. I'm Dosu, and I'm helping the beeai-framework team manage their backlog and am marking this issue as stale.

Recap

• The original concern was that the Python OpenAI server bound to 0.0.0.0 by default without an API key, leaving /responses unauthenticated and exposing conversation data to guessing, reading, injection, and memory poisoning.
• A secure-by-default fix has already landed in fix(adapters): default OpenAIServer to loopback and warn on unauthenticated bind (#1516) #1531: the server now defaults to loopback and warns when it is exposed on a non-loopback interface without authentication.
• The remaining follow-up is to scope /responses conversation memory to the caller so conversation_id cannot be used as an IDOR between authenticated clients.
• That follow-up work is still marked as help wanted and the issue remains unresolved.

Next Steps

• If this is still relevant on the latest version of beeai-framework, please comment here to keep the discussion open.
• Otherwise, this issue will be automatically closed in 7 days.

Thanks for your understanding and contribution.