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.

1147 vulnerabilities reference this CWE, most recent first.

CVE-2026-94416 (GCVE-0-2026-94416)

Vulnerability from cvelistv5 – Published: 2026-09-24 12:25 – Updated: 2026-09-24 14:59
VLAI
Title
Aap-gateway: aap-gateway: authorization bypass via workload identity token forgery
Summary
An authorization bypass was found in the Ansible Automation Platform (AAP) gateway. The gateway API allows an authenticated administrator to create a new service key for the Controller service cluster. Because service-key creation is not restricted to the installer-provisioned provisioning path, an administrator-issued key is cryptographically indistinguishable from a legitimate one and can be used to forge a service-authentication token that impersonates the Controller service. Combined with the gateway OIDC workload-identity endpoint (enabled via FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED), the attacker can drive the gateway to sign Workload Identity Tokens (WITs) for arbitrary Controller workloads. A downstream resource server such as HashiCorp Vault that trusts the gateway OIDC key will accept the forged WIT and return the AAP credentials bound to that workload, disclosing secrets beyond the attacker's authorization boundary.
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-24 13:58 UTC
CWE
  • CWE-290 - Authentication Bypass by Spoofing
Impacted products
Vendor Product Version
Red Hat Red Hat Ansible Automation Platform 2     cpe:/a:redhat:ansible_automation_platform:2
Create a notification for this product.
Date Public
2026-09-18 00:00
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-94416",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-24T13:58:49.431691Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-24T14:59:36.447Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/a:redhat:ansible_automation_platform:2"
          ],
          "defaultStatus": "unknown",
          "packageName": "ansible-automation-platform-25/gateway-rhel8",
          "product": "Red Hat Ansible Automation Platform 2",
          "vendor": "Red Hat"
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/a:redhat:ansible_automation_platform:2"
          ],
          "defaultStatus": "affected",
          "packageName": "ansible-automation-platform-26/gateway-rhel9",
          "product": "Red Hat Ansible Automation Platform 2",
          "vendor": "Red Hat"
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/a:redhat:ansible_automation_platform:2"
          ],
          "defaultStatus": "affected",
          "packageName": "ansible-automation-platform-27/gateway-rhel9",
          "product": "Red Hat Ansible Automation Platform 2",
          "vendor": "Red Hat"
        },
        {
          "collectionURL": "https://access.redhat.com/downloads/content/package-browser/",
          "cpes": [
            "cpe:/a:redhat:ansible_automation_platform:2"
          ],
          "defaultStatus": "affected",
          "packageName": "automation-gateway",
          "product": "Red Hat Ansible Automation Platform 2",
          "vendor": "Red Hat"
        }
      ],
      "datePublic": "2026-09-18T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "An authorization bypass was found in the Ansible Automation Platform (AAP) gateway. The gateway API allows an authenticated administrator to create a new service key for the Controller service cluster. Because service-key creation is not restricted to the installer-provisioned provisioning path, an administrator-issued key is cryptographically indistinguishable from a legitimate one and can be used to forge a service-authentication token that impersonates the Controller service. Combined with the gateway OIDC workload-identity endpoint (enabled via FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED), the attacker can drive the gateway to sign Workload Identity Tokens (WITs) for arbitrary Controller workloads. A downstream resource server such as HashiCorp Vault that trusts the gateway OIDC key will accept the forged WIT and return the AAP credentials bound to that workload, disclosing secrets beyond the attacker\u0027s authorization boundary."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "namespace": "https://access.redhat.com/security/updates/classification/",
              "value": "Moderate"
            },
            "type": "Red Hat severity rating"
          }
        },
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 6.8,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "HIGH",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
            "version": "3.1"
          },
          "format": "CVSS"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-290",
              "description": "Authentication Bypass by Spoofing",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-24T12:25:11.735Z",
        "orgId": "53f830b8-0a3f-465b-8143-3b8a9948e749",
        "shortName": "redhat"
      },
      "references": [
        {
          "tags": [
            "vdb-entry",
            "x_refsource_REDHAT"
          ],
          "url": "https://access.redhat.com/security/cve/CVE-2026-94416"
        },
        {
          "name": "RHBZ#2537465",
          "tags": [
            "issue-tracking",
            "x_refsource_REDHAT"
          ],
          "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2537465"
        },
        {
          "url": "https://github.com/ansible/ansible.platform/pull/254"
        },
        {
          "url": "https://github.com/ansible/jewel/pull/235"
        }
      ],
      "timeline": [
        {
          "lang": "en",
          "time": "2026-09-16T00:00:00.000Z",
          "value": "Reported to Red Hat."
        },
        {
          "lang": "en",
          "time": "2026-09-18T00:00:00.000Z",
          "value": "Made public."
        }
      ],
      "title": "Aap-gateway: aap-gateway: authorization bypass via workload identity token forgery",
      "workarounds": [
        {
          "lang": "en",
          "value": "Audit and revoke any Controller service keys that were not provisioned by the installer; this is the most important immediate action and applies to environments upgraded from 2.5/2.6 as well. Where the integration is not required, set FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED=false to disable the workload-identity endpoint. Rotate any downstream credentials (e.g. in HashiCorp Vault) that could have been retrieved via a forged workload identity."
        }
      ],
      "x_generator": {
        "engine": "cvelib 1.8.0"
      },
      "x_redhatCweChain": "CWE-290: Authentication Bypass by Spoofing"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "53f830b8-0a3f-465b-8143-3b8a9948e749",
    "assignerShortName": "redhat",
    "cveId": "CVE-2026-94416",
    "datePublished": "2026-09-24T12:25:11.735Z",
    "dateReserved": "2026-09-21T15:15:54.901Z",
    "dateUpdated": "2026-09-24T14:59:36.447Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-93538 (GCVE-0-2026-93538)

Vulnerability from cvelistv5 – Published: 2026-09-28 14:10 – Updated: 2026-09-28 16:22
VLAI
Title
Cross-tenant BundleDeployment and Secret disclosure via spoofed cluster labels during agent-initiated registration in Fleet
Summary
A cross-tenant authorization issue was discovered in SUSE Rancher Fleet. During agent-initiated cluster registration, cluster labels supplied by the registering agent, including labels in the reserved management.cattle.io/ namespace such as the cluster display name label, were applied to the resulting upstream Cluster object. Because Fleet resolves GitRepo and Bundle targets from those cluster labels, a party able to register a cluster into a Fleet workspace namespace shared with other tenants could cause its own cluster to satisfy targeting rules that administrators intended for a different cluster. This affects SUSE Rancher Fleet 0.16 before 0.16.1, 0.15 before 0.15.6, 0.14 before 0.14.10, 0.13 before 0.13.15, 0.12 before 0.12.19 and older versions.
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-28 15:46 UTC
CWE
  • CWE-290 - Authentication bypass by spoofing
  • CWE-639 - Authorization bypass through User-Controlled key
