CVE-2026-66882 (GCVE-0-2026-66882)

Vulnerability from cvelistv5 – Published: 2026-08-25 08:03 – Updated: 2026-08-25 19:51
VLAI
Title
Reflected XSS in AshAuthentication confirmation and magic link interaction forms
Summary
Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms. When a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input's value attribute without HTML escaping: lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex interpolates the confirm parameter, and lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex interpolates the magic link token parameter. These templates are compiled with EEx.function_from_file/3 using plain <%= %> expressions, which perform no escaping, so the parameter is reflected verbatim. Neither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a <script> element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required. The injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin's cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target. This issue affects ash_authentication: from 4.8.0 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.
Severity
2.1 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N
SSVC
Exploitation: poc Automatable: no Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-25 19:50 UTC
CWE
  • CWE-79 - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Assigner
References
Impacted products
Vendor Product Version CPE status
team-alembic ash_authentication Affected: 4.8.0 , < 4.14.2 (semver)
Affected: 5.0.0-rc.0 , < 5.0.0-rc.13 (semver)
    cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*
Create a notification for this product.
team-alembic ash_authentication Affected: fe0b4558dbe852fee5d81a460a8355577618a8c8 , < * (git)
    cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*
Create a notification for this product.
Credits
Arpit Jain James Harton Jonatan Männchen / EEF
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-66882",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-25T19:50:10.506279Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-25T19:51:21.332Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-54fc-x3hv-ffhw"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.hex.pm",
          "cpes": [
            "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "modules": [
            "\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027",
            "\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027"
          ],
          "packageName": "ash_authentication",
          "packageURL": "pkg:hex/ash_authentication",
          "product": "ash_authentication",
          "programFiles": [
            "lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex",
            "lib/ash_authentication/strategies/magic_link/plug.ex",
            "lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex",
            "lib/ash_authentication/add_ons/confirmation/plug.ex"
          ],
          "programRoutines": [
            {
              "name": "\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027:accept/2"
            },
            {
              "name": "\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027:accept/2"
            }
          ],
          "repo": "https://github.com/team-alembic/ash_authentication",
          "vendor": "team-alembic",
          "versions": [
            {
              "lessThan": "4.14.2",
              "status": "affected",
              "version": "4.8.0",
              "versionType": "semver"
            },
            {
              "lessThan": "5.0.0-rc.13",
              "status": "affected",
              "version": "5.0.0-rc.0",
              "versionType": "semver"
            }
          ]
        },
        {
          "collectionURL": "https://github.com",
          "cpes": [
            "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "modules": [
            "\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027",
            "\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027"
          ],
          "packageName": "team-alembic/ash_authentication",
          "packageURL": "pkg:github/team-alembic/ash_authentication",
          "product": "ash_authentication",
          "programFiles": [
            "lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex",
            "lib/ash_authentication/strategies/magic_link/plug.ex",
            "lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex",
            "lib/ash_authentication/add_ons/confirmation/plug.ex"
          ],
          "programRoutines": [
            {
              "name": "\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027:accept/2"
            },
            {
              "name": "\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027:accept/2"
            }
          ],
          "repo": "https://github.com/team-alembic/ash_authentication",
          "vendor": "team-alembic",
          "versions": [
            {
              "changes": [
                {
                  "at": "62719710790a150a9eacab9c0a066e0d122d15be",
                  "status": "unaffected"
                },
                {
                  "at": "0bd5199db066be22b2ca1ec8bc6109e5d62e6070",
                  "status": "unaffected"
                }
              ],
              "lessThan": "*",
              "status": "affected",
              "version": "fe0b4558dbe852fee5d81a460a8355577618a8c8",
              "versionType": "git"
            }
          ]
        }
      ],
      "configurations": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eOnly strategies configured with \u003ccode\u003erequire_interaction?\u003c/code\u003e set to \u003ccode\u003etrue\u003c/code\u003e are affected. This option defaults to \u003ccode\u003efalse\u003c/code\u003e, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.\u003c/p\u003e\n\u003cp\u003eThe option is not obscure: AshAuthentication\u0027s own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.\u003c/p\u003e\n\u003cp\u003eAt least one of the following must be configured with \u003ccode\u003erequire_interaction? true\u003c/code\u003e:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ethe \u003ccode\u003econfirmation\u003c/code\u003e add-on, which serves the affected confirmation accept form; or\u003c/li\u003e\n\u003cli\u003ethe \u003ccode\u003emagic_link\u003c/code\u003e strategy, which serves the affected sign-in accept form.\u003c/li\u003e\n\u003c/ul\u003e"
            },
            {
              "base64": false,
              "type": "text/markdown",
              "value": "Only strategies configured with `require_interaction?` set to `true` are affected. This option defaults to `false`, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.\n\nThe option is not obscure: AshAuthentication\u0027s own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.\n\nAt least one of the following must be configured with `require_interaction? true`:\n\n- the `confirmation` add-on, which serves the affected confirmation accept form; or\n- the `magic_link` strategy, which serves the affected sign-in accept form."
            }
          ],
          "value": "Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.\n\nThe option is not obscure: AshAuthentication\u0027s own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.\n\nAt least one of the following must be configured with require_interaction? true:\n\n* the confirmation add-on, which serves the affected confirmation accept form; or\n* the magic_link strategy, which serves the affected sign-in accept form."
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.14.2",
                  "versionStartIncluding": "4.8.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.0.0-rc.13",
                  "versionStartIncluding": "5.0.0-rc.0",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ],
          "operator": "AND"
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Arpit Jain"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "James Harton"
        },
        {
          "lang": "en",
          "type": "coordinator",
          "value": "Jonatan M\u00e4nnchen / EEF"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eImproper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.\u003c/p\u003e\n\u003cp\u003eWhen a strategy is configured with \u003ccode\u003erequire_interaction?\u003c/code\u003e set to \u003ccode\u003etrue\u003c/code\u003e, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input\u0027s \u003ccode\u003evalue\u003c/code\u003e attribute without HTML escaping: \u003ccode\u003elib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex\u003c/code\u003e interpolates the \u003ccode\u003econfirm\u003c/code\u003e parameter, and \u003ccode\u003elib/ash_authentication/strategies/magic_link/sign_in_form.html.eex\u003c/code\u003e interpolates the magic link token parameter. These templates are compiled with \u003ccode\u003eEEx.function_from_file/3\u003c/code\u003e using plain \u003ccode\u003e\u0026lt;%= %\u0026gt;\u003c/code\u003e expressions, which perform no escaping, so the parameter is reflected verbatim.\u003c/p\u003e\n\u003cp\u003eNeither accept handler validates the value before rendering it. \u003ccode\u003eAshAuthentication.AddOn.Confirmation.Plug.accept/2\u003c/code\u003e only checks that a \u003ccode\u003econfirm\u003c/code\u003e key is present, and \u003ccode\u003eAshAuthentication.Strategy.MagicLink.Plug.accept/2\u003c/code\u003e reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a \u003ccode\u003e\u0026lt;script\u0026gt;\u003c/code\u003e element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.\u003c/p\u003e\n\u003cp\u003eThe injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin\u0027s cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.\u003c/p\u003e\n\u003cp\u003eThis issue affects ash_authentication: from 4.8.0 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.\u003c/p\u003e"
            },
            {
              "base64": false,
              "type": "text/markdown",
              "value": "Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.\n\nWhen a strategy is configured with `require_interaction?` set to `true`, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input\u0027s `value` attribute without HTML escaping: `lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex` interpolates the `confirm` parameter, and `lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex` interpolates the magic link token parameter. These templates are compiled with `EEx.function_from_file/3` using plain `\u003c%= %\u003e` expressions, which perform no escaping, so the parameter is reflected verbatim.\n\nNeither accept handler validates the value before rendering it. `AshAuthentication.AddOn.Confirmation.Plug.accept/2` only checks that a `confirm` key is present, and `AshAuthentication.Strategy.MagicLink.Plug.accept/2` reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a `\u003cscript\u003e` element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.\n\nThe injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin\u0027s cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.\n\nThis issue affects ash_authentication: from 4.8.0 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13."
            }
          ],
          "value": "Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.\n\nWhen a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input\u0027s value attribute without HTML escaping: lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex interpolates the confirm parameter, and lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex interpolates the magic link token parameter. These templates are compiled with EEx.function_from_file/3 using plain \u003c%= %\u003e expressions, which perform no escaping, so the parameter is reflected verbatim.\n\nNeither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a \u003cscript\u003e element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.\n\nThe injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin\u0027s cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.\n\nThis issue affects ash_authentication: from 4.8.0 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-591",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-591 Reflected XSS"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 2.1,
            "baseSeverity": "LOW",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "LOW",
            "subIntegrityImpact": "LOW",
            "userInteraction": "ACTIVE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-79",
              "description": "CWE-79 Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-25T08:03:47.721Z",
        "orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
        "shortName": "EEF"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory",
            "related"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-54fc-x3hv-ffhw"
        },
        {
          "tags": [
            "related"
          ],
          "url": "https://cna.erlef.org/cves/CVE-2026-66882.html"
        },
        {
          "tags": [
            "related"
          ],
          "url": "https://osv.dev/vulnerability/EEF-CVE-2026-66882"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/commit/62719710790a150a9eacab9c0a066e0d122d15be"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/team-alembic/ash_authentication/commit/0bd5199db066be22b2ca1ec8bc6109e5d62e6070"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Reflected XSS in AshAuthentication confirmation and magic link interaction forms"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
    "assignerShortName": "EEF",
    "cveId": "CVE-2026-66882",
    "datePublished": "2026-08-25T08:03:47.721Z",
    "dateReserved": "2026-07-28T04:15:10.240Z",
    "dateUpdated": "2026-08-25T19:51:21.332Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-66882",
      "date": "2026-08-25",
      "epss": "0.00417",
      "percentile": "0.34527"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-66882\",\"sourceIdentifier\":\"6b3ad84c-e1a6-4bf7-a703-f496b71e49db\",\"published\":\"2026-08-25T08:18:10.143\",\"lastModified\":\"2026-08-25T20:17:01.407\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.\\n\\nWhen a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input\u0027s value attribute without HTML escaping: lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex interpolates the confirm parameter, and lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex interpolates the magic link token parameter. These templates are compiled with EEx.function_from_file/3 using plain \u003c%= %\u003e expressions, which perform no escaping, so the parameter is reflected verbatim.\\n\\nNeither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a \u003cscript\u003e element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.\\n\\nThe injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin\u0027s cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.\\n\\nThis issue affects ash_authentication: from 4.8.0 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.\"}],\"affected\":[{\"source\":\"6b3ad84c-e1a6-4bf7-a703-f496b71e49db\",\"affectedData\":[{\"vendor\":\"team-alembic\",\"product\":\"ash_authentication\",\"defaultStatus\":\"unaffected\",\"collectionURL\":\"https://repo.hex.pm\",\"packageName\":\"ash_authentication\",\"cpes\":[\"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*\"],\"modules\":[\"\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027\",\"\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027\"],\"programFiles\":[\"lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex\",\"lib/ash_authentication/strategies/magic_link/plug.ex\",\"lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex\",\"lib/ash_authentication/add_ons/confirmation/plug.ex\"],\"programRoutines\":[{\"name\":\"\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027:accept/2\"},{\"name\":\"\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027:accept/2\"}],\"repo\":\"https://github.com/team-alembic/ash_authentication\",\"packageURL\":\"pkg:hex/ash_authentication\",\"versions\":[{\"version\":\"4.8.0\",\"lessThan\":\"4.14.2\",\"versionType\":\"semver\",\"status\":\"affected\"},{\"version\":\"5.0.0-rc.0\",\"lessThan\":\"5.0.0-rc.13\",\"versionType\":\"semver\",\"status\":\"affected\"}]},{\"vendor\":\"team-alembic\",\"product\":\"ash_authentication\",\"defaultStatus\":\"unaffected\",\"collectionURL\":\"https://github.com\",\"packageName\":\"team-alembic/ash_authentication\",\"cpes\":[\"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*\"],\"modules\":[\"\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027\",\"\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027\"],\"programFiles\":[\"lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex\",\"lib/ash_authentication/strategies/magic_link/plug.ex\",\"lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex\",\"lib/ash_authentication/add_ons/confirmation/plug.ex\"],\"programRoutines\":[{\"name\":\"\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027:accept/2\"},{\"name\":\"\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027:accept/2\"}],\"repo\":\"https://github.com/team-alembic/ash_authentication\",\"packageURL\":\"pkg:github/team-alembic/ash_authentication\",\"versions\":[{\"version\":\"fe0b4558dbe852fee5d81a460a8355577618a8c8\",\"lessThan\":\"*\",\"versionType\":\"git\",\"status\":\"affected\",\"changes\":[{\"at\":\"62719710790a150a9eacab9c0a066e0d122d15be\",\"status\":\"unaffected\"},{\"at\":\"0bd5199db066be22b2ca1ec8bc6109e5d62e6070\",\"status\":\"unaffected\"}]}]}]}],\"metrics\":{\"cvssMetricV40\":[{\"source\":\"6b3ad84c-e1a6-4bf7-a703-f496b71e49db\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"4.0\",\"vectorString\":\"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/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\",\"baseScore\":2.1,\"baseSeverity\":\"LOW\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"attackRequirements\":\"PRESENT\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"ACTIVE\",\"vulnConfidentialityImpact\":\"NONE\",\"vulnIntegrityImpact\":\"NONE\",\"vulnAvailabilityImpact\":\"NONE\",\"subConfidentialityImpact\":\"LOW\",\"subIntegrityImpact\":\"LOW\",\"subAvailabilityImpact\":\"NONE\",\"exploitMaturity\":\"NOT_DEFINED\",\"confidentialityRequirement\":\"NOT_DEFINED\",\"integrityRequirement\":\"NOT_DEFINED\",\"availabilityRequirement\":\"NOT_DEFINED\",\"modifiedAttackVector\":\"NOT_DEFINED\",\"modifiedAttackComplexity\":\"NOT_DEFINED\",\"modifiedAttackRequirements\":\"NOT_DEFINED\",\"modifiedPrivilegesRequired\":\"NOT_DEFINED\",\"modifiedUserInteraction\":\"NOT_DEFINED\",\"modifiedVulnConfidentialityImpact\":\"NOT_DEFINED\",\"modifiedVulnIntegrityImpact\":\"NOT_DEFINED\",\"modifiedVulnAvailabilityImpact\":\"NOT_DEFINED\",\"modifiedSubConfidentialityImpact\":\"NOT_DEFINED\",\"modifiedSubIntegrityImpact\":\"NOT_DEFINED\",\"modifiedSubAvailabilityImpact\":\"NOT_DEFINED\",\"Safety\":\"NOT_DEFINED\",\"Automatable\":\"NOT_DEFINED\",\"Recovery\":\"NOT_DEFINED\",\"valueDensity\":\"NOT_DEFINED\",\"vulnerabilityResponseEffort\":\"NOT_DEFINED\",\"providerUrgency\":\"NOT_DEFINED\"}}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2026-08-25T19:50:10.506279Z\",\"id\":\"CVE-2026-66882\",\"options\":[{\"exploitation\":\"poc\"},{\"automatable\":\"no\"},{\"technicalImpact\":\"partial\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"6b3ad84c-e1a6-4bf7-a703-f496b71e49db\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-79\"}]}],\"references\":[{\"url\":\"https://cna.erlef.org/cves/CVE-2026-66882.html\",\"source\":\"6b3ad84c-e1a6-4bf7-a703-f496b71e49db\"},{\"url\":\"https://github.com/team-alembic/ash_authentication/commit/0bd5199db066be22b2ca1ec8bc6109e5d62e6070\",\"source\":\"6b3ad84c-e1a6-4bf7-a703-f496b71e49db\"},{\"url\":\"https://github.com/team-alembic/ash_authentication/commit/62719710790a150a9eacab9c0a066e0d122d15be\",\"source\":\"6b3ad84c-e1a6-4bf7-a703-f496b71e49db\"},{\"url\":\"https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-54fc-x3hv-ffhw\",\"source\":\"6b3ad84c-e1a6-4bf7-a703-f496b71e49db\"},{\"url\":\"https://osv.dev/vulnerability/EEF-CVE-2026-66882\",\"source\":\"6b3ad84c-e1a6-4bf7-a703-f496b71e49db\"},{\"url\":\"https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-54fc-x3hv-ffhw\",\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\"}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-66882\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"poc\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-08-25T19:50:10.506279Z\"}}}], \"references\": [{\"url\": \"https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-54fc-x3hv-ffhw\", \"tags\": [\"exploit\"]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-08-25T19:51:13.735Z\"}}], \"cna\": {\"title\": \"Reflected XSS in AshAuthentication confirmation and magic link interaction forms\", \"source\": {\"discovery\": \"EXTERNAL\"}, \"credits\": [{\"lang\": \"en\", \"type\": \"finder\", \"value\": \"Arpit Jain\"}, {\"lang\": \"en\", \"type\": \"remediation developer\", \"value\": \"James Harton\"}, {\"lang\": \"en\", \"type\": \"coordinator\", \"value\": \"Jonatan M\\u00e4nnchen / EEF\"}], \"impacts\": [{\"capecId\": \"CAPEC-591\", \"descriptions\": [{\"lang\": \"en\", \"value\": \"CAPEC-591 Reflected XSS\"}]}], \"metrics\": [{\"format\": \"CVSS\", \"cvssV4_0\": {\"Safety\": \"NOT_DEFINED\", \"version\": \"4.0\", \"Recovery\": \"NOT_DEFINED\", \"baseScore\": 2.1, \"Automatable\": \"NOT_DEFINED\", \"attackVector\": \"NETWORK\", \"baseSeverity\": \"LOW\", \"valueDensity\": \"NOT_DEFINED\", \"vectorString\": \"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N\", \"providerUrgency\": \"NOT_DEFINED\", \"userInteraction\": \"ACTIVE\", \"attackComplexity\": \"LOW\", \"attackRequirements\": \"PRESENT\", \"privilegesRequired\": \"NONE\", \"subIntegrityImpact\": \"LOW\", \"vulnIntegrityImpact\": \"NONE\", \"subAvailabilityImpact\": \"NONE\", \"vulnAvailabilityImpact\": \"NONE\", \"subConfidentialityImpact\": \"LOW\", \"vulnConfidentialityImpact\": \"NONE\", \"vulnerabilityResponseEffort\": \"NOT_DEFINED\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"GENERAL\"}]}], \"affected\": [{\"cpes\": [\"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*\"], \"repo\": \"https://github.com/team-alembic/ash_authentication\", \"vendor\": \"team-alembic\", \"modules\": [\"\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027\", \"\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027\"], \"product\": \"ash_authentication\", \"versions\": [{\"status\": \"affected\", \"version\": \"4.8.0\", \"lessThan\": \"4.14.2\", \"versionType\": \"semver\"}, {\"status\": \"affected\", \"version\": \"5.0.0-rc.0\", \"lessThan\": \"5.0.0-rc.13\", \"versionType\": \"semver\"}], \"packageURL\": \"pkg:hex/ash_authentication\", \"packageName\": \"ash_authentication\", \"programFiles\": [\"lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex\", \"lib/ash_authentication/strategies/magic_link/plug.ex\", \"lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex\", \"lib/ash_authentication/add_ons/confirmation/plug.ex\"], \"collectionURL\": \"https://repo.hex.pm\", \"defaultStatus\": \"unaffected\", \"programRoutines\": [{\"name\": \"\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027:accept/2\"}, {\"name\": \"\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027:accept/2\"}]}, {\"cpes\": [\"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*\"], \"repo\": \"https://github.com/team-alembic/ash_authentication\", \"vendor\": \"team-alembic\", \"modules\": [\"\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027\", \"\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027\"], \"product\": \"ash_authentication\", \"versions\": [{\"status\": \"affected\", \"changes\": [{\"at\": \"62719710790a150a9eacab9c0a066e0d122d15be\", \"status\": \"unaffected\"}, {\"at\": \"0bd5199db066be22b2ca1ec8bc6109e5d62e6070\", \"status\": \"unaffected\"}], \"version\": \"fe0b4558dbe852fee5d81a460a8355577618a8c8\", \"lessThan\": \"*\", \"versionType\": \"git\"}], \"packageURL\": \"pkg:github/team-alembic/ash_authentication\", \"packageName\": \"team-alembic/ash_authentication\", \"programFiles\": [\"lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex\", \"lib/ash_authentication/strategies/magic_link/plug.ex\", \"lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex\", \"lib/ash_authentication/add_ons/confirmation/plug.ex\"], \"collectionURL\": \"https://github.com\", \"defaultStatus\": \"unaffected\", \"programRoutines\": [{\"name\": \"\u0027Elixir.AshAuthentication.Strategy.MagicLink.Plug\u0027:accept/2\"}, {\"name\": \"\u0027Elixir.AshAuthentication.AddOn.Confirmation.Plug\u0027:accept/2\"}]}], \"references\": [{\"url\": \"https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-54fc-x3hv-ffhw\", \"tags\": [\"vendor-advisory\", \"related\"]}, {\"url\": \"https://cna.erlef.org/cves/CVE-2026-66882.html\", \"tags\": [\"related\"]}, {\"url\": \"https://osv.dev/vulnerability/EEF-CVE-2026-66882\", \"tags\": [\"related\"]}, {\"url\": \"https://github.com/team-alembic/ash_authentication/commit/62719710790a150a9eacab9c0a066e0d122d15be\", \"tags\": [\"patch\"]}, {\"url\": \"https://github.com/team-alembic/ash_authentication/commit/0bd5199db066be22b2ca1ec8bc6109e5d62e6070\", \"tags\": [\"patch\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.\\n\\nWhen a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input\u0027s value attribute without HTML escaping: lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex interpolates the confirm parameter, and lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex interpolates the magic link token parameter. These templates are compiled with EEx.function_from_file/3 using plain \u003c%= %\u003e expressions, which perform no escaping, so the parameter is reflected verbatim.\\n\\nNeither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a \u003cscript\u003e element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.\\n\\nThe injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin\u0027s cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.\\n\\nThis issue affects ash_authentication: from 4.8.0 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.\", \"supportingMedia\": [{\"type\": \"text/html\", \"value\": \"\u003cp\u003eImproper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.\u003c/p\u003e\\n\u003cp\u003eWhen a strategy is configured with \u003ccode\u003erequire_interaction?\u003c/code\u003e set to \u003ccode\u003etrue\u003c/code\u003e, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input\u0027s \u003ccode\u003evalue\u003c/code\u003e attribute without HTML escaping: \u003ccode\u003elib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex\u003c/code\u003e interpolates the \u003ccode\u003econfirm\u003c/code\u003e parameter, and \u003ccode\u003elib/ash_authentication/strategies/magic_link/sign_in_form.html.eex\u003c/code\u003e interpolates the magic link token parameter. These templates are compiled with \u003ccode\u003eEEx.function_from_file/3\u003c/code\u003e using plain \u003ccode\u003e\u0026lt;%= %\u0026gt;\u003c/code\u003e expressions, which perform no escaping, so the parameter is reflected verbatim.\u003c/p\u003e\\n\u003cp\u003eNeither accept handler validates the value before rendering it. \u003ccode\u003eAshAuthentication.AddOn.Confirmation.Plug.accept/2\u003c/code\u003e only checks that a \u003ccode\u003econfirm\u003c/code\u003e key is present, and \u003ccode\u003eAshAuthentication.Strategy.MagicLink.Plug.accept/2\u003c/code\u003e reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a \u003ccode\u003e\u0026lt;script\u0026gt;\u003c/code\u003e element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.\u003c/p\u003e\\n\u003cp\u003eThe injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin\u0027s cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.\u003c/p\u003e\\n\u003cp\u003eThis issue affects ash_authentication: from 4.8.0 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.\u003c/p\u003e\", \"base64\": false}, {\"type\": \"text/markdown\", \"value\": \"Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.\\n\\nWhen a strategy is configured with `require_interaction?` set to `true`, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input\u0027s `value` attribute without HTML escaping: `lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex` interpolates the `confirm` parameter, and `lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex` interpolates the magic link token parameter. These templates are compiled with `EEx.function_from_file/3` using plain `\u003c%= %\u003e` expressions, which perform no escaping, so the parameter is reflected verbatim.\\n\\nNeither accept handler validates the value before rendering it. `AshAuthentication.AddOn.Confirmation.Plug.accept/2` only checks that a `confirm` key is present, and `AshAuthentication.Strategy.MagicLink.Plug.accept/2` reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a `\u003cscript\u003e` element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.\\n\\nThe injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin\u0027s cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.\\n\\nThis issue affects ash_authentication: from 4.8.0 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.\", \"base64\": false}]}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-79\", \"description\": \"CWE-79 Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027)\"}]}], \"configurations\": [{\"lang\": \"en\", \"value\": \"Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.\\n\\nThe option is not obscure: AshAuthentication\u0027s own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.\\n\\nAt least one of the following must be configured with require_interaction? true:\\n\\n* the confirmation add-on, which serves the affected confirmation accept form; or\\n* the magic_link strategy, which serves the affected sign-in accept form.\", \"supportingMedia\": [{\"type\": \"text/html\", \"value\": \"\u003cp\u003eOnly strategies configured with \u003ccode\u003erequire_interaction?\u003c/code\u003e set to \u003ccode\u003etrue\u003c/code\u003e are affected. This option defaults to \u003ccode\u003efalse\u003c/code\u003e, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.\u003c/p\u003e\\n\u003cp\u003eThe option is not obscure: AshAuthentication\u0027s own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.\u003c/p\u003e\\n\u003cp\u003eAt least one of the following must be configured with \u003ccode\u003erequire_interaction? true\u003c/code\u003e:\u003c/p\u003e\\n\u003cul\u003e\\n\u003cli\u003ethe \u003ccode\u003econfirmation\u003c/code\u003e add-on, which serves the affected confirmation accept form; or\u003c/li\u003e\\n\u003cli\u003ethe \u003ccode\u003emagic_link\u003c/code\u003e strategy, which serves the affected sign-in accept form.\u003c/li\u003e\\n\u003c/ul\u003e\", \"base64\": false}, {\"type\": \"text/markdown\", \"value\": \"Only strategies configured with `require_interaction?` set to `true` are affected. This option defaults to `false`, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.\\n\\nThe option is not obscure: AshAuthentication\u0027s own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.\\n\\nAt least one of the following must be configured with `require_interaction? true`:\\n\\n- the `confirmation` add-on, which serves the affected confirmation accept form; or\\n- the `magic_link` strategy, which serves the affected sign-in accept form.\", \"base64\": false}]}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"4.14.2\", \"versionStartIncluding\": \"4.8.0\"}, {\"criteria\": \"cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.0.0-rc.13\", \"versionStartIncluding\": \"5.0.0-rc.0\"}], \"operator\": \"OR\"}], \"operator\": \"AND\"}], \"providerMetadata\": {\"orgId\": \"6b3ad84c-e1a6-4bf7-a703-f496b71e49db\", \"shortName\": \"EEF\", \"dateUpdated\": \"2026-08-25T08:03:47.721Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-66882\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-08-25T19:51:21.332Z\", \"dateReserved\": \"2026-07-28T04:15:10.240Z\", \"assignerOrgId\": \"6b3ad84c-e1a6-4bf7-a703-f496b71e49db\", \"datePublished\": \"2026-08-25T08:03:47.721Z\", \"assignerShortName\": \"EEF\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.