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.
1046 vulnerabilities reference this CWE, most recent first.
GHSA-J8GJ-9RM5-4XHX
Vulnerability from github – Published: 2026-05-27 21:11 – Updated: 2026-05-27 21:11Cas2Handler builds this service parameter from Request::getSchemeAndHttpHost(), which reflects the attacker-controlled HTTP Host header whenever Symfony's framework.trusted_hosts setting is not configured (the default). An attacker who controls any other application registered with the same CAS server can replay a victim's ticket against the Symfony application, with a spoofed Host header, and be authenticated as that victim.
Resolution
A new required service_url configuration option is introduced on Cas2Handler. The CAS service parameter sent to the validation endpoint is now built from this configured URL instead of being derived from the request's Host header, preventing cross-service ticket replay via Host header spoofing.
The patch for this issue is available here for branch 7.4.
Credits
Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and Nicolas Grekas for providing the fix.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/security-http"
},
"ranges": [
{
"events": [
{
"introduced": "7.1.0"
},
{
"fixed": "7.4.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/security-http"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "7.1.0"
},
{
"fixed": "7.4.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45074"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-27T21:11:59Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "`Cas2Handler` builds this `service` parameter from `Request::getSchemeAndHttpHost()`, which reflects the attacker-controlled HTTP `Host` header whenever Symfony\u0027s `framework.trusted_hosts` setting is not configured (the default). An attacker who controls any *other* application registered with the same CAS server can replay a victim\u0027s ticket against the Symfony application, with a spoofed `Host` header, and be authenticated as that victim.\n\n### Resolution\n\nA new required `service_url` configuration option is introduced on `Cas2Handler`. The CAS `service` parameter sent to the validation endpoint is now built from this configured URL instead of being derived from the request\u0027s `Host` header, preventing cross-service ticket replay via Host header spoofing.\n\nThe patch for this issue is available [here](https://github.com/symfony/symfony/commit/5ba145dba702404801bdf9e7e8d6df170060d541) for branch 7.4.\n\n### Credits\n\nSymfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and Nicolas Grekas for providing the fix.",
"id": "GHSA-j8gj-9rm5-4xhx",
"modified": "2026-05-27T21:11:59Z",
"published": "2026-05-27T21:11:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/security/advisories/GHSA-j8gj-9rm5-4xhx"
},
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/commit/5ba145dba702404801bdf9e7e8d6df170060d541"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/security-http/CVE-2026-45074.yaml"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45074.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/symfony/symfony"
},
{
"type": "WEB",
"url": "https://symfony.com/cve-2026-45074"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Symfony\u0027s Cas2Handler Derives CAS service URL from Client Host Header \u2192 Cross-Service Ticket Replay"
}
GHSA-J8H8-75H3-JG53
Vulnerability from github – Published: 2026-05-14 13:13 – Updated: 2026-05-15 23:44Impact
Fleet trusted client-supplied IP address headers when determining the source IP for incoming requests. This allowed authenticated and unauthenticated clients to spoof their apparent IP address and bypass per-IP rate limiting controls.
Fleet determines a client’s public IP address using HTTP headers such as: - X-Forwarded-For - X-Real-IP - True-Client-IP
These headers were trusted without validation. An attacker could supply arbitrary values in these headers, causing Fleet to treat each request as originating from a different IP address.
This could allow an attacker to bypass per-IP rate limits and increase the effectiveness of brute-force or password-spraying attempts against authentication endpoints.
This issue does not allow authentication bypass, privilege escalation, data exposure, or remote code execution on its own.
Workarounds
Run Fleet behind a trusted reverse proxy or load balancer that overwrites client IP headers.
For more information
If you have any questions or comments about this advisory:
Email us at security@fleetdm.com Join #fleet in osquery Slack
Credits
We thank @fuzzztf for responsibly reporting this issue.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/fleetdm/fleet/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.80.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-24000"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-14T13:13:39Z",
"nvd_published_at": "2026-05-14T20:17:01Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nFleet trusted client-supplied IP address headers when determining the source IP for incoming requests. This allowed authenticated and unauthenticated clients to spoof their apparent IP address and bypass per-IP rate limiting controls.\n\nFleet determines a client\u2019s public IP address using HTTP headers such as:\n- X-Forwarded-For\n- X-Real-IP\n- True-Client-IP\n\nThese headers were trusted without validation. An attacker could supply arbitrary values in these headers, causing Fleet to treat each request as originating from a different IP address.\n\nThis could allow an attacker to bypass per-IP rate limits and increase the effectiveness of brute-force or password-spraying attempts against authentication endpoints.\n\nThis issue does not allow authentication bypass, privilege escalation, data exposure, or remote code execution on its own.\n\n### Workarounds\n\nRun Fleet behind a trusted reverse proxy or load balancer that overwrites client IP headers.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\nEmail us at [security@fleetdm.com](mailto:security@fleetdm.com)\nJoin #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw)\n\n### Credits\n\nWe thank @fuzzztf for responsibly reporting this issue.",
"id": "GHSA-j8h8-75h3-jg53",
"modified": "2026-05-15T23:44:40Z",
"published": "2026-05-14T13:13:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fleetdm/fleet/security/advisories/GHSA-j8h8-75h3-jg53"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24000"
},
{
"type": "PACKAGE",
"url": "https://github.com/fleetdm/fleet"
},
{
"type": "WEB",
"url": "https://github.com/fleetdm/fleet/releases/tag/fleet-v4.80.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Fleet has a rate limiting bypass via untrusted client IP headers"
}
GHSA-J946-QF4C-JRJH
Vulnerability from github – Published: 2025-02-20 18:31 – Updated: 2025-11-04 21:31A lack of rate limiting in the 'Forgot Password' feature of PHPJabbers Shared Asset Booking System v1.0 allows attackers to send an excessive amount of email for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages.
{
"affected": [],
"aliases": [
"CVE-2023-51323"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-20T16:15:35Z",
"severity": "MODERATE"
},
"details": "A lack of rate limiting in the \u0027Forgot Password\u0027 feature of PHPJabbers Shared Asset Booking System v1.0 allows attackers to send an excessive amount of email for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages.",
"id": "GHSA-j946-qf4c-jrjh",
"modified": "2025-11-04T21:31:30Z",
"published": "2025-02-20T18:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51323"
},
{
"type": "WEB",
"url": "https://packetstorm.news/files/id/176503"
},
{
"type": "WEB",
"url": "https://www.phpjabbers.com/shared-asset-booking-system/#sectionDemo"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/176503/PHPJabbers-Shared-Asset-Booking-System-1.0-Missing-Rate-Limit.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J9GM-F3P3-J5G3
Vulnerability from github – Published: 2022-07-24 00:00 – Updated: 2022-07-28 00:00Inappropriate implementation in Full Screen Mode in Google Chrome on Android prior to 100.0.4896.60 allowed a remote attacker to spoof the contents of the Omnibox (URL bar) via a crafted HTML page.
{
"affected": [],
"aliases": [
"CVE-2022-1129"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-23T00:15:00Z",
"severity": "MODERATE"
},
"details": "Inappropriate implementation in Full Screen Mode in Google Chrome on Android prior to 100.0.4896.60 allowed a remote attacker to spoof the contents of the Omnibox (URL bar) via a crafted HTML page.",
"id": "GHSA-j9gm-f3p3-j5g3",
"modified": "2022-07-28T00:00:48Z",
"published": "2022-07-24T00:00:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1129"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2022/03/stable-channel-update-for-desktop_29.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1300253"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202208-25"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J9GQ-W73W-9H6C
Vulnerability from github – Published: 2023-10-02 21:30 – Updated: 2024-10-21 20:53An issue was discovered in pretix before 2023.7.1. Incorrect parsing of configuration files causes the application to trust unchecked X-Forwarded-For headers even though it has not been configured to do so. This can lead to IP address spoofing by users of the application.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pretix"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2023.7.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-44463"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-04T14:12:10Z",
"nvd_published_at": "2023-10-02T20:15:10Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in pretix before 2023.7.1. Incorrect parsing of configuration files causes the application to trust unchecked X-Forwarded-For headers even though it has not been configured to do so. This can lead to IP address spoofing by users of the application.",
"id": "GHSA-j9gq-w73w-9h6c",
"modified": "2024-10-21T20:53:25Z",
"published": "2023-10-02T21:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44463"
},
{
"type": "WEB",
"url": "https://github.com/pretix/pretix/commit/ccdce2ccb8207b82501af3c03f50abc0f819b469"
},
{
"type": "WEB",
"url": "https://github.com/pretix/pretix"
},
{
"type": "WEB",
"url": "https://github.com/pretix/pretix/compare/v2023.7.0...v2023.7.1"
},
{
"type": "WEB",
"url": "https://github.com/pretix/pretix/tags"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/pretix/PYSEC-2023-187.yaml"
},
{
"type": "WEB",
"url": "https://pretix.eu/about/en/blog/20230911-release-2023-7-1"
},
{
"type": "WEB",
"url": "https://pretix.eu/about/en/ticketing"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "pretix potential IP address spoofing vulnerability"
}
GHSA-JC5P-HFQ2-7MFM
Vulnerability from github – Published: 2023-01-26 21:30 – Updated: 2023-02-01 18:30An issue has been discovered in GitLab affecting all versions starting from 15.4 prior to 15.4.4, and 15.5 prior to 15.5.2. GitLab was not performing correct authentication with some Package Registries when IP address restrictions were configured, allowing an attacker already in possession of a valid Deploy Token to misuse it from any location.
{
"affected": [],
"aliases": [
"CVE-2022-3820"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-26T21:15:00Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab affecting all versions starting from 15.4 prior to 15.4.4, and 15.5 prior to 15.5.2. GitLab was not performing correct authentication with some Package Registries when IP address restrictions were configured, allowing an attacker already in possession of a valid Deploy Token to misuse it from any location.",
"id": "GHSA-jc5p-hfq2-7mfm",
"modified": "2023-02-01T18:30:24Z",
"published": "2023-01-26T21:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3820"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-3820.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/378638"
}
],
"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-JF2C-V9V9-9R3W
Vulnerability from github – Published: 2021-11-25 00:00 – Updated: 2026-08-19 18:31{
"affected": [],
"aliases": [
"CVE-2021-43220"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-24T01:15:00Z",
"severity": "HIGH"
},
"details": "Microsoft Edge for iOS Spoofing Vulnerability",
"id": "GHSA-jf2c-v9v9-9r3w",
"modified": "2026-08-19T18:31:45Z",
"published": "2021-11-25T00:00:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43220"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-43220"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-43220"
}
],
"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-JF52-3F2H-H9J5
Vulnerability from github – Published: 2026-01-07 19:22 – Updated: 2026-01-08 20:51Impact
An authentication bypass in the Stripe Trigger node allows unauthenticated parties to trigger workflows by sending forged Stripe webhook events.
The Stripe Trigger creates and stores a Stripe webhook signing secret when registering the webhook endpoint, but incoming webhook requests were not verified against this secret. As a result, any HTTP client that knows the webhook URL could send a POST request containing a matching event type, causing the workflow to execute as if a legitimate Stripe event had been received.
This issue affects n8n users who have active workflows using the Stripe Trigger node. An attacker could potentially fake payment or subscription events and influence downstream workflow behavior. The practical risk is reduced by the fact that the webhook URL contains a high-entropy UUID; however, authenticated n8n users with access to the workflow can view this webhook ID.
Patches
The issue has been fixed in n8n version 2.2.2. Users should upgrade to this version or later to ensure that Stripe webhook signatures are properly verified.
Workarounds
There is no complete workaround short of upgrading. As a temporary mitigation, users can deactivate affected workflows or restrict access to workflows containing Stripe Trigger nodes to trusted users only.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "n8n"
},
"ranges": [
{
"events": [
{
"introduced": "0.150.0"
},
{
"fixed": "2.2.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-21894"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-07T19:22:54Z",
"nvd_published_at": "2026-01-08T10:15:55Z",
"severity": "MODERATE"
},
"details": "### Impact\nAn authentication bypass in the Stripe Trigger node allows unauthenticated parties to trigger workflows by sending forged Stripe webhook events.\n\nThe Stripe Trigger creates and stores a Stripe webhook signing secret when registering the webhook endpoint, but incoming webhook requests were not verified against this secret. As a result, any HTTP client that knows the webhook URL could send a POST request containing a matching event `type`, causing the workflow to execute as if a legitimate Stripe event had been received.\n\nThis issue affects n8n users who have active workflows using the Stripe Trigger node. An attacker could potentially fake payment or subscription events and influence downstream workflow behavior. The practical risk is reduced by the fact that the webhook URL contains a high-entropy UUID; however, authenticated n8n users with access to the workflow can view this webhook ID.\n\n### Patches\nThe issue has been fixed in n8n version 2.2.2. Users should upgrade to this version or later to ensure that Stripe webhook signatures are properly verified.\n\n### Workarounds\nThere is no complete workaround short of upgrading. As a temporary mitigation, users can deactivate affected workflows or restrict access to workflows containing Stripe Trigger nodes to trusted users only.",
"id": "GHSA-jf52-3f2h-h9j5",
"modified": "2026-01-08T20:51:27Z",
"published": "2026-01-07T19:22:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-jf52-3f2h-h9j5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21894"
},
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/pull/22764"
},
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/commit/a61a5991093c41863506888336e808ac1eff8d59"
},
{
"type": "PACKAGE",
"url": "https://github.com/n8n-io/n8n"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "n8n\u0027s Missing Stripe-Signature Verification Allows Unauthenticated Forged Webhooks"
}
GHSA-JHPV-4Q4F-43G5
Vulnerability from github – Published: 2025-10-07 21:15 – Updated: 2025-10-07 21:15Impact
This is a critical network security vulnerability for Akka.Remote users who have SSL / TLS enabled on their Akka.Remote connections and were expecting certificate-based authentication to be enforced on all peers attempting to join the network.
In all versions of Akka.Remote from v1.2.0 to v1.5.51, TLS could be enabled via our akka.remote.dot-netty.tcp transport and this would correctly enforce private key validation on the server-side of inbound connections. Akka.Remote, however, never asked the outbound-connecting client to present ITS certificate - therefore it's possible for untrusted parties to connect to a private key'd Akka.NET cluster and begin communicating with it without any certificate.
The issue here is that for certificate-based authentication to work properly, ensuring that all members of the Akka.Remote network are secured with the same private key, Akka.Remote needed to implement mutual TLS. This was not the case before Akka.NET v1.5.52.
If you are running Akka.NET inside a private network you fully control or you were never using TLS in the first place, then this bug has no impact on you. However: if you are using TLS to secure your network YOU MUST upgrade to Akka.NET V1.5.52 or later.
Patches
https://github.com/akkadotnet/akka.net/pull/7847 - forces "fail fast" semantics if TLS is enabled but the private key is missing or invalid. Previous versions would only check that once connection attempts occurred. https://github.com/akkadotnet/akka.net/pull/7851 - critical fix: enforces mutual TLS (mTLS) by default, so both parties must be keyed using the same certificate. This fulfills the original security
These updates have been shipped into Akka.NET v1.5.52: https://github.com/akkadotnet/akka.net/releases/tag/1.5.52
Workarounds
If your application isn't exposed publicly, then CVE-2025-61778 has no practical impact on your application. That being said: upgrading to Akka.NET v1.5.52 or later is a good idea.
References
Please view our latest network security documentation here: https://getakka.net/articles/remoting/security.html
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Akka.Remote"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0"
},
{
"fixed": "1.5.52"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Akka.Cluster"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0"
},
{
"fixed": "1.5.52"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-61778"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-07T21:15:44Z",
"nvd_published_at": "2025-10-06T17:16:08Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nThis is a critical network security vulnerability for Akka.Remote **users who have SSL / TLS enabled** on their Akka.Remote connections and were expecting certificate-based authentication to be enforced on all peers attempting to join the network.\n\nIn all versions of Akka.Remote from v1.2.0 to v1.5.51, TLS could be enabled via our `akka.remote.dot-netty.tcp` transport and this would correctly enforce private key validation on the server-side of inbound connections. Akka.Remote, however, never asked the outbound-connecting client to present ITS certificate - therefore it\u0027s possible for untrusted parties to connect to a private key\u0027d Akka.NET cluster and begin communicating with it **without any certificate**. \n\nThe issue here is that for certificate-based authentication to work properly, ensuring that all members of the Akka.Remote network are secured with the same private key, Akka.Remote needed to implement mutual TLS. This was not the case before Akka.NET v1.5.52.\n\nIf you are running Akka.NET inside a private network you fully control or you were never using TLS in the first place, then this bug has no impact on you. However: if you are using TLS to secure your network YOU MUST upgrade to Akka.NET V1.5.52 or later.\n\n### Patches\n\nhttps://github.com/akkadotnet/akka.net/pull/7847 - forces \"fail fast\" semantics if TLS is enabled but the private key is missing or invalid. Previous versions would only check that once connection attempts occurred.\nhttps://github.com/akkadotnet/akka.net/pull/7851 - **critical fix**: enforces mutual TLS (mTLS) by default, so both parties must be keyed using the same certificate. This fulfills the original security \n\nThese updates have been shipped into Akka.NET v1.5.52: https://github.com/akkadotnet/akka.net/releases/tag/1.5.52\n\n### Workarounds\n\nIf your application isn\u0027t exposed publicly, then CVE-2025-61778 has no practical impact on your application. That being said: upgrading to Akka.NET v1.5.52 or later is a good idea.\n\n### References\n\nPlease view our latest network security documentation here: https://getakka.net/articles/remoting/security.html",
"id": "GHSA-jhpv-4q4f-43g5",
"modified": "2025-10-07T21:15:45Z",
"published": "2025-10-07T21:15:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/akkadotnet/akka.net/security/advisories/GHSA-jhpv-4q4f-43g5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61778"
},
{
"type": "WEB",
"url": "https://github.com/akkadotnet/akka.net/pull/7847"
},
{
"type": "WEB",
"url": "https://github.com/akkadotnet/akka.net/pull/7851"
},
{
"type": "WEB",
"url": "https://getakka.net/articles/remoting/security.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/akkadotnet/akka.net"
},
{
"type": "WEB",
"url": "https://github.com/akkadotnet/akka.net/releases/tag/1.5.52"
}
],
"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",
"type": "CVSS_V4"
}
],
"summary": "Akka.Remote TLS did not properly implement certificate-based authentication"
}
GHSA-JJ26-78H6-475H
Vulnerability from github – Published: 2022-05-02 03:21 – Updated: 2024-02-13 18:38The web interface on the snom VoIP phones snom 300, snom 320, snom 360, snom 370, and snom 820 with firmware 6.5 before 6.5.20, 7.1 before 7.1.39, and 7.3 before 7.3.14 allows remote attackers to bypass authentication, and reconfigure the phone or make arbitrary use of the phone, via a (1) http or (2) https request with 127.0.0.1 in the Host header.
{
"affected": [],
"aliases": [
"CVE-2009-1048"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-08-14T15:16:00Z",
"severity": "HIGH"
},
"details": "The web interface on the snom VoIP phones snom 300, snom 320, snom 360, snom 370, and snom 820 with firmware 6.5 before 6.5.20, 7.1 before 7.1.39, and 7.3 before 7.3.14 allows remote attackers to bypass authentication, and reconfigure the phone or make arbitrary use of the phone, via a (1) http or (2) https request with 127.0.0.1 in the Host header.",
"id": "GHSA-jj26-78h6-475h",
"modified": "2024-02-13T18:38:21Z",
"published": "2022-05-02T03:21:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-1048"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/52424"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/36293"
},
{
"type": "WEB",
"url": "http://www.csnc.ch/misc/files/advisories/cve-2009-1048.txt"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/505723/100/0/threaded"
}
],
"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"
}
]
}
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.