References
Impacted products
Vendor Product Version
SUSE Rancher Affected: 0.16.0 , < 0.16.1 (semver)
Affected: 0.15.0 , < 0.15.6 (semver)
Affected: 0.14.0 , < 0.14.10 (semver)
Affected: 0.13.0 , < 0.13.15 (semver)
Affected: 0.12.0 , < 0.12.19 (semver)
    cpe:2.3:a:suse:rancher:*:*:*:*:*:*:*:*
    cpe:2.3:a:suse:rancher:*:*:*:*:*:*:*:*
    cpe:2.3:a:suse:rancher:*:*:*:*:*:*:*:*
    cpe:2.3:a:suse:rancher:*:*:*:*:*:*:*:*
    cpe:2.3:a:suse:rancher:*:*:*:*:*:*:*:*
Create a notification for this product.
Date Public
2026-09-28 14:05
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-93538",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-28T15:46:41.479078Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-28T16:22:26.562Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageName": "Fleet",
          "product": "Rancher",
          "repo": "https://github.com/rancher/fleet/",
          "vendor": "SUSE",
          "versions": [
            {
              "lessThan": "0.16.1",
              "status": "affected",
              "version": "0.16.0",
              "versionType": "semver"
            },
            {
              "lessThan": "0.15.6",
              "status": "affected",
              "version": "0.15.0",
              "versionType": "semver"
            },
            {
              "lessThan": "0.14.10",
              "status": "affected",
              "version": "0.14.0",
              "versionType": "semver"
            },
            {
              "lessThan": "0.13.15",
              "status": "affected",
              "version": "0.13.0",
              "versionType": "semver"
            },
            {
              "lessThan": "0.12.19",
              "status": "affected",
              "version": "0.12.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:suse:rancher:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "0.16.1",
                  "versionStartIncluding": "0.16.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:a:suse:rancher:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "0.15.6",
                  "versionStartIncluding": "0.15.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:a:suse:rancher:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "0.14.10",
                  "versionStartIncluding": "0.14.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:a:suse:rancher:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "0.13.15",
                  "versionStartIncluding": "0.13.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:a:suse:rancher:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "0.12.19",
                  "versionStartIncluding": "0.12.0",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ],
          "operator": "OR"
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "https://github.com/Pig-Tail"
        }
      ],
      "datePublic": "2026-09-28T14:05:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "A cross-tenant authorization issue was discovered in SUSE Rancher Fleet. During agent-initiated\u0026nbsp;cluster registration, cluster labels supplied by the registering agent, including labels in the reserved \u003ccode\u003emanagement.cattle.io/\u003c/code\u003e namespace such as the cluster display name label, were applied to the resulting upstream \u003ccode\u003eCluster\u003c/code\u003e object. Because Fleet resolves \u003ccode\u003eGitRepo\u003c/code\u003e and \u003ccode\u003eBundle\u003c/code\u003e targets from those cluster labels, a party able to register a cluster into a Fleet workspace namespace shared with other tenants could cause its own cluster to satisfy targeting rules that administrators intended for a different cluster.\u003cbr\u003eThis affects SUSE Rancher Fleet 0.16 before 0.16.1, 0.15 before 0.15.6, 0.14 before 0.14.10, 0.13 before 0.13.15, 0.12 before 0.12.19 and older versions."
            }
          ],
          "value": "A cross-tenant authorization issue was discovered in SUSE Rancher Fleet. During agent-initiated\u00a0cluster registration, cluster labels supplied by the registering agent, including labels in the reserved management.cattle.io/ namespace such as the cluster display name label, were applied to the resulting upstream Cluster object. Because Fleet resolves GitRepo and Bundle targets from those cluster labels, a party able to register a cluster into a Fleet workspace namespace shared with other tenants could cause its own cluster to satisfy targeting rules that administrators intended for a different cluster.\nThis affects SUSE Rancher Fleet 0.16 before 0.16.1, 0.15 before 0.15.6, 0.14 before 0.14.10, 0.13 before 0.13.15, 0.12 before 0.12.19 and older versions."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-122",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-122 Privilege Abuse"
            }
          ]
        },
        {
          "capecId": "CAPEC-195",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-195 Principal Spoof"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "LOW",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-290",
              "description": "CWE-290 Authentication bypass by spoofing",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-639",
              "description": "CWE-639 Authorization bypass through User-Controlled key",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-28T14:10:21.720Z",
        "orgId": "404e59f5-483d-4b8a-8e7a-e67604dd8afb",
        "shortName": "suse"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://github.com/rancher/fleet/security/advisories/GHSA-h9p5-fp5h-qpqr"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Cross-tenant BundleDeployment and Secret disclosure via spoofed cluster labels during agent-initiated registration in Fleet",
      "x_generator": {
        "engine": "Vulnogram 1.0.5"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "404e59f5-483d-4b8a-8e7a-e67604dd8afb",
    "assignerShortName": "suse",
    "cveId": "CVE-2026-93538",
    "datePublished": "2026-09-28T14:10:21.720Z",
    "dateReserved": "2026-09-18T09:08:10.294Z",
    "dateUpdated": "2026-09-28T16:22:26.562Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-92929 (GCVE-0-2026-92929)

Vulnerability from cvelistv5 – Published: 2026-09-22 23:10 – Updated: 2026-09-23 14:59
VLAI
Summary
OpenEye Apex Network Video Recorder (NVR) firmware 3.2.9.376 trusts an X-Forwarded-For header supplied by an arbitrary client when determining the request source address. An unauthenticated remote attacker can spoof a loopback address to bypass local-connection-only security controls exposed on the affected non-TLS web interfaces and disclose configuration information. The underlying design has been present since at least firmware 2.2.3.4. Upgrade to version 3.5.4.
SSVC
Exploitation: none Automatable: yes Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-23 14:58 UTC
CWE
  • CWE-290 - Authentication Bypass by Spoofing
Impacted products
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-92929",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-23T14:58:43.938282Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-23T14:59:15.413Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unknown",
          "product": "Apex Network Video Recorder (NVR)",
          "vendor": "OpenEye",
          "versions": [
            {
              "status": "affected",
              "version": "3.2.9.376"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Ryan Wincey (@rwincey, Securifera)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "OpenEye Apex Network Video Recorder (NVR) firmware 3.2.9.376 trusts an X-Forwarded-For header supplied by an arbitrary client when determining the request source address. An unauthenticated remote attacker can spoof a loopback address to bypass local-connection-only security controls exposed on the affected non-TLS web interfaces and disclose configuration information. The underlying design has been present since at least firmware 2.2.3.4.\n\nUpgrade to version 3.5.4."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 5.3,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-290",
              "description": "CWE-290: Authentication Bypass by Spoofing",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-22T23:19:15.124Z",
        "orgId": "c35fbbdf-8d87-49b6-8120-920a36e62b7f",
        "shortName": "Securifera"
      },
      "references": [
        {
          "url": "https://portal.openeye.net/updates/issue-alerts/1059"
        },
        {
          "url": "https://www.securifera.com/advisories/"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "value": "Upgrade to version 3.5.4."
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "c35fbbdf-8d87-49b6-8120-920a36e62b7f",
    "assignerShortName": "Securifera",
    "cveId": "CVE-2026-92929",
    "datePublished": "2026-09-22T23:10:17.485Z",
    "dateReserved": "2026-09-17T12:03:24.121Z",
    "dateUpdated": "2026-09-23T14:59:15.413Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-92395 (GCVE-0-2026-92395)

Vulnerability from cvelistv5 – Published: 2026-09-16 14:35 – Updated: 2026-09-17 18:39
VLAI
Title
@fastify/proxy-addr vulnerable to IP spoofing via IPv4-mapped IPv6 trust subnet
Summary
@fastify/proxy-addr is a Fastify plugin that determines a request's client address behind trusted reverse proxies, and it backs Fastify request.ip and request.ips. In versions 3.0.0 through 5.1.0, a trust subnet written in IPv4-mapped IPv6 notation with an IPv4-sized prefix, such as ::ffff:10.0.0.0/8 instead of the correct ::ffff:10.0.0.0/104, is accepted without error but trusts every IPv4 address on the internet rather than the block it names. Because the socket peer then becomes trusted at hop 0, any unauthenticated client can supply an arbitrary X-Forwarded-For header and control the address the application reads, which defeats IP-based access control, rate limiting, geolocation, and audit logging. The plugin inherited this defect from the upstream proxy-addr module (CVE-2026-90711). The issue is fixed in @fastify/proxy-addr 5.1.1, and users should upgrade to 5.1.1 or later. As a workaround, ensure any IPv4-mapped IPv6 trust subnet uses a prefix length of at least 97, or express the range in plain IPv4 notation.
SSVC
Exploitation: none Automatable: yes Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 18:38 UTC
CWE
  • CWE-290 - Authentication Bypass by Spoofing
  • CWE-348 - Use of Less Trusted Source
  • CWE-697 - Incorrect Comparison
Impacted products
Vendor Product Version
@fastify/proxy-addr @fastify/proxy-addr Affected: 3.0.0 , < 5.1.1 (semver)
Unaffected: 5.1.1 (semver)
Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-92395",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-17T18:38:56.138579Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-17T18:39:20.231Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageURL": "pkg:npm/@fastify/proxy-addr",
          "product": "@fastify/proxy-addr",
          "vendor": "@fastify/proxy-addr",
          "versions": [
            {
              "lessThan": "5.1.1",
              "status": "affected",
              "version": "3.0.0",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "5.1.1",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "kagebunsher"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "UlisesGascon"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "mcollina"
        },
        {
          "lang": "en",
          "type": "finder",
          "value": "kustundag"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "@fastify/proxy-addr is a Fastify plugin that determines a request\u0027s client address behind trusted reverse proxies, and it backs Fastify request.ip and request.ips. In versions 3.0.0 through 5.1.0, a trust subnet written in IPv4-mapped IPv6 notation with an IPv4-sized prefix, such as ::ffff:10.0.0.0/8 instead of the correct ::ffff:10.0.0.0/104, is accepted without error but trusts every IPv4 address on the internet rather than the block it names. Because the socket peer then becomes trusted at hop 0, any unauthenticated client can supply an arbitrary X-Forwarded-For header and control the address the application reads, which defeats IP-based access control, rate limiting, geolocation, and audit logging. The plugin inherited this defect from the upstream proxy-addr module (CVE-2026-90711). The issue is fixed in @fastify/proxy-addr 5.1.1, and users should upgrade to 5.1.1 or later. As a workaround, ensure any IPv4-mapped IPv6 trust subnet uses a prefix length of at least 97, or express the range in plain IPv4 notation."
            }
          ],
          "value": "@fastify/proxy-addr is a Fastify plugin that determines a request\u0027s client address behind trusted reverse proxies, and it backs Fastify request.ip and request.ips. In versions 3.0.0 through 5.1.0, a trust subnet written in IPv4-mapped IPv6 notation with an IPv4-sized prefix, such as ::ffff:10.0.0.0/8 instead of the correct ::ffff:10.0.0.0/104, is accepted without error but trusts every IPv4 address on the internet rather than the block it names. Because the socket peer then becomes trusted at hop 0, any unauthenticated client can supply an arbitrary X-Forwarded-For header and control the address the application reads, which defeats IP-based access control, rate limiting, geolocation, and audit logging. The plugin inherited this defect from the upstream proxy-addr module (CVE-2026-90711). The issue is fixed in @fastify/proxy-addr 5.1.1, and users should upgrade to 5.1.1 or later. As a workaround, ensure any IPv4-mapped IPv6 trust subnet uses a prefix length of at least 97, or express the range in plain IPv4 notation."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 9.1,
            "baseSeverity": "CRITICAL",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-290",
              "description": "CWE-290: Authentication Bypass by Spoofing",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-348",
              "description": "CWE-348: Use of Less Trusted Source",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-697",
              "description": "CWE-697: Incorrect Comparison",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-16T14:35:05.121Z",
        "orgId": "ce714d77-add3-4f53-aff5-83d477b104bb",
        "shortName": "openjs"
      },
      "references": [
        {
          "url": "https://github.com/fastify/proxy-addr/security/advisories/GHSA-8cmm-mhw6-v7xq"
        },
        {
          "url": "https://cna.openjsf.org/security-advisories.html"
        }
      ],
      "title": "@fastify/proxy-addr vulnerable to IP spoofing via IPv4-mapped IPv6 trust subnet",
      "x_generator": {
        "engine": "cve-kit 1.0.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "ce714d77-add3-4f53-aff5-83d477b104bb",
    "assignerShortName": "openjs",
    "cveId": "CVE-2026-92395",
    "datePublished": "2026-09-16T14:35:05.121Z",
    "dateReserved": "2026-09-16T08:28:17.064Z",
    "dateUpdated": "2026-09-17T18:39:20.231Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-91039 (GCVE-0-2026-91039)

Vulnerability from cvelistv5 – Published: 2026-09-17 15:19 – Updated: 2026-09-17 19:40
VLAI
Title
dynamic_oidc identities are not namespaced by connection in ash_authentication, allowing cross-connection account takeover
Summary
Authentication Bypass by Spoofing vulnerability in team-alembic ash_authentication allows an attacker who operates one identity-provider connection of a dynamic_oidc strategy to be signed in as a local user established through a different connection. The strategy is meant to keep each connection in its own identity namespace by writing every UserIdentity row's strategy field as "<name>/<connection_id>", but that namespacing never takes effect. __connection_id__ is populated only on the ephemeral runtime struct built per request in dynamic_oidc/plug.ex, and DynamicOidc.IdentityChange.change/3 re-fetches the strategy from the compile-time DSL through Info.strategy_for_action, yielding the persisted struct whose __connection_id__ is its defstruct default of nil. OAuth2.identity_strategy_name/1 therefore falls back to the bare strategy name for both the identity write and the reads in oauth2/user_resolver.ex and oauth2/sign_in_preparation.ex. Since the identity resource's unique key is (uid, strategy), one row exists per sub across every connection, and the identity-match branch runs before any email check. Neither strategy handles iss, so nothing else distinguishes the issuers: OpenID Connect Core section 5.7 makes sub unique only within an issuer, so two connections numbering subjects independently share one subject space. This issue affects ash_authentication: from 5.0.0-rc.10 before 5.0.0-rc.14.
SSVC
Exploitation: none Automatable: no Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-17 19:40 UTC
CWE
  • CWE-290 - Authentication Bypass by Spoofing
Impacted products
Vendor Product Version
team-alembic ash_authentication Affected: 5.0.0-rc.10 , < 5.0.0-rc.14 (semver)
    cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*
Create a notification for this product.
team-alembic ash_authentication Affected: 64530644f9b37ebb76ca14aeb83a77597a0034b7 , < 73ad16e452670bbf843550a13361bd41e72ad964 (git)
    cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*
Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-91039",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-17T19:40:12.687953Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-17T19:40:32.068Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.hex.pm",
          "cpes": [
            "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "packageName": "ash_authentication",
          "packageURL": "pkg:hex/ash_authentication",
          "product": "ash_authentication",
          "repo": "https://github.com/team-alembic/ash_authentication",
          "vendor": "team-alembic",
          "versions": [
            {
              "lessThan": "5.0.0-rc.14",
              "status": "affected",
              "version": "5.0.0-rc.10",
              "versionType": "semver"
            }
          ]
        },
        {
          "collectionURL": "https://github.com",
          "cpes": [
            "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "packageName": "team-alembic/ash_authentication",
          "packageURL": "pkg:github/team-alembic/ash_authentication",
          "product": "ash_authentication",
          "repo": "https://github.com/team-alembic/ash_authentication",
          "vendor": "team-alembic",
          "versions": [
            {
              "lessThan": "73ad16e452670bbf843550a13361bd41e72ad964",
              "status": "affected",
              "version": "64530644f9b37ebb76ca14aeb83a77597a0034b7",
              "versionType": "git"
            }
          ]
        }
      ],
      "configurations": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eOnly deployments running a \u003ccode\u003edynamic_oidc\u003c/code\u003e strategy with more than one identity-provider connection are exposed, since a single connection has no second namespace to collide with.\u003c/p\u003e\n\u003cp\u003eTwo partial mitigations exist and neither is sufficient. A \u003ccode\u003econfirmation\u003c/code\u003e add-on incidentally blocks the takeover only while the victim is unconfirmed, leaving confirmed victims and confirmation-free applications exposed. Ash multitenancy isolates only a one-connection-per-tenant topology, so non-multitenant deployments and tenants holding several connections get no isolation; connection namespacing is orthogonal to tenancy.\u003c/p\u003e"
            },
            {
              "base64": false,
              "type": "text/markdown",
              "value": "Only deployments running a `dynamic_oidc` strategy with more than one identity-provider connection are exposed, since a single connection has no second namespace to collide with.\n\nTwo partial mitigations exist and neither is sufficient. A `confirmation` add-on incidentally blocks the takeover only while the victim is unconfirmed, leaving confirmed victims and confirmation-free applications exposed. Ash multitenancy isolates only a one-connection-per-tenant topology, so non-multitenant deployments and tenants holding several connections get no isolation; connection namespacing is orthogonal to tenancy."
            }
          ],
          "value": "Only deployments running a dynamic_oidc strategy with more than one identity-provider connection are exposed, since a single connection has no second namespace to collide with.\n\nTwo partial mitigations exist and neither is sufficient. A confirmation add-on incidentally blocks the takeover only while the victim is unconfirmed, leaving confirmed victims and confirmation-free applications exposed. Ash multitenancy isolates only a one-connection-per-tenant topology, so non-multitenant deployments and tenants holding several connections get no isolation; connection namespacing is orthogonal to tenancy."
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.0.0-rc.14",
                  "versionStartIncluding": "5.0.0-rc.10",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ],
          "operator": "AND"
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Jace"
        },
        {
          "lang": "en",
          "type": "coordinator",
          "value": "Jonatan M\u00e4nnchen / EEF"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "manus-pi"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "James Harton"
        }
      ],
      "dateAssigned": "2026-09-17T05:25:04.000Z",
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eAuthentication Bypass by Spoofing vulnerability in team-alembic ash_authentication allows an attacker who operates one identity-provider connection of a \u003ccode\u003edynamic_oidc\u003c/code\u003e strategy to be signed in as a local user established through a different connection.\u003c/p\u003e\n\u003cp\u003eThe strategy is meant to keep each connection in its own identity namespace by writing every \u003ccode\u003eUserIdentity\u003c/code\u003e row\u0027s \u003ccode\u003estrategy\u003c/code\u003e field as \u003ccode\u003e\"\u0026lt;name\u0026gt;/\u0026lt;connection_id\u0026gt;\"\u003c/code\u003e, but that namespacing never takes effect. \u003ccode\u003e__connection_id__\u003c/code\u003e is populated only on the ephemeral runtime struct built per request in \u003ccode\u003edynamic_oidc/plug.ex\u003c/code\u003e, and \u003ccode\u003eDynamicOidc.IdentityChange.change/3\u003c/code\u003e re-fetches the strategy from the compile-time DSL through \u003ccode\u003eInfo.strategy_for_action\u003c/code\u003e, yielding the persisted struct whose \u003ccode\u003e__connection_id__\u003c/code\u003e is its \u003ccode\u003edefstruct\u003c/code\u003e default of \u003ccode\u003enil\u003c/code\u003e. \u003ccode\u003eOAuth2.identity_strategy_name/1\u003c/code\u003e therefore falls back to the bare strategy name for both the identity write and the reads in \u003ccode\u003eoauth2/user_resolver.ex\u003c/code\u003e and \u003ccode\u003eoauth2/sign_in_preparation.ex\u003c/code\u003e. Since the identity resource\u0027s unique key is \u003ccode\u003e(uid, strategy)\u003c/code\u003e, one row exists per \u003ccode\u003esub\u003c/code\u003e across every connection, and the identity-match branch runs before any email check. Neither strategy handles \u003ccode\u003eiss\u003c/code\u003e, so nothing else distinguishes the issuers: OpenID Connect Core section 5.7 makes \u003ccode\u003esub\u003c/code\u003e unique only within an issuer, so two connections numbering subjects independently share one subject space.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 5.0.0-rc.10 before 5.0.0-rc.14.\u003c/p\u003e"
            },
            {
              "base64": false,
              "type": "text/markdown",
              "value": "Authentication Bypass by Spoofing vulnerability in team-alembic ash_authentication allows an attacker who operates one identity-provider connection of a `dynamic_oidc` strategy to be signed in as a local user established through a different connection.\n\nThe strategy is meant to keep each connection in its own identity namespace by writing every `UserIdentity` row\u0027s `strategy` field as `\"\u003cname\u003e/\u003cconnection_id\u003e\"`, but that namespacing never takes effect. `__connection_id__` is populated only on the ephemeral runtime struct built per request in `dynamic_oidc/plug.ex`, and `DynamicOidc.IdentityChange.change/3` re-fetches the strategy from the compile-time DSL through `Info.strategy_for_action`, yielding the persisted struct whose `__connection_id__` is its `defstruct` default of `nil`. `OAuth2.identity_strategy_name/1` therefore falls back to the bare strategy name for both the identity write and the reads in `oauth2/user_resolver.ex` and `oauth2/sign_in_preparation.ex`. Since the identity resource\u0027s unique key is `(uid, strategy)`, one row exists per `sub` across every connection, and the identity-match branch runs before any email check. Neither strategy handles `iss`, so nothing else distinguishes the issuers: OpenID Connect Core section 5.7 makes `sub` unique only within an issuer, so two connections numbering subjects independently share one subject space.\n\nThis issue affects ash_authentication: from 5.0.0-rc.10 before 5.0.0-rc.14."
            }
          ],
          "value": "Authentication Bypass by Spoofing vulnerability in team-alembic ash_authentication allows an attacker who operates one identity-provider connection of a dynamic_oidc strategy to be signed in as a local user established through a different connection.\n\nThe strategy is meant to keep each connection in its own identity namespace by writing every UserIdentity row\u0027s strategy field as \"\u003cname\u003e/\u003cconnection_id\u003e\", but that namespacing never takes effect. __connection_id__ is populated only on the ephemeral runtime struct built per request in dynamic_oidc/plug.ex, and DynamicOidc.IdentityChange.change/3 re-fetches the strategy from the compile-time DSL through Info.strategy_for_action, yielding the persisted struct whose __connection_id__ is its defstruct default of nil. OAuth2.identity_strategy_name/1 therefore falls back to the bare strategy name for both the identity write and the reads in oauth2/user_resolver.ex and oauth2/sign_in_preparation.ex. Since the identity resource\u0027s unique key is (uid, strategy), one row exists per sub across every connection, and the identity-match branch runs before any email check. Neither strategy handles iss, so nothing else distinguishes the issuers: OpenID Connect Core section 5.7 makes sub unique only within an issuer, so two connections numbering subjects independently share one subject space.\n\nThis issue affects ash_authentication: from 5.0.0-rc.10 before 5.0.0-rc.14."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-21",
          "descriptions": [
            {
              "lang": "en",
              "supportingMedia": [
                {
                  "base64": false,
                  "type": "text/html",
                  "value": "\u003cp\u003eAn attacker who can obtain or choose their \u003ccode\u003esub\u003c/code\u003e on any connection served by a \u003ccode\u003edynamic_oidc\u003c/code\u003e strategy is authenticated as the local user established through a different connection, with no interaction from the victim and no pre-existing account on the application. Token, nonce and audience validation all pass legitimately, because they only prove the assertion came from the attacker\u0027s own identity provider.\u003c/p\u003e\n\u003cp\u003eThe same collision also occurs with no attacker at all: two honest providers numbering subjects sequentially produce overlapping \u003ccode\u003esub\u003c/code\u003e values and silently merge distinct users, so this may already have happened in affected deployments.\u003c/p\u003e"
                },
                {
                  "base64": false,
                  "type": "text/markdown",
                  "value": "An attacker who can obtain or choose their `sub` on any connection served by a `dynamic_oidc` strategy is authenticated as the local user established through a different connection, with no interaction from the victim and no pre-existing account on the application. Token, nonce and audience validation all pass legitimately, because they only prove the assertion came from the attacker\u0027s own identity provider.\n\nThe same collision also occurs with no attacker at all: two honest providers numbering subjects sequentially produce overlapping `sub` values and silently merge distinct users, so this may already have happened in affected deployments."
                }
              ],
              "value": "An attacker who can obtain or choose their sub on any connection served by a dynamic_oidc strategy is authenticated as the local user established through a different connection, with no interaction from the victim and no pre-existing account on the application. Token, nonce and audience validation all pass legitimately, because they only prove the assertion came from the attacker\u0027s own identity provider.\n\nThe same collision also occurs with no attacker at all: two honest providers numbering subjects sequentially produce overlapping sub values and silently merge distinct users, so this may already have happened in affected deployments."
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 9.1,
            "baseSeverity": "CRITICAL",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-290",
              "description": "CWE-290 Authentication Bypass by Spoofing",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-17T15:19:15.994Z",
        "orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
        "shortName": "EEF"
      },
      "references": [
        {
          "name": "GitHub Advisory",
          "tags": [
            "related",
            "vendor-advisory"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-73j9-m294-fvv9"
        },
        {
          "name": "EEF CNA record for CVE-2026-91039",
          "tags": [
            "related"
          ],
          "url": "https://cna.erlef.org/cves/CVE-2026-91039.html"
        },
        {
          "name": "OSV record EEF-CVE-2026-91039",
          "tags": [
            "related"
          ],
          "url": "https://osv.dev/vulnerability/EEF-CVE-2026-91039"
        },
        {
          "name": "Introducing commit 6453064 in team-alembic/ash_authentication",
          "tags": [
            "related"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7"
        },
        {
          "name": "Fix commit 73ad16e in team-alembic/ash_authentication",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/commit/73ad16e452670bbf843550a13361bd41e72ad964"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eUpgrading is not sufficient on its own, for two reasons.\u003c/p\u003e\n\u003cp\u003eNamespacing changes the value the identity lookup keys on, so \u003ccode\u003eUserIdentity\u003c/code\u003e rows written before the fix, all holding the bare strategy name, no longer match. Each row\u0027s \u003ccode\u003estrategy\u003c/code\u003e must be relinked in place to \u003ccode\u003e\"\u0026lt;name\u0026gt;/\u0026lt;connection_id\u0026gt;\"\u003c/code\u003e. Deleting the rows does not work: the block is the account match that follows, refused under the default \u003ccode\u003eon_untrusted_email_match :reject\u003c/code\u003e whether the row exists or not, and deleting also discards the stored refresh token. Where a deployment has one connection the mapping is unambiguous and the update is mechanical, but it must run in the same deployment as the upgrade and before users sign in, or a newly written namespaced row can collide with a surviving bare row on the \u003ccode\u003e(uid, strategy)\u003c/code\u003e index.\u003c/p\u003e\n\u003cp\u003eThe fix also cannot separate accounts already merged, and the merge is not detectable from the database, because a collision never produced two rows to compare: the second user\u0027s identity was never created and the surviving row looks legitimate. Deployments running more than one connection must audit out of band, by exporting each connection\u0027s set of \u003ccode\u003esub\u003c/code\u003e values from its identity provider and intersecting them. Any \u003ccode\u003esub\u003c/code\u003e present in more than one set identifies an account that may have been merged.\u003c/p\u003e"
            },
            {
              "base64": false,
              "type": "text/markdown",
              "value": "Upgrading is not sufficient on its own, for two reasons.\n\nNamespacing changes the value the identity lookup keys on, so `UserIdentity` rows written before the fix, all holding the bare strategy name, no longer match. Each row\u0027s `strategy` must be relinked in place to `\"\u003cname\u003e/\u003cconnection_id\u003e\"`. Deleting the rows does not work: the block is the account match that follows, refused under the default `on_untrusted_email_match :reject` whether the row exists or not, and deleting also discards the stored refresh token. Where a deployment has one connection the mapping is unambiguous and the update is mechanical, but it must run in the same deployment as the upgrade and before users sign in, or a newly written namespaced row can collide with a surviving bare row on the `(uid, strategy)` index.\n\nThe fix also cannot separate accounts already merged, and the merge is not detectable from the database, because a collision never produced two rows to compare: the second user\u0027s identity was never created and the surviving row looks legitimate. Deployments running more than one connection must audit out of band, by exporting each connection\u0027s set of `sub` values from its identity provider and intersecting them. Any `sub` present in more than one set identifies an account that may have been merged."
            }
          ],
          "value": "Upgrading is not sufficient on its own, for two reasons.\n\nNamespacing changes the value the identity lookup keys on, so UserIdentity rows written before the fix, all holding the bare strategy name, no longer match. Each row\u0027s strategy must be relinked in place to \"\u003cname\u003e/\u003cconnection_id\u003e\". Deleting the rows does not work: the block is the account match that follows, refused under the default on_untrusted_email_match :reject whether the row exists or not, and deleting also discards the stored refresh token. Where a deployment has one connection the mapping is unambiguous and the update is mechanical, but it must run in the same deployment as the upgrade and before users sign in, or a newly written namespaced row can collide with a surviving bare row on the (uid, strategy) index.\n\nThe fix also cannot separate accounts already merged, and the merge is not detectable from the database, because a collision never produced two rows to compare: the second user\u0027s identity was never created and the surviving row looks legitimate. Deployments running more than one connection must audit out of band, by exporting each connection\u0027s set of sub values from its identity provider and intersecting them. Any sub present in more than one set identifies an account that may have been merged."
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "dynamic_oidc identities are not namespaced by connection in ash_authentication, allowing cross-connection account takeover"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
    "assignerShortName": "EEF",
    "cveId": "CVE-2026-91039",
    "datePublished": "2026-09-17T15:19:15.994Z",
    "dateReserved": "2026-09-15T15:30:01.883Z",
    "dateUpdated": "2026-09-17T19:40:32.068Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-90711 (GCVE-0-2026-90711)

Vulnerability from cvelistv5 – Published: 2026-09-15 06:19 – Updated: 2026-09-15 14:48
VLAI
Title
proxy-addr vulnerable to IP spoofing via IPv4-mapped IPv6 trust subnet
Summary
proxy-addr is a Node.js module that determines a request's client address behind trusted reverse proxies, and it backs Express req.ip and req.ips. In versions 1.1.0 through 2.0.7, a trust subnet written in IPv4-mapped IPv6 notation with an IPv4-sized prefix, such as ::ffff:10.0.0.0/8 instead of the correct ::ffff:10.0.0.0/104, is accepted without error but trusts every IPv4 address on the internet rather than the block it names. Because the socket peer then becomes trusted at hop 0, any unauthenticated client can supply an arbitrary X-Forwarded-For header and control the address the application reads, which defeats IP-based access control, rate limiting, geolocation, and audit logging. This is a fail-open regression introduced in version 1.1.0. The issue is fixed in proxy-addr 2.0.8, and users should upgrade to 2.0.8 or later. As a workaround, ensure any IPv4-mapped IPv6 trust subnet uses a prefix length of at least 97, or express the range in plain IPv4 notation.
SSVC
Exploitation: none Automatable: no Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-15 14:46 UTC
CWE
  • CWE-290 - Authentication Bypass by Spoofing
  • CWE-348 - Use of Less Trusted Source
  • CWE-697 - Incorrect Comparison
Impacted products
Vendor Product Version
proxy-addr proxy-addr Affected: 1.1.0 , < 2.0.8 (semver)
Unaffected: 2.0.8 (semver)
Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-90711",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-15T14:46:09.894513Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-15T14:48:38.703Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageURL": "pkg:npm/proxy-addr",
          "product": "proxy-addr",
          "vendor": "proxy-addr",
          "versions": [
            {
              "lessThan": "2.0.8",
              "status": "affected",
              "version": "1.1.0",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "2.0.8",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "kagebunsher"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "UlisesGascon"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "kustundag"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "proxy-addr is a Node.js module that determines a request\u0027s client address behind trusted reverse proxies, and it backs Express req.ip and req.ips. In versions 1.1.0 through 2.0.7, a trust subnet written in IPv4-mapped IPv6 notation with an IPv4-sized prefix, such as ::ffff:10.0.0.0/8 instead of the correct ::ffff:10.0.0.0/104, is accepted without error but trusts every IPv4 address on the internet rather than the block it names. Because the socket peer then becomes trusted at hop 0, any unauthenticated client can supply an arbitrary X-Forwarded-For header and control the address the application reads, which defeats IP-based access control, rate limiting, geolocation, and audit logging. This is a fail-open regression introduced in version 1.1.0. The issue is fixed in proxy-addr 2.0.8, and users should upgrade to 2.0.8 or later. As a workaround, ensure any IPv4-mapped IPv6 trust subnet uses a prefix length of at least 97, or express the range in plain IPv4 notation."
            }
          ],
          "value": "proxy-addr is a Node.js module that determines a request\u0027s client address behind trusted reverse proxies, and it backs Express req.ip and req.ips. In versions 1.1.0 through 2.0.7, a trust subnet written in IPv4-mapped IPv6 notation with an IPv4-sized prefix, such as ::ffff:10.0.0.0/8 instead of the correct ::ffff:10.0.0.0/104, is accepted without error but trusts every IPv4 address on the internet rather than the block it names. Because the socket peer then becomes trusted at hop 0, any unauthenticated client can supply an arbitrary X-Forwarded-For header and control the address the application reads, which defeats IP-based access control, rate limiting, geolocation, and audit logging. This is a fail-open regression introduced in version 1.1.0. The issue is fixed in proxy-addr 2.0.8, and users should upgrade to 2.0.8 or later. As a workaround, ensure any IPv4-mapped IPv6 trust subnet uses a prefix length of at least 97, or express the range in plain IPv4 notation."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 9.1,
            "baseSeverity": "CRITICAL",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-290",
              "description": "CWE-290: Authentication Bypass by Spoofing",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-348",
              "description": "CWE-348: Use of Less Trusted Source",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-697",
              "description": "CWE-697: Incorrect Comparison",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-15T06:19:46.332Z",
        "orgId": "ce714d77-add3-4f53-aff5-83d477b104bb",
        "shortName": "openjs"
      },
      "references": [
        {
          "url": "https://github.com/jshttp/proxy-addr/security/advisories/GHSA-jqcg-44mw-7w3h"
        },
        {
          "url": "https://cna.openjsf.org/security-advisories.html"
        }
      ],
      "title": "proxy-addr vulnerable to IP spoofing via IPv4-mapped IPv6 trust subnet",
      "x_generator": {
        "engine": "cve-kit 1.0.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "ce714d77-add3-4f53-aff5-83d477b104bb",
    "assignerShortName": "openjs",
    "cveId": "CVE-2026-90711",
    "datePublished": "2026-09-15T06:19:46.332Z",
    "dateReserved": "2026-09-13T09:18:12.590Z",
    "dateUpdated": "2026-09-15T14:48:38.703Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-90447 (GCVE-0-2026-90447)

Vulnerability from cvelistv5 – Published: 2026-09-11 21:48 – Updated: 2026-09-14 16:14
VLAI
Summary
A routing rule selects between two different authentication mechanisms for the same downstream service based on the value of a client-supplied request header, rather than on any property the client cannot control. An authenticated user in possession of a shared service credential can set this header to route around the primary role-based authorization check and reach the alternate path's fixed, elevated role instead. This allows a low-privileged authenticated attacker who knows the shared credential to perform actions reserved for a higher-privileged role.
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-14 16:14 UTC
CWE
  • CWE-290 - Authentication bypass by spoofing
References
URL Tags
https://raw.githubusercontent.com/cisagov/CSAF/de… government-resourcevendor-advisory
Impacted products
Vendor Product Version
CISA Malcolm Affected: 0 , < v26.06.0 (custom)
Unaffected: v26.06.0
Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-90447",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-14T16:14:01.854681Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-14T16:14:13.574Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Malcolm",
          "repo": "https://github.com/cisagov/Malcolm",
          "vendor": "CISA",
          "versions": [
            {
              "lessThan": "v26.06.0",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            },
            {
              "status": "unaffected",
              "version": "v26.06.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003e\u003cdiv\u003eA routing rule selects between two different authentication mechanisms for the same downstream service based on the value of a client-supplied request header, rather than on any property the client cannot control. An authenticated user in possession of a shared service credential can set this header to route around the primary role-based authorization check and reach the alternate path\u0027s fixed, elevated role instead. This allows a low-privileged authenticated attacker who knows the shared credential to perform actions reserved for a higher-privileged role.\u003c/div\u003e\u003c/div\u003e"
            }
          ],
          "value": "A routing rule selects between two different authentication mechanisms for the same downstream service based on the value of a client-supplied request header, rather than on any property the client cannot control. An authenticated user in possession of a shared service credential can set this header to route around the primary role-based authorization check and reach the alternate path\u0027s fixed, elevated role instead. This allows a low-privileged authenticated attacker who knows the shared credential to perform actions reserved for a higher-privileged role."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "LOW",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-290",
              "description": "CWE-290 Authentication bypass by spoofing",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-11T21:48:51.996Z",
        "orgId": "7d14cffa-0d7d-4270-9dc0-52cabd5a23a6",
        "shortName": "icscert"
      },
      "references": [
        {
          "tags": [
            "government-resource",
            "vendor-advisory"
          ],
          "url": "https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/OT/white/2026/icsa-26-254-01.json"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003e\u003cdiv\u003eThe latest version of Malcolm (September 2026 or later) fixes these vulnerabilities. Affected users are encouraged to update their instance of Malcolm to the latest version.\u003c/div\u003e\u003c/div\u003e"
            }
          ],
          "value": "The latest version of Malcolm (September 2026 or later) fixes these vulnerabilities. Affected users are encouraged to update their instance of Malcolm to the latest version."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "x_generator": {
        "engine": "Vulnogram 1.0.5"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "7d14cffa-0d7d-4270-9dc0-52cabd5a23a6",
    "assignerShortName": "icscert",
    "cveId": "CVE-2026-90447",
    "datePublished": "2026-09-11T21:48:51.996Z",
    "dateReserved": "2026-09-11T21:00:07.497Z",
    "dateUpdated": "2026-09-14T16:14:13.574Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-89022 (GCVE-0-2026-89022)

Vulnerability from cvelistv5 – Published: 2026-09-15 16:11 – Updated: 2026-10-01 15:21 X_Open Source
VLAI
Title
BookStack < 26.05.5 Authentication Bypass via Social Login Provider Confusion
Summary
BookStack before 26.05.5 contains an authentication bypass vulnerability in its social login implementation that allows unauthenticated attackers to sign in as arbitrary users by authenticating through a different social provider sharing the same driver_id namespace. Attackers can authenticate at one enabled social provider using a user ID that matches an account linked to a different social provider, bypassing credential verification entirely because the SocialAuthService::handleLoginCallback query ignores the driver column when retrieving linked account records.
SSVC
Exploitation: none Automatable: no Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-15 19:04 UTC
CWE
  • CWE-290 - Authentication Bypass by Spoofing
References
Impacted products
Vendor Product Version
bookstackapp bookstack Affected: 0 , < 26.05.5 (custom)
    cpe:2.3:a:bookstackapp:bookstack:*:*:*:*:*:*:*:*
Create a notification for this product.
Date Public
2026-09-14 00:00
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-89022",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-15T19:04:04.179125Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-15T19:04:50.041Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageURL": "pkg:github/bookstackapp/bookstack",
          "product": "bookstack",
          "repo": "https://github.com/bookstackapp/bookstack",
          "vendor": "bookstackapp",
          "versions": [
            {
              "lessThan": "26.05.5",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:bookstackapp:bookstack:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "26.05.5",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Ada Logics"
        },
        {
          "lang": "en",
          "type": "finder",
          "value": "Google"
        }
      ],
      "datePublic": "2026-09-14T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "BookStack before 26.05.5 contains an authentication bypass vulnerability in its social login implementation that allows unauthenticated attackers to sign in as arbitrary users by authenticating through a different social provider sharing the same driver_id namespace. Attackers can authenticate at one enabled social provider using a user ID that matches an account linked to a different social provider, bypassing credential verification entirely because the SocialAuthService::handleLoginCallback query ignores the driver column when retrieving linked account records."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "HIGH",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 9.1,
            "baseSeverity": "CRITICAL",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 7.4,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-290",
              "description": "Authentication Bypass by Spoofing",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-01T15:21:50.290Z",
        "orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
        "shortName": "VulnCheck"
      },
      "references": [
        {
          "name": "Vendor Advisory",
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://www.bookstackapp.com/blog/bookstack-release-v26-05-5/"
        },
        {
          "tags": [
            "third-party-advisory"
          ],
          "url": "https://www.vulncheck.com/advisories/bookstack-authentication-bypass-via-social-login-provider-confusion"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "tags": [
        "x_open-source"
      ],
      "title": "BookStack \u003c 26.05.5 Authentication Bypass via Social Login Provider Confusion",
      "x_generator": {
        "engine": "vulncheck"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
    "assignerShortName": "VulnCheck",
    "cveId": "CVE-2026-89022",
    "datePublished": "2026-09-15T16:11:56.151Z",
    "dateReserved": "2026-09-10T16:23:54.471Z",
    "dateUpdated": "2026-10-01T15:21:50.290Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-88879 (GCVE-0-2026-88879)

Vulnerability from cvelistv5 – Published: 2026-09-10 13:05 – Updated: 2026-09-10 15:04
VLAI
Title
Traefik before v2.11.56 Identity Spoofing via Header Alias
Summary
Traefik is an HTTP reverse proxy and load balancer. In Traefik v1.x, v2.x through v2.11.55, and v3.0.0 through v3.7.11, header names are canonicalized only on dashes, so X-Auth-User, X_Auth_User and X.Auth.User are treated as three distinct headers by Traefik, while backends that derive variable names from header names (CGI, WSGI, PHP, NGINX and others) collapse them into a single variable. A client can therefore smuggle a dot-form alias of a header that Traefik manages past the middleware managing it — for example supplying X.Authenticated.User alongside the canonical X-Authenticated-User written by the ForwardAuth middleware — causing such a backend to read the client-supplied value instead of the identity Traefik asserted. In the tested configuration (PHP 8.2 built-in SAPI over an HTTP/1 backend path), Go's lexical header ordering makes the attacker-supplied value win deterministically, so a client that ForwardAuth admits as a low-privilege identity can be treated by the backend as a different user or role. Any header Traefik sets is affected, not only ForwardAuth's. This is an incomplete fix for GHSA-x677-9fxg-v5c5, which blocked only the underscore form. Fixed in v2.11.56 and v3.7.12, which add the aliasHeadersStrategy entry-point option; because it defaults to 'keep' for backwards compatibility, it must be explicitly set to 'delete' or 'reject' for the fix to take effect. Unmaintained release lines will not receive a patch.
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-10 15:03 UTC
CWE
  • CWE-290 - Authentication Bypass by Spoofing
References
Impacted products
Vendor Product Version
traefik traefik Affected: 0 , < 2.11.56 (semver)
Unaffected: 2.11.56 (semver)
Create a notification for this product.
traefik traefik Affected: 3.0.0 , ≤ 3.7.13 (semver)
Create a notification for this product.
Date Public
2026-08-27 00:00
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-88879",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-10T15:03:25.506535Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-10T15:04:00.316Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageURL": "pkg:golang/Traefik",
          "product": "traefik",
          "vendor": "traefik",
          "versions": [
            {
              "lessThan": "2.11.56",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "2.11.56",
              "versionType": "semver"
            }
          ]
        },
        {
          "defaultStatus": "unaffected",
          "packageURL": "pkg:golang/Traefik",
          "product": "traefik",
          "vendor": "traefik",
          "versions": [
            {
              "lessThanOrEqual": "3.7.13",
              "status": "affected",
              "version": "3.0.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:traefik:traefik:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "2.11.56",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        },
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:traefik:traefik:*:*:*:*:*:*:*:*",
                  "versionEndIncluding": "3.7.13",
                  "versionStartIncluding": "3.0.0",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "velgusgus599"
        }
      ],
      "datePublic": "2026-08-27T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "Traefik is an HTTP reverse proxy and load balancer. In Traefik v1.x, v2.x through v2.11.55, and v3.0.0 through v3.7.11, header names are canonicalized only on dashes, so X-Auth-User, X_Auth_User and X.Auth.User are treated as three distinct headers by Traefik, while backends that derive variable names from header names (CGI, WSGI, PHP, NGINX and others) collapse them into a single variable. A client can therefore smuggle a dot-form alias of a header that Traefik manages past the middleware managing it \u2014 for example supplying X.Authenticated.User alongside the canonical X-Authenticated-User written by the ForwardAuth middleware \u2014 causing such a backend to read the client-supplied value instead of the identity Traefik asserted. In the tested configuration (PHP 8.2 built-in SAPI over an HTTP/1 backend path), Go\u0027s lexical header ordering makes the attacker-supplied value win deterministically, so a client that ForwardAuth admits as a low-privilege identity can be treated by the backend as a different user or role. Any header Traefik sets is affected, not only ForwardAuth\u0027s. This is an incomplete fix for GHSA-x677-9fxg-v5c5, which blocked only the underscore form. Fixed in v2.11.56 and v3.7.12, which add the aliasHeadersStrategy entry-point option; because it defaults to \u0027keep\u0027 for backwards compatibility, it must be explicitly set to \u0027delete\u0027 or \u0027reject\u0027 for the fix to take effect. Unmaintained release lines will not receive a patch."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 5.3,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE"
          },
          "format": "CVSS"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-290",
              "description": "Authentication Bypass by Spoofing",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-10T13:05:30.872Z",
        "orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
        "shortName": "VulnCheck"
      },
      "references": [
        {
          "name": "GitHub Security Advisory (GHSA-rf44-j88r-hh8c)",
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://github.com/traefik/traefik/security/advisories/GHSA-rf44-j88r-hh8c"
        },
        {
          "name": "VulnCheck Advisory: Traefik before v2.11.56 Identity Spoofing via Header Alias",
          "tags": [
            "third-party-advisory"
          ],
          "url": "https://www.vulncheck.com/advisories/traefik-before-2.11.56-identity-spoofing-via-header-alias"
        }
      ],
      "title": "Traefik before v2.11.56 Identity Spoofing via Header Alias",
      "x_generator": {
        "engine": "vulncheck-endgame"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
    "assignerShortName": "VulnCheck",
    "cveId": "CVE-2026-88879",
    "datePublished": "2026-09-10T13:05:30.872Z",
    "dateReserved": "2026-09-10T11:24:26.196Z",
    "dateUpdated": "2026-09-10T15:04:00.316Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-88819 (GCVE-0-2026-88819)

Vulnerability from cvelistv5 – Published: 2026-09-14 15:32 – Updated: 2026-09-14 19:23
VLAI
Summary
In Siglet current and past versions the refresh token handler do not enforce proof of possession of the issuer DID.
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-14 19:12 UTC
CWE
  • CWE-290 - Authentication bypass by spoofing
  • CWE-345 - Insufficient Verification of Data Authenticity
Impacted products
Vendor Product Version
Eclipse Foundation Eclipse Data Plane Core Affected: a6f7d4cc0093931287c349e1e546ad2932c08e8d , < 882fe22db42bc67abfd0304c4cdb141b762c35d1 (git)
Affected: 0.1.0 , ≤ 0.1.3 (semver)
Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-88819",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-14T19:12:37.702936Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-14T19:23:00.453Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Eclipse Data Plane Core",
          "vendor": "Eclipse Foundation",
          "versions": [
            {
              "lessThan": "882fe22db42bc67abfd0304c4cdb141b762c35d1",
              "status": "affected",
              "version": "a6f7d4cc0093931287c349e1e546ad2932c08e8d",
              "versionType": "git"
            },
            {
              "lessThanOrEqual": "0.1.3",
              "status": "affected",
              "version": "0.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Eclipse Foundation Security Team"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "In Siglet current and past versions the refresh token handler do not enforce proof of possession of the issuer DID."
            }
          ],
          "value": "In Siglet current and past versions the refresh token handler do not enforce proof of possession of the issuer DID."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "HIGH",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 6.3,
            "baseSeverity": "MEDIUM",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "LOW",
            "vulnConfidentialityImpact": "LOW",
            "vulnIntegrityImpact": "LOW",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-290",
              "description": "CWE-290 Authentication bypass by spoofing",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-345",
              "description": "CWE-345 Insufficient Verification of Data Authenticity",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-14T15:32:36.047Z",
        "orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
        "shortName": "eclipse"
      },
      "references": [
        {
          "url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/work_items/931"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "x_generator": {
        "engine": "Vulnogram 1.0.5"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
    "assignerShortName": "eclipse",
    "cveId": "CVE-2026-88819",
    "datePublished": "2026-09-14T15:32:36.047Z",
    "dateReserved": "2026-09-10T08:53:25.943Z",
    "dateUpdated": "2026-09-14T19:23:00.453Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

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.