CWE-306
AllowedMissing Authentication for Critical Function
Abstraction: Base · Status: Draft
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
3570 vulnerabilities reference this CWE, most recent first.
GHSA-8JR5-6GVJ-RFPF
Vulnerability from github – Published: 2026-05-09 00:10 – Updated: 2026-06-08 23:34SSE Transport Has No Authentication and Wildcard CORS, Exposing All 86 GitLab Tools Including Destructive Operations
A review of mcp-gitlab-server at commit 80a7b4cf3fba6b55389c0ef491a48190f7c8996a uncovered that the SSE HTTP transport — advertised in the README and comparison table as a differentiating feature — runs with no authentication and wildcard CORS on every endpoint. The maintainers' own roadmap confirms auth is a known gap.
When USE_SSE=true, the HTTP server in src/transport.ts sets:
res.setHeader('Access-Control-Allow-Origin', '*');
res.setHeader('Access-Control-Allow-Methods', 'GET, POST');
res.setHeader('Access-Control-Allow-Headers', 'Content-Type');
The httpServer.listen(port) call at line 97 passes no host argument — Node.js defaults to 0.0.0.0, binding on all interfaces. Two endpoints are exposed with no credential check:
GET /sse— opens an SSE connection, returns a session endpoint URLPOST /messages?sessionId=<id>— sends MCP messages to the server using the loadedGITLAB_PERSONAL_ACCESS_TOKEN
Any caller who can reach the port — LAN, cloud instance, or via the browser-tab vector the wildcard CORS enables — gets full access to all 86 tools the server exposes using the operator's GitLab PAT. That includes delete_repository, delete_group, push_files, create_merge_request, update_repository_settings, and any other tool the server exposes. The PAT doesn't leave the process, but every API call it backs is available to the unauthenticated caller.
The wildcard CORS makes the browser-tab vector direct: any web page the operator visits while the server is running can open an SSE connection and make tool calls via cross-origin fetch. No user interaction beyond visiting the page.
PoC — reproduces from the documented USE_SSE=true configuration:
# Step 1: connect SSE and capture the session endpoint
curl -N http://localhost:3000/sse &
# Output includes: event: endpoint
# data: /messages?sessionId=<UUID>
# Step 2: call any tool — no auth header needed
curl -X POST "http://localhost:3000/messages?sessionId=<UUID>" \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "get_repository",
"arguments": {"project_id": "target-org/private-repo"}
}
}'
# Returns repository data using the operator's GitLab PAT
# Same path works for delete_repository, push_files, etc.
Root cause
The HTTP transport in src/transport.ts ships with no authentication layer at all and a wildcard Access-Control-Allow-Origin: * on every response. The structural defect is that the SSE server stands up a stateful, mutation-capable RPC endpoint that is backed by the operator's GITLAB_PERSONAL_ACCESS_TOKEN without any inbound credential check, then advertises itself to every cross-origin browser context via the wildcard CORS header. The httpServer.listen(port) call at line 97 also passes no host argument, so the bind defaults to 0.0.0.0 and exposes the auth-less surface on every interface. Auth isn't fail-opening on a missing config — there is no auth check at any code path on either /sse or /messages?sessionId=....
Auth boundary violated
Trust-domain boundary — untrusted cross-origin browser context (and any unauthenticated network caller) crossing into the trusted server-state-mutating GitLab API surface that the operator's PAT backs. Respected-here: nothing. The transport carries no Authorization check, no origin allowlist, no session-binding to the originating client, and no host restriction. Ignored-there: the SSE handler at src/transport.ts accepts an arbitrary Origin (since Access-Control-Allow-Origin: *), opens a session, and the matching POST /messages?sessionId=... proxies tool calls — including delete_repository, push_files, update_repository_settings — to the GitLab API using the operator's PAT. Any web page the operator visits while the server runs can drive the full 86-tool surface via cross-origin fetch.
The roadmap in README.md at line 190 includes - [ ] SAML/OAuth3 authentication — confirming the maintainers are already tracking this gap. The issue is disclosure of impact in the interim: operators who follow the README's SSE setup instructions and don't see an auth requirement in the docs may reasonably assume the transport is safe to use on a network-accessible host.
CVSS 4.0: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N — ~6.3 (Medium). AT:P reflects the USE_SSE=true precondition. When that precondition is met, the effective severity for those deployments is High — full GitLab PAT access without authentication. The Medium CVSS is the aggregate across all deployments; for any operator who has activated SSE mode (which the README promotes as a feature), the finding is functionally High.
Fix — four concrete changes:
- Require
MCP_GITLAB_AUTH_TOKENas a startup precondition whenUSE_SSE=true. If the env var is unset, the server should exit with a clear message before the HTTP server starts:
typescript
if (process.env.USE_SSE === 'true') {
if (!process.env.MCP_GITLAB_AUTH_TOKEN) {
console.error(
'ERROR: MCP_GITLAB_AUTH_TOKEN must be set when USE_SSE=true. ' +
'SSE transport without authentication exposes all GitLab tools to unauthenticated callers.'
);
process.exit(1);
}
}
The token check in src/transport.ts validates it on every request:
typescript
const authToken = process.env.MCP_GITLAB_AUTH_TOKEN;
if (authToken) {
const provided = req.headers['authorization']?.replace(/^Bearer /, '');
if (provided !== authToken) {
res.writeHead(401);
res.end(JSON.stringify({ error: 'Unauthorized' }));
return;
}
}
-
Bind to
127.0.0.1by default for the SSE transport rather than0.0.0.0. An explicitMCP_GITLAB_HOST=0.0.0.0flag with a startup banner warning can expose it to the network for operators who need that — but the safe default should be loopback-only. -
Replace the wildcard
Access-Control-Allow-Origin: *with a localhost-only default. When network exposure is intentional (explicit flag + auth token set), an explicitCORS_ORIGINSallowlist should be required. -
The SAML/OAuth3 roadmap item is the right long-term direction. In the interim — before that ships — the three changes above are entirely in the existing codebase with no new dependencies.
No prior security advisories, CVEs, or public security issues exist for this package — a search of the repository issue list and npm advisory database did not yield any duplicate issues.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@yoda.digital/gitlab-mcp-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44895"
],
"database_specific": {
"cwe_ids": [
"CWE-306",
"CWE-942"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-09T00:10:28Z",
"nvd_published_at": "2026-05-26T22:16:42Z",
"severity": "HIGH"
},
"details": "## SSE Transport Has No Authentication and Wildcard CORS, Exposing All 86 GitLab Tools Including Destructive Operations\n\nA review of `mcp-gitlab-server` at commit `80a7b4cf3fba6b55389c0ef491a48190f7c8996a` uncovered that the SSE HTTP transport \u2014 advertised in the README and comparison table as a differentiating feature \u2014 runs with no authentication and wildcard CORS on every endpoint. The maintainers\u0027 own roadmap confirms auth is a known gap.\n\nWhen `USE_SSE=true`, the HTTP server in `src/transport.ts` sets:\n\n```typescript\nres.setHeader(\u0027Access-Control-Allow-Origin\u0027, \u0027*\u0027);\nres.setHeader(\u0027Access-Control-Allow-Methods\u0027, \u0027GET, POST\u0027);\nres.setHeader(\u0027Access-Control-Allow-Headers\u0027, \u0027Content-Type\u0027);\n```\n\nThe `httpServer.listen(port)` call at line 97 passes no host argument \u2014 Node.js defaults to `0.0.0.0`, binding on all interfaces. Two endpoints are exposed with no credential check:\n\n- `GET /sse` \u2014 opens an SSE connection, returns a session endpoint URL\n- `POST /messages?sessionId=\u003cid\u003e` \u2014 sends MCP messages to the server using the loaded `GITLAB_PERSONAL_ACCESS_TOKEN`\n\nAny caller who can reach the port \u2014 LAN, cloud instance, or via the browser-tab vector the wildcard CORS enables \u2014 gets full access to all 86 tools the server exposes using the operator\u0027s GitLab PAT. That includes `delete_repository`, `delete_group`, `push_files`, `create_merge_request`, `update_repository_settings`, and any other tool the server exposes. The PAT doesn\u0027t leave the process, but every API call it backs is available to the unauthenticated caller.\n\nThe wildcard CORS makes the browser-tab vector direct: any web page the operator visits while the server is running can open an SSE connection and make tool calls via cross-origin fetch. No user interaction beyond visiting the page.\n\n**PoC \u2014 reproduces from the documented USE_SSE=true configuration:**\n\n```bash\n# Step 1: connect SSE and capture the session endpoint\ncurl -N http://localhost:3000/sse \u0026\n# Output includes: event: endpoint\n# data: /messages?sessionId=\u003cUUID\u003e\n\n# Step 2: call any tool \u2014 no auth header needed\ncurl -X POST \"http://localhost:3000/messages?sessionId=\u003cUUID\u003e\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\n \"jsonrpc\": \"2.0\",\n \"id\": 1,\n \"method\": \"tools/call\",\n \"params\": {\n \"name\": \"get_repository\",\n \"arguments\": {\"project_id\": \"target-org/private-repo\"}\n }\n }\u0027\n# Returns repository data using the operator\u0027s GitLab PAT\n\n# Same path works for delete_repository, push_files, etc.\n```\n\n## Root cause\n\nThe HTTP transport in `src/transport.ts` ships with no authentication layer at all and a wildcard `Access-Control-Allow-Origin: *` on every response. The structural defect is that the SSE server stands up a stateful, mutation-capable RPC endpoint that is backed by the operator\u0027s `GITLAB_PERSONAL_ACCESS_TOKEN` without any inbound credential check, then advertises itself to every cross-origin browser context via the wildcard CORS header. The `httpServer.listen(port)` call at line 97 also passes no host argument, so the bind defaults to `0.0.0.0` and exposes the auth-less surface on every interface. Auth isn\u0027t fail-opening on a missing config \u2014 there is no auth check at any code path on either `/sse` or `/messages?sessionId=...`.\n\n## Auth boundary violated\n\nTrust-domain boundary \u2014 untrusted cross-origin browser context (and any unauthenticated network caller) crossing into the trusted server-state-mutating GitLab API surface that the operator\u0027s PAT backs. Respected-here: nothing. The transport carries no `Authorization` check, no origin allowlist, no session-binding to the originating client, and no host restriction. Ignored-there: the SSE handler at `src/transport.ts` accepts an arbitrary `Origin` (since `Access-Control-Allow-Origin: *`), opens a session, and the matching `POST /messages?sessionId=...` proxies tool calls \u2014 including `delete_repository`, `push_files`, `update_repository_settings` \u2014 to the GitLab API using the operator\u0027s PAT. Any web page the operator visits while the server runs can drive the full 86-tool surface via cross-origin fetch.\n\nThe roadmap in `README.md` at line 190 includes `- [ ] SAML/OAuth3 authentication` \u2014 confirming the maintainers are already tracking this gap. The issue is disclosure of impact in the interim: operators who follow the README\u0027s SSE setup instructions and don\u0027t see an auth requirement in the docs may reasonably assume the transport is safe to use on a network-accessible host.\n\n**CVSS 4.0:** `CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N` \u2014 **~6.3 (Medium)**. `AT:P` reflects the `USE_SSE=true` precondition. When that precondition is met, the effective severity for those deployments is High \u2014 full GitLab PAT access without authentication. The Medium CVSS is the aggregate across all deployments; for any operator who has activated SSE mode (which the README promotes as a feature), the finding is functionally High.\n\n**Fix \u2014 four concrete changes:**\n\n1. Require `MCP_GITLAB_AUTH_TOKEN` as a startup precondition when `USE_SSE=true`. If the env var is unset, the server should exit with a clear message before the HTTP server starts:\n\n ```typescript\n if (process.env.USE_SSE === \u0027true\u0027) {\n if (!process.env.MCP_GITLAB_AUTH_TOKEN) {\n console.error(\n \u0027ERROR: MCP_GITLAB_AUTH_TOKEN must be set when USE_SSE=true. \u0027 +\n \u0027SSE transport without authentication exposes all GitLab tools to unauthenticated callers.\u0027\n );\n process.exit(1);\n }\n }\n ```\n\n The token check in `src/transport.ts` validates it on every request:\n ```typescript\n const authToken = process.env.MCP_GITLAB_AUTH_TOKEN;\n if (authToken) {\n const provided = req.headers[\u0027authorization\u0027]?.replace(/^Bearer /, \u0027\u0027);\n if (provided !== authToken) {\n res.writeHead(401);\n res.end(JSON.stringify({ error: \u0027Unauthorized\u0027 }));\n return;\n }\n }\n ```\n\n2. Bind to `127.0.0.1` by default for the SSE transport rather than `0.0.0.0`. An explicit `MCP_GITLAB_HOST=0.0.0.0` flag with a startup banner warning can expose it to the network for operators who need that \u2014 but the safe default should be loopback-only.\n\n3. Replace the wildcard `Access-Control-Allow-Origin: *` with a localhost-only default. When network exposure is intentional (explicit flag + auth token set), an explicit `CORS_ORIGINS` allowlist should be required.\n\n4. The SAML/OAuth3 roadmap item is the right long-term direction. In the interim \u2014 before that ships \u2014 the three changes above are entirely in the existing codebase with no new dependencies.\n\n---\n\nNo prior security advisories, CVEs, or public security issues exist for this package \u2014 a search of the repository issue list and npm advisory database did not yield any duplicate issues.",
"id": "GHSA-8jr5-6gvj-rfpf",
"modified": "2026-06-08T23:34:55Z",
"published": "2026-05-09T00:10:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/yoda-digital/mcp-gitlab-server/security/advisories/GHSA-8jr5-6gvj-rfpf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44895"
},
{
"type": "PACKAGE",
"url": "https://github.com/yoda-digital/mcp-gitlab-server"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "@yoda.digital/gitlab-mcp-server\u0027s SSE transport has no authentication and wildcard CORS, exposing all 86 GitLab tools"
}
GHSA-8JRM-JHC8-CCHX
Vulnerability from github – Published: 2026-02-17 15:31 – Updated: 2026-06-05 15:32Missing Authentication for Critical Function vulnerability in TUBITAK BILGEM Software Technologies Research Institute Liderahenk allows Remote Code Inclusion.This issue affects Liderahenk: from 3.0.0 to 3.3.1 before 3.5.0.
{
"affected": [],
"aliases": [
"CVE-2025-7706"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-17T14:16:00Z",
"severity": "MODERATE"
},
"details": "Missing Authentication for Critical Function vulnerability in TUBITAK BILGEM Software Technologies Research Institute Liderahenk allows Remote Code Inclusion.This issue affects Liderahenk: from 3.0.0 to 3.3.1 before 3.5.0.",
"id": "GHSA-8jrm-jhc8-cchx",
"modified": "2026-06-05T15:32:07Z",
"published": "2026-02-17T15:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7706"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-26-0069"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-26-0069"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8JVW-RWM2-M37G
Vulnerability from github – Published: 2024-03-01 21:31 – Updated: 2024-03-01 21:31A vulnerability was found in CodeAstro House Rental Management System 1.0. It has been rated as problematic. Affected by this issue is some unknown functionality of the file booking.php/owner.php/tenant.php. The manipulation leads to missing authentication. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-255392.
{
"affected": [],
"aliases": [
"CVE-2024-2076"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-01T19:15:07Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in CodeAstro House Rental Management System 1.0. It has been rated as problematic. Affected by this issue is some unknown functionality of the file booking.php/owner.php/tenant.php. The manipulation leads to missing authentication. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-255392.",
"id": "GHSA-8jvw-rwm2-m37g",
"modified": "2024-03-01T21:31:16Z",
"published": "2024-03-01T21:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2076"
},
{
"type": "WEB",
"url": "https://docs.qq.com/doc/DYlREVXpuRUFwRFpQ"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.255392"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.255392"
}
],
"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"
}
]
}
GHSA-8JXM-4XFH-VC8V
Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-03-16 15:30Philips Hue Bridge HomeKit Accessory Protocol Transient Pairing Mode Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of Philips Hue Bridge. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the configuration of the HomeKit Accessory Protocol service, which listens on TCP port 8080 by default. The issue results from the lack of authentication prior to allowing access to functionality. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-28374.
{
"affected": [],
"aliases": [
"CVE-2026-3558"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-16T14:19:48Z",
"severity": "HIGH"
},
"details": "Philips Hue Bridge HomeKit Accessory Protocol Transient Pairing Mode Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of Philips Hue Bridge. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the configuration of the HomeKit Accessory Protocol service, which listens on TCP port 8080 by default. The issue results from the lack of authentication prior to allowing access to functionality. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-28374.",
"id": "GHSA-8jxm-4xfh-vc8v",
"modified": "2026-03-16T15:30:44Z",
"published": "2026-03-16T15:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3558"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-26-156"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8M6J-X8HV-VFPR
Vulnerability from github – Published: 2023-10-18 00:31 – Updated: 2024-04-04 08:44Vulnerability in the Oracle WebLogic Server product of Oracle Fusion Middleware (component: Core). Supported versions that are affected are 12.2.1.4.0 and 14.1.1.0.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via T3, IIOP to compromise Oracle WebLogic Server. Successful attacks of this vulnerability can result in takeover of Oracle WebLogic Server. CVSS 3.1 Base Score 8.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).
{
"affected": [],
"aliases": [
"CVE-2023-22101"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-17T22:15:15Z",
"severity": "HIGH"
},
"details": "Vulnerability in the Oracle WebLogic Server product of Oracle Fusion Middleware (component: Core). Supported versions that are affected are 12.2.1.4.0 and 14.1.1.0.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via T3, IIOP to compromise Oracle WebLogic Server. Successful attacks of this vulnerability can result in takeover of Oracle WebLogic Server. CVSS 3.1 Base Score 8.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).",
"id": "GHSA-8m6j-x8hv-vfpr",
"modified": "2024-04-04T08:44:36Z",
"published": "2023-10-18T00:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22101"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2023.html"
}
],
"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"
}
]
}
GHSA-8MJ9-MW5F-CCV3
Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2022-10-27 19:00The server permits communication without any authentication procedure, allowing the attacker to initiate a session with the server without providing any form of authentication.
{
"affected": [],
"aliases": [
"CVE-2021-38457"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-22T12:15:00Z",
"severity": "CRITICAL"
},
"details": "The server permits communication without any authentication procedure, allowing the attacker to initiate a session with the server without providing any form of authentication.",
"id": "GHSA-8mj9-mw5f-ccv3",
"modified": "2022-10-27T19:00:31Z",
"published": "2022-05-24T19:18:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38457"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsa-21-292-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-8P6M-W3WG-J3C3
Vulnerability from github – Published: 2026-07-22 00:31 – Updated: 2026-07-22 00:31Vulnerability in the Oracle Coherence product of Oracle Fusion Middleware (component: Core). Supported versions that are affected are 14.1.1.0.0, 14.1.2.0.0 and 15.1.1.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via TCP to compromise Oracle Coherence. Successful attacks of this vulnerability can result in takeover of Oracle Coherence. CVSS 3.1 Base Score 9.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
{
"affected": [],
"aliases": [
"CVE-2026-60210"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-21T22:17:22Z",
"severity": "CRITICAL"
},
"details": "Vulnerability in the Oracle Coherence product of Oracle Fusion Middleware (component: Core). Supported versions that are affected are 14.1.1.0.0, 14.1.2.0.0 and 15.1.1.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via TCP to compromise Oracle Coherence. Successful attacks of this vulnerability can result in takeover of Oracle Coherence. CVSS 3.1 Base Score 9.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).",
"id": "GHSA-8p6m-w3wg-j3c3",
"modified": "2026-07-22T00:31:24Z",
"published": "2026-07-22T00:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60210"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2026.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"
}
]
}
GHSA-8PJJ-R2JJ-C282
Vulnerability from github – Published: 2025-08-22 12:30 – Updated: 2025-08-22 12:30WebITR developed by Uniong has a Missing Authentication vulnerability, allowing unauthenticated remote attackers to log into the system as arbitrary users by exploiting a specific functionality.
{
"affected": [],
"aliases": [
"CVE-2025-9254"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-22T12:15:33Z",
"severity": "CRITICAL"
},
"details": "WebITR developed by Uniong has a Missing Authentication vulnerability, allowing unauthenticated remote attackers to log into the system as arbitrary users by exploiting a specific functionality.",
"id": "GHSA-8pjj-r2jj-c282",
"modified": "2025-08-22T12:30:31Z",
"published": "2025-08-22T12:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9254"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/en/cp-139-10329-a1c5d-2.html"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-10328-dbc35-1.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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/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-8PRX-VW4F-9Q7P
Vulnerability from github – Published: 2023-05-19 03:30 – Updated: 2024-04-04 04:14The BP Social Connect plugin for WordPress is vulnerable to authentication bypass in versions up to, and including, 1.5. This is due to insufficient verification on the user being supplied during a Facebook login through the plugin. This makes it possible for unauthenticated attackers to log in as any existing user on the site, such as an administrator, if they have access to the email.
{
"affected": [],
"aliases": [
"CVE-2023-2704"
],
"database_specific": {
"cwe_ids": [
"CWE-288",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-19T03:15:08Z",
"severity": "CRITICAL"
},
"details": "The BP Social Connect plugin for WordPress is vulnerable to authentication bypass in versions up to, and including, 1.5. This is due to insufficient verification on the user being supplied during a Facebook login through the plugin. This makes it possible for unauthenticated attackers to log in as any existing user on the site, such as an administrator, if they have access to the email.",
"id": "GHSA-8prx-vw4f-9q7p",
"modified": "2024-04-04T04:14:57Z",
"published": "2023-05-19T03:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2704"
},
{
"type": "WEB",
"url": "https://lana.codes/lanavdb/1bd0dfd9-ffec-4d69-bc55-286751300cab"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/bp-social-connect/tags/1.5/includes/social/facebook/class.facebook.php#L138"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/bp-social-connect/tags/1.5/includes/social/facebook/class.facebook.php#L188"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=2914042%40bp-social-connect%2Ftrunk\u0026old=1904372%40bp-social-connect%2Ftrunk\u0026sfp_email=\u0026sfph_mail=#file6"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/44c96df2-530a-4ebe-b722-c606a7b135f9?source=cve"
}
],
"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"
}
]
}
GHSA-8Q5C-H63V-V869
Vulnerability from github – Published: 2024-05-08 06:30 – Updated: 2025-03-25 21:31The SSL Zen WordPress plugin before 4.6.0 only relies on the use of .htaccess to prevent visitors from accessing the site's generated private keys, which allows an attacker to read them if the site runs on a server who doesn't support .htaccess files, like NGINX.
{
"affected": [],
"aliases": [
"CVE-2024-1076"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-08T06:15:06Z",
"severity": "MODERATE"
},
"details": "The SSL Zen WordPress plugin before 4.6.0 only relies on the use of .htaccess to prevent visitors from accessing the site\u0027s generated private keys, which allows an attacker to read them if the site runs on a server who doesn\u0027t support .htaccess files, like NGINX.",
"id": "GHSA-8q5c-h63v-v869",
"modified": "2025-03-25T21:31:30Z",
"published": "2024-05-08T06:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1076"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/9c3e9c72-3d6c-4e2c-bb8a-f4efce1371d5"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
Mitigation
- Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.
- Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.
- In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mitigation
- Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks.
- In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
Mitigation MIT-4.5
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
Mitigation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].
CAPEC-12: Choosing Message Identifier
This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.
CAPEC-166: Force the System to Reset Values
An attacker forces the target into a previous state in order to leverage potential weaknesses in the target dependent upon a prior configuration or state-dependent factors. Even in cases where an attacker may not be able to directly control the configuration of the targeted application, they may be able to reset the configuration to a prior state since many applications implement reset functions.
CAPEC-216: Communication Channel Manipulation
An adversary manipulates a setting or parameter on communications channel in order to compromise its security. This can result in information exposure, insertion/removal of information from the communications stream, and/or potentially system compromise.
CAPEC-36: Using Unpublished Interfaces or Functionality
An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.
CAPEC-62: Cross Site Request Forgery
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.