Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

API response cwe.mitre.org

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

5964 vulnerabilities reference this CWE, most recent first.

GHSA-9XRJ-439H-62HG

Vulnerability from github – Published: 2022-05-17 01:38 – Updated: 2022-07-12 22:16
VLAI
Summary
Improper Authentication in Apache Tomcat
Details

The HTTP Digest Access Authentication implementation in Apache Tomcat 5.5.x before 5.5.36, 6.x before 6.0.36, and 7.x before 7.0.30 caches information about the authenticated user within the session state, which makes it easier for remote attackers to bypass authentication via vectors related to the session ID.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat-catalina"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.5.0"
            },
            {
              "fixed": "5.5.36"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat-catalina"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.0.36"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat-catalina"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.30"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2012-5886"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-12T22:16:12Z",
    "nvd_published_at": "2012-11-17T19:55:00Z",
    "severity": "MODERATE"
  },
  "details": "The HTTP Digest Access Authentication implementation in Apache Tomcat 5.5.x before 5.5.36, 6.x before 6.0.36, and 7.x before 7.0.30 caches information about the authenticated user within the session state, which makes it easier for remote attackers to bypass authentication via vectors related to the session ID.",
  "id": "GHSA-9xrj-439h-62hg",
  "modified": "2022-07-12T22:16:12Z",
  "published": "2022-05-17T01:38:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-5886"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/80407"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-updates/2012-12/msg00089.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-updates/2012-12/msg00090.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-updates/2013-01/msg00037.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2013-0623.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2013-0629.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2013-0631.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2013-0632.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2013-0640.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2013-0647.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2013-0648.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2013-0726.html"
    },
    {
      "type": "WEB",
      "url": "http://svn.apache.org/viewvc?view=revision\u0026revision=1377807"
    },
    {
      "type": "WEB",
      "url": "http://svn.apache.org/viewvc?view=revision\u0026revision=1380829"
    },
    {
      "type": "WEB",
      "url": "http://svn.apache.org/viewvc?view=revision\u0026revision=1392248"
    },
    {
      "type": "WEB",
      "url": "http://tomcat.apache.org/security-5.html"
    },
    {
      "type": "WEB",
      "url": "http://tomcat.apache.org/security-6.html"
    },
    {
      "type": "WEB",
      "url": "http://tomcat.apache.org/security-7.html"
    },
    {
      "type": "WEB",
      "url": "http://www-01.ibm.com/support/docview.wss?uid=swg21626891"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-1637-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Improper Authentication in Apache Tomcat"
}

GHSA-9XX5-CV6J-X533

Vulnerability from github – Published: 2026-04-29 21:58 – Updated: 2026-05-08 20:14
VLAI
Summary
Admidio: OIDC Token Introspection Endpoint Returns Active for All Tokens Without Validation
Details

Summary

The OIDC token introspection endpoint (/modules/sso/index.php/oidc/introspect) always returns {"active": true} for every request, regardless of whether a valid token is provided, whether the token is expired, revoked, or completely fabricated. The endpoint performs no authentication of the calling resource server and no validation of the submitted token. Any resource server that relies on this introspection endpoint to validate access tokens will accept all requests as authorized, enabling complete authentication bypass.

Additionally, the OIDC token revocation endpoint (/oidc/revoke) returns {"revoked": true} without actually revoking any token, preventing resource servers from invalidating compromised credentials.

Details

The vulnerability is in src/SSO/Service/OIDCService.php, lines 604-619:

public function handleIntrospectionRequest() {
    // TODO_RK
    if (!$this->isServiceSetup) {
        $this->setupService();
    }
    return new JsonResponse(["active" => true]);
}

public function handleRevocationRequest() {
    // TODO_RK
    if (!$this->isServiceSetup) {
        $this->setupService();
    }

    return new JsonResponse(["revoked" => true]);
}

