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.
5964 vulnerabilities reference this CWE, most recent first.
GHSA-V83C-8HCJ-4545
Vulnerability from github – Published: 2022-02-15 01:44 – Updated: 2022-02-15 01:44Apache Guacamole 1.2.0 and 1.3.0 do not properly validate responses received from a SAML identity provider. If SAML support is enabled, this may allow a malicious user to assume the identity of another Guacamole user.
{
"affected": [],
"aliases": [
"CVE-2021-43999"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-11T22:15:00Z",
"severity": "HIGH"
},
"details": "Apache Guacamole 1.2.0 and 1.3.0 do not properly validate responses received from a SAML identity provider. If SAML support is enabled, this may allow a malicious user to assume the identity of another Guacamole user.",
"id": "GHSA-v83c-8hcj-4545",
"modified": "2022-02-15T01:44:10Z",
"published": "2022-02-15T01:44:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43999"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/guacamole-client"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/4dt9h5mo4o9rxlgxm3rp8wfqdtdjn2z9"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/01/11/7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Improper Authentication in Apache Guacamole"
}
GHSA-V83P-2PCP-WWG6
Vulnerability from github – Published: 2022-05-24 19:06 – Updated: 2022-07-13 00:01An issue was discovered in the CentralAuth extension in MediaWiki through 1.36. Autoblocks for CentralAuth-issued suppression blocks are not properly implemented.
{
"affected": [],
"aliases": [
"CVE-2021-36128"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-07-02T13:15:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in the CentralAuth extension in MediaWiki through 1.36. Autoblocks for CentralAuth-issued suppression blocks are not properly implemented.",
"id": "GHSA-v83p-2pcp-wwg6",
"modified": "2022-07-13T00:01:29Z",
"published": "2022-05-24T19:06:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36128"
},
{
"type": "WEB",
"url": "https://gerrit.wikimedia.org/r/q/I15d14c88a1e30df92c470bc191c4ee573172d4d1"
},
{
"type": "WEB",
"url": "https://gerrit.wikimedia.org/r/q/I3e65690695313380c798b62edfda726b6e374f89"
},
{
"type": "WEB",
"url": "https://phabricator.wikimedia.org/T281972"
}
],
"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-V85Q-G5FQ-684C
Vulnerability from github – Published: 2022-02-17 00:00 – Updated: 2022-07-13 00:01An authorization bypass exploited by a user-controlled key in SpecificApps REST API in ScratchOAuth2 before commit d856dc704b2504cd3b92cf089fdd366dd40775d6 allows app owners to set flags that indicate whether an app is verified on their own apps.
{
"affected": [],
"aliases": [
"CVE-2021-46249"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-15T23:15:00Z",
"severity": "MODERATE"
},
"details": "An authorization bypass exploited by a user-controlled key in SpecificApps REST API in ScratchOAuth2 before commit d856dc704b2504cd3b92cf089fdd366dd40775d6 allows app owners to set flags that indicate whether an app is verified on their own apps.",
"id": "GHSA-v85q-g5fq-684c",
"modified": "2022-07-13T00:01:51Z",
"published": "2022-02-17T00:00:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46249"
},
{
"type": "WEB",
"url": "https://github.com/ScratchVerifier/ScratchOAuth2/commit/d856dc704b2504cd3b92cf089fdd366dd40775d6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V85V-4G2G-QMJ9
Vulnerability from github – Published: 2024-08-28 18:31 – Updated: 2024-08-28 18:31In WS_FTP Server versions before 8.8.8 (2022.0.8), a Missing Critical Step in Multi-Factor Authentication of the Web Transfer Module allows users to skip the second-factor verification and log in with username and password only.
{
"affected": [],
"aliases": [
"CVE-2024-7745"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-28T17:15:11Z",
"severity": "MODERATE"
},
"details": "In WS_FTP Server versions before 8.8.8 (2022.0.8), a Missing Critical Step in Multi-Factor Authentication of the Web Transfer Module allows users to skip the second-factor verification and log in with username and password only.",
"id": "GHSA-v85v-4g2g-qmj9",
"modified": "2024-08-28T18:31:55Z",
"published": "2024-08-28T18:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7745"
},
{
"type": "WEB",
"url": "https://community.progress.com/s/article/WS-FTP-Server-Service-Pack-August-2024"
},
{
"type": "WEB",
"url": "https://www.progress.com/ftp-server"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V887-6G7G-J8HV
Vulnerability from github – Published: 2022-05-17 05:14 – Updated: 2022-05-17 05:14VMware vCenter Server 4.0 before Update 4b and 4.1 before Update 3a, VMware VirtualCenter 2.5, VMware vSphere Client 4.0 before Update 4b and 4.1 before Update 3a, VMware VI-Client 2.5, VMware ESXi 3.5 through 4.1, and VMware ESX 3.5 through 4.1 do not properly implement the management authentication protocol, which allow remote servers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2013-1405"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-02-15T12:09:00Z",
"severity": "HIGH"
},
"details": "VMware vCenter Server 4.0 before Update 4b and 4.1 before Update 3a, VMware VirtualCenter 2.5, VMware vSphere Client 4.0 before Update 4b and 4.1 before Update 3a, VMware VI-Client 2.5, VMware ESXi 3.5 through 4.1, and VMware ESX 3.5 through 4.1 do not properly implement the management authentication protocol, which allow remote servers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified vectors.",
"id": "GHSA-v887-6g7g-j8hv",
"modified": "2022-05-17T05:14:58Z",
"published": "2022-05-17T05:14:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-1405"
},
{
"type": "WEB",
"url": "http://www.vmware.com/security/advisories/VMSA-2013-0001.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V89F-4MC4-H6W9
Vulnerability from github – Published: 2022-05-17 04:58 – Updated: 2024-10-26 22:36Salt (aka SaltStack) 0.15.0 through 0.17.0 allows remote authenticated users who are using external authentication or client ACL to execute restricted routines by embedding the routine in another routine.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.17.0"
},
"package": {
"ecosystem": "PyPI",
"name": "salt"
},
"ranges": [
{
"events": [
{
"introduced": "0.15.0"
},
{
"fixed": "0.17.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2013-4435"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-01T11:19:14Z",
"nvd_published_at": "2013-11-05T18:55:00Z",
"severity": "HIGH"
},
"details": "Salt (aka SaltStack) 0.15.0 through 0.17.0 allows remote authenticated users who are using external authentication or client ACL to execute restricted routines by embedding the routine in another routine.",
"id": "GHSA-v89f-4mc4-h6w9",
"modified": "2024-10-26T22:36:55Z",
"published": "2022-05-17T04:58:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-4435"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/salt/PYSEC-2013-12.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/saltstack/salt"
},
{
"type": "WEB",
"url": "https://github.com/saltstack/salt/blob/master/doc/topics/releases/0.17.1.rst"
},
{
"type": "WEB",
"url": "http://docs.saltstack.com/topics/releases/0.17.1.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2013/10/18/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Salt has insufficient argument validation in several modules"
}
GHSA-V8HX-4VX8-WC96
Vulnerability from github – Published: 2026-07-14 00:33 – Updated: 2026-07-14 00:33Summary
Two-factor authentication (TOTP) can be fully bypassed for the REST API. The KIMAI_SESSION cookie returned in the response to the login request; issued after only the password is verified, before the TOTP step; is already accepted as authenticated by every /api/* endpoint.
So after submitting just the password, the web UI correctly holds the browser at the TOTP screen (/en/auth/2fa), but the cookie from that same login response can be replayed against the API to act as the user without ever entering the second factor. This affects any account with 2FA enabled and requires only the account password.
Details
Affected Component
- The API firewall / authorization.
config/packages/security.yaml guards the API with { path: '^/api', roles: IS_AUTHENTICATED }. During 2FA the session carries a Scheb TwoFactorToken, which satisfies IS_AUTHENTICATED (it is a real, non-anonymous token). App\API\Authentication\ApiRequestMatcher returns !$request->hasPreviousSession(), so a request that carries the login session skips the stateless API firewall and is served by the main session firewall; Scheb's TwoFactorAccessDecider::isAccessible() then evaluates IS_AUTHENTICATED to true for ^/api and lets it through, and App\Voter\ApiVoter grants API to any token whose user is a User. Web routes are not affected because they require concrete roles (e.g. ROLE_USER) that a TwoFactorToken does not hold.
PoC
A PoC was provided, but removed for security reasons.
Impact
Two-factor authentication provides no protection for the REST API. If an attacker obtains a user's password (phishing, credential stuffing, reuse, breach); exactly the threat 2FA is meant to defend against; they get full authenticated API access as that user without the second factor. The whole exploit is a single cookie taken from the login response; no API token, Bearer header or CSRF token is required.
Solution
- The
/api/firewall now usesIS_AUTHENTICATED_REMEMBEREDwhich is only assigned after 2FA. The historically usedIS_AUTHENTICATEDflag is applied immediately after login and before 2FA happened. - The APIVoter checks both
$token instanceof TwoFactorTokenInterfaceandisGranted('IS_AUTHENTICATED_2FA_IN_PROGRESS', $user)to make sure that the user is not currently in the 2FA step. - Regression tests were added to prevent future escalation of the same issue.
See https://www.kimai.org/en/security/ghsa-v8hx-4vx8-wc96 for more information.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "kimai/kimai"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.59.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-52827"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-14T00:33:39Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nTwo-factor authentication (TOTP) can be fully bypassed for the REST API. The `KIMAI_SESSION` cookie returned in the response to the login request; issued after only the password is verified, before the TOTP step; is already accepted as authenticated by every `/api/*` endpoint.\n\nSo after submitting just the password, the web UI correctly holds the browser at the TOTP screen (`/en/auth/2fa`), but the cookie from that same login response can be replayed against the API to act as the user without ever entering the second factor. This affects any account with 2FA enabled and requires only the account password.\n\n### Details\n\n#### Affected Component\n- The API firewall / authorization.\n\n`config/packages/security.yaml` guards the API with `{ path: \u0027^/api\u0027, roles: IS_AUTHENTICATED }`. During 2FA the session carries a Scheb `TwoFactorToken`, which satisfies `IS_AUTHENTICATED` (it is a real, non-anonymous token). `App\\API\\Authentication\\ApiRequestMatcher` returns `!$request-\u003ehasPreviousSession()`, so a request that carries the login session skips the stateless API firewall and is served by the main session firewall; Scheb\u0027s `TwoFactorAccessDecider::isAccessible()` then evaluates `IS_AUTHENTICATED` to true for `^/api` and lets it through, and `App\\Voter\\ApiVoter` grants `API` to any token whose user is a `User`. Web routes are not affected because they require concrete roles (e.g. `ROLE_USER`) that a `TwoFactorToken` does not hold.\n\n### PoC\n\n_A PoC was provided, but removed for security reasons._\n\n### Impact\n\nTwo-factor authentication provides no protection for the REST API. If an attacker obtains a user\u0027s password (phishing, credential stuffing, reuse, breach); exactly the threat 2FA is meant to defend against; they get full authenticated API access as that user without the second factor. The whole exploit is a single cookie taken from the login response; no API token, Bearer header or CSRF token is required.\n\n## Solution\n\n- The `/api/` firewall now uses `IS_AUTHENTICATED_REMEMBERED` which is only assigned after 2FA. The historically used `IS_AUTHENTICATED` flag is applied immediately after login and before 2FA happened.\n- The APIVoter checks both `$token instanceof TwoFactorTokenInterface` and `isGranted(\u0027IS_AUTHENTICATED_2FA_IN_PROGRESS\u0027, $user)` to make sure that the user is not currently in the 2FA step.\n- Regression tests were added to prevent future escalation of the same issue.\n\nSee [https://www.kimai.org/en/security/ghsa-v8hx-4vx8-wc96](https://www.kimai.org/en/security/ghsa-v8hx-4vx8-wc96) for more information.",
"id": "GHSA-v8hx-4vx8-wc96",
"modified": "2026-07-14T00:33:39Z",
"published": "2026-07-14T00:33:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kimai/kimai/security/advisories/GHSA-v8hx-4vx8-wc96"
},
{
"type": "PACKAGE",
"url": "https://github.com/kimai/kimai"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Kimai: Pre-2FA KIMAI_SESSION\u00a0cookie grants full authenticated REST API access, bypassing TOTP"
}
GHSA-V8JW-9WV4-WXG3
Vulnerability from github – Published: 2026-07-04 15:30 – Updated: 2026-07-04 15:30A security vulnerability has been detected in NousResearch hermes-agent up to 0.15.2. This affects the function DiscordAdapter._is_allowed_user of the file gateway/platforms/discord.py of the component Discord Platform Integration. Such manipulation leads to improper authentication. The attack can be launched remotely. This attack is characterized by high complexity. The exploitability is reported as difficult. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2026-14627"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-04T13:16:30Z",
"severity": "LOW"
},
"details": "A security vulnerability has been detected in NousResearch hermes-agent up to 0.15.2. This affects the function DiscordAdapter._is_allowed_user of the file gateway/platforms/discord.py of the component Discord Platform Integration. Such manipulation leads to improper authentication. The attack can be launched remotely. This attack is characterized by high complexity. The exploitability is reported as difficult. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-v8jw-9wv4-wxg3",
"modified": "2026-07-04T15:30:23Z",
"published": "2026-07-04T15:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14627"
},
{
"type": "WEB",
"url": "https://gist.github.com/YLChen-007/d030c690b10a97319efb129ca2f5badb"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-14627"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/845598"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/376143"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/376143/cti"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/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-V8QG-Q79M-VP4Q
Vulnerability from github – Published: 2022-05-24 19:13 – Updated: 2022-05-24 19:13An issue existed with authenticating the action triggered by an NFC tag. The issue was addressed with improved action authentication. This issue is fixed in iOS 14.5 and iPadOS 14.5. A person with physical access to an iOS device may be able to place phone calls to any phone number.
{
"affected": [],
"aliases": [
"CVE-2021-1863"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-08T15:15:00Z",
"severity": "LOW"
},
"details": "An issue existed with authenticating the action triggered by an NFC tag. The issue was addressed with improved action authentication. This issue is fixed in iOS 14.5 and iPadOS 14.5. A person with physical access to an iOS device may be able to place phone calls to any phone number.",
"id": "GHSA-v8qg-q79m-vp4q",
"modified": "2022-05-24T19:13:33Z",
"published": "2022-05-24T19:13:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1863"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT212317"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V92C-556H-XM93
Vulnerability from github – Published: 2025-08-06 18:31 – Updated: 2025-08-06 18:31On April 18th 2025, Microsoft announced Exchange Server Security Changes for Hybrid Deployments and accompanying non-security Hot Fix. Microsoft made these changes in the general interest of improving the security of hybrid Exchange deployments. Following further investigation, Microsoft identified specific security implications tied to the guidance and configuration steps outlined in the April announcement. Microsoft is issuing CVE-2025-53786 to document a vulnerability that is addressed by taking the steps documented with the April 18th announcement. Microsoft strongly recommends reading the information, installing the April 2025 (or later) Hot Fix and implementing the changes in your Exchange Server and hybrid environment.
{
"affected": [],
"aliases": [
"CVE-2025-53786"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-06T16:15:30Z",
"severity": "HIGH"
},
"details": "On April 18th 2025, Microsoft announced Exchange Server Security Changes for Hybrid Deployments and accompanying non-security Hot Fix. Microsoft made these changes in the general interest of improving the security of hybrid Exchange deployments. Following further investigation, Microsoft identified specific security implications tied to the guidance and configuration steps outlined in the April announcement. Microsoft is issuing CVE-2025-53786 to document a vulnerability that is addressed by taking the steps documented with the April 18th announcement. Microsoft strongly recommends reading the information, installing the April 2025 (or later) Hot Fix and implementing the changes in your Exchange Server and hybrid environment.",
"id": "GHSA-v92c-556h-xm93",
"modified": "2025-08-06T18:31:20Z",
"published": "2025-08-06T18:31:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53786"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53786"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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.