Dradis Community Edition Broken Access Control Leading to SSRF via AI Agent Provider Reconfiguration

Technical Analysis

The ProvidersController and AgentsController rely on `defined?(Dradis::Pro)` to gate their admin_required before_action, but since this constant only exists in the paid Pro edition, the check silently evaluates to false in Community Edition and the authorization filter never runs. A low-privileged authenticated user can exploit this to create a malicious AI provider record pointing at an internal or link-local address (e.g., 169.254.169.254) and reassign the Roslin AI agent to use it as its backend. When any user subsequently triggers an AI interaction, the Dradis server itself issues the HTTP request to the attacker-specified endpoint, and on non-2xx responses the raw response body is reflected to the attacker via ActionCable/Turbo Stream messages, turning a blind SSRF into a fully readable one capable of exfiltrating cloud instance credentials or probing internal network services.

Affected Systems

Dradis Community Edition

Detection Signatures

• Log entries showing AI Provider creation/update by non-admin user accounts
• Provider base_url fields pointing to internal/link-local IPs (169.254.169.254, 127.0.0.1, 10.x, 192.168.x, metadata.google.internal)
• Unexpected outbound HTTP requests from Dradis application server to non-allowlisted hosts
• ActionCable/Turbo Stream messages containing raw HTTP error bodies from unfamiliar hosts
• AgentsController PATCH/PUT requests reassigning Roslin agent's provider_id by unprivileged users

Remediation Steps

1. 1

   Patch to fixed Dradis CE release

   Upgrade to a version where admin_required authorization no longer depends on the undefined Dradis::Pro constant and is properly enforced in Community Edition.

2. 2

   Enforce authorization checks independent of edition flags

   Replace conditional gating like defined?(Dradis::Pro) with explicit role/permission checks that fail closed rather than silently skipping when the constant is undefined.

3. 3

   Restrict outbound requests from AI provider integrations

   Implement an egress allowlist or network policy that blocks the application server from reaching internal/link-local address ranges including cloud metadata IPs.

4. 4

   Sanitize error responses surfaced to clients

   Avoid reflecting raw upstream HTTP response bodies back to end users via ActionCable/Turbo Stream; log full details server-side only and return generic error messages to the client.

5. 5

   Audit AI provider and agent configuration changes

   Add logging and alerting for creation or modification of AI provider records and agent-provider reassignments, especially by non-admin accounts.