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.
6877 vulnerabilities reference this CWE, most recent first.
GHSA-293Q-567P-WMWQ
Vulnerability from github – Published: 2026-06-10 00:31 – Updated: 2026-06-30 21:35In Spring Security Web, SubjectDnX509PrincipalExtractor does not correctly handle certain malformed X.509 certificate CN values, which can lead to reading the wrong value for the username. In a carefully crafted certificate, this can lead to an attacker impersonating another user.
SubjectDnX509PrincipalExtractor is deprecated by this CVE and replaced with SubjectX500PrincipalExtractor. As part of updating, you should also migrate to SubjectX500PrincipalExtractor.
Affected versions: Spring Security Enterprise 5.7.0 through 5.7.24; 5.8.0 through 5.8.26; 6.3.0 through 6.3.17; 6.4.0 through 6.4.17; 6.5.0 through 6.5.10. OSS 6.5.0 through 6.5.10.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.5.10"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-web"
},
"ranges": [
{
"events": [
{
"introduced": "6.5.0"
},
{
"fixed": "6.5.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-web"
},
"ranges": [
{
"events": [
{
"introduced": "6.4.0"
},
{
"last_affected": "6.4.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-web"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"last_affected": "6.3.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-web"
},
"ranges": [
{
"events": [
{
"introduced": "5.8.0"
},
{
"last_affected": "5.8.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-web"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.7.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47838"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-30T21:35:09Z",
"nvd_published_at": "2026-06-10T00:16:54Z",
"severity": "MODERATE"
},
"details": "In Spring Security Web, `SubjectDnX509PrincipalExtractor` does not correctly handle certain malformed X.509 certificate CN values, which can lead to reading the wrong value for the username. In a carefully crafted certificate, this can lead to an attacker impersonating another user.\n\n`SubjectDnX509PrincipalExtractor` is deprecated by this CVE and replaced with `SubjectX500PrincipalExtractor`. As part of updating, you should also migrate to `SubjectX500PrincipalExtractor`.\n\nAffected versions:\nSpring Security Enterprise 5.7.0 through 5.7.24; 5.8.0 through 5.8.26; 6.3.0 through 6.3.17; 6.4.0 through 6.4.17; 6.5.0 through 6.5.10. \nOSS 6.5.0 through 6.5.10.",
"id": "GHSA-293q-567p-wmwq",
"modified": "2026-06-30T21:35:09Z",
"published": "2026-06-10T00:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47838"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-2jrg-rf5x-568g"
},
{
"type": "WEB",
"url": "https://spring.io/security/cve-2026-47838"
},
{
"type": "PACKAGE",
"url": "spring-projects/spring-security"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Spring Security Vulnerable to Unauthorized User Impersonation when Using X.509 Client Certificates"
}
GHSA-294J-79HR-F57F
Vulnerability from github – Published: 2022-12-22 21:30 – Updated: 2022-12-31 03:30IBM Security Verify Governance, Identity Manager 10.0.1 software component could allow an authenticated user to modify or cancel any other user's access request using man-in-the-middle techniques. IBM X-Force ID: 231096.
{
"affected": [],
"aliases": [
"CVE-2022-35646"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-22T20:15:00Z",
"severity": "MODERATE"
},
"details": "IBM Security Verify Governance, Identity Manager 10.0.1 software component could allow an authenticated user to modify or cancel any other user\u0027s access request using man-in-the-middle techniques. IBM X-Force ID: 231096.",
"id": "GHSA-294j-79hr-f57f",
"modified": "2022-12-31T03:30:26Z",
"published": "2022-12-22T21:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35646"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/231096"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/6850809"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-29H6-GGVX-W3VW
Vulnerability from github – Published: 2022-06-14 00:00 – Updated: 2022-06-23 00:00An issue was discovered in Couchbase Server before 7.0.4. XDCR lacks role checking when changing internal settings.
{
"affected": [],
"aliases": [
"CVE-2022-32560"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-13T21:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Couchbase Server before 7.0.4. XDCR lacks role checking when changing internal settings.",
"id": "GHSA-29h6-ggvx-w3vw",
"modified": "2022-06-23T00:00:26Z",
"published": "2022-06-14T00:00:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32560"
},
{
"type": "WEB",
"url": "https://docs.couchbase.com/server/current/release-notes/relnotes.html"
},
{
"type": "WEB",
"url": "https://forums.couchbase.com/tags/security"
},
{
"type": "WEB",
"url": "https://www.couchbase.com/alerts"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-29HH-2H73-48VC
Vulnerability from github – Published: 2022-02-16 00:01 – Updated: 2022-07-13 00:01Affected versions of Atlassian Jira Service Management Server and Data Center allow authenticated remote attackers to view import source configuration information via a Broken Access Control vulnerability in the Insight Import Source feature. The affected versions are before version 4.21.0.
{
"affected": [],
"aliases": [
"CVE-2021-43950"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-15T03:15:00Z",
"severity": "MODERATE"
},
"details": "Affected versions of Atlassian Jira Service Management Server and Data Center allow authenticated remote attackers to view import source configuration information via a Broken Access Control vulnerability in the Insight Import Source feature. The affected versions are before version 4.21.0.",
"id": "GHSA-29hh-2h73-48vc",
"modified": "2022-07-13T00:01:49Z",
"published": "2022-02-16T00:01:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43950"
},
{
"type": "WEB",
"url": "https://jira.atlassian.com/browse/JSDSERVER-10983"
}
],
"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"
}
]
}
GHSA-29MQ-29C5-43RG
Vulnerability from github – Published: 2022-05-17 05:11 – Updated: 2022-05-17 05:11The authentication-proxy implementation on Cisco Adaptive Security Appliances (ASA) devices with software 7.x before 7.2(5.10), 8.0 before 8.0(5.31), 8.1 and 8.2 before 8.2(5.38), 8.3 before 8.3(2.37), 8.4 before 8.4(5.3), 8.5 and 8.6 before 8.6(1.10), 8.7 before 8.7(1.4), 9.0 before 9.0(1.1), and 9.1 before 9.1(1.2) allows remote attackers to cause a denial of service (device reload) via a crafted URL, aka Bug ID CSCud16590.
{
"affected": [],
"aliases": [
"CVE-2013-1150"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-04-11T10:55:00Z",
"severity": "HIGH"
},
"details": "The authentication-proxy implementation on Cisco Adaptive Security Appliances (ASA) devices with software 7.x before 7.2(5.10), 8.0 before 8.0(5.31), 8.1 and 8.2 before 8.2(5.38), 8.3 before 8.3(2.37), 8.4 before 8.4(5.3), 8.5 and 8.6 before 8.6(1.10), 8.7 before 8.7(1.4), 9.0 before 9.0(1.1), and 9.1 before 9.1(1.2) allows remote attackers to cause a denial of service (device reload) via a crafted URL, aka Bug ID CSCud16590.",
"id": "GHSA-29mq-29c5-43rg",
"modified": "2022-05-17T05:11:08Z",
"published": "2022-05-17T05:11:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-1150"
},
{
"type": "WEB",
"url": "http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130410-asa"
},
{
"type": "WEB",
"url": "http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2013-1150"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-29MV-GCCW-23PV
Vulnerability from github – Published: 2022-05-14 03:44 – Updated: 2025-04-20 03:46The doFilter method in UrlAccessController in HPE Intelligent Management Center (iMC) PLAT 7.2 E0403P06 allows remote bypass of authentication via unspecified strings in a URI.
{
"affected": [],
"aliases": [
"CVE-2017-5791"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-10-11T21:29:00Z",
"severity": "CRITICAL"
},
"details": "The doFilter method in UrlAccessController in HPE Intelligent Management Center (iMC) PLAT 7.2 E0403P06 allows remote bypass of authentication via unspecified strings in a URI.",
"id": "GHSA-29mv-gccw-23pv",
"modified": "2025-04-20T03:46:38Z",
"published": "2022-05-14T03:44:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5791"
},
{
"type": "WEB",
"url": "https://h20564.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-hpesbhf03716en_us"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/101224"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/96815"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1037983"
},
{
"type": "WEB",
"url": "http://www.zerodayinitiative.com/advisories/ZDI-17-161"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-29RF-F4VV-PVQ6
Vulnerability from github – Published: 2026-08-14 15:36 – Updated: 2026-08-14 15:36The OAuth callback handler links incoming OAuth identities (Google, GitHub, etc.) to existing accounts matched by email address without verifying that the existing account's email was verified by its original owner. An attacker who pre-registers with a victim's email address (without verifying it) gains persistent password-based access to the victim's account after the victim completes a normal OAuth login. Verified against HEAD (commit 73679fa).
Root Cause
In internal/http_handlers/oauth_callback.go, when an OAuth login occurs for an email that already exists in the database:
Line 125: The existing user is looked up by email:
existingUser, err := h.StorageProvider.GetUserByEmail(ctx, refs.StringValue(user.Email))
Line 164: The OAuth user object is replaced with the existing user:
user = existingUser
Lines 173-176: The OAuth provider is appended to the existing user's signup methods:
signupMethod := existingUser.SignupMethods
if !strings.Contains(signupMethod, provider) {
signupMethod = signupMethod + "," + provider
}
user.SignupMethods = signupMethod
Lines 179-181: If the existing account's email was NOT verified, it is automatically verified:
if user.EmailVerifiedAt == nil {
now := time.Now().Unix()
user.EmailVerifiedAt = &now
}
Line 219: The merged user is saved to the database:
user, err = h.StorageProvider.UpdateUser(ctx, user)
At no point is the existing account's password invalidated or the owner notified that a new OAuth identity was linked.
Attack Chain
-
Attacker signs up with
victim@company.comusing email/password. Attacker sets a known password but does NOT click the email verification link. The account exists in the database withEmailVerifiedAt = nil. -
Some time later, the real owner of
victim@company.comlogs in via Google OAuth (a completely normal action). -
The OAuth callback at line 125 finds the attacker's existing account by email.
-
At line 164, the Google OAuth identity is linked to the attacker's account.
-
At line 179-181, the email is automatically verified (the attacker never verified it, but now it's marked as verified).
-
At line 175, "google" is appended to the signup methods. The account now has both "basic_auth" and "google" as valid login methods.
-
The attacker's original password is still valid in the database. It was never cleared, changed, or invalidated.
-
The attacker logs in with
victim@company.comand the password they originally set. They now have full access to the victim's account, including any data the victim added via their Google session.
Why This Is Zero-Click
The victim performs no unusual action. They simply log in via their Google account, which is the expected, secure behavior. The attacker staged the account beforehand and gains access without any further interaction.
This is a classic Account Linking vulnerability (cited in OWASP authentication guidelines). The core logic flaw is a trust boundary violation. Authorizer correctly trusts that Google has verified the email address, but it incorrectly extends that trust to validate the password that was set by the unverified attacker. The attacker maintains persistent, password-based backdoor access to the victim's account, even if the victim later revokes Authorizer's OAuth access from their Google account settings. The password was set before Google was ever involved and is never invalidated by the linking process.
Impact
- Full account takeover for any user who logs in via OAuth
- Attacker maintains persistent password-based access even after the victim changes OAuth providers
- All data the victim creates after OAuth login is accessible to the attacker
- The victim has no indication their account was pre-staged
- Affects every OAuth provider configured in Authorizer (Google, GitHub, Facebook, Apple, LinkedIn, Twitter, Discord, Twitch, Roblox, Microsoft)
Suggested Fix
Before linking an OAuth identity to an existing account, verify that the existing account's email is already verified:
existingUser, err := h.StorageProvider.GetUserByEmail(ctx, refs.StringValue(user.Email))
if err == nil {
// Account exists. Only link if email is already verified.
if existingUser.EmailVerifiedAt == nil {
// Email not verified by original owner. Do NOT link.
// Either: reject the login, or create a new separate account,
// or delete the unverified account and create a fresh one for the OAuth user.
}
}
Additionally, when linking a new OAuth identity, invalidate any existing password on the account or require the user to re-authenticate via the original method.
Credit
Koda Reef
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/authorizerdev/authorizer"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260807033110-66fe488fd2a4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35511"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-14T15:36:15Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "The OAuth callback handler links incoming OAuth identities (Google, GitHub, etc.) to existing accounts matched by email address without verifying that the existing account\u0027s email was verified by its original owner. An attacker who pre-registers with a victim\u0027s email address (without verifying it) gains persistent password-based access to the victim\u0027s account after the victim completes a normal OAuth login. Verified against HEAD (commit 73679fa).\n\n## Root Cause\n\nIn `internal/http_handlers/oauth_callback.go`, when an OAuth login occurs for an email that already exists in the database:\n\nLine 125: The existing user is looked up by email:\n\n existingUser, err := h.StorageProvider.GetUserByEmail(ctx, refs.StringValue(user.Email))\n\nLine 164: The OAuth user object is replaced with the existing user:\n\n user = existingUser\n\nLines 173-176: The OAuth provider is appended to the existing user\u0027s signup methods:\n\n signupMethod := existingUser.SignupMethods\n if !strings.Contains(signupMethod, provider) {\n signupMethod = signupMethod + \",\" + provider\n }\n user.SignupMethods = signupMethod\n\nLines 179-181: If the existing account\u0027s email was NOT verified, it is automatically verified:\n\n if user.EmailVerifiedAt == nil {\n now := time.Now().Unix()\n user.EmailVerifiedAt = \u0026now\n }\n\nLine 219: The merged user is saved to the database:\n\n user, err = h.StorageProvider.UpdateUser(ctx, user)\n\nAt no point is the existing account\u0027s password invalidated or the owner notified that a new OAuth identity was linked.\n\n## Attack Chain\n\n1. Attacker signs up with `victim@company.com` using email/password. Attacker sets a known password but does NOT click the email verification link. The account exists in the database with `EmailVerifiedAt = nil`.\n\n2. Some time later, the real owner of `victim@company.com` logs in via Google OAuth (a completely normal action).\n\n3. The OAuth callback at line 125 finds the attacker\u0027s existing account by email.\n\n4. At line 164, the Google OAuth identity is linked to the attacker\u0027s account.\n\n5. At line 179-181, the email is automatically verified (the attacker never verified it, but now it\u0027s marked as verified).\n\n6. At line 175, \"google\" is appended to the signup methods. The account now has both \"basic_auth\" and \"google\" as valid login methods.\n\n7. The attacker\u0027s original password is still valid in the database. It was never cleared, changed, or invalidated.\n\n8. The attacker logs in with `victim@company.com` and the password they originally set. They now have full access to the victim\u0027s account, including any data the victim added via their Google session.\n\n## Why This Is Zero-Click\n\nThe victim performs no unusual action. They simply log in via their Google account, which is the expected, secure behavior. The attacker staged the account beforehand and gains access without any further interaction.\n\nThis is a classic Account Linking vulnerability (cited in OWASP authentication guidelines). The core logic flaw is a trust boundary violation. Authorizer correctly trusts that Google has verified the email address, but it incorrectly extends that trust to validate the password that was set by the unverified attacker. The attacker maintains persistent, password-based backdoor access to the victim\u0027s account, even if the victim later revokes Authorizer\u0027s OAuth access from their Google account settings. The password was set before Google was ever involved and is never invalidated by the linking process.\n\n## Impact\n\n- Full account takeover for any user who logs in via OAuth\n- Attacker maintains persistent password-based access even after the victim changes OAuth providers\n- All data the victim creates after OAuth login is accessible to the attacker\n- The victim has no indication their account was pre-staged\n- Affects every OAuth provider configured in Authorizer (Google, GitHub, Facebook, Apple, LinkedIn, Twitter, Discord, Twitch, Roblox, Microsoft)\n\n## Suggested Fix\n\nBefore linking an OAuth identity to an existing account, verify that the existing account\u0027s email is already verified:\n\n existingUser, err := h.StorageProvider.GetUserByEmail(ctx, refs.StringValue(user.Email))\n if err == nil {\n // Account exists. Only link if email is already verified.\n if existingUser.EmailVerifiedAt == nil {\n // Email not verified by original owner. Do NOT link.\n // Either: reject the login, or create a new separate account,\n // or delete the unverified account and create a fresh one for the OAuth user.\n }\n }\n\nAdditionally, when linking a new OAuth identity, invalidate any existing password on the account or require the user to re-authenticate via the original method.\n\n## Credit\nKoda Reef",
"id": "GHSA-29rf-f4vv-pvq6",
"modified": "2026-08-14T15:36:15Z",
"published": "2026-08-14T15:36:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/authorizerdev/authorizer/security/advisories/GHSA-29rf-f4vv-pvq6"
},
{
"type": "WEB",
"url": "https://github.com/authorizerdev/authorizer/commit/66fe488fd2a4e7acf1e517334344d5e8f3ddd296"
},
{
"type": "PACKAGE",
"url": "https://github.com/authorizerdev/authorizer"
},
{
"type": "WEB",
"url": "https://github.com/authorizerdev/authorizer/releases/tag/2.4.0-rc.16"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Authorizer: Zero-click account takeover via OAuth identity linking to unverified email accounts"
}
GHSA-29VJ-QPHH-JWR9
Vulnerability from github – Published: 2022-05-02 03:54 – Updated: 2022-05-02 03:54Jax Guestbook 3.5.0 allows remote attackers to bypass authentication and modify administrator settings via a direct request to admin/guestbook.admin.php.
{
"affected": [],
"aliases": [
"CVE-2009-4447"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-12-29T20:41:00Z",
"severity": "HIGH"
},
"details": "Jax Guestbook 3.5.0 allows remote attackers to bypass authentication and modify administrator settings via a direct request to admin/guestbook.admin.php.",
"id": "GHSA-29vj-qphh-jwr9",
"modified": "2022-05-02T03:54:51Z",
"published": "2022-05-02T03:54:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-4447"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/55077"
},
{
"type": "WEB",
"url": "http://osvdb.org/61299"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/37921"
},
{
"type": "WEB",
"url": "http://www.exploit-db.com/exploits/10626"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/37466"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-2C3W-HJXH-5RQG
Vulnerability from github – Published: 2022-05-04 00:27 – Updated: 2022-05-04 00:27Red Hat JBoss Operations Network (JON) before 2.4.2 and 3.0.x before 3.0.1 allows remote attackers to hijack agent sessions via an agent registration request without a security token.
{
"affected": [],
"aliases": [
"CVE-2012-0062"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-02-14T15:55:00Z",
"severity": "MODERATE"
},
"details": "Red Hat JBoss Operations Network (JON) before 2.4.2 and 3.0.x before 3.0.1 allows remote attackers to hijack agent sessions via an agent registration request without a security token.",
"id": "GHSA-2c3w-hjxh-5rqg",
"modified": "2022-05-04T00:27:49Z",
"published": "2022-05-04T00:27:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2012-0062"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=783008"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2012-0089.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2012-0406.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-2C4W-43W5-H44Q
Vulnerability from github – Published: 2022-05-01 18:11 – Updated: 2022-05-01 18:11Ingate Firewall and SIParator before 4.5.2 allow remote attackers to bypass SIP authentication via a certain maddr parameter.
{
"affected": [],
"aliases": [
"CVE-2007-3177"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2007-06-11T22:30:00Z",
"severity": "MODERATE"
},
"details": "Ingate Firewall and SIParator before 4.5.2 allow remote attackers to bypass SIP authentication via a certain maddr parameter.",
"id": "GHSA-2c4w-43w5-h44q",
"modified": "2022-05-01T18:11:05Z",
"published": "2022-05-01T18:11:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-3177"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/34887"
},
{
"type": "WEB",
"url": "http://osvdb.org/36708"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/25420"
},
{
"type": "WEB",
"url": "http://www.ingate.com/relnote-452.php"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2007/1973"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Strategy: Libraries or Frameworks
Use an authentication framework or library such as the OWASP ESAPI Authentication feature.
CAPEC-114: Authentication Abuse
An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.
CAPEC-115: Authentication Bypass
An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.
CAPEC-151: Identity Spoofing
Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.
CAPEC-194: Fake the Source of Data
An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.
CAPEC-22: Exploiting Trust in Client
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data
This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.
CAPEC-593: Session Hijacking
This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.
CAPEC-633: Token Impersonation
An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.
CAPEC-650: Upload a Web Shell to a Web Server
By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.
CAPEC-94: Adversary in the Middle (AiTM)
An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.