CWE-290

{
  "affected": [],
  "aliases": [
    "CVE-2019-13715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-25T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient validation of untrusted input in Omnibox in Google Chrome prior to 78.0.3904.70 allowed a remote attacker to perform domain spoofing via IDN homographs via a crafted domain name.",
  "id": "GHSA-3466-79gg-gm5r",
  "modified": "2022-10-14T19:00:31Z",
  "published": "2022-05-24T17:01:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13715"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2019/10/stable-channel-update-for-desktop_22.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/760855"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-01/msg00008.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2019-13703"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-25T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient policy enforcement in the Omnibox in Google Chrome on Android prior to 78.0.3904.70 allowed a remote attacker to spoof the contents of the Omnibox (URL bar) via a crafted HTML page.",
  "id": "GHSA-34q3-rr2f-2gwp",
  "modified": "2022-10-14T19:00:19Z",
  "published": "2022-05-24T17:01:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13703"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2019/10/stable-channel-update-for-desktop_22.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/992838"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-01/msg00008.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T16:12:46Z",
    "nvd_published_at": "2026-05-06T20:16:35Z",
    "severity": "HIGH"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-r6xh-pqhr-v4xh. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.4.22 derives loopback MCP owner context from spoofable server-issued bearer tokens in request headers. Non-owner loopback clients can present themselves as owner to bypass owner-gated operations by manipulating the sender-owner header metadata.",
  "id": "GHSA-35vf-vw9f-q3cr",
  "modified": "2026-05-11T16:12:46Z",
  "published": "2026-05-06T21:31:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-r6xh-pqhr-v4xh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44118"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/3cb1a56bfc9579a0f2336f9cfa12a8a744332a19"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-owner-context-spoofing-via-bearer-token-header"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/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"
    }
  ],
  "summary": "Duplicate Advisory: OpenClaw: MCP loopback owner context is derived from server-issued bearer tokens",
  "withdrawn": "2026-05-11T16:12:46Z"
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-12430"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-10T20:15:37Z",
    "severity": "HIGH"
  },
  "details": "Object lifecycle issue in Media in Google Chrome prior to 142.0.7444.59 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: High)",
  "id": "GHSA-3674-h5mr-fx7g",
  "modified": "2025-11-12T21:31:06Z",
  "published": "2025-11-10T21:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12430"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2025/10/stable-channel-update-for-desktop_28.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/442860743"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2018-7842"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-22T20:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "A CWE-290: Authentication Bypass by Spoofing vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause an elevation of privilege by conducting a brute force attack on Modbus parameters sent to the controller.",
  "id": "GHSA-36fw-7hg5-xv5p",
  "modified": "2022-05-24T16:46:13Z",
  "published": "2022-05-24T16:46:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7842"
    },
    {
      "type": "WEB",
      "url": "https://www.schneider-electric.com/en/download/document/SEVD-2019-134-11"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2018-0741"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.3.0"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "SPID.AspNetCore.Authentication"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-24894"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-18T19:25:13Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Description\n\nAuthentication using Spid and CIE is based on the SAML2 standard which provides for two entities:\n\nIdentity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity;\nService Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources.\nThe library `spid-aspnetcorerefers` to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:\n\n![](https://github.com/user-attachments/assets/5b10c8f8-5121-446f-95f8-c0355daa5959)\n\nAs shown in the diagram, the IdP, after verifying the user\u0027s credentials, generates a signed SAML response, this is propagated to the SP by the user\u0027s browser and the SP, after verifying the signature, can extract the data needed to build the user\u0027s session.\n\nThe signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.\n\nThe following is the validation code implemented in `spid-aspnetcore`.\n\n```csharp\ninternal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){\n    //...SNIP...\n    SignedXml signedXml = new SignedXml(signedDocument);\n    if (identityProvider is not null)\n    {\n        bool validated = false;\n        foreach (var certificate in identityProvider.X509SigningCertificates){\n            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));\n            XmlNodeList nodeList = (signedDocument.GetElementsByTagName(\"ds:Signature\")?.Count \u003e 1) ?\n                                    signedDocument.GetElementsByTagName(\"ds:Signature\") :\n                                   (signedDocument.GetElementsByTagName(\"ns2:Signature\")?.Count \u003e 1) ?\n                                    signedDocument.GetElementsByTagName(\"ns2:Signature\") :\n                                    signedDocument.GetElementsByTagName(\"Signature\");\n            signedXml.LoadXml((XmlElement)nodeList[0]);\n            validated |= signedXml.CheckSignature(publicMetadataCert, true);\n        }\n        return validated;\n    }\n    else{\n        XmlNodeList nodeList = (signedDocument.GetElementsByTagName(\"ds:Signature\")?.Count \u003e 0) ?\n                               signedDocument.GetElementsByTagName(\"ds:Signature\") :\n                               signedDocument.GetElementsByTagName(\"Signature\");\n        signedXml.LoadXml((XmlElement)nodeList[0]);\n        return signedXml.CheckSignature();\n    }\n    //...SNIP...\n}\n```\n\nThe parameter `signedDocument` contains the SAML response in XML format, while the parameter `identityProvider` can contain the IdP info. If the parameter `identityProvider` has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.\n\nNext, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.\n\nFinally, the first element of this list, i.e. the first signature found, is extracted and verified.\n\nIn a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):\n\n```xml\n\u003csamlp:Response ID=\"response_id\" IssueInstant=\"2025-01-07T13:37:00Z\" Version=\"2.0\" xmlns:saml=\"urn:oasis:names:tc:SAML:2.0:assertion\" xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\"\u003e\n    \u003csaml:Issuer Format=\"urn:oasis:names:tc:SAML:2.0:nameid-format:entity\"\u003e\n        https://demo.spid.gov.it/validator\n    \u003c/saml:Issuer\u003e\n    \u003cds:Signature xmlns:ds=\"http://www.w3.org/2000/09/xmldsig#\"\u003e\n        \u003cds:SignedInfo\u003e\n            \u003cds:CanonicalizationMethod Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\"/\u003e\n            \u003cds:SignatureMethod Algorithm=\"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256\"/\u003e\n            \u003cds:Reference URI=\"#response_id\"\u003e\n                \u003cds:Transforms\u003e\n                    \u003cds:Transform Algorithm=\"http://www.w3.org/2000/09/xmldsig#enveloped-signature\"/\u003e\n                \u003c/ds:Transforms\u003e\n                \u003cds:DigestMethod Algorithm=\"http://www.w3.org/2001/04/xmlenc#sha256\"/\u003e\n                \u003cds:DigestValue\u003e\n                    \u003c!-- DIGEST --\u003e\n                \u003c/ds:DigestValue\u003e\n            \u003c/ds:Reference\u003e\n        \u003c/ds:SignedInfo\u003e\n        \u003cds:SignatureValue\u003e\n           \u003c!-- SIGNATURE --\u003e\n        \u003c/ds:SignatureValue\u003e\n        \u003cds:KeyInfo\u003e\n            \u003cds:X509Data\u003e\n                \u003cds:X509Certificate\u003e\n                    \u003c!-- CERTIFICATE --\u003e\n                \u003c/ds:X509Certificate\u003e\n            \u003c/ds:X509Data\u003e\n        \u003c/ds:KeyInfo\u003e\n    \u003c/ds:Signature\u003e\n    \u003csamlp:Status\u003e\n        \u003csamlp:StatusCode Value=\"urn:oasis:names:tc:SAML:2.0:status:Success\"/\u003e\n    \u003c/samlp:Status\u003e\n    \u003csaml:Assertion ID=\"assertion_id\" IssueInstant=\"2025-01-07T13:37:00Z\" Version=\"2.0\" xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\u003e\n        \u003csaml:Issuer Format=\"urn:oasis:names:tc:SAML:2.0:nameid-format:entity\"\u003e\n            https://demo.spid.gov.it/validator\n        \u003c/saml:Issuer\u003e\n        \u003cds:Signature xmlns:ds=\"http://www.w3.org/2000/09/xmldsig#\"\u003e\n            \u003cds:SignedInfo\u003e\n                \u003cds:CanonicalizationMethod Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\"/\u003e\n                \u003cds:SignatureMethod Algorithm=\"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256\"/\u003e\n                \u003cds:Reference URI=\"#assertion_id\"\u003e\n                    \u003cds:Transforms\u003e\n                        \u003cds:Transform Algorithm=\"http://www.w3.org/2000/09/xmldsig#enveloped-signature\"/\u003e\n                    \u003c/ds:Transforms\u003e\n                    \u003cds:DigestMethod Algorithm=\"http://www.w3.org/2001/04/xmlenc#sha256\"/\u003e\n                    \u003cds:DigestValue\u003e\n                        \u003c!-- DIGEST --\u003e\n                    \u003c/ds:DigestValue\u003e\n                \u003c/ds:Reference\u003e\n            \u003c/ds:SignedInfo\u003e\n            \u003cds:SignatureValue\u003e\n                \u003c!-- SIGNATURE --\u003e\n            \u003c/ds:SignatureValue\u003e\n            \u003cds:KeyInfo\u003e\n                \u003cds:X509Data\u003e\n                    \u003cds:X509Certificate\u003e\n                        \u003c!-- CERTIFICATE --\u003e\n                    \u003c/ds:X509Certificate\u003e\n                \u003c/ds:X509Data\u003e\n            \u003c/ds:KeyInfo\u003e\n        \u003c/ds:Signature\u003e\n        \u003csaml:AttributeStatement\u003e\n            \u003csaml:Attribute Name=\"spidCode\" NameFormat=\"urn:oasis:names:tc:SAML:2.0:attrname-format:basic\"\u003e\n                \u003csaml:AttributeValue xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:type=\"xs:string\"\u003e\n                    AGID-001\n                \u003c/saml:AttributeValue\u003e\n            \u003c/saml:Attribute\u003e\n            \u003c!-- ... SNIP ... --\u003e\n        \u003c/saml:AttributeStatement\u003e\n    \u003c/saml:Assertion\u003e\n\u003c/samlp:Response\u003e\n```\n\nThe SDK code would get as the first element of the `nodeList`, that is `nodeList[0]`, the signature referring to the entire SAML response, in fact the reference of the first signature `\u003cds:Reference URI=\"#response_id\"\u003e` points to the root object `\u003csamlp:Response ID=\"response_id\" ...\u003e`. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.\n\nHowever, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.\n\nThe SAML response would be structured like this:\n\n![](https://github.com/user-attachments/assets/42b8c97a-96ae-45c9-afed-aab7066201a1)\n\n### Impact\nAn attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.\n\n### Complexity of the attack\nThe attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.\n\n### Related issues\nN/A\n\n### PoC\n\n1. Clone the repository https://github.com/italia/spid-aspnetcore.git\n2. From the root of the project, enter the folder relating to the example webapp: `samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/`\n3. Change the value of the `AssertionConsumerServiceURL` key in the file `appsettings.json` to a custom domain: `https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid`\n4. Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values \u200b\u200bused in step 3: `dotnet build \"SPID.AspNetCore.WebApp.csproj\" -o ./app/build \u0026\u0026 dotnet publish \"SPID.AspNetCore.WebApp.csproj\" -o ./app/publish \u0026\u0026 dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT`\n5. Visit URL: `https://$CUSTOM_DOMAIN:$CUSTOM_PORT/`\n6. Click \"Enter with SPID\" \u003e \"DemoSpid\" (second IdP in the list)\n7. Visit the \"Response\" \u003e \"Check Response\" section\n8. Insert the following string into the \"Audience\" field (right column): `https://spid.aspnetcore.it/`\n9. Click \"Send response to Service Provider\", note the redirect to  `/home/loggedin` and consequently the correct execution of the login on the example portal\n\n![](https://github.com/user-attachments/assets/af3775a1-5f01-4ffa-9b28-730fef487869)\n\n10. Repeat steps 5 to 8 inclusive\n11. Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger\u0027s BurpSuite\n12. Perform URL-decoding and Base64-decoding of the POST `SAMLResponse` parameter\n13. Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml\n14. Change the contents of the tag `\u003csaml:Assertion\u003e`, for example change the `email` attribute to an arbitrary value: `spid.tech@shielder.it`\n15. Run Base64-encoding and then URL-encoding the `SAMLResponse` parameter\n16. Send the request and note the redirect to `/home/loggedin` which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in `SAMLResponse` despite the modification of the assertion\n\n![](https://github.com/user-attachments/assets/a725401f-7884-4910-b4e5-b6c55c1cde83)\n\n### Recommended Solution\n\nVerify all signatures within the SAML response and do not accept unsigned XML elements.\n\n### References\n\n- https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html\n\n### Credits\n- [Abdel Adim `smaury` Oisfi](https://x.com/smaury92) di [Shielder](https://www.shielder.com)\n- [Paolo`paupu` Cavagli\u00e0](https://x.com/paupu_95) di [Shielder](https://www.shielder.com)\n- [Nicola `fromveeko` Davico](https://x.com/fromveeko) di [Shielder](https://www.shielder.com)",
  "id": "GHSA-36h8-r92j-w9vw",
  "modified": "2025-02-18T19:25:13Z",
  "published": "2025-02-18T19:25:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/italia/spid-aspnetcore/security/advisories/GHSA-36h8-r92j-w9vw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/italia/spid-aspnetcore/commit/093efa2273f8a1e0481f678a0bfcd57fbdc7b029"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/italia/spid-aspnetcore"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.alibaba.nacos:nacos-common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-29441"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-27T20:08:38Z",
    "nvd_published_at": "2021-04-27T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "When configured to use authentication (`-Dnacos.core.auth.enabled=true`) Nacos uses the `AuthFilter` servlet filter to enforce authentication. This filter has a [backdoor](https://github.com/alibaba/nacos/blob/5fa05aef52f7432aeab19fe53035431b9d8c91d9/core/src/main/java/com/alibaba/nacos/core/auth/AuthFilter.java#L78-L81) that enables Nacos servers to bypass this filter and therefore skip authentication checks. This mechanism relies on the `user-agent` HTTP header so it can be easily spoofed.\n\nThe following request to the `configuration` endpoint gets rejected as we are not providing any credentials:\n```\n\u276f curl -X POST \"http://127.0.0.1:8848/nacos/v1/cs/configs?dataId=nacos.cfg.dataIdfoo\u0026group=foo\u0026content=helloWorld\"\n{\"timestamp\":\"2020-12-02T14:33:57.154+0000\",\"status\":403,\"error\":\"Forbidden\",\"message\":\"unknown user!\",\"path\":\"/nacos/v1/cs/configs\"}                                                                                                       \n```\n\nHowever the following one gets accepted by using the `Nacos-Server` user-agent header:\n```\n\u276f curl -X POST -A Nacos-Server \"http://127.0.0.1:8848/nacos/v1/cs/configs?dataId=nacos.cfg.dataIdfoo\u0026group=foo\u0026content=helloWorld\"\ntrue \n```\n\n#### Impact\n\nThis issue may allow any user to carry out any administrative tasks on the Nacos server.",
  "id": "GHSA-36hp-jr8h-556f",
  "modified": "2021-05-10T14:56:08Z",
  "published": "2021-04-27T20:09:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29441"
    },
    {
      "type": "WEB",
      "url": "https://github.com/alibaba/nacos/issues/4701"
    },
    {
      "type": "WEB",
      "url": "https://github.com/alibaba/nacos/pull/4703"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-36hp-jr8h-556f"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Authentication Bypass"
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-20674"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-305"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-09T18:15:50Z",
    "severity": "CRITICAL"
  },
  "details": "Windows Kerberos Security Feature Bypass Vulnerability",
  "id": "GHSA-37gw-25xx-74f7",
  "modified": "2024-01-09T18:30:28Z",
  "published": "2024-01-09T18:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20674"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-20674"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.123.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-26T22:47:06Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Impact\nAn attacker who knows the webhook URL of a workflow using the ZendeskTrigger node could send unsigned POST requests and trigger the workflow with arbitrary data. The node does not verify the HMAC-SHA256 signature that Zendesk attaches to every outbound webhook, allowing any party to inject crafted payloads into the connected workflow.\n\n## Patches\nThe issue has been fixed in n8n versions 2.6.2 and 1.123.18. Users should upgrade to one of these versions or later to remediate the vulnerability.\n\n## Workarounds\nIf upgrading is not immediately possible, administrators should consider the following temporary mitigations:\n- Limit workflow creation and editing permissions to fully trusted users only.\n- Restrict network access to the n8n webhook endpoint to known Zendesk IP ranges.\n\nThese workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.",
  "id": "GHSA-38c7-23hj-2wgq",
  "modified": "2026-02-26T22:47:06Z",
  "published": "2026-02-26T22:47:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-38c7-23hj-2wgq"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/commit/3839e310bd4c3002c646c363d1411916fa195151"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/commit/c6520e4e87614fa60c9433e93019e211f19f65f9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/n8n-io/n8n"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "n8n has Webhook Forgery on Zendesk Trigger Node"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.17.16"
      },
      "package": {
        "ecosystem": "Go",
        "name": "https://github.com/dadrus/heimdall"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.17.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-20",
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T14:24:37Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nWhen the `trusted_proxies` option is configured, heimdall extracts client IP addresses from the `Forwarded` (`for=` parameter) and `X-Forwarded-For` headers and exposes them as `Request.ClientIPAddresses` to the rule pipeline. However, extracted values are not validated to be syntactically valid IP addresses. Arbitrary strings, malformed IP literals, and RFC 7239 `unknown` values and obfuscated identifiers are accepted without further checks.\nIn addition, the `Forwarded` header parser splits on `,` and `;` without accounting for RFC 7239 quoted strings, which can cause a single quoted value to be parsed as multiple entries, with fragments \u2014 including trailing quote characters \u2014 treated as independent addresses.\n\n### Impact\n\n`Request.ClientIPAddresses` is available to all pipeline mechanisms. Its contents can therefore influence rule evaluation in deployments where rules reference this property \u2014 for example, in a `CEL` authorizer that checks whether a request originates from a trusted IP range using the `networks()` function, or in a `Remote` authorizer that forwards the client IP as part of its payload to an external authorization system. Whether and how `Request.ClientIPAddresses` is used is entirely determined by the rule configuration.\n\nAdditionally, in proxy mode, `Request.ClientIPAddresses` is used directly to construct the `X-Forwarded-For` and `Forwarded` headers forwarded to upstream services. Injected or malformed values are therefore propagated to upstream services unchanged.\n\n### Attack Scenarios\n\nAll scenarios require that `trusted_proxies` is configured. If this option is not set, heimdall ignores forwarding headers entirely, and this vulnerability is not exploitable. Scenarios A and C  (see below) additionally require that rules reference `Request.ClientIPAddresses` in their pipeline.\n\n#### Scenario A \u2013 Manipulation of rule evaluation\n\nAn attacker who can influence forwarding headers \u2014 either by connecting directly to heimdall or through a proxy that does not sanitize these headers \u2014 can inject arbitrary values into `Request.ClientIPAddresses`. In deployments where a rule references this property (e.g. to restrict access to specific IP ranges), this may allow an attacker to bypass the intended access control logic.\n\n#### Scenario B \u2013 IP spoofing against upstream services (proxy mode)\n\nIn proxy mode, injected or malformed values in `Request.ClientIPAddresses` are written unchanged into the `X-Forwarded-For` header sent to upstream services. Upstream services that trust this header may therefore receive and act on attacker-controlled IP values.\n\n#### Scenario C \u2013 Malformed entries via quoted-string misparse\n\nA `Forwarded` header containing a quoted value with embedded delimiters (`,` or `;`) is misparsed, producing unintended additional entries in `Request.ClientIPAddresses`, including malformed fragments with trailing quote characters.\n\n### Workarounds\n\n* Ensure at the network level that only trusted proxies can communicate directly with heimdall.\n* Ensure that the proxy forwarding the requests to heimdall sanitizes or overrides (not merely appends to) `Forwarded` or `X-Forwarded-For` headers before forwarding them.\n* Avoid relying on `Request.ClientIPAddresses` for security-sensitive decisions until patched",
  "id": "GHSA-38x9-25wx-7fg2",
  "modified": "2026-06-18T14:24:37Z",
  "published": "2026-06-18T14:24:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/security/advisories/GHSA-38x9-25wx-7fg2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dadrus/heimdall"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Heimdall: IP Spoofing via Unvalidated Forwarding Headers"
}