CWE-287
DiscouragedImproper 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.
6343 vulnerabilities reference this CWE, most recent first.
GHSA-X626-FCWX-F5PC
Vulnerability from github – Published: 2026-08-28 20:28 – Updated: 2026-08-28 20:28Summary
Portainer supports restoring an instance from a backup archive via the /api/restore endpoint. This endpoint is intentionally unauthenticated to allow restoring before the first admin account is created, and remains accessible for the five-minute initialization window that opens each time Portainer starts. Any unauthenticated attacker with network access to a Portainer instance that has not yet been initialised can exploit this window to replace the Portainer database with a crafted archive containing attacker-controlled credentials and gain full administrative access. The same unauthenticated setup window also exposes the administrator-account-creation endpoint (/api/users/admin/init), which an attacker can call to create the first administrator directly; the fix gates both endpoints.
The attack requires the instance to be uninitialized, reachable by the attacker, and within the five-minute window. Once that window expires without initialization, Portainer locks its API and requires a restart to re-enable setup — each restart opens a fresh window. No credentials, session tokens, or local access are required.
Severity
High
The endpoint requires no authentication and no user interaction, but successful exploitation depends on three conditions holding simultaneously: the instance must be uninitialized, reachable from the attacker's network, and within the five-minute setup window that Portainer enforces before locking the instance pending a restart. Once those conditions are met, the attack itself is straightforward — no specialized tooling or elevated privileges are needed. The vulnerable system impact is limited by the precondition: a brand new instance carries no confidential data, no existing users, and no running workloads, so the direct integrity and availability impact is low. The severity is driven entirely by the subsequent-system chain — Portainer CE is typically bound to a Docker socket that grants root-equivalent access to the host, and the compromised admin account inherits credentials and API access for every Docker host, Kubernetes cluster, and edge agent registered in the instance.
Affected Versions
The unauthenticated initialization path has been present since the backup/restore feature was introduced.
Fixes are included in the following releases:
| Branch | First vulnerable | Fixed in |
|---|---|---|
| 2.39.x (LTS) | 2.39.0 | 2.39.4 |
| 2.43.x (STS) | all prior | 2.43.0 |
Portainer releases prior to 2.39.0 are end-of-life and will not receive a fix. This includes the 2.33.x LTS line. Users on end-of-life versions should upgrade to a supported branch.
Workarounds
Administrators who cannot immediately upgrade can reduce exposure by:
- Provision the administrator account at deploy time. Start any network-reachable instance with
--admin-passwordor--admin-password-file, supplying a pre-set administrator password. The admin account then exists from first boot, so the instance is never in the uninitialised state that the restore and admin-init endpoints depend on — there is no setup window for an attacker to race. This is the most effective workaround for new, internet- or network-facing deployments. Instances on genuinely trusted networks (air-gapped or isolated private LANs) don't require it. - Restrict network access to Portainer before completing initial setup. Use firewall rules, VPC security groups, or a reverse proxy to prevent untrusted networks from reaching the Portainer API while the instance is uninitialised. Remove the restriction once an admin account has been created and initial setup is complete.
- Complete initial setup immediately after deployment. The initialization endpoints stop accepting requests once the instance has an administrator account. Minimising the uninitialised window limits the exploitation opportunity.
- Audit existing deployments for unauthorised admin accounts. If a deployment may have been accessible before setup was completed, review the admin account list and rotate all credentials.
None of these replace the fix.
Affected Code
The vulnerability is in api/http/handler/backup/handler.go and api/http/handler/backup/restore.go. The handler registers the restore endpoint with bouncer.PublicAccess, bypassing all authentication middleware:
// api/http/handler/backup/handler.go — NewHandler
h.Handle("/restore", bouncer.PublicAccess(httperror.LoggerHandler(h.restore))).Methods(http.MethodPost)
The restore handler then checks only whether the instance has been initialised before proceeding:
// api/http/handler/backup/restore.go — restore
func (h *Handler) restore(w http.ResponseWriter, r *http.Request) *httperror.HandlerError {
initialized, err := h.adminMonitor.WasInitialized()
if err != nil {
return httperror.InternalServerError("Failed to check system initialization", err)
}
if initialized {
return httperror.BadRequest("Cannot restore already initialized instance", errors.New("system already initialized"))
}
h.adminMonitor.Stop()
// Proceeds to restore the archive unconditionally
The fix introduces a one-time setup token that gates the public initialization endpoints — both administrator account creation (/api/users/admin/init) and restore (/api/restore) — while an instance is uninitialised. On startup, when no administrator account exists and no admin password was supplied through configuration, Portainer generates a cryptographically random token and writes it to the server logs. The restore and admin-init handlers reject any request that does not present this token in an X-Setup-Token header, returning 403 Forbidden. Deployments that provision the administrator password at deploy time (--admin-password / --admin-password-file) require no token; the requirement can be pinned to an operator-chosen value (--setup-token) or disabled on trusted networks (--no-setup-token). The same change is backported to release/2.39 for the 2.39.4 release.
Impact
- Full administrative access to Portainer. The attacker replaces the database with one containing their own admin credentials and can then authenticate as a full administrator with no legitimate-user involvement.
- Host-level compromise. Portainer CE typically runs with access to the Docker socket (
/var/run/docker.sock); an attacker with Portainer admin access can use container creation APIs to mount the host filesystem and execute commands as root. - Access to all managed environments. The compromised Portainer admin account has credentials and API access for every Docker host, Kubernetes cluster, and edge agent registered in that instance, including any stored registry credentials, environment variables, and secrets.
- Persistence across credential changes. Because the attacker controls the database, they can re-insert admin credentials or maintain secondary accounts even if a legitimate user later resets the primary password via the UI.
Timeline
- 2026-05-07: Reported privately by um3b0shi.
- 2026-06-04: Fix merged to
develop. - 2026-06-24: 2.43.0 (STS) released with the fix.
- 2026-06-25: 2.39.4 (LTS) released with the backported fix.
Credit
- um3b0shi — discovered and reported the unauthenticated admin takeover via the
/api/restoreendpoint. Coverage of the companion administrator-account-creation endpoint (/api/users/admin/init) was added by the Portainer team as part of the fix.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/portainer/portainer"
},
"ranges": [
{
"events": [
{
"introduced": "2.39.0"
},
{
"fixed": "2.39.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/portainer/portainer"
},
"ranges": [
{
"events": [
{
"introduced": "2.40.0"
},
{
"fixed": "2.43.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55761"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T20:28:19Z",
"nvd_published_at": "2026-07-08T16:16:31Z",
"severity": "HIGH"
},
"details": "## Summary\nPortainer supports restoring an instance from a backup archive via the /api/restore endpoint. This endpoint is intentionally unauthenticated to allow restoring before the first admin account is created, and remains accessible for the five-minute initialization window that opens each time Portainer starts. Any unauthenticated attacker with network access to a Portainer instance that has not yet been initialised can exploit this window to replace the Portainer database with a crafted archive containing attacker-controlled credentials and gain full administrative access. The same unauthenticated setup window also exposes the administrator-account-creation endpoint (`/api/users/admin/init`), which an attacker can call to create the first administrator directly; the fix gates both endpoints.\n\nThe attack requires the instance to be uninitialized, reachable by the attacker, and within the five-minute window. Once that window expires without initialization, Portainer locks its API and requires a restart to re-enable setup \u2014 each restart opens a fresh window. No credentials, session tokens, or local access are required.\n\n## Severity\n**High**\n\nThe endpoint requires no authentication and no user interaction, but successful exploitation depends on three conditions holding simultaneously: the instance must be uninitialized, reachable from the attacker\u0027s network, and within the five-minute setup window that Portainer enforces before locking the instance pending a restart. Once those conditions are met, the attack itself is straightforward \u2014 no specialized tooling or elevated privileges are needed. The vulnerable system impact is limited by the precondition: a brand new instance carries no confidential data, no existing users, and no running workloads, so the direct integrity and availability impact is low. The severity is driven entirely by the subsequent-system chain \u2014 Portainer CE is typically bound to a Docker socket that grants root-equivalent access to the host, and the compromised admin account inherits credentials and API access for every Docker host, Kubernetes cluster, and edge agent registered in the instance.\n\n## Affected Versions\n\nThe unauthenticated initialization path has been present since the backup/restore feature was introduced.\n\nFixes are included in the following releases:\n\n| Branch | First vulnerable | Fixed in |\n|--------------|------------------|------------|\n| 2.39.x (LTS) | 2.39.0 | **2.39.4** |\n| 2.43.x (STS) | all prior | **2.43.0** |\n\nPortainer releases prior to 2.39.0 are end-of-life and will not receive a fix. This includes the 2.33.x LTS line. Users on end-of-life versions should upgrade to a supported branch.\n\n## Workarounds\nAdministrators who cannot immediately upgrade can reduce exposure by:\n\n- **Provision the administrator account at deploy time.** Start any network-reachable instance with `--admin-password` or `--admin-password-file`, supplying a pre-set administrator password. The admin account then exists from first boot, so the instance is never in the uninitialised state that the restore and admin-init endpoints depend on \u2014 there is no setup window for an attacker to race. This is the most effective workaround for new, internet- or network-facing deployments. Instances on genuinely trusted networks (air-gapped or isolated private LANs) don\u0027t require it.\n- **Restrict network access to Portainer before completing initial setup.** Use firewall rules, VPC security groups, or a reverse proxy to prevent untrusted networks from reaching the Portainer API while the instance is uninitialised. Remove the restriction once an admin account has been created and initial setup is complete.\n- **Complete initial setup immediately after deployment.** The initialization endpoints stop accepting requests once the instance has an administrator account. Minimising the uninitialised window limits the exploitation opportunity.\n- **Audit existing deployments for unauthorised admin accounts.** If a deployment may have been accessible before setup was completed, review the admin account list and rotate all credentials.\n\nNone of these replace the fix.\n\n## Affected Code\nThe vulnerability is in `api/http/handler/backup/handler.go` and `api/http/handler/backup/restore.go`. The handler registers the restore endpoint with `bouncer.PublicAccess`, bypassing all authentication middleware:\n\n```go\n// api/http/handler/backup/handler.go \u2014 NewHandler\nh.Handle(\"/restore\", bouncer.PublicAccess(httperror.LoggerHandler(h.restore))).Methods(http.MethodPost)\n```\n\nThe restore handler then checks only whether the instance has been initialised before proceeding:\n\n```go\n// api/http/handler/backup/restore.go \u2014 restore\nfunc (h *Handler) restore(w http.ResponseWriter, r *http.Request) *httperror.HandlerError {\n initialized, err := h.adminMonitor.WasInitialized()\n if err != nil {\n return httperror.InternalServerError(\"Failed to check system initialization\", err)\n }\n if initialized {\n return httperror.BadRequest(\"Cannot restore already initialized instance\", errors.New(\"system already initialized\"))\n }\n h.adminMonitor.Stop()\n // Proceeds to restore the archive unconditionally\n```\n\nThe fix introduces a one-time setup token that gates the public initialization endpoints \u2014 both administrator account creation (`/api/users/admin/init`) and restore (`/api/restore`) \u2014 while an instance is uninitialised. On startup, when no administrator account exists and no admin password was supplied through configuration, Portainer generates a cryptographically random token and writes it to the server logs. The restore and admin-init handlers reject any request that does not present this token in an `X-Setup-Token` header, returning `403 Forbidden`. Deployments that provision the administrator password at deploy time (`--admin-password` / `--admin-password-file`) require no token; the requirement can be pinned to an operator-chosen value (`--setup-token`) or disabled on trusted networks (`--no-setup-token`). The same change is backported to `release/2.39` for the 2.39.4 release.\n\n## Impact\n- **Full administrative access to Portainer.** The attacker replaces the database with one containing their own admin credentials and can then authenticate as a full administrator with no legitimate-user involvement.\n- **Host-level compromise.** Portainer CE typically runs with access to the Docker socket (`/var/run/docker.sock`); an attacker with Portainer admin access can use container creation APIs to mount the host filesystem and execute commands as root.\n- **Access to all managed environments.** The compromised Portainer admin account has credentials and API access for every Docker host, Kubernetes cluster, and edge agent registered in that instance, including any stored registry credentials, environment variables, and secrets.\n- **Persistence across credential changes.** Because the attacker controls the database, they can re-insert admin credentials or maintain secondary accounts even if a legitimate user later resets the primary password via the UI.\n\n## Timeline\n- 2026-05-07: Reported privately by **um3b0shi**.\n- 2026-06-04: Fix merged to `develop`.\n- 2026-06-24: 2.43.0 (STS) released with the fix.\n- 2026-06-25: 2.39.4 (LTS) released with the backported fix.\n\n## Credit\n- **um3b0shi** \u2014 discovered and reported the unauthenticated admin takeover via the `/api/restore` endpoint. Coverage of the companion administrator-account-creation endpoint (`/api/users/admin/init`) was added by the Portainer team as part of the fix.",
"id": "GHSA-x626-fcwx-f5pc",
"modified": "2026-08-28T20:28:19Z",
"published": "2026-08-28T20:28:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/portainer/portainer/security/advisories/GHSA-x626-fcwx-f5pc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55761"
},
{
"type": "WEB",
"url": "https://github.com/portainer/portainer/issues/2770"
},
{
"type": "WEB",
"url": "https://github.com/portainer/portainer/commit/49f19107cf9a3540cbe406c9eb7f24390e1af02b"
},
{
"type": "WEB",
"url": "https://github.com/portainer/portainer/commit/d2b56efcb4e43c4168bb6688eee9f6bf22867312"
},
{
"type": "PACKAGE",
"url": "https://github.com/portainer/portainer"
},
{
"type": "WEB",
"url": "https://github.com/portainer/portainer/releases/tag/2.39.4"
},
{
"type": "WEB",
"url": "https://github.com/portainer/portainer/releases/tag/2.43.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "Portainer has Unauthenticated Restore Endpoint that Allows Admin Takeover on Uninitialized Instances"
}
GHSA-X637-X8P3-5P22
Vulnerability from github – Published: 2024-03-20 15:32 – Updated: 2024-12-05 22:17Spring Authorization Server versions 1.0.0 - 1.0.5, 1.1.0 - 1.1.5, 1.2.0 - 1.2.2 and older unsupported versions are susceptible to a PKCE Downgrade Attack for Confidential Clients.
Specifically, an application is vulnerable when a Confidential Client uses PKCE for the Authorization Code Grant.
An application is not vulnerable when a Public Client uses PKCE for the Authorization Code Grant.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-oauth2-authorization-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-oauth2-authorization-server"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0"
},
{
"fixed": "1.2.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-22258"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-470"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-20T17:09:02Z",
"nvd_published_at": "2024-03-20T04:15:08Z",
"severity": "MODERATE"
},
"details": "Spring Authorization Server versions 1.0.0 - 1.0.5, 1.1.0 - 1.1.5, 1.2.0 - 1.2.2 and older unsupported versions are susceptible to a PKCE Downgrade Attack for Confidential Clients.\n\nSpecifically, an application is vulnerable when a Confidential Client\u00a0uses PKCE for the Authorization Code Grant.\n\nAn application is not vulnerable when a Public Client\u00a0uses PKCE for the Authorization Code Grant.\n\n",
"id": "GHSA-x637-x8p3-5p22",
"modified": "2024-12-05T22:17:59Z",
"published": "2024-03-20T15:32:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22258"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-authorization-server/commit/a7035d22bd2de6c24e7125623d38fb83d8f659a9"
},
{
"type": "WEB",
"url": "https://spring.io/security/cve-2024-22258"
},
{
"type": "PACKAGE",
"url": "github.com/spring-projects/spring-authorization-server"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Improper Authentication in Spring Authorization Server"
}
GHSA-X64M-WG95-494X
Vulnerability from github – Published: 2026-01-20 03:30 – Updated: 2026-01-20 03:30A security flaw has been discovered in CRMEB up to 5.6.3. The affected element is the function appleLogin of the file crmeb/app/api/controller/v1/LoginController.php. Performing a manipulation of the argument openId results in improper authentication. The attack is possible to be carried out remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2026-1202"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-20T01:15:56Z",
"severity": "MODERATE"
},
"details": "A security flaw has been discovered in CRMEB up to 5.6.3. The affected element is the function appleLogin of the file crmeb/app/api/controller/v1/LoginController.php. Performing a manipulation of the argument openId results in improper authentication. The attack is possible to be carried out remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-x64m-wg95-494x",
"modified": "2026-01-20T03:30:28Z",
"published": "2026-01-20T03:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1202"
},
{
"type": "WEB",
"url": "https://github.com/foeCat/CVE/blob/main/CRMEB/apple_login_auth_bypass.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.341788"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.341788"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.734711"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-X67C-FH4P-7V8M
Vulnerability from github – Published: 2024-05-07 06:30 – Updated: 2024-05-07 06:30Improper Authentication vulnerability in Secure Folder prior to SMR May-2024 Release 1 allows physical attackers to access Secure Folder without proper authentication in a specific scenario.
{
"affected": [],
"aliases": [
"CVE-2024-20856"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-07T05:15:49Z",
"severity": "MODERATE"
},
"details": "Improper Authentication vulnerability in Secure Folder prior to SMR May-2024 Release 1 allows physical attackers to access Secure Folder without proper authentication in a specific scenario.",
"id": "GHSA-x67c-fh4p-7v8m",
"modified": "2024-05-07T06:30:36Z",
"published": "2024-05-07T06:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20856"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2024\u0026month=05"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-X69C-MG5C-F526
Vulnerability from github – Published: 2022-05-17 04:44 – Updated: 2022-05-17 04:44D-Link DIR-505L SharePort Mobile Companion 1.01 and DIR-826L Wireless N600 Cloud Router 1.02 allows remote attackers to bypass authentication via a direct request when an authorized session is active.
{
"affected": [],
"aliases": [
"CVE-2013-4772"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-05-12T14:55:00Z",
"severity": "HIGH"
},
"details": "D-Link DIR-505L SharePort Mobile Companion 1.01 and DIR-826L Wireless N600 Cloud Router 1.02 allows remote attackers to bypass authentication via a direct request when an authorized session is active.",
"id": "GHSA-x69c-mg5c-f526",
"modified": "2022-05-17T04:44:25Z",
"published": "2022-05-17T04:44:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-4772"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/122314/D-Link-DIR-505L-DIR-826L-Authentication-Bypass.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-X6FW-778M-WR9V
Vulnerability from github – Published: 2026-03-09 17:42 – Updated: 2026-03-09 17:42Impact
The Google, Apple, and Facebook authentication adapters use JWT verification to validate identity tokens. When the adapter's audience configuration option is not set (clientId for Google/Apple, appIds for Facebook), JWT verification silently skips audience claim validation. This allows an attacker to use a validly signed JWT issued for a different application to authenticate as any user on the target Parse Server.
- For Google and Apple, the vulnerability is exploitable when the server does not configure
clientId. The adapters accepted this as valid and simply skipped audience validation. - For Facebook Limited Login, the vulnerability exists regardless of configuration. The adapter validated
appIdsonly for Standard Login (Graph API), but the Limited Login JWT path never passedappIdsas the audience to JWT verification.
Patches
The fix enforces clientId (Google/Apple) and appIds (Facebook) as mandatory and passes them to JWT verification for audience validation. While this is technically a breaking change for servers that omit these options, it is not a breaking change as per documentation — all three options are documented as required configuration.
Workarounds
- Google / Apple: Ensure
clientIdis set in the adapter configuration. When set, JWT verification correctly validates the audience claim even on unpatched versions. - Facebook Limited Login: There is no workaround. The unpatched adapter does not pass
appIdsto JWT audience validation, so the only mitigation is to upgrade.
References
- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-x6fw-778m-wr9v
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.11
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.10
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "parse-server"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0-alpha.1"
},
{
"fixed": "9.5.0-alpha.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "parse-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.6.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30863"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-09T17:42:22Z",
"nvd_published_at": "2026-03-07T17:15:54Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nThe Google, Apple, and Facebook authentication adapters use JWT verification to validate identity tokens. When the adapter\u0027s audience configuration option is not set (`clientId` for Google/Apple, `appIds` for Facebook), JWT verification silently skips audience claim validation. This allows an attacker to use a validly signed JWT issued for a different application to authenticate as any user on the target Parse Server.\n\n- For Google and Apple, the vulnerability is exploitable when the server does not configure `clientId`. The adapters accepted this as valid and simply skipped audience validation.\n- For Facebook Limited Login, the vulnerability exists regardless of configuration. The adapter validated `appIds` only for Standard Login (Graph API), but the Limited Login JWT path never passed `appIds` as the audience to JWT verification.\n\n### Patches\n\nThe fix enforces `clientId` (Google/Apple) and `appIds` (Facebook) as mandatory and passes them to JWT verification for audience validation. While this is technically a breaking change for servers that omit these options, it is not a breaking change as per documentation \u2014 all three options are documented as required configuration.\n\n### Workarounds\n\n- Google / Apple: Ensure `clientId` is set in the adapter configuration. When set, JWT verification correctly validates the audience claim even on unpatched versions.\n- Facebook Limited Login: There is no workaround. The unpatched adapter does not pass `appIds` to JWT audience validation, so the only mitigation is to upgrade.\n\n### References\n\n- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-x6fw-778m-wr9v\n- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.11\n- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.10",
"id": "GHSA-x6fw-778m-wr9v",
"modified": "2026-03-09T17:42:22Z",
"published": "2026-03-09T17:42:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-x6fw-778m-wr9v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30863"
},
{
"type": "PACKAGE",
"url": "https://github.com/parse-community/parse-server"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Parse Server: JWT audience validation bypass in Google, Apple, and Facebook authentication adapters"
}
GHSA-X6GJ-R267-C9VW
Vulnerability from github – Published: 2022-05-17 03:11 – Updated: 2022-05-17 03:11The cherokee_validator_ldap_check function in validator_ldap.c in Cherokee 1.2.103 and earlier, when LDAP is used, does not properly consider unauthenticated-bind semantics, which allows remote attackers to bypass authentication via an empty password.
{
"affected": [],
"aliases": [
"CVE-2014-4668"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-07-02T04:14:00Z",
"severity": "MODERATE"
},
"details": "The cherokee_validator_ldap_check function in validator_ldap.c in Cherokee 1.2.103 and earlier, when LDAP is used, does not properly consider unauthenticated-bind semantics, which allows remote attackers to bypass authentication via an empty password.",
"id": "GHSA-x6gj-r267-c9vw",
"modified": "2022-05-17T03:11:37Z",
"published": "2022-05-17T03:11:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-4668"
},
{
"type": "WEB",
"url": "https://github.com/cherokee/webserver/commit/fbda667221c51f0aa476a02366e0cf66cb012f88"
},
{
"type": "WEB",
"url": "http://advisories.mageia.org/MGASA-2015-0181.html"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2015-April/155776.html"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2015-April/156162.html"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2015-April/156190.html"
},
{
"type": "WEB",
"url": "http://openwall.com/lists/oss-security/2014/06/28/3"
},
{
"type": "WEB",
"url": "http://openwall.com/lists/oss-security/2014/06/28/7"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDVSA-2015:225"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/68249"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-X6GV-2R2J-Q73M
Vulnerability from github – Published: 2022-05-02 04:00 – Updated: 2022-05-02 04:00CRE Loaded before 6.2.14, and possibly other versions before 6.3.x, allows remote attackers to bypass authentication and gain administrator privileges via a request with (1) login.php or (2) password_forgotten.php appended as the PATH_INFO, which bypasses a check that uses PHP_SELF, which is not properly handled by (a) includes/application_top.php and (b) admin/includes/application_top.php, as exploited in the wild in 2009.
{
"affected": [],
"aliases": [
"CVE-2009-5076"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2011-06-08T10:36:00Z",
"severity": "HIGH"
},
"details": "CRE Loaded before 6.2.14, and possibly other versions before 6.3.x, allows remote attackers to bypass authentication and gain administrator privileges via a request with (1) login.php or (2) password_forgotten.php appended as the PATH_INFO, which bypasses a check that uses PHP_SELF, which is not properly handled by (a) includes/application_top.php and (b) admin/includes/application_top.php, as exploited in the wild in 2009.",
"id": "GHSA-x6gv-2r2j-q73m",
"modified": "2022-05-02T04:00:52Z",
"published": "2022-05-02T04:00:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-5076"
},
{
"type": "WEB",
"url": "https://www.creloaded.com/fdm_file_detail.php?file_id=191"
},
{
"type": "WEB",
"url": "http://hosting-4-creloaded.com/node/116"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-X6RR-9JXR-VQVG
Vulnerability from github – Published: 2026-08-25 12:31 – Updated: 2026-08-25 12:31A vulnerability was found in liketrek TREK up to 3.0.22. Impacted is the function loginUser of the file server/src/services/authService.ts of the component Pre-2FA mfa_token Handler. The manipulation results in improper authentication. The attack may be performed from remote. Upgrading to version 3.1.0 is recommended to address this issue. Upgrading the affected component is recommended.
{
"affected": [],
"aliases": [
"CVE-2026-78863"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-25T11:16:54Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in liketrek TREK up to 3.0.22. Impacted is the function loginUser of the file server/src/services/authService.ts of the component Pre-2FA mfa_token Handler. The manipulation results in improper authentication. The attack may be performed from remote. Upgrading to version 3.1.0 is recommended to address this issue. Upgrading the affected component is recommended.",
"id": "GHSA-x6rr-9jxr-vqvg",
"modified": "2026-08-25T12:31:23Z",
"published": "2026-08-25T12:31:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mauriceboe/TREK/security/advisories/GHSA-mjh4-w6fq-54qm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78863"
},
{
"type": "WEB",
"url": "https://github.com/liketrek/TREK/releases/tag/v3.1.0"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-78863"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/886929"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/394939"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/394939/cti"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-X6X2-P3PJ-7MV4
Vulnerability from github – Published: 2022-05-03 03:25 – Updated: 2022-05-03 03:25The Local Security Authority Subsystem Service (LSASS) in Microsoft Windows XP SP2 and SP3 and Server 2003 SP2 does not properly process authentication requests, which allows local users to gain privileges via a request with a crafted length, aka "LSASS Length Validation Vulnerability."
{
"affected": [],
"aliases": [
"CVE-2011-0039"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2011-02-09T01:00:00Z",
"severity": "HIGH"
},
"details": "The Local Security Authority Subsystem Service (LSASS) in Microsoft Windows XP SP2 and SP3 and Server 2003 SP2 does not properly process authentication requests, which allows local users to gain privileges via a request with a crafted length, aka \"LSASS Length Validation Vulnerability.\"",
"id": "GHSA-x6x2-p3pj-7mv4",
"modified": "2022-05-03T03:25:30Z",
"published": "2022-05-03T03:25:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-0039"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2011/ms11-014"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A12537"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/43253"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/46152"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id?1025049"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2011/0327"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
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.