The introspection endpoint is routed at modules/sso/index.php, line 58-59:

} elseif (strpos($requestUri, '/oidc/introspect') !== false) {
    $response = $oidcService->handleIntrospectionRequest();

The router comment at line 35 says "Login checks will be done in the individual endpoint handler functions!" but neither handleIntrospectionRequest nor handleRevocationRequest perform any authentication or authorization checks.

Per RFC 7662 (OAuth 2.0 Token Introspection), the introspection endpoint: 1. MUST authenticate the calling resource server (Section 2.1) 2. MUST validate the submitted token against its database 3. MUST return {"active": false} for invalid, expired, or revoked tokens

The current implementation violates all three requirements.

Attack flow: 1. Attacker obtains a resource server's endpoint URL that uses Admidio as its OIDC provider 2. Attacker crafts any arbitrary string as a Bearer token 3. Resource server sends the fabricated token to /oidc/introspect for validation 4. Admidio returns {"active": true} without any checks 5. Resource server accepts the fabricated token as valid and grants access

The revocation bypass compounds this: If a legitimate token is stolen, the resource server or client application cannot revoke it. Calling /oidc/revoke returns success without actually revoking the token in the database, so the stolen token remains usable indefinitely (until its expiry time).

PoC

# Step 1: Confirm the introspection endpoint exists and always returns active
# No valid token needed - any string works
curl -X POST https://TARGET/modules/sso/index.php/oidc/introspect \
  -d "token=COMPLETELY_FABRICATED_TOKEN_12345"

# Expected response: {"active":true}

# Step 2: Try with an empty token
curl -X POST https://TARGET/modules/sso/index.php/oidc/introspect \
  -d "token="

# Expected response: {"active":true}

# Step 3: Demonstrate that revocation is also broken
curl -X POST https://TARGET/modules/sso/index.php/oidc/revoke \
  -d "token=any_valid_token_here"

# Expected response: {"revoked":true}
# But the token is NOT actually revoked in the database

# Step 4: Verify the token is still active after "revocation"
curl -X POST https://TARGET/modules/sso/index.php/oidc/introspect \
  -d "token=any_valid_token_here"

# Still returns: {"active":true}

Impact

  • Authentication Bypass on Resource Servers: Any application (wiki, CMS, project management tool, etc.) configured to validate tokens against this Admidio OIDC introspection endpoint will accept completely fabricated tokens. An attacker can impersonate any user on all connected resource servers.
  • Inability to Revoke Compromised Tokens: If a legitimate access token is leaked or stolen, there is no way to revoke it through the standard OIDC revocation flow. The token remains valid until its 1-hour expiry.
  • Scope Change (S:C): The vulnerability in the Admidio authorization server directly impacts the security of all connected resource servers (different security authority), which is why the CVSS scope is Changed.

Recommended Fix

Replace the stub implementations with proper token introspection and revocation logic:

public function handleIntrospectionRequest() {
    if (!$this->isServiceSetup) {
        $this->setupService();
    }

    $request = $this->getRequest();

    // 1. Authenticate the resource server (RFC 7662 Section 2.1)
    // The resource server MUST authenticate using client credentials
    $clientId = $request->getParsedBody()['client_id'] ?? null;
    $clientSecret = $request->getParsedBody()['client_secret'] ?? null;

    if (!$clientId || !$this->clientRepository->validateClient($clientId, $clientSecret, null)) {
        return new JsonResponse(['error' => 'invalid_client'], 401);
    }

    // 2. Get and validate the token
    $tokenValue = $request->getParsedBody()['token'] ?? '';
    if (empty($tokenValue)) {
        return new JsonResponse(['active' => false]);
    }

    try {
        // Validate the token using the resource server
        $validatedRequest = $this->resourceServer->validateAuthenticatedRequest(
            $request->withHeader('Authorization', 'Bearer ' . $tokenValue)
        );

        $tokenId = $validatedRequest->getAttribute('oauth_access_token_id');

        // Check if token is revoked
        if ($this->accessTokenRepository->isAccessTokenRevoked($tokenId)) {
            return new JsonResponse(['active' => false]);
        }

        $token = $this->accessTokenRepository->getToken($tokenId);

        // Check expiry
        if ($token->getExpiryDateTime() < new \DateTimeImmutable()) {
            return new JsonResponse(['active' => false]);
        }

        return new JsonResponse([
            'active' => true,
            'sub' => $token->getUserIdentifier(),
            'client_id' => $token->getClient()->getIdentifier(),
            'exp' => $token->getExpiryDateTime()->getTimestamp(),
            'scope' => implode(' ', array_map(fn($s) => $s->getIdentifier(), $token->getScopes())),
        ]);
    } catch (\Exception $e) {
        return new JsonResponse(['active' => false]);
    }
}

public function handleRevocationRequest() {
    if (!$this->isServiceSetup) {
        $this->setupService();
    }

    $request = $this->getRequest();

    // Authenticate the client
    $clientId = $request->getParsedBody()['client_id'] ?? null;
    $clientSecret = $request->getParsedBody()['client_secret'] ?? null;

    if (!$clientId || !$this->clientRepository->validateClient($clientId, $clientSecret, null)) {
        return new JsonResponse(['error' => 'invalid_client'], 401);
    }

    $tokenValue = $request->getParsedBody()['token'] ?? '';
    if (!empty($tokenValue)) {
        try {
            $validatedRequest = $this->resourceServer->validateAuthenticatedRequest(
                $request->withHeader('Authorization', 'Bearer ' . $tokenValue)
            );
            $tokenId = $validatedRequest->getAttribute('oauth_access_token_id');
            $this->accessTokenRepository->revokeAccessToken($tokenId);
        } catch (\Exception $e) {
            // RFC 7009: The server responds with HTTP 200 even for invalid tokens
        }
    }

    return new JsonResponse([], 200);
}
Severity
6.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.0.8"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "admidio/admidio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41671"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-29T21:58:56Z",
    "nvd_published_at": "2026-05-07T04:16:32Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe OIDC token introspection endpoint (`/modules/sso/index.php/oidc/introspect`) always returns `{\"active\": true}` for every request, regardless of whether a valid token is provided, whether the token is expired, revoked, or completely fabricated. The endpoint performs no authentication of the calling resource server and no validation of the submitted token. Any resource server that relies on this introspection endpoint to validate access tokens will accept all requests as authorized, enabling complete authentication bypass.\n\nAdditionally, the OIDC token revocation endpoint (`/oidc/revoke`) returns `{\"revoked\": true}` without actually revoking any token, preventing resource servers from invalidating compromised credentials.\n\n## Details\n\nThe vulnerability is in `src/SSO/Service/OIDCService.php`, lines 604-619:\n\n```php\npublic function handleIntrospectionRequest() {\n    // TODO_RK\n    if (!$this-\u003eisServiceSetup) {\n        $this-\u003esetupService();\n    }\n    return new JsonResponse([\"active\" =\u003e true]);\n}\n\npublic function handleRevocationRequest() {\n    // TODO_RK\n    if (!$this-\u003eisServiceSetup) {\n        $this-\u003esetupService();\n    }\n\n    return new JsonResponse([\"revoked\" =\u003e true]);\n}\n```\n\nThe introspection endpoint is routed at `modules/sso/index.php`, line 58-59:\n\n```php\n} elseif (strpos($requestUri, \u0027/oidc/introspect\u0027) !== false) {\n    $response = $oidcService-\u003ehandleIntrospectionRequest();\n```\n\nThe router comment at line 35 says \"Login checks will be done in the individual endpoint handler functions!\" but neither `handleIntrospectionRequest` nor `handleRevocationRequest` perform any authentication or authorization checks.\n\nPer RFC 7662 (OAuth 2.0 Token Introspection), the introspection endpoint:\n1. MUST authenticate the calling resource server (Section 2.1)\n2. MUST validate the submitted token against its database\n3. MUST return `{\"active\": false}` for invalid, expired, or revoked tokens\n\nThe current implementation violates all three requirements.\n\n**Attack flow:**\n1. Attacker obtains a resource server\u0027s endpoint URL that uses Admidio as its OIDC provider\n2. Attacker crafts any arbitrary string as a Bearer token\n3. Resource server sends the fabricated token to `/oidc/introspect` for validation\n4. Admidio returns `{\"active\": true}` without any checks\n5. Resource server accepts the fabricated token as valid and grants access\n\n**The revocation bypass compounds this:** If a legitimate token is stolen, the resource server or client application cannot revoke it. Calling `/oidc/revoke` returns success without actually revoking the token in the database, so the stolen token remains usable indefinitely (until its expiry time).\n\n## PoC\n\n```bash\n# Step 1: Confirm the introspection endpoint exists and always returns active\n# No valid token needed - any string works\ncurl -X POST https://TARGET/modules/sso/index.php/oidc/introspect \\\n  -d \"token=COMPLETELY_FABRICATED_TOKEN_12345\"\n\n# Expected response: {\"active\":true}\n\n# Step 2: Try with an empty token\ncurl -X POST https://TARGET/modules/sso/index.php/oidc/introspect \\\n  -d \"token=\"\n\n# Expected response: {\"active\":true}\n\n# Step 3: Demonstrate that revocation is also broken\ncurl -X POST https://TARGET/modules/sso/index.php/oidc/revoke \\\n  -d \"token=any_valid_token_here\"\n\n# Expected response: {\"revoked\":true}\n# But the token is NOT actually revoked in the database\n\n# Step 4: Verify the token is still active after \"revocation\"\ncurl -X POST https://TARGET/modules/sso/index.php/oidc/introspect \\\n  -d \"token=any_valid_token_here\"\n\n# Still returns: {\"active\":true}\n```\n\n## Impact\n\n- **Authentication Bypass on Resource Servers**: Any application (wiki, CMS, project management tool, etc.) configured to validate tokens against this Admidio OIDC introspection endpoint will accept completely fabricated tokens. An attacker can impersonate any user on all connected resource servers.\n- **Inability to Revoke Compromised Tokens**: If a legitimate access token is leaked or stolen, there is no way to revoke it through the standard OIDC revocation flow. The token remains valid until its 1-hour expiry.\n- **Scope Change (S:C)**: The vulnerability in the Admidio authorization server directly impacts the security of all connected resource servers (different security authority), which is why the CVSS scope is Changed.\n\n## Recommended Fix\n\nReplace the stub implementations with proper token introspection and revocation logic:\n\n```php\npublic function handleIntrospectionRequest() {\n    if (!$this-\u003eisServiceSetup) {\n        $this-\u003esetupService();\n    }\n    \n    $request = $this-\u003egetRequest();\n    \n    // 1. Authenticate the resource server (RFC 7662 Section 2.1)\n    // The resource server MUST authenticate using client credentials\n    $clientId = $request-\u003egetParsedBody()[\u0027client_id\u0027] ?? null;\n    $clientSecret = $request-\u003egetParsedBody()[\u0027client_secret\u0027] ?? null;\n    \n    if (!$clientId || !$this-\u003eclientRepository-\u003evalidateClient($clientId, $clientSecret, null)) {\n        return new JsonResponse([\u0027error\u0027 =\u003e \u0027invalid_client\u0027], 401);\n    }\n    \n    // 2. Get and validate the token\n    $tokenValue = $request-\u003egetParsedBody()[\u0027token\u0027] ?? \u0027\u0027;\n    if (empty($tokenValue)) {\n        return new JsonResponse([\u0027active\u0027 =\u003e false]);\n    }\n    \n    try {\n        // Validate the token using the resource server\n        $validatedRequest = $this-\u003eresourceServer-\u003evalidateAuthenticatedRequest(\n            $request-\u003ewithHeader(\u0027Authorization\u0027, \u0027Bearer \u0027 . $tokenValue)\n        );\n        \n        $tokenId = $validatedRequest-\u003egetAttribute(\u0027oauth_access_token_id\u0027);\n        \n        // Check if token is revoked\n        if ($this-\u003eaccessTokenRepository-\u003eisAccessTokenRevoked($tokenId)) {\n            return new JsonResponse([\u0027active\u0027 =\u003e false]);\n        }\n        \n        $token = $this-\u003eaccessTokenRepository-\u003egetToken($tokenId);\n        \n        // Check expiry\n        if ($token-\u003egetExpiryDateTime() \u003c new \\DateTimeImmutable()) {\n            return new JsonResponse([\u0027active\u0027 =\u003e false]);\n        }\n        \n        return new JsonResponse([\n            \u0027active\u0027 =\u003e true,\n            \u0027sub\u0027 =\u003e $token-\u003egetUserIdentifier(),\n            \u0027client_id\u0027 =\u003e $token-\u003egetClient()-\u003egetIdentifier(),\n            \u0027exp\u0027 =\u003e $token-\u003egetExpiryDateTime()-\u003egetTimestamp(),\n            \u0027scope\u0027 =\u003e implode(\u0027 \u0027, array_map(fn($s) =\u003e $s-\u003egetIdentifier(), $token-\u003egetScopes())),\n        ]);\n    } catch (\\Exception $e) {\n        return new JsonResponse([\u0027active\u0027 =\u003e false]);\n    }\n}\n\npublic function handleRevocationRequest() {\n    if (!$this-\u003eisServiceSetup) {\n        $this-\u003esetupService();\n    }\n    \n    $request = $this-\u003egetRequest();\n    \n    // Authenticate the client\n    $clientId = $request-\u003egetParsedBody()[\u0027client_id\u0027] ?? null;\n    $clientSecret = $request-\u003egetParsedBody()[\u0027client_secret\u0027] ?? null;\n    \n    if (!$clientId || !$this-\u003eclientRepository-\u003evalidateClient($clientId, $clientSecret, null)) {\n        return new JsonResponse([\u0027error\u0027 =\u003e \u0027invalid_client\u0027], 401);\n    }\n    \n    $tokenValue = $request-\u003egetParsedBody()[\u0027token\u0027] ?? \u0027\u0027;\n    if (!empty($tokenValue)) {\n        try {\n            $validatedRequest = $this-\u003eresourceServer-\u003evalidateAuthenticatedRequest(\n                $request-\u003ewithHeader(\u0027Authorization\u0027, \u0027Bearer \u0027 . $tokenValue)\n            );\n            $tokenId = $validatedRequest-\u003egetAttribute(\u0027oauth_access_token_id\u0027);\n            $this-\u003eaccessTokenRepository-\u003erevokeAccessToken($tokenId);\n        } catch (\\Exception $e) {\n            // RFC 7009: The server responds with HTTP 200 even for invalid tokens\n        }\n    }\n    \n    return new JsonResponse([], 200);\n}\n```",
  "id": "GHSA-9xx5-cv6j-x533",
  "modified": "2026-05-08T20:14:32Z",
  "published": "2026-04-29T21:58:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Admidio/admidio/security/advisories/GHSA-9xx5-cv6j-x533"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41671"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Admidio/admidio"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Admidio/admidio/releases/tag/v5.0.9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Admidio: OIDC Token Introspection Endpoint Returns Active for All Tokens Without Validation"
}

