CWE-290
AllowedAuthentication Bypass by Spoofing
Abstraction: Base · Status: Incomplete
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
1030 vulnerabilities reference this CWE, most recent first.
GHSA-735V-X99Q-VQ7W
Vulnerability from github – Published: 2022-05-13 01:19 – Updated: 2022-05-13 01:19Authentication Bypass by Spoofing vulnerability in ECOS System Management Appliance (aka SMA) 5.2.68 allows a man-in-the-middle attacker to compromise authentication keys and configurations via IP spoofing during "Easy Enrollment."
{
"affected": [],
"aliases": [
"CVE-2018-12331"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-06-17T16:29:00Z",
"severity": "HIGH"
},
"details": "Authentication Bypass by Spoofing vulnerability in ECOS System Management Appliance (aka SMA) 5.2.68 allows a man-in-the-middle attacker to compromise authentication keys and configurations via IP spoofing during \"Easy Enrollment.\"",
"id": "GHSA-735v-x99q-vq7w",
"modified": "2022-05-13T01:19:01Z",
"published": "2022-05-13T01:19:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-12331"
},
{
"type": "WEB",
"url": "https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/advisory.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7365-JMQC-QF8W
Vulnerability from github – Published: 2025-12-19 00:31 – Updated: 2025-12-19 00:31Microsoft Edge (Chromium-based) Spoofing Vulnerability
{
"affected": [],
"aliases": [
"CVE-2025-65046"
],
"database_specific": {
"cwe_ids": [
"CWE-290",
"CWE-451"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-18T22:16:01Z",
"severity": "LOW"
},
"details": "Microsoft Edge (Chromium-based) Spoofing Vulnerability",
"id": "GHSA-7365-jmqc-qf8w",
"modified": "2025-12-19T00:31:42Z",
"published": "2025-12-19T00:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65046"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-65046"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7446-X75G-7GMF
Vulnerability from github – Published: 2022-05-24 19:14 – Updated: 2022-05-24 19:14Yandex Browser before 20.10.0 allows remote attackers to spoof the address bar
{
"affected": [],
"aliases": [
"CVE-2020-27970"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-13T12:15:00Z",
"severity": "MODERATE"
},
"details": "Yandex Browser before 20.10.0 allows remote attackers to spoof the address bar",
"id": "GHSA-7446-x75g-7gmf",
"modified": "2022-05-24T19:14:21Z",
"published": "2022-05-24T19:14:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27970"
},
{
"type": "WEB",
"url": "https://yandex.com/bugbounty/i/hall-of-fame-browser"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-75HV-856G-Q3WX
Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2024-04-04 05:32A CWE-290: Authentication Bypass by Spoofing vulnerability exists that could cause legitimate users to be locked out of devices or facilitate backdoor account creation by spoofing a device on the local network. Affected Products: EcoStruxure™ Cybersecurity Admin Expert (CAE) (Versions prior to 2.2)
{
"affected": [],
"aliases": [
"CVE-2022-32747"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-30T23:15:00Z",
"severity": "HIGH"
},
"details": "A CWE-290: Authentication Bypass by Spoofing vulnerability exists that could cause legitimate users to be locked out of devices or facilitate backdoor account creation by spoofing a device on the local network. Affected Products: EcoStruxure\u2122 Cybersecurity Admin Expert (CAE) (Versions prior to 2.2)",
"id": "GHSA-75hv-856g-q3wx",
"modified": "2024-04-04T05:32:06Z",
"published": "2023-07-06T19:24:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32747"
},
{
"type": "WEB",
"url": "https://download.schneider-electric.com/files?p_enDocType=Security+and+Safety+Notice\u0026p_File_Name=SEVD-2022-165-08_Cybersecurity_Admin_Expert_Security_Notification.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7654-7H8M-J5FF
Vulnerability from github – Published: 2025-12-13 18:30 – Updated: 2026-01-14 18:31The SWD debug interface on the Growatt ShineLan-X communication dongle is available by default, allowing an attacker to attain debug access to the device and to extracting secrets or domains from within the device
{
"affected": [],
"aliases": [
"CVE-2025-36753"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-13T16:16:54Z",
"severity": "HIGH"
},
"details": "The SWD debug interface on the Growatt ShineLan-X communication dongle is available by default, allowing an attacker to attain debug access to the device and to extracting secrets or domains from within the device",
"id": "GHSA-7654-7h8m-j5ff",
"modified": "2026-01-14T18:31:16Z",
"published": "2025-12-13T18:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36753"
},
{
"type": "WEB",
"url": "https://csirt.divd.nl/CVE-2025-36753"
}
],
"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:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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-777C-2FXX-QR28
Vulnerability from github – Published: 2026-08-25 18:20 – Updated: 2026-08-25 18:20Summary
AshAuthentication's OAuth2 and OIDC family strategies matched the local user by email address rather than by the OpenID Connect iss/sub claim combination. A provider login presenting a victim's email (including an unverified, reused, or email_verified: false account) resolved to and signed in as the victim's existing local account. An unauthenticated attacker who can register an account on any accepted OAuth provider with the victim's email obtains the victim's full local privileges.
Details
Per OpenID Connect Core §5.7, only the iss/sub claim combination uniquely and stably identifies an end-user; any other claim, including email, MUST NOT be used as a unique identifier. AshAuthentication's OAuth2/OIDC register flow nonetheless drove the upsert by the email field (upsert_identity on email, or a user-defined sign-in filter), and the sign-in preparation filtered users by email.
1. Provider login. The attacker signs in to a configured OAuth/OIDC provider with the victim's email. This is trivial for providers that don't verify email ownership, and possible under email-reuse / reclamation for providers that do.
2. AshAuthentication register step. 'Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange':change/3 invokes the upsert action whose upsert_identity resolves on the email. The action lands on the victim's existing record.
3. Sign-in preparation. 'Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation':prepare/3 does not verify the returned user against an iss/sub identity, so the attacker is authenticated as the victim.
Configurations
Exploitation requires one of:
- The configured OAuth/OIDC provider does not reliably verify email ownership (lets a user register with any email, or fails to verify it). Many social/enterprise providers fall into this category, including Slack, generic OIDC deployments, and any custom OAuth2 endpoint without strict email validation.
- The provider allows email reclamation: the victim's email becomes available on the provider (account deletion, organisation off-boarding, mail-host change) and the attacker registers it. The attacker then signs in via that provider and takes over the local account.
Providers that strictly verify email ownership and forbid reuse (e.g. modern Google Workspace, GitHub for accounts that have completed verification) are not directly exploitable, but applications that accept any of the affected strategy types in addition are still exposed via the weaker providers in the set.
PoC
- On any accepted OAuth/OIDC provider, register an account whose email is the victim's email (or use a provider that allows email reuse).
- Complete the standard OAuth flow against the AshAuthentication application.
- The application's upsert resolves on email, signs the attacker in as the victim, and returns a session token for the victim's account.
Impact
Unauthenticated remote account takeover against any AshAuthentication-using application that exposes an OAuth2/OIDC strategy. The default configuration of every affected strategy is vulnerable; no application-level misconfiguration is required. An attacker who succeeds gains the victim's full local identity, with read, write, and destructive access to whatever the victim's account can do.
References
- Introduction commit: https://github.com/team-alembic/ash_authentication/commit/c5f589058e04239263f50a1430eb17ea6d5dd1a2
- Patch commit (4.x backport): https://github.com/team-alembic/ash_authentication/commit/728b8d28c1b5f465fa1116ef044a815300fc733d
- Patch commit (5.x): https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7
{
"affected": [
{
"package": {
"ecosystem": "Hex",
"name": "ash_authentication"
},
"ranges": [
{
"events": [
{
"introduced": "0.1.0"
},
{
"fixed": "4.14.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Hex",
"name": "ash_authentication"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-rc.0"
},
{
"fixed": "5.0.0-rc.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-49757"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-25T18:20:27Z",
"nvd_published_at": "2026-06-15T12:16:25Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\nAshAuthentication\u0027s OAuth2 and OIDC family strategies matched the local user by email address rather than by the OpenID Connect `iss`/`sub` claim combination. A provider login presenting a victim\u0027s email (including an unverified, reused, or `email_verified: false` account) resolved to and signed in as the victim\u0027s existing local account. An unauthenticated attacker who can register an account on any accepted OAuth provider with the victim\u0027s email obtains the victim\u0027s full local privileges.\n\n### Details\n\nPer OpenID Connect Core \u00a75.7, only the `iss`/`sub` claim combination uniquely and stably identifies an end-user; any other claim, including `email`, MUST NOT be used as a unique identifier. AshAuthentication\u0027s OAuth2/OIDC register flow nonetheless drove the upsert by the email field (`upsert_identity` on email, or a user-defined sign-in filter), and the sign-in preparation filtered users by email.\n\n**1. Provider login.** The attacker signs in to a configured OAuth/OIDC provider with the victim\u0027s email. This is trivial for providers that don\u0027t verify email ownership, and possible under email-reuse / reclamation for providers that do.\n\n**2. AshAuthentication register step.** `\u0027Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange\u0027:change/3` invokes the upsert action whose `upsert_identity` resolves on the email. The action lands on the victim\u0027s existing record.\n\n**3. Sign-in preparation.** `\u0027Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation\u0027:prepare/3` does not verify the returned user against an `iss`/`sub` identity, so the attacker is authenticated as the victim.\n\n#### Configurations\n\nExploitation requires one of:\n\n* The configured OAuth/OIDC provider does not reliably verify email ownership (lets a user register with any email, or fails to verify it). Many social/enterprise providers fall into this category, including Slack, generic OIDC deployments, and any custom OAuth2 endpoint without strict email validation.\n* The provider allows email reclamation: the victim\u0027s email becomes available on the provider (account deletion, organisation off-boarding, mail-host change) and the attacker registers it. The attacker then signs in via that provider and takes over the local account.\n\nProviders that strictly verify email ownership and forbid reuse (e.g. modern Google Workspace, GitHub for accounts that have completed verification) are not directly exploitable, but applications that accept any of the affected strategy types in addition are still exposed via the weaker providers in the set.\n\n### PoC\n\n1. On any accepted OAuth/OIDC provider, register an account whose email is the victim\u0027s email (or use a provider that allows email reuse).\n2. Complete the standard OAuth flow against the AshAuthentication application.\n3. The application\u0027s upsert resolves on email, signs the attacker in as the victim, and returns a session token for the victim\u0027s account.\n\n### Impact\n\nUnauthenticated remote account takeover against any AshAuthentication-using application that exposes an OAuth2/OIDC strategy. The default configuration of every affected strategy is vulnerable; no application-level misconfiguration is required. An attacker who succeeds gains the victim\u0027s full local identity, with read, write, and destructive access to whatever the victim\u0027s account can do.\n\n## References\n\n* Introduction commit: https://github.com/team-alembic/ash_authentication/commit/c5f589058e04239263f50a1430eb17ea6d5dd1a2\n* Patch commit (4.x backport): https://github.com/team-alembic/ash_authentication/commit/728b8d28c1b5f465fa1116ef044a815300fc733d\n* Patch commit (5.x): https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7",
"id": "GHSA-777c-2fxx-qr28",
"modified": "2026-08-25T18:20:27Z",
"published": "2026-08-25T18:20:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-777c-2fxx-qr28"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49757"
},
{
"type": "WEB",
"url": "https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7"
},
{
"type": "WEB",
"url": "https://github.com/team-alembic/ash_authentication/commit/728b8d28c1b5f465fa1116ef044a815300fc733d"
},
{
"type": "WEB",
"url": "https://cna.erlef.org/cves/CVE-2026-49757.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/team-alembic/ash_authentication"
},
{
"type": "WEB",
"url": "https://github.com/team-alembic/ash_authentication/releases/tag/v4.14.0"
},
{
"type": "WEB",
"url": "https://github.com/team-alembic/ash_authentication/releases/tag/v5.0.0-rc.10"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-49757"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "AshAuthentication vulnerable to OAuth2/OIDC account takeover via email-based user matching"
}
GHSA-77F9-JV8V-XRJP
Vulnerability from github – Published: 2022-07-30 00:00 – Updated: 2022-08-06 00:00Due to a bug in the handling of the communication between the client and server, it was possible for one client, already registered with their own client ID, to send messages to the server claiming to come from another client ID. This issue was resolved in Velociraptor 0.6.5-2.
{
"affected": [],
"aliases": [
"CVE-2022-35629"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-29T17:15:00Z",
"severity": "MODERATE"
},
"details": "Due to a bug in the handling of the communication between the client and server, it was possible for one client, already registered with their own client ID, to send messages to the server claiming to come from another client ID. This issue was resolved in Velociraptor 0.6.5-2.",
"id": "GHSA-77f9-jv8v-xrjp",
"modified": "2022-08-06T00:00:50Z",
"published": "2022-07-30T00:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35629"
},
{
"type": "WEB",
"url": "https://www.rapid7.com/blog/post/2022/07/26/cve-2022-35629-35632-velociraptor-multiple-vulnerabilities-fixed"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-77FW-RF4V-VFP9
Vulnerability from github – Published: 2023-06-21 22:00 – Updated: 2023-06-21 22:00Information
Please note that this is not a new disclosure, and is previously reported in our SECURITY-NOTICE.md which we removed in favor of github advisory.
Overview
This vulnerability allows an attacker to impersonate another user and potentially elevate their privileges if the SAML identity provider:
-
signs SAML response and signs assertion
-
does not sign SAML response and signs assertion
Am I affected?
You may be affected if you use SAML2 protocol with passport-wsfed-saml2 versions below 3.0.5 and your SAML identity Provider: 1. signs SAML response and signs assertion; or 2. does not sign SAML response and signs assertion
How do I fix it?
You may fix this vulnerability by upgrading your library to version 3.0.5 or above.
Will the fix impact my users?
This fix patches the library that your application runs, but will not impact your users, their current state, or any existing sessions.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "passport-wsfed-saml2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-16897"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-21T22:00:18Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Information\nPlease note that this is not a new disclosure, and is previously reported in our [SECURITY-NOTICE.md](https://github.com/auth0/passport-wsfed-saml2/commit/520b9fc0bb4249ce83bec47e30153419f086ab70\n) which we removed in favor of github advisory. \n\n# Overview \n This vulnerability allows an attacker to impersonate another user and potentially elevate their privileges if the SAML identity provider:\n\n- signs SAML response and signs assertion\n\n- does not sign SAML response and signs assertion\n\n# Am I affected?\n\nYou may be affected if you use SAML2 protocol with passport-wsfed-saml2 versions below 3.0.5 and your SAML identity Provider: \n1. signs SAML response and signs assertion; or \n2. does not sign SAML response and signs assertion\n\n# How do I fix it?\n\nYou may fix this vulnerability by upgrading your library to version 3.0.5 or above. \n\n# Will the fix impact my users?\nThis fix patches the library that your application runs, but will not impact your users, their current state, or any existing sessions.",
"id": "GHSA-77fw-rf4v-vfp9",
"modified": "2023-06-21T22:00:18Z",
"published": "2023-06-21T22:00:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/auth0/passport-wsfed-saml2/security/advisories/GHSA-77fw-rf4v-vfp9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-16897"
},
{
"type": "WEB",
"url": "https://github.com/auth0/passport-wsfed-saml2/commit/520b9fc0bb4249ce83bec47e30153419f086ab70"
},
{
"type": "WEB",
"url": "https://auth0.com/docs/security/bulletins/cve-2017-16897"
},
{
"type": "PACKAGE",
"url": "https://github.com/auth0/passport-wsfed-saml2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "passport-wsfed-saml2 vulnerable to Signature Bypass in SAML2 token"
}
GHSA-786W-P5PM-CVGH
Vulnerability from github – Published: 2026-08-28 18:30 – Updated: 2026-08-28 18:30Summary
phpSysInfo's PSI_ALLOWED IP allowlist can be trivially bypassed by any unauthenticated remote attacker. The access-control check in read_config.php derives the client IP from the attacker-controlled X-Forwarded-For and Client-IP HTTP headers before falling back to REMOTE_ADDR. An attacker can send X-Forwarded-For: <an allowed IP> to impersonate a trusted address and gain full access to all exposed system information, defeating the only IP-based access restriction the application provides.
Affected component
- File:
read_config.php - Versions: all versions up to and including 3.4.x (current
main)
Description
When PSI_ALLOWED is configured, read_config.php enforces an IP allowlist. The client IP is resolved as follows:
if (isset($_SERVER["HTTP_X_FORWARDED_FOR"])) {
$ip = $_SERVER["HTTP_X_FORWARDED_FOR"];
} else {
if (isset($_SERVER["HTTP_CLIENT_IP"])) {
$ip = $_SERVER["HTTP_CLIENT_IP"];
} else {
$ip = $_SERVER["REMOTE_ADDR"];
}
}
Both HTTP_X_FORWARDED_FOR and HTTP_CLIENT_IP are fully attacker-controlled request headers. They are trusted unconditionally and take priority over REMOTE_ADDR. There is no concept of a configured/trusted reverse proxy, so even when phpSysInfo is exposed directly (no proxy in front), the spoofed header wins. As a result the allowlist provides no real protection.
Proof of Concept
Verified against phpSysInfo 3.4.x-main-d786ab2 running in a local Docker container (php:8.2-apache).
Deployment with the allowlist (under [main]) restricted to an address the attacker does not own:
; phpsysinfo.ini ([main] section)
ALLOWED=8.8.8.8
Request without the spoofed header — correctly denied (attacker's real IP is the container gateway 172.17.0.1):
$ curl -s http://localhost:8080/xml.php | head -c 200
Client IP address (172.17.0.1) not allowed.
Request with a spoofed X-Forwarded-For matching the allowlist — bypass, full system information returned:
$ curl -s -H "X-Forwarded-For: 8.8.8.8" http://localhost:8080/xml.php | head -c 200
<?xml version="1.0" encoding="UTF-8"?>
<tns:phpsysinfo xmlns:tns="http://phpsysinfo.sourceforge.net/" ...>
The same bypass works with the Client-IP header (HTTP_CLIENT_IP), which is also trusted before REMOTE_ADDR.
Impact
Any remote, unauthenticated attacker can defeat the PSI_ALLOWED access restriction and read the complete system information exposed by phpSysInfo, including hostname, kernel version, CPU model, memory layout, mounted filesystems, and all network interface addresses. This information is valuable for reconnaissance and targeting of further attacks.
Remediation
Use REMOTE_ADDR as the authoritative client IP by default. Only honor X-Forwarded-For / Client-IP when the request originates from an explicitly configured list of trusted proxies, and when honoring it, parse the correct entry from the chain rather than trusting the whole header. Example direction:
$ip = $_SERVER["REMOTE_ADDR"];
if (defined('PSI_TRUSTED_PROXIES') && in_array($ip, $trusted_proxies, true)
&& isset($_SERVER["HTTP_X_FORWARDED_FOR"])) {
// take the right-most untrusted hop from the XFF chain
$parts = array_map('trim', explode(',', $_SERVER["HTTP_X_FORWARDED_FOR"]));
$ip = end($parts);
}
Discovery / Credit
- Reported by: Muhammed Mirac Kayıkci
- Coordinated disclosure; no third-party systems were tested. Verification performed against a local Docker deployment only.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.4.5"
},
"package": {
"ecosystem": "Packagist",
"name": "phpsysinfo/phpsysinfo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55584"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T18:30:55Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\nphpSysInfo\u0027s `PSI_ALLOWED` IP allowlist can be trivially bypassed by any unauthenticated remote attacker. The access-control check in `read_config.php` derives the client IP from the attacker-controlled `X-Forwarded-For` and `Client-IP` HTTP headers **before** falling back to `REMOTE_ADDR`. An attacker can send `X-Forwarded-For: \u003can allowed IP\u003e` to impersonate a trusted address and gain full access to all exposed system information, defeating the only IP-based access restriction the application provides.\n\n## Affected component\n- File: `read_config.php`\n- Versions: all versions up to and including 3.4.x (current `main`)\n\n## Description\nWhen `PSI_ALLOWED` is configured, `read_config.php` enforces an IP allowlist. The client IP is resolved as follows:\n\n```php\nif (isset($_SERVER[\"HTTP_X_FORWARDED_FOR\"])) {\n $ip = $_SERVER[\"HTTP_X_FORWARDED_FOR\"];\n} else {\n if (isset($_SERVER[\"HTTP_CLIENT_IP\"])) {\n $ip = $_SERVER[\"HTTP_CLIENT_IP\"];\n } else {\n $ip = $_SERVER[\"REMOTE_ADDR\"];\n }\n}\n```\n\nBoth `HTTP_X_FORWARDED_FOR` and `HTTP_CLIENT_IP` are fully attacker-controlled request headers. They are trusted unconditionally and take priority over `REMOTE_ADDR`. There is no concept of a configured/trusted reverse proxy, so even when phpSysInfo is exposed directly (no proxy in front), the spoofed header wins. As a result the allowlist provides no real protection.\n\n## Proof of Concept\nVerified against phpSysInfo `3.4.x-main-d786ab2` running in a local Docker container (`php:8.2-apache`).\n\nDeployment with the allowlist (under `[main]`) restricted to an address the attacker does not own:\n\n```ini\n; phpsysinfo.ini ([main] section)\nALLOWED=8.8.8.8\n```\n\nRequest without the spoofed header \u2014 correctly denied (attacker\u0027s real IP is the container gateway `172.17.0.1`):\n\n```bash\n$ curl -s http://localhost:8080/xml.php | head -c 200\nClient IP address (172.17.0.1) not allowed.\n```\n\nRequest with a spoofed `X-Forwarded-For` matching the allowlist \u2014 bypass, full system information returned:\n\n```bash\n$ curl -s -H \"X-Forwarded-For: 8.8.8.8\" http://localhost:8080/xml.php | head -c 200\n\u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\n\u003ctns:phpsysinfo xmlns:tns=\"http://phpsysinfo.sourceforge.net/\" ...\u003e\n```\n\nThe same bypass works with the `Client-IP` header (`HTTP_CLIENT_IP`), which is also trusted before `REMOTE_ADDR`.\n\n## Impact\nAny remote, unauthenticated attacker can defeat the `PSI_ALLOWED` access restriction and read the complete system information exposed by phpSysInfo, including hostname, kernel version, CPU model, memory layout, mounted filesystems, and all network interface addresses. This information is valuable for reconnaissance and targeting of further attacks.\n\n## Remediation\nUse `REMOTE_ADDR` as the authoritative client IP by default. Only honor `X-Forwarded-For` / `Client-IP` when the request originates from an explicitly configured list of trusted proxies, and when honoring it, parse the correct entry from the chain rather than trusting the whole header. Example direction:\n\n```php\n$ip = $_SERVER[\"REMOTE_ADDR\"];\nif (defined(\u0027PSI_TRUSTED_PROXIES\u0027) \u0026\u0026 in_array($ip, $trusted_proxies, true)\n \u0026\u0026 isset($_SERVER[\"HTTP_X_FORWARDED_FOR\"])) {\n // take the right-most untrusted hop from the XFF chain\n $parts = array_map(\u0027trim\u0027, explode(\u0027,\u0027, $_SERVER[\"HTTP_X_FORWARDED_FOR\"]));\n $ip = end($parts);\n}\n```\n\n## Discovery / Credit\n- Reported by: Muhammed Mirac Kay\u0131kci\n- Coordinated disclosure; no third-party systems were tested. Verification performed against a local Docker deployment only.",
"id": "GHSA-786w-p5pm-cvgh",
"modified": "2026-08-28T18:30:55Z",
"published": "2026-08-28T18:30:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/phpsysinfo/phpsysinfo/security/advisories/GHSA-786w-p5pm-cvgh"
},
{
"type": "WEB",
"url": "https://github.com/phpsysinfo/phpsysinfo/commit/019fa2d7e568ea11461adb4bd33da5dc87c4b9ab"
},
{
"type": "PACKAGE",
"url": "https://github.com/phpsysinfo/phpsysinfo"
},
{
"type": "WEB",
"url": "https://github.com/phpsysinfo/phpsysinfo/releases/tag/v3.4.6"
}
],
"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"
}
],
"summary": "phpSysInfo has an IP allowlist (PSI_ALLOWED) bypass via spoofed X-Forwarded-For / Client-IP headers"
}
GHSA-78GQ-Q74G-W632
Vulnerability from github – Published: 2025-04-15 21:31 – Updated: 2025-04-15 21:31In Ubuntu, gnome-control-center did not properly reflect SSH remote login status when the system was configured to use systemd socket activation for openssh-server. This could unknowingly leave the local machine exposed to remote SSH access contrary to expectation of the user.
{
"affected": [],
"aliases": [
"CVE-2023-5616"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-15T19:16:06Z",
"severity": "MODERATE"
},
"details": "In Ubuntu, gnome-control-center did not properly reflect SSH remote login status when the system was configured to use systemd socket activation for openssh-server. This could unknowingly leave the local machine exposed to remote SSH access contrary to expectation of the user.",
"id": "GHSA-78gq-q74g-w632",
"modified": "2025-04-15T21:31:43Z",
"published": "2025-04-15T21:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5616"
},
{
"type": "WEB",
"url": "https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/2039577"
},
{
"type": "WEB",
"url": "https://ubuntu.com/security/CVE-2023-5616"
},
{
"type": "WEB",
"url": "https://ubuntu.com/security/notices/USN-6554-1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-21: Exploitation of Trusted Identifiers
An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.
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-459: Creating a Rogue Certification Authority Certificate
An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.
CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness
An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.
CAPEC-473: Signature Spoof
An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.
CAPEC-476: Signature Spoofing by Misrepresentation
An attacker exploits a weakness in the parsing or display code of the recipient software to generate a data blob containing a supposedly valid signature, but the signer's identity is falsely represented, which can lead to the attacker manipulating the recipient software or its victim user to perform compromising actions.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-667: Bluetooth Impersonation AttackS (BIAS)
An adversary disguises the MAC address of their Bluetooth enabled device to one for which there exists an active and trusted connection and authenticates successfully. The adversary can then perform malicious actions on the target Bluetooth device depending on the target’s capabilities.
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.