GHSA-C22H-WWM4-7X2J

Vulnerability from github – Published: 2025-09-29 21:30 – Updated: 2025-11-11 21:30
VLAI
Details

Trivision NC-227WF firmware 5.80 (build 20141010) login mechanism reveals whether a username exists or not by returning different error messages ("Unknown user" vs. "Wrong password"), allowing an attacker to enumerate valid usernames.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-56764"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-204",
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-29T20:15:33Z",
    "severity": "MODERATE"
  },
  "details": "Trivision NC-227WF firmware 5.80 (build 20141010) login mechanism reveals whether a username exists or not by returning different error messages (\"Unknown user\" vs. \"Wrong password\"), allowing an attacker to enumerate valid usernames.",
  "id": "GHSA-c22h-wwm4-7x2j",
  "modified": "2025-11-11T21:30:27Z",
  "published": "2025-09-29T21:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-56764"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Remenis/CVE-2025-56764"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Remenis/CVE-2025-56764-trivision-nc227wf"
    }
  ],
  "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"
    }
  ]
}

GHSA-C246-VH69-9F94

Vulnerability from github – Published: 2022-04-29 03:02 – Updated: 2022-04-29 03:02
VLAI
Details

Polar HelpDesk 3.0 allows remote attackers to bypass authentication by setting the UserId and UserType values in a cookie.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2004-2736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2004-12-31T05:00:00Z",
    "severity": "MODERATE"
  },
  "details": "Polar HelpDesk 3.0 allows remote attackers to bypass authentication by setting the UserId and UserType values in a cookie.",
  "id": "GHSA-c246-vh69-9f94",
  "modified": "2022-04-29T03:02:00Z",
  "published": "2022-04-29T03:02:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2004-2736"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/16778"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/12120"
    },
    {
      "type": "WEB",
      "url": "http://www.osvdb.org/8168"
    },
    {
      "type": "WEB",
      "url": "http://www.securiteam.com/windowsntfocus/5OP0K0ADGA.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/10775"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-C27R-X354-4M68

Vulnerability from github – Published: 2020-10-27 20:39 – Updated: 2022-08-02 20:03
VLAI
Summary
xml-crypto's HMAC-SHA1 signatures can bypass validation via key confusion
Details

Impact

An attacker can inject an HMAC-SHA1 signature that is valid using only knowledge of the RSA public key. This allows bypassing signature validation.

Patches

Version 2.0.0 has the fix.

Workarounds

The recommendation is to upgrade. In case that is not possible remove the 'http://www.w3.org/2000/09/xmldsig#hmac-sha1' entry from SignedXml.SignatureAlgorithms.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.5.3"
      },
      "package": {
        "ecosystem": "npm",
        "name": "xml-crypto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-10-27T20:35:52Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nAn attacker can inject an HMAC-SHA1 signature that is valid using only knowledge of the RSA public key. This allows bypassing signature validation.\n\n### Patches\nVersion 2.0.0 has the fix.\n\n### Workarounds\nThe recommendation is to upgrade. In case that is not possible remove the \u0027http://www.w3.org/2000/09/xmldsig#hmac-sha1\u0027 entry from SignedXml.SignatureAlgorithms.",
  "id": "GHSA-c27r-x354-4m68",
  "modified": "2022-08-02T20:03:05Z",
  "published": "2020-10-27T20:39:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/yaronn/xml-crypto/security/advisories/GHSA-c27r-x354-4m68"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yaronn/xml-crypto/commit/3d9db712e6232c765cd2ad6bd2902b88a0d22100"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/yaronn/xml-crypto"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/xml-crypto"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "xml-crypto\u0027s HMAC-SHA1 signatures can bypass validation via key confusion"
}

GHSA-C2F3-QM3G-QJ54

Vulnerability from github – Published: 2022-05-05 00:29 – Updated: 2024-04-03 23:58
VLAI
Details

TRENDnet TS-S402 has a backdoor to enable TELNET.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2013-6360"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-02-13T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "TRENDnet TS-S402 has a backdoor to enable TELNET.",
  "id": "GHSA-c2f3-qm3g-qj54",
  "modified": "2024-04-03T23:58:11Z",
  "published": "2022-05-05T00:29:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-6360"
    },
    {
      "type": "WEB",
      "url": "http://firmware.re/usenixsec14"
    },
    {
      "type": "WEB",
      "url": "http://firmware.re/vulns/acsa-2013-014.php"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C2FG-VQVF-QQCJ

Vulnerability from github – Published: 2024-08-08 12:30 – Updated: 2024-08-08 12:30
VLAI
Details

Vulnerability of PIN enhancement failures in the screen lock module Impact: Successful exploitation of this vulnerability may affect service confidentiality, integrity, and availability.

Severity
8.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-42038"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-08T10:15:08Z",
    "severity": "HIGH"
  },
  "details": "Vulnerability of PIN enhancement failures in the screen lock module\nImpact: Successful exploitation of this vulnerability may affect service confidentiality, integrity, and availability.",
  "id": "GHSA-c2fg-vqvf-qqcj",
  "modified": "2024-08-08T12:30:34Z",
  "published": "2024-08-08T12:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42038"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2024/8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C2HR-6QHM-XV9R

Vulnerability from github – Published: 2024-10-24 21:31 – Updated: 2024-10-30 15:30
VLAI
Details

In WhatsUp Gold versions released before 2024.0.0, 

an Authentication Bypass issue exists which allows an attacker to obtain encrypted user credentials.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-7763"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-24T21:15:15Z",
    "severity": "CRITICAL"
  },
  "details": "In WhatsUp Gold versions released before 2024.0.0,\u00a0\n\nan Authentication Bypass issue exists which allows an attacker to obtain encrypted user credentials.",
  "id": "GHSA-c2hr-6qhm-xv9r",
  "modified": "2024-10-30T15:30:45Z",
  "published": "2024-10-24T21:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7763"
    },
    {
      "type": "WEB",
      "url": "https://community.progress.com/s/article/WhatsUp-Gold-Security-Bulletin-August-2024"
    },
    {
      "type": "WEB",
      "url": "https://www.progress.com/network-monitoring"
    }
  ],
  "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-C2JP-C369-7PVX

Vulnerability from github – Published: 2025-10-29 15:38 – Updated: 2026-01-21 21:56
VLAI
Summary
FastMCP Auth Integration Allows for Confused Deputy Account Takeover
Details

Summary

FastMCP documentation covers the scenario where it is possible to use Entra ID or other providers for authentication. In this context, because Entra ID does not support Dynamic Client Registration (DCR), the FastMCP-hosted MCP server is acting as the authorization provider, as declared in the Protected Resource Metadata (PRM) document hosted on the server.

For example, on a local MCP server, it may be hosted here:

http://localhost:8000/.well-known/oauth-protected-resource

And the JSON representation of the PRM document:

{
  "resource": "http://localhost:8000/mcp",
  "authorization_servers": [
    "http://localhost:8000/"
  ],
  "scopes_supported": [
    "User.Read",
    "email",
    "openid",
    "profile"
  ],
  "bearer_methods_supported": [
    "header"
  ]
}

Notice that the authorization_servers field contains the MCP server itself - it acts as an OAuth Client to the downstream authorization server (e.g., Entra ID) and as a Authorization Server (AS) to the MCP client.

The FastMCP server also hosts the AS metadata:

http://localhost:8000/.well-known/oauth-authorization-server

With the following content:

{
  "issuer": "http://localhost:8000/",
  "authorization_endpoint": "http://localhost:8000/authorize",
  "token_endpoint": "http://localhost:8000/token",
  "registration_endpoint": "http://localhost:8000/register",
  "scopes_supported": [
    "User.Read",
    "email",
    "openid",
    "profile"
  ],
  "response_types_supported": [
    "code"
  ],
  "grant_types_supported": [
    "authorization_code",
    "refresh_token"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_post"
  ],
  "code_challenge_methods_supported": [
    "S256"
  ]
}

All of this confirms that the FastMCP server is, in fact, handling the client-to-server authorization and then delegating the downstream effects (i.e., authorization with Entra ID) to its own redirect logic, with a call like this (as seen through MCP Inspector):

http://localhost:8000/authorize?response_type=code&client_id=fdec0bb8-3423-40d0-aa2a-73de26bf6f93&code_challenge=2a9ZxAEr5NEsKPwFWuEFA1W-kFMXc-02u6qc8aLf_g4&code_challenge_method=S256&redirect_uri=http%3A%2F%2Flocalhost%3A6274%2Foauth%2Fcallback%2Fdebug&state=9f23fd47e2b8786b502f116bdbfd6ae3d7d2801167e24fea82f608bb52312bbd&scope=User.Read+email+openid+profile&resource=http%3A%2F%2Flocalhost%3A8000%2Fmcp

When using the built-in FastMCP /authorize endpoint, and in the example above, FastMCP server configured with Entra ID, it will then redirect the user here:

https://login.microsoftonline.com/412e93fe-74e5-4ee6-9b67-1eeb1c79550e/oauth2/v2.0/authorize?response_type=code&client_id=7bac43f2-ca62-4148-93a5-fd5686cb16c0&redirect_uri=http%3A%2F%2Flocalhost%3A8000%2Fauth%2Fcallback&state=Tcv7bbg_v0Qi69RHbCzqR4tQHSHKPQuDDxjuo0wu5qU&scope=User.Read+email+openid+profile&code_challenge=bxICFAJDViuTTHIPUPdSXGLKbNbgPwiB-0ITXUJkjYM&code_challenge_method=S256&resource=http%3A%2F%2Flocalhost%3A8000%2Fmcp

[!NOTE] In the scenario above, the app registration in Entra ID is set up in the FastMCP server, as outlined in the PoC below.

image

Notice that the client ID and redirect URIs in the login.microsoftonline.com call are different than the initial /authorize call - that's because we're now switching to using the MCP server's static app registration instead of the DCR client details.

Completing the authorization flow here for the first time for a user would trigger the Entra ID consent flow:

image

This consent flow is only showed the first time the user needs to use this application. Once the consent is set, they will never be prompted for this unless revoked.

This is where the vulnerability comes in. After the user consented and is authorized, Entra ID will set a browser cookie capturing the authorization state. This helps prevent nagging re-authorization prompts.

With the user consented to the static client for Entra ID that the FastMCP server exposes, they will now not be prompted the next time they need to use the same application ID.

Now, an attacker comes in - in their own MCP client (i.e., they maintain one at https://evil.example.com) they start the authorization with the same remote MCP server and get to the point where the server produces their own authorization URI for this client ID:

http://localhost:8000/authorize?response_type=code&client_id=9a5d63d0-3aa3-465c-b097-0e2e196392dd&code_challenge=2F4Lbfppwd7xuynLT1y4Cy2Dac-S6HOO2B84itAwppw&code_challenge_method=S256&redirect_uri=https%3A%2F%2Fevil.example.com%3A6274%2Foauth%2Fcallback%2Fdebug&state=221fab2ccdc1481511639c110ee7382445930e22be25396b01f32d973d7176dc&scope=User.Read+email+openid+profile&resource=http%3A%2F%2Flocalhost%3A8000%2Fmcp

[!IMPORTANT] Note that the redirect URI above points to the https://evil.example.com client.

At this point - they grab the URL and coerce the victim (user that already authenticated with Entra ID on their machine) to click on this link. This could be done through spam, spear-phishing, or any other traditional link sharing approaches. The moment the victim clicks on this link, they will be taken to the browser, where there is already a cookie set by Entra ID for the static Entra ID client that the MCP server is using. The DCR-d registered client ID that the FastMCP server is handling now got linked to the internal FastMCP authorization server, and the authorization code is returned to https://evil.example.com.

The user will be automatically speed-ran through the authorization flow (no prompts) and they will effectively give access to the MCP server to the attacker with their account. Attacker can now exchange the authorization code for a token and access the remote MCP server as the victim.

Details

See above - the outline covers the attack vector.

PoC

Standard documented sample that uses Entra ID:

from fastmcp import FastMCP
from fastmcp.server.auth.providers.azure import AzureProvider

# The AzureProvider handles Azure's token format and validation
auth_provider = AzureProvider(
    client_id="f527ed01-9725-45bd-8173-8d3a017ba02f",  # Your Azure App Client ID
    client_secret="#####~######_#######",                 # Your Azure App Client Secret
    tenant_id="412e93fe-74e5-4ee6-9b67-1eeb1c79550e", # Your Azure Tenant ID (REQUIRED)
    base_url="http://localhost:8000",                   # Must match your App registration
    required_scopes=["User.Read", "email", "openid", "profile"],  # Microsoft Graph permissions
    # redirect_path="/auth/callback"                  # Default value, customize if needed
)

mcp = FastMCP(name="Azure Secured App", auth=auth_provider)

# Add a protected tool to test authentication
@mcp.tool
async def get_user_info() -> dict:
    """Returns information about the authenticated Azure user."""
    from fastmcp.server.dependencies import get_access_token

    token = get_access_token()
    # The AzureProvider stores user data in token claims
    return {
        "azure_id": token.claims.get("sub"),
        "email": token.claims.get("email"),
        "name": token.claims.get("name"),
        "job_title": token.claims.get("job_title"),
        "office_location": token.claims.get("office_location")
    }

Impact

Potential for server account compromise.

Severity
7.3 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "fastmcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.13.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-29T15:38:07Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nFastMCP documentation [covers the scenario](https://gofastmcp.com/integrations/azure) where it is possible to use Entra ID or other providers for authentication. In this context, because Entra ID does not support Dynamic Client Registration (DCR), the FastMCP-hosted MCP server is acting as the authorization provider, as declared in the Protected Resource Metadata (PRM) document hosted on the server.\n\nFor example, on a local MCP server, it may be hosted here:\n\n```http\nhttp://localhost:8000/.well-known/oauth-protected-resource\n```\n\nAnd the JSON representation of the PRM document:\n\n```json\n{\n  \"resource\": \"http://localhost:8000/mcp\",\n  \"authorization_servers\": [\n    \"http://localhost:8000/\"\n  ],\n  \"scopes_supported\": [\n    \"User.Read\",\n    \"email\",\n    \"openid\",\n    \"profile\"\n  ],\n  \"bearer_methods_supported\": [\n    \"header\"\n  ]\n}\n```\n\nNotice that the `authorization_servers` field contains the MCP server itself - it acts as an **OAuth Client** to the downstream authorization server (e.g., Entra ID) and as a **Authorization Server** (AS) to the MCP client.\n\nThe FastMCP server also hosts the AS metadata:\n\n```bash\nhttp://localhost:8000/.well-known/oauth-authorization-server\n```\n\nWith the following content:\n\n```json\n{\n  \"issuer\": \"http://localhost:8000/\",\n  \"authorization_endpoint\": \"http://localhost:8000/authorize\",\n  \"token_endpoint\": \"http://localhost:8000/token\",\n  \"registration_endpoint\": \"http://localhost:8000/register\",\n  \"scopes_supported\": [\n    \"User.Read\",\n    \"email\",\n    \"openid\",\n    \"profile\"\n  ],\n  \"response_types_supported\": [\n    \"code\"\n  ],\n  \"grant_types_supported\": [\n    \"authorization_code\",\n    \"refresh_token\"\n  ],\n  \"token_endpoint_auth_methods_supported\": [\n    \"client_secret_post\"\n  ],\n  \"code_challenge_methods_supported\": [\n    \"S256\"\n  ]\n}\n```\n\nAll of this confirms that the FastMCP server is, in fact, handling the client-to-server authorization and then delegating the downstream effects (i.e., authorization with Entra ID) to its own redirect logic, with a call like this (as seen through MCP Inspector):\n\n```http\nhttp://localhost:8000/authorize?response_type=code\u0026client_id=fdec0bb8-3423-40d0-aa2a-73de26bf6f93\u0026code_challenge=2a9ZxAEr5NEsKPwFWuEFA1W-kFMXc-02u6qc8aLf_g4\u0026code_challenge_method=S256\u0026redirect_uri=http%3A%2F%2Flocalhost%3A6274%2Foauth%2Fcallback%2Fdebug\u0026state=9f23fd47e2b8786b502f116bdbfd6ae3d7d2801167e24fea82f608bb52312bbd\u0026scope=User.Read+email+openid+profile\u0026resource=http%3A%2F%2Flocalhost%3A8000%2Fmcp\n```\n\nWhen using the built-in FastMCP `/authorize` endpoint, and in the example above, FastMCP server configured with Entra ID, it will then redirect the user here:\n\n```http\nhttps://login.microsoftonline.com/412e93fe-74e5-4ee6-9b67-1eeb1c79550e/oauth2/v2.0/authorize?response_type=code\u0026client_id=7bac43f2-ca62-4148-93a5-fd5686cb16c0\u0026redirect_uri=http%3A%2F%2Flocalhost%3A8000%2Fauth%2Fcallback\u0026state=Tcv7bbg_v0Qi69RHbCzqR4tQHSHKPQuDDxjuo0wu5qU\u0026scope=User.Read+email+openid+profile\u0026code_challenge=bxICFAJDViuTTHIPUPdSXGLKbNbgPwiB-0ITXUJkjYM\u0026code_challenge_method=S256\u0026resource=http%3A%2F%2Flocalhost%3A8000%2Fmcp\n```\n\n\u003e[!NOTE]\n\u003eIn the scenario above, the app registration in Entra ID is set up in the FastMCP server, as outlined in the PoC below.\n\n\u003cimg width=\"2725\" height=\"630\" alt=\"image\" src=\"https://github.com/user-attachments/assets/7ea612bf-a49e-44da-bd79-236c26bb42f3\" /\u003e\n\nNotice that the client ID and redirect URIs in the `login.microsoftonline.com` call are different than the initial `/authorize` call - that\u0027s because we\u0027re now switching to using the MCP server\u0027s **static app registration** instead of the DCR client details.\n\nCompleting the authorization flow here for the first time for a user would trigger the Entra ID consent flow:\n\n\u003cimg width=\"751\" height=\"952\" alt=\"image\" src=\"https://github.com/user-attachments/assets/2cc4b7ee-c110-4623-8f86-438821f4addf\" /\u003e\n\nThis consent flow is **only showed the first time the user needs to use this application**. Once the consent is set, they will never be prompted for this unless revoked.\n\nThis is where the vulnerability comes in. After the user consented and is authorized, Entra ID will set a browser cookie capturing the authorization state. This helps prevent nagging re-authorization prompts.\n\nWith the user consented to the **static client for Entra ID** that the FastMCP server exposes, they will now not be prompted the next time they need to use the same application ID.\n\nNow, an attacker comes in - in **their own MCP client** (i.e., they maintain one at `https://evil.example.com`) they start the authorization with the same remote MCP server and get to the point where the server produces **their own** authorization URI for this client ID:\n\n```http\nhttp://localhost:8000/authorize?response_type=code\u0026client_id=9a5d63d0-3aa3-465c-b097-0e2e196392dd\u0026code_challenge=2F4Lbfppwd7xuynLT1y4Cy2Dac-S6HOO2B84itAwppw\u0026code_challenge_method=S256\u0026redirect_uri=https%3A%2F%2Fevil.example.com%3A6274%2Foauth%2Fcallback%2Fdebug\u0026state=221fab2ccdc1481511639c110ee7382445930e22be25396b01f32d973d7176dc\u0026scope=User.Read+email+openid+profile\u0026resource=http%3A%2F%2Flocalhost%3A8000%2Fmcp\n```\n\n\u003e[!IMPORTANT]\n\u003eNote that the redirect URI above points to the `https://evil.example.com` client.\n\nAt this point - they grab the URL and **coerce the victim** (user that already authenticated with Entra ID on their machine) to click on this link. This could be done through spam, spear-phishing, or any other traditional link sharing approaches. The moment the victim clicks on this link, they will be taken to the browser, where there is already a cookie set by Entra ID for the **static Entra ID client that the MCP server is using**. The DCR-d **registered client ID** that the FastMCP server is handling now got linked to the internal FastMCP authorization server, and the authorization code is returned to `https://evil.example.com`.\n\nThe user will be automatically speed-ran through the authorization flow (no prompts) and they will effectively give access to the MCP server to the attacker with their account. Attacker can now exchange the authorization code for a token and access the remote MCP server as the victim.\n\n### Details\n\nSee above - the outline covers the attack vector.\n\n### PoC\n\nStandard documented sample that uses Entra ID:\n\n```python\nfrom fastmcp import FastMCP\nfrom fastmcp.server.auth.providers.azure import AzureProvider\n\n# The AzureProvider handles Azure\u0027s token format and validation\nauth_provider = AzureProvider(\n    client_id=\"f527ed01-9725-45bd-8173-8d3a017ba02f\",  # Your Azure App Client ID\n    client_secret=\"#####~######_#######\",                 # Your Azure App Client Secret\n    tenant_id=\"412e93fe-74e5-4ee6-9b67-1eeb1c79550e\", # Your Azure Tenant ID (REQUIRED)\n    base_url=\"http://localhost:8000\",                   # Must match your App registration\n    required_scopes=[\"User.Read\", \"email\", \"openid\", \"profile\"],  # Microsoft Graph permissions\n    # redirect_path=\"/auth/callback\"                  # Default value, customize if needed\n)\n\nmcp = FastMCP(name=\"Azure Secured App\", auth=auth_provider)\n\n# Add a protected tool to test authentication\n@mcp.tool\nasync def get_user_info() -\u003e dict:\n    \"\"\"Returns information about the authenticated Azure user.\"\"\"\n    from fastmcp.server.dependencies import get_access_token\n    \n    token = get_access_token()\n    # The AzureProvider stores user data in token claims\n    return {\n        \"azure_id\": token.claims.get(\"sub\"),\n        \"email\": token.claims.get(\"email\"),\n        \"name\": token.claims.get(\"name\"),\n        \"job_title\": token.claims.get(\"job_title\"),\n        \"office_location\": token.claims.get(\"office_location\")\n    }\n```\n\n### Impact\n\nPotential for server account compromise.",
  "id": "GHSA-c2jp-c369-7pvx",
  "modified": "2026-01-21T21:56:44Z",
  "published": "2025-10-29T15:38:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jlowin/fastmcp/security/advisories/GHSA-c2jp-c369-7pvx"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jlowin/fastmcp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "FastMCP Auth Integration Allows for Confused Deputy Account Takeover"
}

GHSA-C2R2-9576-9Q36

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

A vulnerability classified as critical has been found in Multilaser Sirius RE016 MLT1.0. Affected is an unknown function of the file /cgi-bin/cstecgi.cgi of the component Password Change Handler. The manipulation leads to improper authentication. It is possible to launch the attack remotely. 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.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-5437"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-02T09:15:21Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability classified as critical has been found in Multilaser Sirius RE016 MLT1.0. Affected is an unknown function of the file /cgi-bin/cstecgi.cgi of the component Password Change Handler. The manipulation leads to improper authentication. It is possible to launch the attack remotely. 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-c2r2-9576-9q36",
  "modified": "2025-06-02T09:31:02Z",
  "published": "2025-06-02T09:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5437"
    },
    {
      "type": "WEB",
      "url": "https://github.com/DefaultCh40s/RE016/blob/main/re016.py"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.310770"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.310770"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.584325"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/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"
    }
  ]
}
Mitigation
Architecture and Design

Strategy: Libraries or Frameworks

Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

CAPEC-114: Authentication Abuse

An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.

CAPEC-115: Authentication Bypass

An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.

CAPEC-151: Identity Spoofing

Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.

CAPEC-194: Fake the Source of Data

An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-593: Session Hijacking

This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.

CAPEC-633: Token Impersonation

An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.

CAPEC-650: Upload a Web Shell to a Web Server

By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.

CAPEC-94: Adversary in the Middle (AiTM)

An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.

← Back to the CWE list